3
$\begingroup$

Is the general approach of block ciphers still relevant when we have secure and performant pure stream ciphers?

For example, TLS 1.3 supports both AES-GCM and chacha20-Poly1305. But I don't understand why one would prefer AES-GCM over chacha20-Poly1305 if the latter is just as secure but simpler and faster. Is it just for historical reasons? (e.g. due to there being hardware support for AES?).

$\endgroup$
9
  • 3
    $\begingroup$ AES has hardware support (called AES-NI) that beats ChaCha20 in hardware where almost all CPU's has it. AES is also a NIST standard, meaning one must comply to work with the government. There are other advantages listed here. $\endgroup$
    – kelalaka
    Apr 1 at 9:33
  • 1
    $\begingroup$ @samuel-lucas6, aren't all block ciphers based on permutations? and I think it's too optimistic to say sponge/duplex is well understood and it's strength quantified, which the rest of your comment somewhat contradicts. It's simply not been long enough time to do this $\endgroup$
    – kodlu
    Apr 2 at 5:35
  • 2
    $\begingroup$ this question reminded me of a keynote by Adi Shamir ("Are Stream Ciphers Dead?") from a conference (Asiacrypt in early 2000's [Queenstown?]). Then again a recurring title in Information Theory symposia used to be "Is Coding (Error Correction, for clarity) Dead?". Yes, things evolve but block ciphers will not disappear $\endgroup$
    – kodlu
    Apr 2 at 5:38
  • 1
    $\begingroup$ @kodlu I mean unkeyed permutations, which seems to be called permutation-based crypto. Fair point, but there have been a lot of hash functions/MACs/AEADs based on them now. They've won the SHA-3, CAESAR, and LWC competitions. $\endgroup$ Apr 2 at 8:03
  • 1
    $\begingroup$ Why chacha20 is more a stream-cipher than AES-GCM? Both have a state where a round function mixes a key, and some other data, and the encryption is the same: the result of the mixing (of the length of the state) is xored with the plaintext. If you call chacha20 a stream cipher, so is AES-GCM. $\endgroup$
    – uk-ny
    Apr 8 at 1:03

1 Answer 1

1
$\begingroup$

At this point, you generally throw hardware at a problem when you either have a power or throughput issue. AES-NI increased the speed of using AES on a CPU considerably, and there's not a reason that you couldn't use Chacha20-Poly1305, but no one has asked for it...in the CPU context.

Having said that, there's a bunch of cores for this available for FPGAs out there. It seems that CISCO has web proxy that has Chacha20-Poly1305 accelerated functions; however, I don't know the details of the implementation.

If you're going to be doing a task all of the time, hardware is great way to go, but if you're not expecting to do it, it's not worth the effort. Zeroth order from looking at the architecture, I would say that Chacha20 would be much faster than AES, as the circuits are smaller. (I've made AES/Blake2/SIMON/curve22519, so this is an opinion).

As an aside, we have super-scaler CPUs, so there's no reason for operations to be in order. I've never understood why AES-NI is clocked, and not just asynchronous where you just insert the output when it's done, like division units, but with AES-NI you have 10, 12, or 14 clocks. Chacha20-Poly1305 would be super easy to implement with or without a clock. I'd probably implement it clockless, but that'd require someone giving me a grant.

$\endgroup$
2
  • $\begingroup$ wouldn't timing attacks be a concern for an asynchronous implementation? $\endgroup$ Apr 2 at 1:11
  • $\begingroup$ @OscarSmith As it's a function and there aren't varying instructions, the operation all completes within the bounds of the randomness that is added due to 2-way shot noise. Also, asynchronous circuits are dual-rail encoded so there's not power dependence on the data, or a completion time difference. It takes 2.2x more area and 2.2x^2 power than synchronous implementations, so it's not advantageous from a cost perspective. $\endgroup$
    – b degnan
    Apr 2 at 11:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.