When the first message in the handshake is called ConnectionOffer, then it would be only logical if the response to it was called ConnectionAccept (= accepting the offer).

It should be documented how Endguard handles different threat models. For this, all security games and threat models which are considered during the design should be documented.

Thread models

• Attacker on the AES encryption scheme that knows an efficient algorithm A(y, n) := k which can derive the key k from a ciphertext y := AES256-GCM(x, k, n) where the nonce n is chosen uniformly at random for each plaintext x.
• Attacker on the ChaCha20 encryption scheme that knows an efficient algorithm A(y, n) = k which can derive the key k from a ciphertext y := Chacha20-Poly1305(x, k, n) where the nonce n is chosen uniformly at random for each plaintext x.
• Attacker on the GCM MAC algorithm with an oracle O(x) := m that can create a valid MAC m for a message x.
• Attacker on the Poly1305 algorithm with an oracle O(x) := m that can create a valid MAC m for a message x.
• Attacker with an efficient algorithm that solves the factorization problem.
• Attacker that knows the CR / CC secret/checksum
• Attacker can create valid HMACs
• Timing attack

Every message should be MACed twice, using different MAC algorithms, to guarantee connection integrity. This is important in case the MAC of an authenticated encryption algorithm breaks. The additional MAC then ensures integrity of the existing connections until they are switched to another block (or stream) cipher algorithm. Integrity is essential for Endguard because setting up a new connection requires the exchange of information over a secondary medium (e.g. a QR code).

1. The first MAC is generated by the authenticated encryption algorithm (GCM for AES-256-GCM or Poly1305 for ChaCha20-Poly1305 #4).
2. Additionally, the entire ciphertext and additional authenticated data (aad) should be MACed again, using HMAC-SHA256. This is a good fit as it is based on the SHA256 hash algorithm, so it functions differently to GCM and Poly1305.

Endguard should support an alternative to the AES256-GCM block-cipher algorithm, in case there ever is a viable attack on AES or the GCM MAC.

The second algorithm should be ChaCha20-Poly1305 as it is included in secure and included in the TLS standard. Also, it is fundamentally different from AES-GCM which means that anyone ever breaks AES or the GCM mode, then ChaCha20-Poly1305 security is still intact.

There should be exact specifications describing the handshake, encryption and decryption (including pseudo-code examples)

It should be documented, what functionality must be exposed as API by every Endguard implementation.