aes256ctr?

[ThomasWaldmann]

Is it missing? I've only found aes128ctr in the src.

I'm asking because I'm considering replacing openssl by libsodium in borgbackup.
But the current cipher we use is aes256ctr (and, you know, people like to read their old backups, so I guess we would need it for backwards compatibility).

[jedisct1]

Hi Thomas,

AES256-GCM is available. But not the raw stream cipher, without authentication, is not exposed.
Using a stream or block cipher without a MAC is likely to be the most common vulnerability in applications using crypto libraries. So I'm very reluctant to adding it. AES128-CTR is also not available in the minimal build of libsodium for this reason, in addition to the lack of an internal counter.

[ThomasWaldmann]

We have an hmac-sha256 on top of aes256-ctr. But not having aes256-ctr means: not reading old encrypted backups. Or not getting rid of openssl.

[jedisct1]

Glad to hear that you are adding an authentication tag.

Unfortunately, AES256-CTR (or any additional stream/block cipher without authentication) will probably not be added to the library.

Maybe you can make openssl optional, only to read old backups?

[cfcs]

While I'm also sceptical of the benefit of adding this, I found this interesting and sort of kind of related:

• http://blog.cryptographyengineering.com/2012/10/so-you-want-to-use-alternative-cipher.html
• https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OneHundredYearCryptography

... IMHO this would make more sense once some of post-quantum crypto people come up with a recommendation for something to couple with ECDH for key establishment.

[jedisct1]

For PQ cryptography, ECDH is what needs to be replaced first.

[paragonie-scott]

Recommended reading: http://pqcrypto.eu.org/docs/initial-recommendations.pdf

[jedisct1]

TL;DR: For authenticated encryption, even in a PQ era: AES256-GCM and Salsa20-Poly1305 are still safe.

But we're digressing here. This issue was about exposing AES256-CTR, without authentication.
It's sometimes hard to make a balance between sticking to APIs that prevents foot-shooting, and adding APIs that are dangerous, but needed by many real-world applications.
In that case, AES256-CTR looks more dangerous than something really needed by many applications.

[ThomasWaldmann]

I am just wondering why aes256-ctr is not present while aes128-ctr is, although the first one should be quite more secure. Also, isn't it easy to add support for 256 bit keys if one already has the 128bit key (aes128-ctr) implementation?

[jedisct1]

Like the initial prototype of Ed25519, AES128-CTR is only present to retain binary compatibility with the original NaCl library.

And the main reason it was in NaCl was to demonstrate that a software AES implementation without side channels is possible.

But it is not used by any high-level construction. Its absence of internal counter makes it prone to nonce reuse, it is horribly slow, it is not included when libsodium is compiled with --enable-minimal, and it may eventually not be compiled any more by default.

[ThomasWaldmann]

ah, ok. :|