Re: Key wrapping and padding

Sent from my iPhone

On Dec 19, 2013, at 6:22 PM, Ryan Sleevi <sleevi@google.com> wrote:




On Thu, Dec 19, 2013 at 8:57 AM, Mark Watson <watsonm@netflix.com> wrote:

> All,
>
> We have defined our "wrap" operation to be the concatenation of export and
> encrypt. However, we have both:
> - export formats that are arbitrary length (e.g. JWK, SPKI)
>

Out of curiosity, who/why would you ever wrap a subject public key info?
Why turn a public key into a secret?


Good point, although I guess our API supports it unless we say it doesn't.
I just listed the arbitrary length key formats without thinking about
applications.



> - encryption methods which accept only specific lengths (e.g. AES Key Wrap
> which is RFC3394)
>
> So we have a problem. I can see 3 solutions:
>
> (a) disallow wrapping for these combinations of key format and encryption
> algorithm (unwrap can still be supported - it's just the wrappers
> responsibility to ensure the payload is an appropriate length)
>

Unwrap of arbitrary contents would still be unsupported, correct? Or are
you suggesting that implementations have an implicit padding scheme?


Is there a typo in your question ?

Unwrap would be supported, but it would be the responsibility of the
(non-WebCrypto) wrapper to ensure the payload was both a supported length
and valid according to the key format.

For example the wrapper could pad a JWK with white space before the closing
bracket.

 ...Mark



>  (b) specify padding schemes on the key format side - i.e. specify how to
> construct a JWK which is always a multiple of 8 bytes for AES-KW (this is
> easy)
>
 (c) specify padding schemes on the encryption algorithm side - i.e.
> specify how to turn the restricted-length enc alg into a arbitrary length
> enc alg
>
>
Specifying our own padding schemes is almost certainly the path of madness.
The choice of padding scheme can have very real effect on the security
properties of a given algorithm - and be used to reveal and/or exploit the
stream. Consider the attacks on TLS, which specifically leveraged the
padding to act as a discriminant and produce a Bleichenbacher oracle.


>  Comments ? Preferences ?
>

Of these, (a) is the only one that would seem to pass the cryptographic
smell test.

If this is unsuitable for certain use cases, then I'm all in favour of
proposing new, well-reviewed wrap/unwrap algorithms that support arbitrary
length (... preferably ones with built in authentication, since the moment
you begin to talk multiple block sizes, "there be dragons" pops up again),
and then look at what the odds are for being able to shepherd such an
algorithm through WGLC/CR appropriately.


>
> ...Mark
>
>
>