I don't think we should standardize draft-jones-jose-aes-gcm-key-wrap-00. No
rationale is apparent. We already have an AES-based key wrap algorithm (A128KW,
A256KW), which has a 64-bit size overhead. The AES-GCM key wrap algorithm in
this draft add almost no useful properties, but has a 224-bit size overhead.
I like the concatenation of the IV, ciphertext, and tag byte arrays. But doing
this here while content encryption serializes the same values as dot-separated
B64 blobs does smell of poor ad hoc design. It is nice to highlight how a
previous choice complicates extending JOSE to other algorithms, but only if we
then fix that previous choice.
If the additional authenticated data (AAD) was used to bind the CEK algorithm
id (or other context info, as ConcatKDF does) to the wrapped key, then there
would at least be an extra security property that would make this key wrap
algorithm worth considering. For instance, instead of AAD being empty, AAD
could be the "key wrap: " + "enc" value.
By reusing a CEK algorithm as a KEK algorithm, and supporting direct
encryption, we substantially increase the risk that an attacker can rearrange
some encrypted content so a legitimate recipient treats it as an encrypted key
leading to security flaws.
For example, Alice sends "Start of PIN = 8" confidentially to Bob:
{alg:dir,enc:A128GCM,kid:1}..iv.ciphertext.tag
An attacker seeing this JOSE message learns nothing about the 1st digit of the
PIN.
But if the attacker sends 10 messages to Bob for 10 guess of that digit:
{alg:A128GCMKW,enc:A128GCM,kid:1}.iv|ciphertext|tag.ivN.ciphertextN.tagN
where ivN.ciphertextN.tagN are calculated using an AES key of "Start of PIN =
<N>", then 9 messages will cause errors, while 1 message will be accepted --
revealing the supposedly confidential information in 10 guesses instead of
2^128.
Actually the above attack does not quite work for the compact encoding as AAD
is never empty for content encryption. I not certain for the JSON encoding. In
any case, an explicit and unambiguous AAD value for key wrapping would be good.
Finally, a key wrap algorithm like this should go to the IETF crypto group
(CRFG) instead of being invented in JOSE. We have already spent a year
unpicking a JOSE-special AEAD algorithm.
--
James Manger
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Jim Schaad
> Sent: Wednesday, 26 June 2013 2:53 AM
> To: [email protected]
> Subject: [jose] Issue #13 - use AES-GCM for Key Wrapping
>
> We now have two documents – one from Richard and one from Mike – which
> provide the two different ways that have been proposed for doing key
> wrapping with an AEAD algorithm.
>
> Please review the two documents and provide comments to the list.
>
> Jim
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
