However the reference implementation does the following: The protocol doesn't describe how the private key is to be stored. Furthermore the addresses have to live in the same stream (at the moment there's only one) and they have to share the address version. Now the odds of finding a collision are even a bit lower than the birthday bound of RIPEMD160 (80 bits) as the hash has to start with a zero (or more zeroes). Basically you'll obtain a collision if the RIPEMD160 of the SHA-512 of the two public keys (encrypting, verifying) yields a collision. I'm not aware of any collisions, however the collision resistance isn't also at 80 bits. The way the public addresses are generated is quite complicated and is documented here. If the MAC's invalid discard the message as "not for you".
Bitmessage mac mac#
Derive the shared key using the provided public ECDH value and your private key, derive the authentication key, check the MAC is correct and decipher the message. The message will be composed of the IV, the public ECDH value, the ciphertext and the MAC.ĭecryption is pretty straightforward.
Encrypt the message using this symmetric encryption scheme and form the HMAC on the ciphertext. Hash the shared secret (using SHA-512) and use the first 256-bit as key for HMAC-SHA-256 and the second 256-bit as the key for AES-CBC with PKCS#7 padding. Generate a new message key by generating a new ECDH key pair and "agree" on a shared key with the recipient's (=Bob) public key.
I'll quickly explain the basics.įor each message, generate a secure 128-bit IV. The bitmessage wiki explains how the encryption takes place. How does asymmetric encryption work in bitmessage? I'll answer your "detailed questions", I'm sure the "main security issues" will become obvious afterwards.
0 kommentar(er)
