Feature #3804
open
SignatureHmacWithSha256_128
Added by Anonymous over 7 years ago.
Updated 9 months ago.
Description
HmacWithSha256 is used in IoT applications with a limited packet size, often less than 64 bytes. A normal HmacWithSha256 is 32 bytes and it would help to save space. It is possible to truncate the hash value as described in RFC 2104 section 5: https://tools.ietf.org/html/rfc2104#section-5
We should add a new signature type SignatureHmacWithSha256_128 where the hash value is truncated to the leftmost 128 bits (16 bytes).
I have a slight preference of not defining this type, but rather use an undefined range for this purpose (e.g., something from 200-252 range).
I disagree with note-1. All signature types should be clearly defined, so that anyone is able to verify them. Usage of undefined range should be discouraged.
- Start date deleted (
10/10/2016)
Instead of adding truncated versions of the (old-ish) SHA2-based HMAC, I would suggest to use new state-of-the-art MAC algorithms such as KMAC or Poly1305.
- Tags set to needs-discussion
- Status changed from New to Rejected
There are security concerns on truncated HMAC.
The new TLS protocols are using AEAD ciphersuites that can output shorter signature lengths, with higher security.
Therefore, this feature is no longer necessary.
See also https://github.com/Mbed-TLS/mbedtls/issues/4341
- Status changed from Rejected to New
Junxiao Shi wrote in #note-5:
There are security concerns on truncated HMAC.
Citation needed. I'm pretty sure that's false. (well, as long as you don't truncate too much; if the MAC is too short you can trivially mount a birthday attack, but that's true in general and not a specific weakness of HMAC)
The new TLS protocols are using AEAD ciphersuites that can output shorter signature lengths, with higher security.
We're talking about MACs here, so I don't see how TLS AEADs are relevant. Sure, you can abuse the authentication tag generated by an AEAD, but you'd be doing a lot more work (encryption) for nothing and it'd be just plain weird. Let's stick to MACs if that's what we need.
See also https://github.com/Mbed-TLS/mbedtls/issues/4341
That issue is about the TLS extension that uses truncated HMAC (as opposed to AEAD), so again I fail to see the relevance.
Davide Pesavento wrote in #note-3:
new state-of-the-art MAC algorithms such as KMAC or Poly1305.
Adding to the list: Ascon-Mac, KangarooTwelve, possibly even the keyed variants of BLAKE2/BLAKE3 (though I'm not sure if they can be truncated).
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by