Re: Key wrapping and padding

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?


> - 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?


> (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
>
>
>