2

In particular, AES-CBC with Blake2b for HMAC combined with xChacha20-Poly1305.

The scheme is to encrypt with xChacha20-poly1305 first, using a key derived from a high entropy password using argon2id then with AES-CBC-Blake2b with a new key derived from the master key using argon2id and random IV encrypt the result of the cipher text and add authentication using blake2b.

Would this be a secure scheme if implemented correctly, or does combining block and stream ciphers cause vulnerabilities?

  • 2
    Related Q. Demonstrably, cascading two ciphers using independent keys is at least as secure as either cipher (we have to think about if that extends to authenticated encryption the way they are combined, though). Depending on reading of the question (in particular, what "master key" is w.r.t. "password", how argon2id salt is handled), that applies, or not. – fgrieu Nov 21 '23 at 19:53
  • Master key being the key derived from a password.

    Salt is 64 bytes generated using random number generator class in cryptography. Argon2id parameters are 32 iterations with 5GiB of memory

    – bismofunyuns Nov 21 '23 at 20:34
  • 1
    Your bottle neck will be the password. What is the strength of it? – kelalaka Nov 21 '23 at 21:20
  • Some things remain unclear: what the Blake2b-based authenticator is; on what data it operates; what key it uses (shared with AES-CBC or not). Also, there are two Argon2id: one turning password to master key, the other turning master key into the key(s) for AES-CBC and the Blake2b-based authenticator. Do these two Argon2id use the same salt, or different salts/IV? How is the xChacha20-poly1305 salt transmitted (it could be part of the AES-CBC-Blake2b payload or not). – fgrieu Nov 21 '23 at 21:38
  • @kelalaka according to a calculator, I’m over 200 bits of entropy. – bismofunyuns Nov 22 '23 at 00:07
  • @fgrieu blake2b hmac that’s included with libsodium. There are 3 keys derived with argon2id, the first derived from the actual password, the second is derived from the first, and the third is derived from the second. There are 3 different salts being used for each argon2id. The xchacha20-poly1305 method in libsodium doesn’t require a salt – bismofunyuns Nov 22 '23 at 00:07

1 Answers1

3

With respect to confidentiality, cascading two ciphers (xChacha20 then AES-CBC in the question) with independent keys is at least as secure as either cipher against KPA and CPA attacks. That's irrespective of the cipher's structure (bloc or stream), and of if IV of the first cipher is encrypted or not by the second.

That extends to authenticated ciphers with independent keys under CCA attack if failure of either integrity test deprives adversaries from any information, and if the second cipher applies to the output of the first including the authenticator of the first (here: if the poly1305 authenticator gets AES-CBC-encrypted and Blake2b-integrity-protected).

With respect to the above, I see no specific vulnerability to combining a block and stream cipher.

But here, we can't rely on the above, because the keys are not independent: the first cipher's key is used to derive all the other keys in a public way (assuming salts are public, as customary). So if a hypothetical attack on the first authenticated cipher (xChacha20-poly1305) leaks its key, which is the "master key", the second authenticated cipher (AES-CBC-Blake2b) does not help. In this circumstance, that could well occur if a side-channel attack on the first cipher succeeds (it's unclear if the question's "implemented correctly" leaves that possible).

This can be improved with a different password-to-keys derivation scheme (e.g. a single Argon2 which results is a split to form the other keys).

But in my opinion, cascading good authenticated ciphers is not useful, even if the keys are made independent. It adds complexity, thus potential for implementation errors. It does nothing towards solving other issues more likely to cause real harm than a break of either of the authenticated ciphers: password leak or guess by dictionary attack, penetration of any of the machines manipulating the plaintext, including but not limited to those doing encryption and decryption.

kelalaka
  • 48,443
  • 11
  • 116
  • 196
fgrieu
  • 140,762
  • 12
  • 307
  • 587
  • I agree that this is excessive. The Argon2 parameters are also ridiculously high/impractical on certain devices when you can just have a higher entropy password. To complement your answer, I would like to point out TripleSec from Keybase. This can be used as a template if set on doing cascade encryption. – samuel-lucas6 Nov 22 '23 at 08:12
  • Is source code allowed to be posted here for you or anyone to judge if things are implemented correctly? It’s written in C# – bismofunyuns Nov 22 '23 at 11:47
  • @bismofunyuns: the short answer is no, significant source code fragments to review are not allowed. A link to a pastebin at the end of the question is OK, but don't hold your breath for a response. There is codereview-SE but comb their doc before posting. – fgrieu Nov 22 '23 at 12:14
  • How about pseudo code? – bismofunyuns Nov 22 '23 at 13:29
  • @bismofunyuns: Pseudo code is fine. When there is an iteration involved, or decisions to abort on error, that's often the best way to precisely describe something. – fgrieu Nov 22 '23 at 15:02