Feature #3804
open
SignatureHmacWithSha256_128
0%
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).
Updated by Alex Afanasyev about 8 years ago
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).
Updated by Junxiao Shi about 8 years ago
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.
Updated by Davide Pesavento over 5 years ago
- 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.
Updated by Junxiao Shi over 1 year ago
- 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
Updated by Davide Pesavento over 1 year ago
- 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.
That issue is about the TLS extension that uses truncated HMAC (as opposed to AEAD), so again I fail to see the relevance.
Updated by Davide Pesavento over 1 year ago
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).