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.
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.
Encryption keys are determined using public key technology (classical: Curve25519, quantum attack resistant: FrodoKEM-1344 (2022-11-29) and mceliece6688128f (round 4)). Note that these variants of Frodokem and Mceliece are recommended by Germany's Federal Office for Information Security, see BSI TR-02102-1. 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.)
Signatures are classical Edwards curve (Ed25519) signatures and CRYSTALS-Dilithium3 (2022-05-09) 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 macs that use keys derived from a shared secret.
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 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 .
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.
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 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 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 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. Macs are calculated over encrypted data.
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.
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: April 18, 2023."Powered by Curve25519" , "Powered by ChaCha20", "Powered by Ed25519"