Re: Preserving WebCrypto Key usages in JWK

(combining responses, as they are very similar)

14 нояб. 2013 г., в 10:27, Graham Steel <graham@cryptosense.com> написал(а):

> Relying on the fact that decrypt and unwrap use different algorithms
> to keep the operations separated is a bad idea. Even if algorithms are
> not identical, they can be similar enough to cause serious problems
> (e.g. if they are variants of a counter mode and allow the same
> keystream to be produced).

Algorithms that are not identical will cause the operation to fail - the JWK key already contains an algorithm identifier that needs to be checked.

I agree that relying on contents of cyphertext being incompatible with other algorithms would have been crazy.


14 нояб. 2013 г., в 0:58, Mark Watson <watsonm@netflix.com> написал(а):

> ​My assumption has been that, in the absence of any text to the contrary, all algorithms that support decrypt also support unwrap, because we have defined unwrap == ( decrypt + import ) ​.​

Not sure if this should be the case - e.g. supporting regular encrypt/decrypt with AES-KW seems unnecessary, and maybe the opposite (supporting key wrapping with other AES variations) is unnecessary too?

>> I'm asking because if the sets of algorithms that support decryption and ones that support unwrapping don't intersect, then there is no problem.
>> 
> Well, you're right that the problem illustrated in my example wouldn't be a problem. But it could also be a problem that a key intended to be used for "decrypt" got given the usage "encrypt" etc. 

I think that this kind of problem is not necessarily something to solve at key format level. As mentioned in the bug, there are lots of possible meaningful restrictions (like, "only allowed to be used during business hours"), and hopefully we are not adding them all into key serialization.

I can't stress it strongly enough that having a key format with separate "use" and "uses" keys that have similar yet subtly different syntax and semantics is not a solution, it only perpetuates the problem by making it impenetrably confusing. I don't have a different solution to propose, but I'm still hopeful that there is no problem, or that it can be worked around in a less confusing manner.

- WBR, Alexey Proskuryakov

Received on Thursday, 14 November 2013 18:54:24 UTC