Cryptographic details

To see a short tutorial on public keys read this tutorial.

Both parties that send and receive emails need that EndCryptor is installed on users' computers in order to encrypt and decrypt. There is no need to place any code on user's email servers.

The encrypted email is a file that can be delivered by any means available from the sender to the receiver. Typically this is done via the users' email systems.  EndCryptor uses email standard's IMAP commands to receive the file that is an attachment in an ordinary email.  Same email account can be used for ordinary unencrypted email and for encrypted email.

The solution is a true decentralized end-to-end encryption solution. Users can change their email addresses and email service providers and the encryption still works - of course contacts must be informed of the change of an email address. Thus there is no central server of Enternet Oy for all users which is needed for email delivery (which could be attacked by hostile parties, nor is there any javascript code that is delivered to users by a central server when using the product, nor is there any server that stores the private keys of users' public keys). This approach also means that Enternet Oy cannot be fooled/forced to deliver hostile code to specific users and that Enternet Oy is not able to decrypt or monitor the email traffic of users.

When encrypting/decrypting the stored information on the EndCryptor's security database on the user's computer is used together with the information that the message in question provides. The security database is encrypted wit ChaCha20, key size is 256 bits. User’s entry password to the security database is hashed using salted password hashing pbkdf2 with hmac sha256 using 10000 iterations.

The implementation of symmetric encryption and classical and quantum attack resistant public keys uses publicly available source code developed by the scientists who designed the systems. Public key technology: classical: Curve25519, quantum attack resistant: Kyber-1024, FrodoKEM-1344 and mceliece6688128f (round 4). Kyber is an official standard of USA, the variants of Frodokem and Mceliece are recommended by Germany's Federal Office for Information Security, see BSI TR-02102-1. The public keys are used in a hybrid setup - this means that an adversary must be able to break all of them. Hybrid setup is used because quantum attack resistant technology is relatively new. The hybrid key setup is done according to the 'Concatenate hybrid key agreement scheme' of ETSI TS 103 744 V1.1.1 (ETSI is a European Standards Organization (ESO). .. the recognized regional standards body dealing with telecommunications, broadcasting and other electronic communications networks and services.)

The implementation of the Ed25519, Curve25519, and Chacha20 is the reference source code implementation available from SUPERCOP benchmark suite and NaCl crypto library (European Network of Excellence in Cryptology II projects funded by European Commission). These primitives are designed to give protection against side channel attacks like cache timing attacks. The implementation of Kyber is from Githup: pq-crystals/kyber, also FrodoKEM-1344 is from GitHup: PQCrypto-LWEKE. The code for mceliece6688128f is from the round-4 NISTPQC submission package. Dilithium code is from GitHup: pq-crystals/dilithium.

A public key packet in EndCryptor (version 2.5.5.67 and later) uses a version of Frodokem that is recommended when there are many ciphertexts to a public key (the version that was submitted for ISO standardization), later ephemeral one-time Frodokem keys are used (eFrodoKEM keys) when parties exchange more emails.

Signatures are classical Edwards curve (Ed25519) signatures and CRYSTALS-Dilithium3 signatures. NIST of USA recommends CRYSTALS-Dilithium as the primary algorithm for signatures. Only the first messages use signatures, later ones are authenticated using Keccak (SHA3-256) macs that use keys derived from a shared secret. Signatures and macs are calculated over sha2-512 hash of encrypted data.

The private keys of public keys are made using BCryptGenRandom system call and private keys of classical elliptic keys are made by a Goldreich-Levin hard-core bit generator. The seed to the generator consists of events like mouse movements and their timings and bytes provided by the BCryptGenRandom system call.

Protocol outline:
This is a stateful protocol. For each contact there is a state for sending and a state for receiving. When encrypting and decrypting the corresponding state is consulted. Keccak algorithm shake256 is used to form a new state and encryption/decryption keys for current message. Upon sending user periodically creates new contact-specific one-time public keys, these public keys are inserted into the outgoing message. When sending a message, a received public key is used once to generate a shared secret (either by creating a classical Curve25519 public key or post quantum KEM ciphertext), the outgoing message will have these public elements so that the receiver can calculate the same shared secrets.

In the following the Sender is going to send a message to the Receiver:

If the Sender has not received a message from the Receiver before, then the Sender must somehow get a public key packet from the intended Receiver. The packet contains Receiver's Curve25519, Kyber and Frodokem public keys as well as Receiver's Ed255119 and Dilithium3 keys, which the Sender can use to verify signature when he receives from the Receiver.

If the Sender has not received KEM calculated ciphertexts against his last sent public keys: If the Sender deduces that the Receiver may not have received his last sent public keys the Sender inserts them into the message.

If the Sender has received KEM calculated ciphertexts against his last sent public keys: If two weeks has passed since the last new Curve25519, Kyber and Frodokem public key generation then those keys are generated and inserted into the message. Every fourth package of new public keys also contains a new mceliece public key. A group send can contain only 1 mceliece public key (due to its 1MB size).

If the Sender has available received public keys from the Receiver: Shared secrets are created and a new curve25519 and required KEM ciphertexts are created. Let State be sender's current state for sending and Shs the calculated hybrid shared secret. Let X be a 96 bytes shake256 result calculated over shared secret Shs and State. The first 32 bytes of X are the new state for sending and next 32 byte blocks are the encryption and mac keys for the message to send. The hybrid key setup is done according to the 'Concatenate hybrid key agreement scheme' of ETSI TS 103 744 V1.1.1. The used received public keys are deleted.

If the Sender has no public keys available from the Receiver: Let X be a 96 bytes shake256 result calculated over the State. The first 32 bytes of X are the new state for sending and next 32 byte blocks are the encryption and mac keys for the message to send.

The message is signed if no messages have been received from the message’s Receiver otherwise there are only macs.

When receiving a message there are two macs that are calculated. The one that is checked first uses a previously calculated key stored into Receivers database, the second mac checking uses the key that is the outcome of a state's processing. Let Y be a 32 byte shared secret obtained from hybrid key shared secret calculation (different than the Shs above) during send. The Sender stores this to be used as the first mac key when calculating the first mac to check incoming message. The parties communicating can deduce the proper key to fetch from the database based on its numbering. Note that this Y value is calculated only when there is a shared secret available. The second mac key is calculated during every encryption/decryption calculation and is the last 32 byte block of X.

Description of encryption of storage files

When an encrypted email is sent or received it is encrypted  again for storage on user’s computer (using different encryption keys than those in the email that is traversing the internet). Each storage file is encrypted using different ChaCha20 256 bit key.

When EndCryptor is started the first time it saves a Personal Export key file and the user is asked to create that file’s password. These items can be used to decrypt and export user’s emails from backup media. The Personal Export key is a symmetric Chacha20 256 bit key.

Additionally a Company Export Key can be used. Such public key is company issued and user installed mceliece6688128f public key.

An encrypted storage file has a field F which stores in encrypted form the file’s actual encryption key so that the file can be decrypted and exported by personal Export Key from backup media.

If the company public key is used to encrypt backups then
the KEM calculated ciphertext (208 bytes) is stored into the backed up file together with field F' which contains the actual encryption key encrypted with the key that is protected by the KEM ciphertext.

Date page changed: March 27, 2024, clarification of how signatures and macs are calculated.

"Powered by Curve25519" , "Powered by ChaCha20", "Powered by Ed25519"