{"type":"rich","version":"1.0","author_name":"npub1wccnjljxnarlx564vuc37hmuzuffurljevjnmuq4u0vjmh7e933sn3hnuq","author_url":"https://nostr.ae/npub1wccnjljxnarlx564vuc37hmuzuffurljevjnmuq4u0vjmh7e933sn3hnuq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-01-08\n📝 Original message:On 08/01/18 05:22, Gregory Maxwell wrote:\n\u003e\u003e https://github.com/satoshilabs/slips/blob/master/slip-0039.md\n\nHey Gregory!\n\nThanks for looking into the scheme. I appreciate your time!\n\n\u003e This specification forces the key being used through a one way\n\u003e function, -- so you cannot take a pre-existing key and encode it with\n\u003e this scheme.\n\nOriginally, we used a bi-directional function to be able to encode and\ndecode the key in both directions using the passphrase. We stretched the\npassphrase using KDF and then applied AES or other symmetric cipher\n\nWe found the following (theoretical) problem:\n\nIf an attacker has knowledge of few words from the beginning of shares,\nthey are able to reconstruct the beginning of the master secret and if\nthe size of the reconstruced master secret is bigger then the cipher\nblocksize (for block ciphers; for stream ciphers 1 bit is enough), then\nthey can reconstruct the beginning of the seed.\n\nCan you find a scheme which does not have this problem? Or you think\nthis problem is not worth solving?\n\n\u003e The KDF it specifies is unconfigurable and fairly weak\n\u003e (20000xhmac-sha2-- which can be cracked at about 0.7M passwords a\n\u003e second on a single motherboard GPU cracker).\n\nYes. We want this to be possible to be computed on TREZOR-like devices\non boot, similarly how we compute BIP39 on boot right now.\n\n\u003e The construction also\n\u003e will silently result in the user getting a different private key if\n\u003e they enter the wrong passphrase-- which could lead to funds loss.\n\nAgain, this is by design and it is main point why plausible deniability\nis achieved both in BIP39 and SLIP39. If we used a different\nconstruction we'd loose plausible deniability.\n\n\u003e It\n\u003e is again, unversioned-- so it kinda of seems like it is intentionally\n\u003e constructed in a way that will prevent interoperable use, since the\n\u003e lack of versioning was a primary complaint from other perspective\n\u003e users.  Of course, it fine if you want to make a trezor only thing,\n\u003e but why bother BIPing something that was not intended for\n\u003e interoperability?  Even for a single vendor spec the lack of\n\u003e versioning seems to make things harder to support new key-related\n\u003e features such as segwit.\n\nThis is argument I keep having all the time.\n\nSuppose we'd introduce a version to encode PBKDF2 rounds or even\ndifferent KDFs. We'll end up with different SLIP39 mnemonics, but they\nwill not be compatible among implementations (because TREZOR can only up\nto 100.000 rounds of PBKDF2 and does not support Argon2 at all, while\nother desktop implementation would rather use memory-hard Argon2).\n\nMy gut feeling is that this would lead to WORSE interoperability, not\nbetter. Look at BIP32 for example. There are lots of wallet that claim\nthey are BIP32 compatible, but in reality they use different paths, so\nthey are not compatible. BIP32 is a good standard, but in reality\n\"BIP32-compatible\" does not mean anything, whereas when you say the\nwallet is \"BIP44-compatible\" you can be sure the migration path works.\n\n\u003e The 16-bit \"checksum\" based on sha2 seems pretty poor since basing\n\u003e small checksums on a cryptographic hash results in a fairly poor\n\u003e checksum that is surprisingly likely to accept an errored string. Your\n\u003e wordlist is 10 bits and you have much less than 1023*10 bits of input,\n\u003e so you could easily have a 20 bit code (two words) which guaranteed\n\u003e that up to two errored words would always be detected, and probably\n\u003e could choose one which catches three words much more often 1:2^20\n\u003e (sipa's crc tools can help find codes like this).\n\nOriginally, we wanted to use 16-bit of CRC32 for checksum, but after the\ndiscussion with Daan Sprenkels we were suggested to change this for\ncryptographically strong function. The argument was that CRC32 contains\nless entropy and mixing high-entropy data (secret) with low-entropy data\n(checksum) is not a good idea.\n\nAlso, there is an argument between a checksum and ECC. We discussed that\nECC might not be a good idea, because it helps the attacker to compute\nmissing information, while we only want to check for integrity. Also the\nword mnemonic is itself a ECC, because if you see the word \"acadornic\"\nit is probably the word \"academic\".\n\n\u003e The metadata seems to make fairly little affordance to help users\n\u003e avoid accidentally mixing shares from distinct sharings of the same\n\u003e key. Is it the idea that this is the only likely cause of a checksum\n\u003e error? (1:2^16 chance of silently returning the wrong key seems kinda\n\u003e bad). -- I'm not sure much could be done here, though, since\n\u003e additional payload is precious.\n\nYes, checksum is supposed to prevent that.\n\n\u003e As an aside, your specification might want to give some better advice\n\u003e about the SSS since my experience virtually everyone gets it wrong in\n\u003e ways that degrade or destroy its properties e.g. many fail to generate\n\u003e the additional coefficients of the polynominal randomly which results\n\u003e in insecurity (see armory for an example).   Oh, also, I believe it is\n\u003e normally refereed to as \"SSS\" (three S)-- four S is the name of a\n\u003e linux program for secret sharing.\n\nWill fix the spelling. About the generic advice about SSS, anyone is\nwelcome to contribute to the text.\n\n\u003e I'm happy to see that there is no obvious way to abuse this one as a\n\u003e brainwallet scheme!\n\nAgreed!\n\n-- \nBest Regards / S pozdravom,\n\nPavol \"stick\" Rusnak\nCTO, SatoshiLabs"}