1
$\begingroup$

I have been reading around protocol specification and there is either too much technical detail or too bad articles on various sites.

I need you to explain in simple words how encryption in bitmessage works and what are main security flaws of bitmessage and why?

To be more detailed with with my question I want to understand how asymetric encryption works in bitmessage and why there are collisions with addresses? how is private key stored(or not).

an example of ie. Bob and Alice exchanging a message over bitmessage (with encryption details) would be great!

BTW. Can somebody please create "bitmessage" tag...

$\endgroup$
1
$\begingroup$

I'll answer your "detailed questions", I'm sure the "main security issues" will become obvious afterwards.

How does asymmetric encryption work in bitmessage?
The bitmessage wiki explains how the encryption takes place. I'll quickly explain the basics.
For each message, generate a secure 128-bit IV. 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. 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. Encrypt the message using this symmetric encryption scheme and form the HMAC on the ciphertext. The message will be composed of the IV, the public ECDH value, the ciphertext and the MAC.
Decryption is pretty straightforward. 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. If the MAC's invalid discard the message as "not for you".

Why there are collisions with addresses?
The way the public addresses are generated is quite complicated and is documented here. I'm not aware of any collisions, however the collision resistance isn't also at 80 bits. Basically you'll obtain a collision if the RIPEMD160 of the SHA-512 of the two public keys (encrypting, verifying) yields a collision. 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). 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.

How is the private key stored (or not)?
The protocol doesn't describe how the private key is to be stored. However the reference implementation does the following:
The private key is stored keys.dat, without encryption, easily accessible by anyone having access to this file. In case of deterministic addresses it can be reproduced with a passphrase, in case of random addresses it can't be.

As you see, the main security issues with the points you mentioned are, that the keys are stored unprotected and that the uniqueness of addresses relies on the collision resistance of RIPEMD160.

$\endgroup$
  • $\begingroup$ Since somebody creating two public keys with the same address doesn't look like a relevant attack, this only relies on (multi-target) second pre-image resistance, not collision resistance. 160 bits is plenty for that. $\endgroup$ – CodesInChaos Jun 29 '15 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.