Re: [Bitcoin-development] BIP32 - invalidation
Does bitcoin properly handle the case of a hash collision? no - because it is considered too unlikely. The case of I_L >= n is also astronomically unlikely, so it's more a matter of improved performance and simpler data structures under expected circumstances and taking that less than 1 in 2^127 chance that it will fail, in which case we can recover by moving everything over to a new tree. -Eric Lombrozo On Aug 9, 2014, at 5:34 PM, second isogeny wrote: > > Does anyone see any concerns when it comes to security of the proposed > > change? > > Yes. This proposal is less secure. > > It is incompatible in theory with existing implementations of the > specification. The incompatibility is also a potentially a security > problem because it may cause users to believe a key is worthless when > it is not or to lose funds when they are unable to spend them. > > It is also an untimely proposal and would be inconsiderate other parties > who have done the work to produce correct and compatible implementations. > > > In case I_L >= n assign I_L := I_L mod n. > > This will make the selection of private keys uneven. > > The unevenness is small and it is unlikely to very matter much but it > is objectively less secure. Future advances in cryptography may make > the distinction more important. The change would eliminate any hope of > the specification ever having provable security equal to random keys. > > The bignum modulo operation also requires complex additional logic and is > just as likely to remain untested in implementations, though unit-testing > can test these cases by replacing the hash function. > > Because of layering no suitable modulo may be available and an incorrect > implementation could create a devastating weakness, like reflecting a > large class of keys to a small number of values. A similar error would > be unlikely for an incorrect implementation of skipping and someone who > managed to still fail would likely have failed either way. > > > most of the implementations don't do the checking at all, because tjen > > it's rather hard at application level to implement skipping logic. OTOH > > There are many corner cases which must be handled in cryptographic > software. > > You must handle the point at infinity cases, you must handle the signature > having a value of zero (or you leak the private key), in the point > arithemetics you must handle the special case of adding colinear points. > > If someone is unprepared to deal with these and many other complications > they may want to leave writing this kind of software for other people. > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP32 - invalidation
> Does anyone see any concerns when it comes to security of the proposed > change? Yes. This proposal is less secure. It is incompatible in theory with existing implementations of the specification. The incompatibility is also a potentially a security problem because it may cause users to believe a key is worthless when it is not or to lose funds when they are unable to spend them. It is also an untimely proposal and would be inconsiderate other parties who have done the work to produce correct and compatible implementations. > In case I_L >= n assign I_L := I_L mod n. This will make the selection of private keys uneven. The unevenness is small and it is unlikely to very matter much but it is objectively less secure. Future advances in cryptography may make the distinction more important. The change would eliminate any hope of the specification ever having provable security equal to random keys. The bignum modulo operation also requires complex additional logic and is just as likely to remain untested in implementations, though unit-testing can test these cases by replacing the hash function. Because of layering no suitable modulo may be available and an incorrect implementation could create a devastating weakness, like reflecting a large class of keys to a small number of values. A similar error would be unlikely for an incorrect implementation of skipping and someone who managed to still fail would likely have failed either way. > most of the implementations don't do the checking at all, because tjen > it's rather hard at application level to implement skipping logic. OTOH There are many corner cases which must be handled in cryptographic software. You must handle the point at infinity cases, you must handle the signature having a value of zero (or you leak the private key), in the point arithemetics you must handle the special case of adding colinear points. If someone is unprepared to deal with these and many other complications they may want to leave writing this kind of software for other people. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP32 - invalidation
Hi all! I would like to discuss invalidation of nodes in BIP32. Currently the document says: a) Public CKD In case I_L >= n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i. b) Private CKD In case I_L >= n or Ki is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i. c) Master Key Generation In case IL is 0 or I_L >= n, the master key is invalid. (All these cases have probability lower than 1 in 2^127.) What do you think about the following change for all 3 cases: In case I_L >= n assign I_L := I_L mod n. Rationale: It's easy to say "mark as invalid and proceed with next", but actually most of the implementations don't do the checking at all, because tjen it's rather hard at application level to implement skipping logic. OTOH it's quite straightforward to perform modulo if needed, so we probably see more implementations doing the checking. We would still need to deal with cases when I_L = 0 or ki = 0 or ki = inf, but these have probability around 1 in 2^255. Does anyone see any concerns when it comes to security of the proposed change? -- Best Regards / S pozdravom, Pavol Rusnak -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
