Bitmessage file size limit plus#

1) Curve25519 is not supported by pyelliptic and we do not roll our own crypto, 2) secp256k1’s faults on the SafeCurves website do not concern us nor does the origin of the base point G, and 3) the Bitcoin project is a multi-billion dollar incentive to research, discover, and exploit any vulnerabilities in ECC and secp256k1. The peanut gallery might wonder why we use secp256k1 instead of Curve25519.

Your keys are encoded in Wallet-Import-Format and saved in the keys.dat file.

This is encoded using base58, and “CH-” is prepended onto the front to differentiate it from Bitmessage and Bitcoin addresses.

A version number (currently 1) is prepended to the front of the RIPE data and a checksum is appended to the end.

The public signing key and the public encryption key are together hashed using SHA512 and then RIPEMD160.

A pair of ECC point multiplications on the secp256k1 curve are done to turn the private keys into public keys.This hash constitutes our ECC private encryption key. The nonce is then incremented and we double-hash again.The first 32 bytes of this hash constitutes our ECC private signing key.The import key and nonce are then hashed twice with SHA512.This import key is then appended with a nonce.It uses a hard-coded salt, 4096 iterations, and SHA512. PBKDF2 is used to “stretch” the import key.This import key can be viewed in the HighSide UI. These 14 words are saved as the “import key”.

Bitmessage file size limit plus#

These 146 bits, plus 8 bits to use as flags, are used to select 14 words from the word list.Using Python’s os.urandom module, 146 bits of random data is generated.The first half is almost exactly what is done with modern Bitcoin wallets the second half is what is done in Bitmessage. To generate your encryption keys and your address, this process is used. Key authentication is taken care of by an admin in your team if users trust the admin then they do not need to all verify each other’s keys.

Sending files works similarly except that files are split, compressed, encrypted, and sent in pieces to speed things up. Each receiving client checks the signature, finds their header, decrypts the AESEphemKey using their private key, and then decrypts the main ciphertext using this AESEphemKey. The whole thing is signed using ECDSA-SHA256, and then the information is sent to the server and relayed to the receiving clients. Then, for every participant who must receive the message, the AESEphemKey is encrypted with the participant’s 512 bit secp256k1 elliptic curve public key and that encrypted AESEphemKey is added to the top of the ciphertext as a header. TL DR Each message is encrypted then HMAC’d with a randomly generated unique 256 bit key using AES-CTR, hereafter the “AESEphemKey”. You do not need to read or understand any of this to use HighSide correctly unless you are the admin for your team in which case you might choose to just read the section on authentication. This is a technical overview of how HighSide’s encrypted messaging & file sharing works for those who are interested in specifics.