W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

RE: AlgorithmIdentifier in encrypt/decrypt/sign/verify operations

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Tue, 2 Apr 2013 19:02:19 +0000
To: Ryan Sleevi <sleevi@google.com>, Mike Jones <Michael.Jones@microsoft.com>
CC: Mark Watson <watsonm@netflix.com>, Richard Barnes <rbarnes@bbn.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <02f6faaac5324ad59dc2ecaad13e466f@DFM-DB3MBX15-07.exchange.corp.microsoft.com>
I'd like to clarify that we're not talking about importing or using existing HMAC keys here. This is only about HMAC key generation. So this is not really a case where you benefit from specifying a value larger than the hash size.

IMO the best argument for specifying the length is Richard's argument on using shorter keys in byte-limited situations. Cryptographically, truncating keys like that sounds bad but if it is an important scenario and people are careful about the truncation I can see the rationale for doing it.


From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Tuesday, April 2, 2013 11:01 AM
To: Mike Jones
Cc: Mark Watson; Richard Barnes; Vijay Bharadwaj; public-webcrypto@w3.org
Subject: Re: AlgorithmIdentifier in encrypt/decrypt/sign/verify operations

+1 for length for HMAC key.

(Still haven't evaluated the rest of Mark's proposal)

On Tue, Apr 2, 2013 at 10:43 AM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
I agree that we shouldn't require that the key size be the size of the hash output in the low-level API - especially when the HMAC specs themselves don't contain this requirement.  I'd be fine with recommendations about key size, but I don't think it's appropriate in the low-level API to require particular key sizes (other than possibly requiring that they be sufficiently long to be meet minimum security requirements).

                                -- Mike

-----Original Message-----
From: Mark Watson [mailto:watsonm@netflix.com<mailto:watsonm@netflix.com>]
Sent: Tuesday, April 02, 2013 7:26 AM
To: Richard Barnes
Cc: Vijay Bharadwaj; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: Re: AlgorithmIdentifier in encrypt/decrypt/sign/verify operations
Sent from my iPhone

On Apr 2, 2013, at 7:16 AM, Richard Barnes <rbarnes@bbn.com<mailto:rbarnes@bbn.com>> wrote:

>
> On Apr 2, 2013, at 10:00 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Apr 2, 2013, at 1:46 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
>>
>>> This was raised as issue #12 back in August. FWIW I think it's a good idea to separate operation-specific parameters from algorithm parameters. At the time we did not have strong use cases that would argue for such separation. Now that the API is taking shape, it does seem like combining them may be adding confusion. So it may be a good idea to try separating them out.
>>>
>>> IMO redundant specifications of the algorithm in different parameters are trouble for implementers - you need to define precedence rules for who wins if they conflict. Better to keep things simple by only requiring the algorithm to be specified in one place.
>>>
>>> I'm not sure that we need a parameter for specifying the length of an HMAC key, though. HMAC is specified to always use a key that is the size of the hash output - if the key is longer it gets hashed to reduce it to the right size. So it should be fine to always generate a key of the size of the hash output, since there is no security advantage to making it longer.
>>
>> That would be a reasonable simplification. We would have to say that in our spec, since as you say the input to the HMAC algorithm as defined in the RFC and FIPS PUB can be any length.
>>
>> ...Mark
>
> The only objection that I can think of is if people wanted to use MAC keys shorter than the full hash length, to save space.  For example, some of the JOSE use cases involve putting a MAC-protected object in an HTTP request URI, which places some limits on how long they can be.

So, then, this really does look like an example where there is an obvious default, but some use-cases where you might want to specify something different ;-)

...Mark
>
> --Richard
>
>
>
>
>
>
>>>
>>>
>>> From: Mark Watson [mailto:watsonm@netflix.com<mailto:watsonm@netflix.com>]
>>> Sent: Saturday, March 30, 2013 9:52 AM
>>> To: Richard Barnes
>>> Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
>>> Subject: Re: AlgorithmIdentifier in encrypt/decrypt/sign/verify
>>> operations
>>>
>>>
>>> On Fri, Mar 29, 2013 at 11:22 AM, Richard Barnes <rbarnes@bbn.com<mailto:rbarnes@bbn.com>> wrote:
>>>
>>> On Mar 27, 2013, at 9:10 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
>>>
>>>> This may be related to ISSUE-12 and apologies again if this has been discussed before - it is coming up now frequently in implementation discussions.
>>>>
>>>> In the encrypt/decrypt/sign/verify operations, two AlgorithmIdentifier objects are provided as input, one as an explicit parameter and one which is associated with the Key object (and appears as the Key.algorithm attribute). Presumably it is an error if the "name" member of the dictionary does not match (after normalization), though I am not sure if this is clearly specified.
>>>>
>>>> In some cases, it is specified that the params member will have different types in these two places (I'm assuming that the Key.algorithm attribute takes the value that was provided to generateKey). For example for AES-CTR, the params in Key.algorithm contains the key length and params in encrypt/decrypt contains the IV.
>>>>
>>>> But for other cases things are very unclear. For example, for HMAC, the same AlgorithmParameters type is used, containing the hash algorithm. In this case it seems completely redundant to provide the same object twice to the sign/verify call (once in the method parameters and again in the Key.algorithm attribute).
>>>>
>>>> Am I missing something ? Does anyone else find this confusing ?
>>>>
>>>> I think the confusion could be resolved by
>>>> (i) replacing the AlgorithmIdentifier argument to sign/verify/encrypt/decrypt with AlgorithmParameters.
>>>> (ii) for HMAC, the params provided to sign/verify must be null, as
>>>> the hash algorithm should have been provided when the Key was
>>>> created/imported/unwrapped
>>>
>>> I agree that it could be made clearer.
>>>
>>> When I was implementing PolyCrypt, my read of the specification was as follows:
>>> 1. The algorithm provided as a parameter to encrypt() specifies the
>>> encryption (and parameters) 2. Throw an error if the
>>> Key.algorithm.name<http://Key.algorithm.name> != algorithm.name<http://algorithm.name>
>>>
>>> That is, for the algorithm in the Key, everything besides the name is ignored.  This seems right to first order, but might be wrong, e.g., for HMAC, where you might want to compare the hash algorithm as well.
>>>
>>> It seems ambiguous to me whether the hash algorithm is a property of the key or a parameter to the operation. Another source of confusion.
>>>
>>>
>>> I'm leery of removing the algorithm parameter from encrypt(), if only because it seems really confusing and non-idiomatic.
>>>
>>> What idiom, and why do you say it's confusing ? The algorithm is a property of the key, so it's confusing that I need to re-specify it as a method parameter. That only seems to introduce an unnecessary failure path and give the incorrect impression to developer that they have some choice about the algorithm here. They don't. It's implicit in the Key.
>>>
>>> I don't think it's terrible to have the algorithm specified in two
>>> places, as long as its clear how those two specifications relate to
>>> each other
>>>
>>> It's not clear now. IIUC, anything in the method AlgorithmIdentifier that is also a property of the Key must match. Anything else is a method parameter.
>>>
>>> A particularly confusing case is when there are both algorithm and
>>> method parameters. For example, suppose a create an AES-CBC key with
>>> { name : "AES-CBC", params: { length: 128 } }. Am I supposed to
>>> write
>>>
>>> encrypt( { name: "AES-CBC", { "length" : 128, "iv" : iv } }, ... )
>>>
>>> ?
>>>
>>> If I'm allowed to miss out the length here, why is it that it makes sense to miss out some of the Key properties and not others (the algorithm name itself) ?
>>>
>>> This could be completely cleaned up by only specifying the "params" member in the methods. Specifically by defining an OperationParameters for that thing and derving the operation parameters objects from that. This would provide a clear separation between algorithm and operation parameters.
>>>
>>> ...Mark
>>>
>>>
>>>
>>>> As a side note, I believe that to generate a HMAC key we need to specify the key length. At least according to FIPS 198-1 the key, K, can be of any length. So, either we require in WebCrypto that it is a particular length (say, the same size as the hash function), or we need a length parameter to generateKey for HMAC.
>>>
>>> +1 on adding a length parameter.
>>>
>>> --Richard
>>>
>>>>
>>>> ...Mark
>
Received on Tuesday, 2 April 2013 19:03:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:16 UTC