Published on: 2014-08-10T01:20:09+00:00
The email conversation revolves around a proposed change in the bitcoin specification, specifically regarding the security concerns associated with this change. The change involves assigning I_L := I_L mod n when I_L >= n, which is deemed less secure due to its potential impact on the selection of private keys and the elimination of provable security equal to random keys.One major concern raised is the incompatibility between the proposed change and existing implementations of the specification. This incompatibility could lead users to mistakenly believe that their keys are worthless or result in the loss of funds when they are unable to spend them. It is also highlighted that other parties who have invested time and effort into producing correct and compatible implementations would be inconvenienced by this change.Furthermore, the proposed change would create an uneven distribution of private keys, which is considered objectively less secure. This imbalance could pose a significant vulnerability if an incorrect implementation reflects a large group of keys to a small number of values.The email emphasizes the importance of handling corner cases in cryptographic software. Examples of such corner cases include dealing with point at infinity cases, zero-value signatures (which could potentially leak the private key), and adding colinear points. While it is acknowledged that some implementations may not currently check for these cases, it is stressed that addressing them is crucial for ensuring the overall security of the system.It is noted that the bignum modulo operation required for the proposed change may present complexities and potential layering issues. Therefore, it may not be readily available for implementation.The email concludes by suggesting that individuals who are unprepared to handle these complications should refrain from writing this type of software and leave it to those who are better equipped to address the security concerns effectively.In addition to the discussion surrounding the proposed change, the email also mentions a separate post by another author proposing a modification to the BIP32 protocol regarding invalidation of nodes. The current protocol suggests proceeding with the next value for i if a resulting key is invalid. However, the author suggests changing this to assigning I_L := I_L mod n in all three cases of public CKD, private CKD, and master key generation. This change aims to simplify the implementation of skipping logic when marking a key as invalid and potentially encourage more implementations to check for invalid keys.The author acknowledges that there are still scenarios where a key may be invalid, such as when I_L = 0 or ki = 0 or ki = inf. However, these situations are considered to have a low probability of occurring. The author seeks input from others regarding any security concerns related to this proposed change.
Updated on: 2023-08-01T10:13:13.598052+00:00