📅 Original date posted:2014-04-07
📝 Original message:>
> I'd be fine with changing the key fingerprint algorithm to something else. Do you like CRC16?
>
I like CRC16. Do you intend to use it in conjunction with a cryptographic hash?
Regarding the choice of fields, any implementation of this BIP will
need big integer arithmetic to do base-58 anyway. The operations
required for SSS are nearly the same as for base-58 and can probably
be done by the same subset of the chosen bignum library. So in fact
using GF(2^8) will add complexity to both the BIP and its
implementations. However, the maths in GF(2^8) is so simple that this
additional complexity can be considered negligible.
As a co-author of a bitcoin application running on a real
microcontroller (not the sort of big-iron thing Trezor runs on), I was
also going to implement my SSS over a 256-bit prime field. (I am not
going into 512-bit master seeds at this time.)
Uniform processing of secrets of any size (instead of using different
primes for different cases) is a valid argument in favour of GF(2^8),
though. I have no preference one way or another.
Nikita Schmidt [ARCHIVE] /
npub1ae…u7ctd
2023-06-07 17:17:09
in reply to nevent1q…ws8r
Author Public Key
npub1aeetueshkcgcx4x7uze7qteaq85d9d4c8kzrwxqmxq2rjnl5drmssu7ctdPublished at
2023-06-07 17:17:09Event JSON
{
"id": "d84d08ee092b247080bb2acbdc3c0ac25e6e4687835cc6399c3f4586b7e476f3",
"pubkey": "ee72be6617b6118354dee0b3e02f3d01e8d2b6b83d8437181b3014394ff468f7",
"created_at": 1686151029,
"kind": 1,
"tags": [
[
"e",
"ec3db7ea61043d2181c683590cc6472afc1e727a155c1437be680d2ee4f9939c",
"",
"root"
],
[
"e",
"d51e222c8443c7a49dc0e880f32779aa451c602cfdd70acaad6dff6ef7079bc6",
"",
"reply"
],
[
"p",
"f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91"
]
],
"content": "📅 Original date posted:2014-04-07\n📝 Original message:\u003e\n\u003e I'd be fine with changing the key fingerprint algorithm to something else. Do you like CRC16?\n\u003e\nI like CRC16. Do you intend to use it in conjunction with a cryptographic hash?\n\nRegarding the choice of fields, any implementation of this BIP will\nneed big integer arithmetic to do base-58 anyway. The operations\nrequired for SSS are nearly the same as for base-58 and can probably\nbe done by the same subset of the chosen bignum library. So in fact\nusing GF(2^8) will add complexity to both the BIP and its\nimplementations. However, the maths in GF(2^8) is so simple that this\nadditional complexity can be considered negligible.\n\nAs a co-author of a bitcoin application running on a real\nmicrocontroller (not the sort of big-iron thing Trezor runs on), I was\nalso going to implement my SSS over a 256-bit prime field. (I am not\ngoing into 512-bit master seeds at this time.)\n\nUniform processing of secrets of any size (instead of using different\nprimes for different cases) is a valid argument in favour of GF(2^8),\nthough. I have no preference one way or another.",
"sig": "66f70eec9122ab5e87b24251760bf52a7d0d08826e95458409f54cdd1d940cd2d5c482e27c7b2f9b6eea951113891df123be0a5bc54d8a32d9fd302716259ff2"
}