Published on: 2014-10-22T14:56:37+00:00
On September 23, 2014, Mem Wallet raised a question about the use of deterministic nonces for ECIES and the potential consequences. The recipient of the email responded by stating that while using deterministic nonces for signatures is acceptable, they should not be used for ECIES unless they are high-quality random bytes. Unit test vectors were mentioned as a possible exception to this rule.In a separate email conversation on October 22, 2014, Chris D'Costa expressed concerns about ensuring that the public key received for encrypting a message is not from a Man-In-The-Middle (MITM) attacker. Pavol Rusnak asked if this was the same problem with PGP.In another email exchange on September 23, 2014, Mem Wallet and Pavol Rusnak discussed a proposed change to BIP44 to include identity keys for structured wallets. Mem Wallet suggested creating a new BIP to describe the HD paths used for ECIES, referring to a working implementation available at http://memwallet.info/btcmssgs.html. Pavol Rusnak agreed that the implementation seemed complete and proposed pushing it as a new BIP for review and standardization.The provided context mentions a proposal for a standardized ECIES scheme for Bitcoin communication, which also includes a proposed change to BIP44. The scheme allows for secure messaging using a Bitcoin wallet without requiring additional software. It enables address owners to prove ownership privately to other address holders without the need for secure communication channels.The scheme described in the document uses CompactSize format for serialization and assumes familiarity with the Bitcoin compact signature format. The sender's address is included for signature validation. The scheme employs HMAC_SHA256 for MAC and PBKDF2 for KDF, with specific iterations and salt values. AES with 256-bit keys and CFB mode with a 128-bit feedback buffer are used for encryption. No padding or envelope is used.The compact_signed_message and compact_unsigned_message formats are explained, along with the inputs for the SendMessage and ReceiveMessage functions. Test vectors are provided in different formats, including WIF, base58_check, C-style UTF-8 string literals, and Base64.It is mentioned that compliant implementations should use random nonces from a cryptographically strong DRBG. The context includes a cryptographic address and a signing address, and the implementation can be found on memwallet.info/btcmssgs.html. The credit for the implementation goes to 76NPRHE2g5pSvbLgP8fEEtBvfPB4zte56veXdxXfaXcsQwRjZB (1Lk96ASyr3k6ZoTFGLrUgxGuctNKF24V5q), with acknowledgments to bitaddress.org, brainwallet.org, and other contributors who have simplified cryptocurrency and Bitcoin coding in JavaScript.
Updated on: 2023-08-01T10:20:13.759645+00:00