On Tue, Sep 2, 2025, 21:09 Martin Thomson <m...@lowentropy.net> wrote:
> On Wed, Sep 3, 2025, at 03:12, Tim Hollebeek wrote: > > In particular, X-ECB is horribly broken and these days probably should > > not be used by anyone, ever. That advice is already a decade old or > > more, at this point. > > Total distraction, but RFC 9001 uses ECB. Defensibly so, I believe. > Though perhaps you might consider the use as part of a more advanced mode, > HN-1. Now for the tongue-in-cheek version: Absolute statements are always > wrong. > To add to the distraction, this is really an example of compounded confusion in how to define things, not a legitimately good use of ECB. RFC 9001 doesn't really use ECB. It uses the AES block cipher, a function that takes a fixed-length 16-byte input to a fixed-length 16-byte output. It's just that some (but not all!) cryptography libraries don't have an API for that, instead insisting on jamming unrelated objects into the same interface. That leads to always having a variable-length Mode(TM) on everything. (This kind of thinking leads to the infamous "RSA/ECB/..." APIs.) Then the (not common) applications that actually need the underlying fixed-length block cipher are stuck using variable-length ECB as the only way to get at it, even though actually making use of the variable-length aspect would be a problem. To that end, RFC 9001 would have been written better to say it used the block cipher, with a little bit of implementation guidance that, if you don't have an API for that, you might be able to call an ECB API instead. Indeed I remember, when I was helping folks implement this, the ECB wording caused a lot of confusion and I had to direct them to the block cipher functions instead. No sense in materializing all the extra machinery for a true variable-length ECB when you were just going to run the block cipher once. David >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
