![]() ![]() The client's name is often shortened to just Bitmessage but is mentioned here to distinguish it from the Bitmessage protocol itself. Messages are transferred over a P2P network through users running the Bitmessage client PyBitmessage. This address is in fact a hash of a public key, and as such, it's much harder for a scammer to assume your identity by sending an email supposedly from your address. Users can exchange messages, as well as subscribe to news lists (Subscriptions) and discussion channels (Chans).Īs with Bitcoin, which works on the basis of "wallet addresses" to receive money, you only need to provide one of your Bitmessage addresses to a fellow user to communicate. Bitmessage users can have one or a number of these addresses ( Figure 1).įigure 1: PyBitmessage, the official Bitmessage client in action. As an average Linux user, it's sufficient to know that each user is assigned a virtual "address" (e.g., BM-2cSpVFB6cDxLLGUeLR圓pZTwYsujmpRzP7) that can be used to send and receive messages. ĭeveloper Jonathan Warren's official whitepaper on Bitmessage goes into considerable detail on how this is achieved. In simplest terms Bitmessage works as a vast e-mail server, albeit one that is not controlled from any one central point. Instead of using a blockchain to record transactions, however, Bitmessage uses complex mathematics to validate and encrypt messages. Like Bitcoin, Bitmessage uses a decentralized peer-to-peer (P2P) protocol. Nor is it very easy to steal coins from another user's digital wallet without their digital private key. Since transactions are confirmed several times, it is highly unfeasible for anyone to forge an entry in the blockchain to give themselves a digital wagonload of Bitcoins. How does asymmetric encryption work in bitmessage? I'll answer your "detailed questions", I'm sure the "main security issues" will become obvious afterwards.Users of the pseudonymous cryptocurrency Bitcoin will know that its strength lies in a blockchain – a decentralized ledger of transactions shared across thousands of computers. The bitmessage wiki explains how the encryption takes place. ![]() I'll quickly explain the basics.įor 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.ĭecryption is pretty straightforward. #Bitmessage echo server mac#ĭerive 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". 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).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |