Hacker News Reader

Comment by vlovich123 | Hacker News Reader

The strategy I used instead was to HKDF derive different keys for each chunk using the offset as part of the info to derive the key. No AD needed.

View on HN

Two calls to SHA-256 for each block would be very slow compared with a modern AEAD.

Hmm… it seemed to run at line speed on our machines. I’m also not sure where you’re getting two calls for sha256 from? Like 1 to derive the key (which is sha256 on a very small amount of data) and the second is?

What does it mean for an AEAD construction to "run at line speed"? Over how many different sessions and with what message sizes and on what hardware?

As in it's processing at the speed that data can be fed into the CPU. This particular use case was files coming in from the network on 10Gbps hardware but that was about the speed the AES HW ran via openssl perf tests. How many sessions and message sizes are irrelevant. Hardware was AMD EPYC 7642.

It's irrelevant to your use case. It's not irrelevant to the broader CS question of why people don't just do what you're doing.

If there’s no HW that demonstrates a speed difference, then maybe the theoretical CS concerns aren’t properly modeled? Also, the approach I outlined has a strength whereby there’s no nonce to mismanage which is a big strength.

You'd have to publish details of the construction you came up with for me to have anything to say about it not having or needing a nonce.

HMAC requires two calls to the underlying hash function. In this case one is with a block-size input and the other is smaller (key size plus output of the first call). When called per-block this approach is much slower than any modern AEAD (which typically requires simple polynomial math on each block plus a single AES/ChaCha/whatever finalization call).

It might be “fast enough for line rate” in your situation but even then you could be saving CPU cycles for other work by using a more efficient construction.

Reply on news.ycombinator.com