RE: Bug 23097 - Underspecified behavior of verify() with regards to truncated signature

I suspect most of the use cases for truncation are where people have a fixed-length field for holding the MAC and truncate all MACs to that regardless of n. So for example I could see people truncating HMAC-SHA512 to 128 bits (and this may well be okay). But letting people truncate to say 8 bits seems like asking for trouble.

I'd suggest a non-normative minimum, even if it's something relatively low like 64 bits. Other opinions?

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Tuesday, November 19, 2013 10:51 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org
Subject: RE: Bug 23097 - Underspecified behavior of verify() with regards to truncated signature


There are definitely use cases for things like 3DES or AES+CBC, but are there any use cases for truncation beyond n/2?

Part of me says defer the min to the app/protocol, but I could live with a non-normative minimum.
On Nov 19, 2013 10:44 PM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
I see. Thanks for the clarification, that was not clear to me from the conversation.

Should we recommend that implementations refuse to truncate below a certain threshold? Or do you think that, as with deprecating weak algorithms, this unnecessarily reduces flexibility in favor of idiot-proofing?

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com<mailto:sleevi@google.com>]
Sent: Tuesday, November 19, 2013 1:23 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: Re: Bug 23097 - Underspecified behavior of verify() with regards to truncated signature

On Thu, Nov 14, 2013 at 1:16 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
> Thinking about this more, it really seems unadvisable to truncate MACs
> without explicit instruction from the caller. I'm leery about issues
> like with XMLSec:
> http://www.w3.org/blog/2009/07/hmac-truncation-in-xml-signatu/
>
>
>
> Imagine a script that receives a signature from somewhere and passes
> it to
> verify() without checking its length (because people are lazy like that).
> It's created a potentially exploitable oracle.
>
>
>
> Can we just add a truncation length parameter to the HmacParams and
> recommend that implementations define a floor below which they will
> refuse to truncate? That way the above example can be fixed, as the
> input signature will be rejected if it wasn't exactly the expected length.

Right, I think that was the proposal for how to deal with the truncation - the caller must explicitly request (as part of the algorithm's parameters) that a truncated signature be generated or verified.