Brian Resnik <[email protected]> writes: >SHA-256 Truncated to 32 bits (SHA-256/32) > >This RFC has value because ultra-low-bandwidth mesh networks cannot afford a >32-byte overhead per packet for a full SHA-256 hash.
I know you're joking with this but I've worked with devices that truncate their MAC to 16 bits for power-utilisation reasons and it's perfectly secure the way they're using it. Having said that, the organisation using this mechanism is also big enough that they don't need an RFC to tell them which end to truncate from. >AES in Electronic Codebook (AES-ECB) Mode Also fine when you're encrypting <= 128 bits in a system with just enough space for a 128-bit block. >RSA with 512-bit Keys (RSA-512) A large percentage of the DKIM-using world did this for something like a decade without anyone ever attacking it, even when the keys were as short as 384 bits. So this is also fine in systems that no-one cares about. This has probably turned into an argument in favour of pure ML-KEM, although it wasn't meant to be that. Peter. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
