V5 [Proposal only]

[SparkDustJoe]

Now that V4 #51 has been released, with one fewer encryption algorithm, and with the closing of the CAESAR Authenticated Encryption competition, looking to future algorithms to maintain high security would be prudent.

Current (each with a separate but commonly-generated key): (Key derivation function: SCRYPT) AES-CTR ---MIDDLE LAYER REMOVED--- Salsa20 (Signed with HMAC-SHA512 and HMAC-SHA-3-512)

Future: (proposals) (Key derivation function: Argon2id) AES-OCB (faster than CTR; Finalist for Case 2, High Performance, in CAESAR, and is an AEAD construction) Camellia-256 (Japanese encryption algorithm in the same vein as AES but completely different internal workings; operates on 128bit [edit] integers internally) ChaCha20-Poly1305 or NORX64-4-1 (Also AEAD constructions, both use ChaCha, which is more secure than Salsa by the creator's own admission; completely different internal workings than the other 2 layers) (Signed with HMAC-SHAKE256-256)

Rationale: Argon2 provides higher defense-in-depth against modern custom hardware attacks, such as those against SCRYPT after the Crypto Currency boom of late.

By using layers that have Authenticated Encryption with Additional Data constructions (AEAD), there is inherent to the process several Message Authentication Codes built-in (which is why the signature is reduced to one pass, and shortened to 256 bits using SHAKE256 with a specified output length [see NIST documentation]).

With the removal of TwoFish, a suitable middle-layer is needed. Camellia is proven secure and has a radically different structure to AES, providing security against a different possible set of attacks, which ups the difficulty for an attacker by an incredible amount for the whole stack. Another option would be the South Korean ARIA algorithm.

Using something with a ChaCha core construction would be more secure than Salsa20 by itself, and using ChaCha20-Poly1305 (which is already an IETF RFC standard used in modern browsers) or NORX64-4-1 would provide a second AEAD MAC in the stack of 3 ciphers (again, reducing the need for as many external, separate signatures).

SHAKE256 is NIST approved and still provides adequate security margin for a signature even though it's not the 512 bits of previous versions.

These are just my opinions, and I welcome constructive critique and feedback on these suggestions.

[SparkDustJoe]

Looking back at OCB, there is a patent consideration, and if that would be a burden, then AEGIS is equally a good option for the outer-most layer. It still uses components of AES, but is faster than CTR mode by a considerable amount, esp. when using AES-NI instructions (although that wouldn't apply in JavaScript version).

Also, in going through the NIST site on the SHAKE algorithm, they don't seem to provide any HMAC samples that I was able to find. HMAC-SHA-3-256 should still be sufficient if any of the layers of TripleSec include AEAD algorithms.

[heronhaye]

Thanks for the proposal, we'll discuss this soon.

[heronhaye]

@SparkDustJoe Do you have any references for security analysis of Camellia? I couldn't find much online. Similarly for Argon as well. It may be a good idea to wait until more security analysis has been done on these newer algorithms before getting rid of something like AES-CTR. Even OCB mode had a serious vulnerability just a few months ago.

Finally, I'm not sure how the security properties of nested AEAD plays out, do you know anything about that? The papers I've seen that deal with nested encryption (and not authentication) require commutativity of the ciphers which I believe would be lost if we used AEADs. What do you think?

[SparkDustJoe]

I'll have to do more digging for Camellia myself, but it was recently introduced to VeraCrypt (the spiritual successor to TrueCrypt).

For Argon, the only recent known attack is on instances where T < 3 and only for one flavor (can't remember if it was the data-dependent or -independent variety; it was referenced in their issues black-log, I'll have to dig that up as well), so as long as a reasonable number of iterations are used with sufficient consumed memory to harden against ASIC's and GPU's then it should be fine, and Argon2id has protections against that kind of attack listed and against most timing attacks. The exact parameters will require some tuning for performance. There was a fair amount published during the PHC, and a few updates afterward. The code base is still maintained.

I don't know if I've seen specific research into nested AEAD's specifically, but since they are stream ciphers, they interact with the data like any other cipher operated in a Counter mode like AES-CTR or any of the other algorithms currently being used in V3/4. The notion of commutativity is still maintained. Since there is an offset between layers in TripleSec already, there is no way to decrypt the layers in parallel, because information for a lower layer has to be revealed by "peeling away" an outer layer first (the IV/Nonce specifically). So that wouldn't likely change with AEAD's.

The Tags/MACS are not secret information, but in the case of Norx, forgery possibilities do exist for reduced "toy" versions due to a symmetry internally. In that case I recommend the 6-round version. The code is released to the public domain, so it's still possible to do some tweaks and republish it as a new version or algorithm (which in-of-itself would require more research). Morus was an alternate Case 2 Finalist from CAESAR and doesn't rely on AES operations so it can be swapped in for Norx or TwoFish. Morus operates in a more traditional Feistal-like manner, but I have noticed that Morus_1280_128 and Morus_1280_256 will produce the exact same results if the first 16 bytes of the key are repeated (internally, that's all that makes Morus_1280_128 different; it copies the key twice).

The benefit of AEAD is that you can inject an Additional Data header that is not written into the output that can be kept secret or packed with the IV or Nonce. The AD is processed before any data, so the state is augmented with the additional information after keying but before encryption. So that leaves some room for either some additional random information derived from the Key, data produced at random like the IV or Nonce, or some combination therein (using the primary Salt in a separate operation for example). Since the tags are essentially random, they are encrypted like any other data and are not (as far as I can tell) susceptible to plaintext attacks in the outer layers. Most tags from CAESAR algorithms were set to 128 bits (16 bytes), which is less than the HMAC operations used in V3/4, so take that for what it's worth. If only one layer of AEAD is used then at least one external MAC is still advised. For performance, there is also the Blake2 hash which can be keyed.

I'll try to do more research as I can... I'm fighting pneumonia at the moment...

[SparkDustJoe]

I'm circling back around to this as NIST has opened both a Post-Quantum asymmetric encryption "competition" of sorts, and a Lightweight Encryption "competition", of which one of the CAESAR finalists, ASCON (first choice for case 1 for restricted or area-reduced hardware mostly), is also being submitted. It is currently a Round 2 candidate for NIST's LWE competition, so it might also work in the stack in place of one of the lower tiers (TwoFish or Salsa20). It's worth looking at that field of candidates when the competition gets farther along.

I still recommend AEAD constructions as they provide "on-the-fly" verification of the given tier in which they are used, reducing the headaches mentioned about having the signatures "out of place" in the final output file. If the MAC fails on any given tier, optionally abandon the whole thing ("fail early", which might introduce it's own issues by given an attacker insight into which tier is failing, something to be considered).

Security of Argon2 seems to continue to hold up, and it is now seeing expanding uses. An attack on Argon2i specifically has been extended to 10 iterations, so the T value needs to be high, but it's unclear if this still applies in the Argon2id construction (which is mostly data-dependent but has an iteration that is not data-dependent). I haven't been able to find anything on Argon2d specifically (according to the authors, there's a potential for some timing-attack vulnerabilities given its purely data-dependent nature).

In any case, moving away from SCRYPT/PBKDF2 would be prudent. There's also Lyra2 which got a nod from the PHC judges. Worse case, you can always run both Lyra and Argon and feed the output of one as an input value into the other.

[maxtaco]

We'll likely wait until there is a really mature implementation of any of those new ciphers. Seems like it doesn't pay to be on the leading edge of adopting a new cipher or a new implementation of a new cipher, since there can be sidechannel attacks, etc.

Agreed that Argon2i or Argon2id looks better than scrypt in terms of side-channel attack resilience.

[SparkDustJoe]

It looks like there are several movements to add Argon2 to OpenSSL (https://github.com/openssl/openssl/pull/9444), the Argon team just needs to update the RFC document to standardize it officially, which is also on that team's docket (active as of 11 days ago).

I think this thread has gotten a little stale. As for possible replacements for Twofish-CTR, I still strongly suggest an AEAD construction, and NIST is still going with their Lightweight Cryptography project (Round 2 candidates announced late last year https://csrc.nist.gov/Projects/lightweight-cryptography/round-2-candidates). ASCON made it to Round 2.

I'm going to close this ticket for now. @maxtaco , the other V4 ticket is still open, which given the official V4 spec has been released, that probably should be closed too.

Thanks for your consideration.