Re: [Sframe] Question about sframe_salt

[Richard Barnes <[e-mail]>]

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]> 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]
> https://www.ietf.org/mailman/listinfo/sframe
>