{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-01-08\n📝 Original message:On Sun, Jan 7, 2018 at 3:16 PM, Pavol Rusnak via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On 05/01/18 14:58, nullius via bitcoin-dev wrote:\n\u003e I am currently drafting a new standard[1] which will allow also Shamir\n\u003e Secret Scheme Splitting and there we disallow usage of a custom wordlist\n\u003e in order to eradicate this mess. Will try to push this as BIP too once\n\u003e we get it to the point we are OK with the contents.\n\u003e\n\u003e https://github.com/satoshilabs/slips/blob/master/slip-0039.md\n\nThis specification forces the key being used through a one way\nfunction, -- so you cannot take a pre-existing key and encode it with\nthis scheme.  The KDF it specifies is unconfigurable and fairly weak\n(20000xhmac-sha2-- which can be cracked at about 0.7M passwords a\nsecond on a single motherboard GPU cracker).  The construction also\nwill silently result in the user getting a different private key if\nthey enter the wrong passphrase-- which could lead to funds loss. It\nis again, unversioned-- so it kinda of seems like it is intentionally\nconstructed in a way that will prevent interoperable use, since the\nlack of versioning was a primary complaint from other perspective\nusers.  Of course, it fine if you want to make a trezor only thing,\nbut why bother BIPing something that was not intended for\ninteroperability?  Even for a single vendor spec the lack of\nversioning seems to make things harder to support new key-related\nfeatures such as segwit.\n\nThe 16-bit \"checksum\" based on sha2 seems pretty poor since basing\nsmall checksums on a cryptographic hash results in a fairly poor\nchecksum that is surprisingly likely to accept an errored string. Your\nwordlist is 10 bits and you have much less than 1023*10 bits of input,\nso you could easily have a 20 bit code (two words) which guaranteed\nthat up to two errored words would always be detected, and probably\ncould choose one which catches three words much more often 1:2^20\n(sipa's crc tools can help find codes like this).\n\nThe metadata seems to make fairly little affordance to help users\navoid accidentally mixing shares from distinct sharings of the same\nkey. Is it the idea that this is the only likely cause of a checksum\nerror? (1:2^16 chance of silently returning the wrong key seems kinda\nbad). -- I'm not sure much could be done here, though, since\nadditional payload is precious.\n\nAs an aside, your specification might want to give some better advice\nabout the SSS since my experience virtually everyone gets it wrong in\nways that degrade or destroy its properties e.g. many fail to generate\nthe additional coefficients of the polynominal randomly which results\nin insecurity (see armory for an example).   Oh, also, I believe it is\nnormally refereed to as \"SSS\" (three S)-- four S is the name of a\nlinux program for secret sharing.\n\nI'm happy to see that there is no obvious way to abuse this one as a\nbrainwallet scheme!"}