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>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]
> Sent: Tuesday, April 02, 2013 7:26 AM
> To: Richard Barnes
> Cc: Vijay Bharadwaj; 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> wrote:
>
> >
> > On Apr 2, 2013, at 10:00 AM, Mark Watson <watsonm@netflix.com> wrote:
> >
> >>
> >>
> >> Sent from my iPhone
> >>
> >> On Apr 2, 2013, at 1:46 AM, Vijay Bharadwaj <
> 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]
> >>> Sent: Saturday, March 30, 2013 9:52 AM
> >>> To: Richard Barnes
> >>> Cc: 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>
> wrote:
> >>>
> >>> On Mar 27, 2013, at 9:10 PM, Mark Watson <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 != 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
> >
>
>
>