crypto: consider AEAD limits

[ThomasWaldmann]

review the master branch code for

• AES256-OCB
• chacha20-poly1305

about

• size limit for a single message encrypted using a specific (key, nonce) pair
• size or count limits for all messages encrypted using one specific key

[ThomasWaldmann]

chacha20-poly1305

https://libsodium.gitbook.io/doc/secret-key_cryptography/aead

• single key/nonce pair: limit 256GB (as for borg each chunk is max 20MiB and we generate a new nonce for each chunk, we are very much on the safe side of this)
• single key: no practical limit (2^64 messages - also no problem for borg)

aes-ocb

https://azet.org/draft-zauner-tls-aes-ocb/#data-volume-limit-under-a-single-key and https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf infos for aes256-ocb

• single key: 64GB limit stated for usage with tls, then must be rekeyed (somehow this seems wrong - is it a limitation for a single key/nonce pair? here we have a 32bit internal counter in OCB plus 16bytes per block == 64GiB)

OTOH:

https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#properties (OCB author's FAQ) states:

• single key: 280TB: "Birthday-bound attacks (as well as good cryptographic hygine) motivate rekeying well in advance of birthday-bound concerns. In RFC 7253 we say that a given key should be used to encrypt at most 2^48 blocks (about 280 terabytes)." Note: 280TB seems wrong. Not sure where that comes from...
• from the RFC: "In order to ensure that s^2 / 2^128 remains small, a given key should be used to encrypt at most 2^48 blocks (2^55 bits or 4 petabytes), including the associated data." (same 2^48 blocks here, but now it correctly tells that is 4PiB)
• 4PiB = 4 * 2^50B = 2^52B == 2^(48+4)B == 2^48 128bit blocks
• for practical usage in borg, i guess 4PiB per backup session (== per session key) is high enough so we do not need to think about rekeying within one session.

[ThomasWaldmann]

while reading through misc. material about chpo and ocb, i also checked for the "nonce / iV" requirements:

for both, it is ok to use a counter as the nonce, a random IV is not needed.

[ThomasWaldmann]

borg/src/borg/crypto/low_level.pyx

Line 479 in 28731c5

if block_count > 2**32:

there is the check for not encrypting messages larger than 2^32 blocks.

[ThomasWaldmann]

@real-or-random can you check this?

[real-or-random]

ChaCha20-Poly1305: That looks right, and yes, no need to worry here.

AES-OCB:

azet.org/draft-zauner-tls-aes-ocb/#data-volume-limit-under-a-single-key and isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf infos for aes256-ocb

* single key: 64GB limit stated for usage with tls, then must be rekeyed (somehow this seems wrong - is it a limitation for a single key/nonce pair? here we have a 32bit internal counter in OCB plus 16bytes per block == 64GiB)

I don't really understand that paragraph in azet.org/draft-zauner-tls-aes-ocb/#data-volume-limit-under-a-single-key. They copy the bound from isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf without justification. But that bound is specifically derived for GCM mode (the derivation relies on Theorems from https://eprint.iacr.org/2012/438.pdf, which is totally specific to GCM). So I don't think the bounds in [azet.org/draft-zauner-tls-aes-ocb/#data-volume-limit-under-a-single-key](https://azet.org/draft-zauner-tls-aes-ocb/#data-volume-limit-under-a-single-key makes sense). (Or if it makes sense, they don't explain why.)

4 PiB makes sense. The calculation is correct, not sure why Rogaway writes 280 TB in the FAQ. Maybe just a miscalculation, 4 PiB/4 ≈ 280 TB. So this is really just a factor of 4, and I wouldn't mind about this. These are not "fixed" bounds anyway, and both 2^48 and 2^46 are well below 2^64.

---

for practical usage in borg, i guess 4PiB per backup session (== per session key) is high enough so we do not need to think about rekeying within one session.

I think these bounds are all large enough so we won't run into problems, so I agree, rekeying is overkill and would just add unnecessary complexity. But it may still make sense check the bounds in the code (and then simply crash if they're violated).