EndCryptor's cryptographic technical 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.

When a new contact is being added then its long term public key can be fetched from the Web Directory if wanted - this public key is signed by a signature chain that the program code trusts.

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, some parts with AES, others with 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.

Used classical elliptic curves in emails are the Edwards curve Ed25519 and the corresponding Curve25519. The Edwards curve is used for signing and the Curve25519 for Diffie-Hellman calculation. The classical security of Curve25519 is 128 bits.

Quantum attack resistant public keys are supersingular isogeny SIDH (p751) 2.0 and 3.0 keys designed by Microsoft. The classical security of a SIDH key is 192 bits. In scientific papers authors of SIDH (p751) construction state that its quantum security is 128 bits, in NIST’s Post-Quantum Cryptography project they classify it as "matching the post-quantum security of AES192" - this refers to NIST's Quantum Security Strength Categories III. Read more about cryptographical strength.

Compare classical cryptographical strengths:

Symmetric | Elliptic | DH or RSA |

80 | 163-223 | 1024 |

112 | 224-255 | 2048 |

128 | 256-383 | 3072 |

192 | 384-511 | 7680 |

256 | 512+ | 15360 |

The classical security of curve25519 is 128 bits and matches that of a 3072 bit RSA/Diffie-Hellman public key. Note that the classical security of 192 symmetric bits corresponds to 7680 DH or RSA public key bits. The reader should note that usually cryptographic construction’s security is expressed as the security of its weakest link – this is usually the public key.

This table appears in NIST Special Publication 800-57 from
July 2012 titled
'Recommendation for Key Management – Part 1: General(Revision 3)'. NIST
means
National Institute of Standards and Technology (USA).

If the parties communicate in turns then the first email’s classical security is 128 bits, after that the classical security is 192 bits. The quantum protection starts from the second email (included). The patented protocol starts after the second email has been received.

The implementation of the Ed25519, Curve25519, Chacha20 and Poly1305 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 the SIDH 2.0 and 3.0 public keys is from GitHup: PQCrypto-SIDH. The code is also constant time code.

The signatures in encrypted messages use Keccak-256 which is constructed according to the specification that won the SHA3 competition (bitrate is 1088 and capacity is 512).

The private keys of public keys are made using 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.

The first messages encrypted using long term public keys consist of classical part and SIDH part. The SIDH part is appended to the end of the classical part. If the parties communicate in turns there are 2 messages of this kind.

EndCryptor’s security properties rely on the protocol that needs to be initialized with 2 short term (ephemeral) classical public keys created at the time of the contact creation. These key are included as an encrypted part of the first exchanged emails’ classical part.

The first emails’ SIDH part contains SIDH 2.0 or 3.0 quantum attack resistant public keys. After the initial exchange the SIDH keys are version 3 keys if both parties have at least version 2.5.4.62. The SIDH keys are later exchanged at intervals of 7 days if parties communicate frequently.

The encryption of a first message to a receiver’s long term public key consists of creating an ephemeral Ed25519 public key which is used to calculate a shared secret with receiver’s long term public key. Additional ephemeral Ed25519 public key is created and put into that part of the classical part that will be encrypted. The whole classical part is signed with sender’s long term classical public key. That part of the message which is encrypted includes the signature at the end of the classical part. The hashed value of shared secret is used as an encryption key for ChaCha20, key size is 256. The last SIDH part of the message contains newly created SIDH keys and a signature of the whole message signed with sender’s long term classical public key.

When the above message has been received and a first message to its sender is sent the sender creates an ephemeral Ed25519 public key and new SIDH keys and calculates a shared secret with that Ed25519 key that was inside the received encrypted message.

The actual encryption/decryption key of the second message is calculated by computing a Keccak hash value over a value derived from the classical shared secret and the SIDH shared secret i.e key=hash(A || B) where || is the concatenation operation, A is the hash of classical shared secret and B is derived from the SIDH shared secret. In more detail: the SIDH shared secret is 192 or 188 (version 3.0) bytes long, it is Sha3-512 hashed. The first 32 bytes of the result are used in this encryption/decryption key computation as value B.

An above described message contains 4 latest classical public keys of its sender. An older one signs the next newer one.

After the exhange of initial messages the protocol is initialized. Then a shared secret is calculated with each pair of exchanged protocol initialization classical public keys i.e. two shared secrets are calculated. They are concatenated and a Keccak hash is calculated over the above mentioned two classical shared secrets and a value derived from the SIDH shared secret i.e initialization value=hash(A1 || A2 || B), where A1 and A2 are classical shared secrets and B is derived from the SIDH shared secret. The result is to be used as initialization value to form protocol’s initial states. The reader should note that an attacker has to find out every calculated shared secret to find out the resulting Keccak hash value. In more detail: the SIDH shared secret is 192 or 188 (version 3.0) bytes long, it is Sha3-512 hashed. The last 32 bytes of the result are used in this initialization value computation as value B.

The rest of the discussion below considers the situation when the initialization set of public keys has been received by both participants and the protocol is working. The idea of the protocol is to continuously exchange new classical and post quantum public keys to enable fast recovery from hacking attack. The protocol also protects old emails so that they cannot be decrypted by the attacker if they have been previously decrypted by the true receiver.

An encrypted message is signed by a previously delivered classical public key that the receiver is known to have – these public keys in messages are delivered to the receiver in encrypted form; they are encrypted together with the plaintext. The signature is encrypted and the message ends also with a Keccak mac, also the ephemeral public key in the message is encrypted (the encryption key for the ephemeral key and the signature and the key for the Keccak mac is either derived from the initial shared secret or is a hash of a public key that was delivered in encrypted form). A reader may ask why there are two authentication methods: signature and mac. The signature is useful if one of the parties is hacked: an attacker cannot impersonate the unhacked party based on information obtained from the hacked party. The Keccak mac is checked first, then the signature. Note that a message is accepted as original only if the plaintext’s authentication code evaluates correctly – see the end of this chapter. Why the additional encryption of the ephemeral public key and the signature? Why not? The less information is given to an observer the better. When EndCryptor was initially released these values were not encrypted – later it was realized that it can be done without affecting the protocol and that there was a value available that could be used as encryption key. One can also argue that a quantum computer cannot break a symmetrically encrypted classical public key.

Encryption of the messages is done using 256 bit key sized ChaCha20.

The plaintext ends with an authentication code, the
authenticator is Poly1305 one time authenticator. During encryption
both the plaintext and the authentication code are encrypted. After the
decryption the authentication code is calculated over the plaintext and
checked.

An outline of the methods used:

Backward security: Every EndCryptor message is encrypted with different symmetric 256-bit key and after the message has been decrypted there is no information in the security database from which the decryption keys could be deduced again. A message can thus be decrypted only once.

Recovery from attack: Every message EndCryptor encrypts contains new classical public keys of the sender that are specific to the receiver; these public keys are created at the time of sending - when the receiver decrypts the message the security is restored. These classical public keys are delivered in encrypted form; they are encrypted together with the plaintext. Quantum attack resistant public keys are also delivered in encrypted form but more seldom – if the parties communicate regularly the exchange happens at 7 day intervals.

Identity hijacking will be revealed even under spying
attack:

The stored security data that is used to build a
symmetric key changes
after every decryption
and depends on the just decrypted message.

The protocol is a stateful protocol. It means that two states are maintained for each contact: one for sending and one for receiving. A new state and the needed symmetric keys for encryption/decryption and plaintext’s mac calculation are constructed from the current state and a calculated Diffie-Hellman (DH) shared secret whenever sending or receiving happens. The calculation of a new state and the symmetric keys is irreversible i.e. one-way and done using a Goldreich-Levin hard-core pseudo random bit generator (PRG):

PRG(state, DH shared secret) -> list of bits.

From the generated list of bits a new state and the needed symmetric keys are separated. The generated bits pass the next-bit test – it is infeasible to predict bit i+1 if the first i bits are known. The irreversibility of the construction and the next bit property cause the backward security property of the protocol. The recovery property is caused by using new public keys in messages – which affect the DH shared secret parameter of the PRG.

The produced new state and the symmetric keys from the construction:

PRG(state, DH shared secret) -> new state and symmetric keys

will
be unknown to the attacker if the attacker knows only one but not both
parameters of the PRG. The state consists of more than 256 bits and it
is stored in encrypted form on user’s computer.

If there
is available a quantum attack resistant DH result then the actual DH
shared secret used in above and below formulas is a Sha3-256 hash over
the classical and quantum attack resistant DH shared secrets.

If
the attacker has accessed user’s computer and has found out all data on
the encrypted security database and then loses access to the computer
he/she will know the classical public key of an outgoing message but
has to break it (or its DH counterpart which the attacker now knows) in
order to decrypt the message. When the receiver of this message sends
next message to the victim the attacker cannot decrypt it without
breaking a public key (if the attacker was not able to decrypt the
message from the victim of the hack then he/she must break 256 bit
symmetric cipher to get the victim’s public key and then break one of
the public keys).

To understand the PRG construction the reader needs
to be
skilled in cryptography.

Hash(x)
uses ChaCha20 to produce 768 bits that form the 256 bit sized
blocks h1, h2, h3.

State
consists of 256 bit sized blocks s1, s2 and s3.

GL(r,x)
produces one Goldreich-Levin hard core bit from x using random
bits r.

PRG(state,DH shared secret) =

Hash(DH shared secret) to produce blocks h1, h2, h3

b1 = s1 + h1

b2 = s2 + h2

b3 = s3 + h3

For (i=0;i<1280;i++)

{

b1, b2 = SHA512(b1,b2)

produce bit GL(b3,b2)

}

The
produced list of bits form the next state’s blocks s1, s2 and s3 and
the required symmetric encryption/decryption and Poly1305 mac keys.

The SHA512 calculation is done using NaCl library’s reference, constant time implementation. The GL calculation neither indexes arrays nor branches using secret data.

Security professionals wishing to know more about the protocol should consult the US Patent 7,899,184 B2 titled "ENDS - Messaging protocol that recovers and has backward security".

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. Additionally a Company Export Key can be used.

The Personal Export key is actually two keys: a public key/private key pair of an Ed25519 curve and a symmetric Chacha20 256 bit 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 from backup media.

For Personal Export key the encryption of the field F happens followingly:

1. Create an ephemeral public key.

2. Compute Diffie-Hellman shared secret with this ephemeral key and
user’s Personal Export public key.

3.
Use Keccak to hash the shared secret to key K. Encrypt file’s
encryption key with this key K. Store the encrypted value of F on the
storage file and store the hash of user’s Personal Export
public
key on the storage file.

4. Encrypt the used ephemeral
public key with a symmetric Chacha20 256 bit sized key and store it on
the storage file.

The user’s Personal Export key file stores the private key of user’s Personal Export public key and the symmetric key that is used to encrypt the ephemeral public key. The private key is not stored on user’s security database but the public key and the symmetric key are.

Company Export Key consists of a public/private key pair.

For a Company Export key the encryption of the field F happens followingly:

1. Create an ephemeral public key.

2. Compute Diffie-Hellman shared secret with this ephemeral key and
company’s Export public key.

3.
Use Keccak to hash the shared secret to key K. Encrypt file’s
encryption key with this key K. Store the encrypted value of
F on
the storage file and store the hash of Company Export public
key on the storage file.

4. Store the ephemeral public key on the storage file.

The company’s Export key file stores the private key of company’s public key. If a user wants to use a Company Key the user imports Company’s public Export key which is used as described above.

In above storage file calculations the Ed25519 curve points are converted to the corresponding Curve25519 points when calculating the Diffie-Hellman shared secret. The password hashing scheme in Export Key files is a salted password hashing pbkdf2 with hmac sha256 using 30000 iterations.

Date page changed: November 26, 2018.