Re: [Sframe] Question about sframe_salt

["Mularczyk, Marta" <[e-mail]>]

Oh, interesting! Thanks for finding all that!

The [MF00] reference was quite helpful.

What I understood is that it's not about the IV being secret but about it not being repeated between different secret keys. Using the same IV would allow an attacker to build a variant of a rainbow table which allows to quickly recover secret keys. And of course using IV = CTR means we all use IV = 0 at the beginning.

-Marta


________________________________
From: Sframe <[e-mail]> on behalf of Richard Barnes <[e-mail]>
Sent: Thursday, August 3, 2023 8:17:05 PM
To: Mularczyk, Marta
Cc: [e-mail]
Subject: RE: [EXTERNAL] [Sframe] Question about sframe_salt


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


The construction here is just mimicking what SRTP does for AES-CTR IV formation [1]:

> IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)

The differences here are just that (1) the SFrame CTR value replaces the SRTP counter `i` and (2) we allow for 32 bits of counter instead of 16.  There is some rationale in RFC 3711 for this design [2]:

>   The effective key size is determined (upper bounded) by the size of
>   the master key and, for encryption, the size of the salting key.  Any
>   additive stream cipher is vulnerable to attacks that use statistical
>   knowledge about the plaintext source to enable key collision and
>   time-memory tradeoff attacks [MF00] [H80] [BS00].

If I understand correctly, the core thing the salt does is make sure that the IV is unknown to any attacker who doesn't also have the key, so that the attacker can't perform certain attacks that would require knowledge of the IV.  Just using nonce = CTR would obviously make the nonce known to the attacker.  This pattern turns out to be pretty universal in protocols that encrypt streams of objects:

* TLS/DTLS XORs a per-record sequence number with a per-stream `client/server_write_iv` [3]
* MLS derives a completely fresh nonce for each message it protects [4]
* IPsec ESP has an explicit IV, but the GCM integration adds a random salt [5]
* SSH derives IVs from secret state via hashing [6]
* HPKE XORs a message counter with a "base nonce" [7]
* NaCl doesn't specify a nonce formation, but notes "Choosing the nonce as a counter followed by (e.g.) 32 random bits helps protect some protocols against denial-of-service attacks" [8]

The only exception I came across in a brief search is Noise, which appears to use an unmodified counter for its nonce [9].

--Richard

[1] https://datatracker.ietf.org/doc/html/rfc3711#section-4.1.1
[2] https://datatracker.ietf.org/doc/html/rfc3711#section-7.2
[3] https://datatracker.ietf.org/doc/html/rfc8446#section-5.3
[4] https://datatracker.ietf.org/doc/html/rfc9420#name-encryption-keys
[5] https://datatracker.ietf.org/doc/html/rfc4106#section-3.1
[6] https://datatracker.ietf.org/doc/html/rfc4253#section-7.2
[7] https://datatracker.ietf.org/doc/html/rfc9180#name-encryption-and-decryption
[8] https://cr.yp.to/highspeed/naclcrypto-20090310.pdf
[9] http://www.noiseprotocol.org/noise.html#security-considerations



On Thu, Aug 3, 2023 at 1:05 PM Mularczyk, Marta <mulmarta=[e-mail]<mailto:[e-mail]>> wrote:

Hi all!


Another small question, this time not necessarily to change anything. Why is the nonce computed as xor(sframe_salt, CTR) instead of nonce = CTR? Is there an attack this prevents?


Best,

Marta

--
Sframe mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sframe