mres

Documentation

Overview

Package mres provides the underlying STROBE protocol for Veil's multi-recipient encryption system.

Encryption

Encrypting a message begins as follows, given the sender's key pair, d_s and Q_s, a plaintext message in blocks P_0…P_n, a list of recipient public keys, Q_r0..Q_rm, and a DEK size N_dek:

INIT('veil.mres', level=256)
AD(LE_32(N_dek),  meta=true)
AD(Q_s)

The protocol context is cloned and keyed with the sender's private key and a random nonce and used to derive a data encryption key, K_dek, and an ephemeral private key, d_e:

KEY(d_s)
KEY(96)
PRF(32) -> K_dek
PRF(64) -> d_e

The ephemeral public key is computed and the cloned context is discarded:

Q_e = G^d_e

The data encryption key and the message offset are encoded into a fixed-length header and copies of it are encrypted with veil.hpke for each recipient using d_e and Q_e. Optional random padding is added to the end, and the resulting block H is written:

SEND_CLR(H)

The protocol is keyed with the DEK and the encrypted message is written:

KEY(K_dek)
SEND_ENC('')
SEND_ENC(P_0,     more=true)
…
SEND_ENC(P_n,     more=true)

Finally, a Schnorr signature S of the entire ciphertext (headers, padding, and DEM ciphertext) is created with d_e and encrypted:

SEND_ENC(S)

The resulting ciphertext then contains, in order: the veil.hpke-encrypted headers, random padding, message ciphertext, and a Schnorr signature of the headers, padding, and ciphertext.

Decryption

Decryption begins as follows, given the recipient's key pair, d_r and Q_r, the sender's public key, Q_s:

INIT('veil.mres', level=256)
AD(LE_32(N_dek),  meta=true)
AD(Q_s)

The recipient reads through the ciphertext in header-sized blocks, looking for one which is decryptable given their key pair and the sender's public key. Having found one, they recover the data encryption key K_dek, the message offset, and the ephemeral public key Q_e. They then read the remainder of the block of encrypted headers and padding H:

RECV_CLR(H)

The protocol is keyed with the DEK and the plaintext decrypted:

KEY(K_dek)
RECV_ENC('')
RECV_ENC(C_0,     more=true)
…
RECV_ENC(C_n,     more=true)

Finally, the signature S is decrypted and verified against the entire ciphertext:

RECV_ENC(S)

Multi-Recipient Confidentiality

To evaluate the confidentiality of this construction, consider an attacker provided with an encryption oracle for the sender's private key and a decryption oracle for each recipient, engaged in an IND-CCA2 game with the goal of gaining an advantage against any individual recipient. The elements they have to analyze and manipulate are the encrypted headers, the random padding, the message ciphertext, and the signature.

Each recipient's header is an IND-CCA2-secure ciphertext, so an attacker can gain no advantage there. Further, the attacker cannot modify the copy of the DEK, the ephemeral public key, or the header length each recipient receives.

The encrypted headers and/or padding for other recipients are not IND-CCA2-secure for all recipients, so the attacker may modify those without producing invalid headers. Similarly, the encrypted message is only IND-CPA-secure. Any attacker attempting to modify any of those, however, will have to forge a valid signature for the overall message to be valid. As veil.schnorr is SUF-CMA-secure, this is not possible.

Multi-Recipient Authenticity

Similarly, an attacker engaged in parallel CMA games with recipients has negligible advantage in forging messages. The veil.schnorr signature covers the entirety of the ciphertext.

The standard KEM/DEM hybrid construction (i.e. Construction 12.20 from Modern Cryptography 3e) provides strong confidentiality (per Theorem 12.14), but no authenticity. A compromised recipient can replace the DEM component of the ciphertext with an arbitrary message encrypted with the same DEK. Even if the KEM provides strong authenticity against insider attacks, the KEM/DEM construction does not. Alwen et al. (https://eprint.iacr.org/2020/1499.pdf) detail this attack against the proposed HPKE standard.

In the single-recipient setting, the practical advantages of this attack are limited: the attacker can forge messages which appear to be from a sender but are only decryptable by the attacker. In the multi-recipient setting, however, the practical advantage is much greater: the attacker can present forged messages which appear to be from a sender to other, honest recipients.

veil.mres eliminates this attack by using the ephemeral key pair to sign the entire ciphertext and including only the public key in the KEM ciphertext. Re-using the KEM ciphertexts with a new message requires forging a new signature for a SUF-CMA-secure scheme. The use of an authenticated KEM serves to authenticate the ephemeral public key and thus the message: only the possessor of the sender's private key can calculate the static shared secret used to encrypt the ephemeral public key, and the recipient can only forge KEM ciphertexts with themselves as the intended recipient.

Repudiability

Because the sender's private key is only used to calculate shared secrets, a veil.mres ciphertext is entirely repudiable unless a recipient reveals their public key. The veil.schnorr keys are randomly generated for each message and all other forms of sender identity which are transmitted are only binding on public information.

Randomness Re-Use

The ephemeral key pair, d_e and Q_e, are used multiple times: once for each veil.hpke header and finally once for the end signature. This improves the efficiency of the scheme without reducing its security, per Bellare et al.'s treatment of Randomness Reusing Multi-Recipient Encryption Schemes (http://cseweb.ucsd.edu/~Mihir/papers/bbs.pdf).

Ephemeral Scalar Hedging

In deriving the DEK and ephemeral scalar from a cloned context, veil.mres uses Aranha et al.'s "hedged signature" technique (https://eprint.iacr.org/2019/956.pdf) to mitigate against both catastrophic randomness failures and differential fault attacks against purely deterministic signature schemes.

Index

• func Decrypt(dst io.Writer, src io.Reader, dR *ristretto255.Scalar, ...) (int64, error)
• func Encrypt(dst io.Writer, src io.Reader, dS *ristretto255.Scalar, ...) (written int64, err error)

Functions

func Decrypt

func Decrypt(dst io.Writer, src io.Reader, dR *ristretto255.Scalar, qR, qS *ristretto255.Element) (int64, error)

Decrypt reads the contents of src, decrypts them iff the owner of qS encrypted them for decryption by dR, and writes the decrypted contents to dst.

func Encrypt

func Encrypt(
	dst io.Writer, src io.Reader, dS *ristretto255.Scalar, qS *ristretto255.Element,
	qRs []*ristretto255.Element, padding int,
) (written int64, err error)

Encrypt reads the contents of src, encrypts them such that all members of qRs will be able to decrypt and authenticate them, and writes the encrypted contents to dst.