RE: Non-extratability Tainting of Keys

<Cleaning out history for readability (I hope)>

 

Wrapping a JWK in RSA:

 

This would appear to be workable based on good key sizes, but this is going
to be a very non-standard feature that is not supported by the current
crypto libraries.  I don't think that this is going to be an issue for you,
but something that you need to think about.

 

A JWK would look like:

 

{"kty":"oct","usage":"unwrap","k":"<base64url of key>",
xtr:"no","alg":"A256KW"} = 63+43 = 106

 

RSA-OAEP w/SHA-256 = k -2*hLen - 2 = 126 (for a 2048-bit key)

 

So yes that does fit.

 

The key wrap and content encryption algorithms would need to be part of the
UA - otherwise the key need needs to be extractable to the new algorithm.

 

Wrapping with AES-KW:

 

This would need to newer updated key AES key wrap algorithm that allows for
wrapped keys that are not a multiple of the AES block size.  Again this is
not a problem.

 

The content encryption algorithm would need to be part of the UA - otherwise
the key needs to be extractible to the new algorithm

 

Wrapping with ECDH:

 

The steps that are done for this are:

1.       Compute the key agreement secret using the non-extractable ECDH key

2.       Run a KDF function on the secret to generate a key

3.       Use the key as a key wrap decryption key to get the desired JWK
wrapped key.

 

The results of step 1 and step 2 currently have their extractability
controlled only by the passed in flags from the script and cannot be
controlled in the same way as the key transport method (i.e. RSA-OEAP) would
be done by including the bits with the wrapped key.

 

In this case only the final key would have the non-extractability flag could
be set by the sender in the JWK.  However one would be able to get any of
the outputs from step 2 or step 3 and decrypt the key outside of the UA.  So
there is no protection.

 

The final content encryption algorithm would need to be part of the UA -
otherwise the key needs to be extractable to the new algorithm.

 

Jim

 

Received on Wednesday, 11 September 2013 20:05:20 UTC