EndCryptor's cryptographic technical details

Both parties that send and receive messages need that EndCryptor is installed in order to encrypt and decrypt. No third parties are used (e.g. to provide public keys, to provide online connection to a third party machine, etc.) neither an online Internet connection between the sender and the receiver is needed. New contact’s 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. When encrypting/decrypting the stored information on the EndCryptor's security database on the used 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 SIDH key is 192 bits and the post-quantum security is matching that of AES192.

See cryptographic strength for more information.

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.

The
first emails using receiver’s long term public key also contain SIDH
2.0 quantum attack resistant public keys. If the parties communicate in
turns then the second exchanged email and others after it are protected
against quantum attacks. SIDH keys (version 2.0 or 3.0) are also used
later in communication, a SIDH key exchange should happen once a week
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 message that will be encrypted. The plaintext of the whole message is signed with sender’s long term public key. That part of the message which is encrypted includes the signature at the end of the message. The shared secret is used as an encryption key for ChaCha20, key size is 256.

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 calculates a shared secret with that Ed25519 key that was inside the received encrypted message. The signature and encryption are done as described above.

The actual encryption/decryption key is calculated by computing a Keccak hash value over a value derived from the SIDH shared secret and the classical shared secret. In more detail: the SIDH shared secret is 192 or 188 (version 3.0) bytes long. A Sha3-512 hash is calculated over it. The first 32 bytes of the result are Sha3-256 hashed to form a value derived from the SIDH shared secret to be used in this encryption/decryption key computation.

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

When the protocol is initialized 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 a value derived from the SIDH shared
secret and the values of the above mentioned
two classical shared secrets. 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. A Sha3-512 hash is
calculated over it. The
last 32 bytes of the result are Sha3-256 hashed to form a value derived
from the SIDH shared secret to be used in this initialization value computation.

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.

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, the are encrypted together
with the plaintext. If both the sender and the receiver have done the
initialization exchange using at least version 2.4.3.08 then 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.

In versions below 2.4.5 the messages are encrypted using 256-bit key sized AES in CBC mode (128-bit block size). If both the sender and the receiver have at least release 2.4.5 then the encryption is done using 256 bit key sized ChaCha20.

The plaintext ends with an authentication code. In versions below 2.4.5 this is CBC-MAC. If both the sender and the receiver have at least release 2.4.5 then 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.

The implementation of the Ed25519, Curve25519, Chacha20 and Poly1305 is the reference source code implementation available from SUPERCOP benchmark suite and the 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, licensed under the MIT license. The code is 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 initial seed consists of events like mouse movements and the operating system’s state and bytes provided by the CryptGenRandom system call.

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 should happen at least once a week.

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.