W3C home > Mailing lists > Public > public-xmlsec@w3.org > June 2009

Re: ACTION-301: Example of KEM message and how to create it

From: Pratik Datta <pratik.datta@oracle.com>
Date: Mon, 08 Jun 2009 11:59:04 -0700
Message-ID: <4A2D5F78.1060403@oracle.com>
To: Magnus Nyström <magnus@rsa.com>
CC: XMLSec WG Public List <public-xmlsec@w3.org>
Ok, so the EncryptedKey is still inline with KEM, thats good.

Can you also also comment on the whether NIST Suite B includes ECIES? I 
see in the page 108 of 
that is says the ECIES of ANSI 9.63 is not allowed.  Is that different 
from the ISO ECIES?  We definitely need to support a NIST approved 
encryption, as that is one of major factors for supporting elliptic 
curves in the first place.  So maybe we need to have two EC encryption 
mechanims - one NIST approved and the other with KEM benefits.


Magnus Nyström wrote:
> Assuming the KDF has certain properties relating to ECIES-KEM (in 
> particular the inclusion of the public ephemeral key in the key 
> derivation) we would not, since in the case of EC (or DL more 
> generally) we're first generating a random key pair (the ephemeral key 
> pair) and from that we're generating a shared key which in turn is 
> used to encrypt something - be it some data or a content-encryption 
> key. So this is OK and in line with KEM.
> As I mentioned on the call this week, you will have the same 
> functionality with the ECDH agreement method but the benefit of KEM is 
> that we're introducing a framework for key encapsulation that fits all 
> public-key systems and which also has some provable security benefits.
> -- Magnus
> On Wed, 3 Jun 2009, Pratik Datta wrote:
>> Are we losing the value of Key Encapsulation, if we use the 
>> EncryptedKey mechanism? (I know I had asked for it, but I am 
>> wondering if it is the right thing to do)
>> What I understood of the KeyEncapulation presentation in the F2F is 
>> that if you generate a symmetric key first, and then encrypt it, it 
>> results in looser or no proof of security. The better thing is to not 
>> generate the symmetric key directly, but use the ECIES-KEM algorithm 
>> to generate a symmetric key from the recepient's public key and the 
>> ephemeral key, and then encrypt the data directly with this generated 
>> symmetric key.
>> Pratik
>> Magnus Nyström wrote:
>>> This is an attempt to respond to ACTION-301 that I got yesterday. 
>>> Given the schema in my earlier proposal
>>> http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0056.html
>>> one can construct the following example <xenc:EncryptedKey> element:
>>> <xenc:EncryptedKey
>>>   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
>>>   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>>>   xmlns:dsig11="http://www.w3.org/2009/xmldsig11#"
>>>   xmlns:dkey="http://www.w3.org/2009/xmlsec-dkey#"
>>>   xmlns:kem="http://www.w3.org/2009/xmlsec-kem#">
>>>   <xenc:EncryptionMethod
>>>     Algorithm="http://www.w3.org/2009/xmlenc11#GenericHybridCipher">
>>>     <kem:GenericHybridCipherMethod>
>>>       <kem:KeyEncapsulationMethod
>>>         Algorithm="http://www.w3.org/2009/xmlenc11#EC-KEM-KTS">
>>>         <dkey:KeyDerivationMethod Algorithm="KDF2"/>
>>>         <kem:KeyLen>16</kem:KeyLen>
>>>       </kem:KeyEncapsulationMethod>
>>>       <kem:DataEncapsulationMethod
>>>         Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
>>>     </kem:GenericHybridCipherMethod>
>>>   </xenc:EncryptionMethod>
>>>   <ds:KeyInfo>
>>>     <dsig11:ECKeyValue>
>>>       <dsig11:NamedCurve URI="urn:oid:1.2.840.10045.3.1.7"/>
>>>       <dsig11:PublicKey>MIIB</dsig11:PublicKey>
>>>     </dsig11:ECKeyValue>
>>>   </ds:KeyInfo>
>>>   <xenc:CipherData>
>>>     <xenc:CipherValue>DEADBEEF</xenc:CipherValue>
>>>   </xenc:CipherData>
>>> </xenc:EncryptedKey>
>>> In the above, what has happened is:
>>> 1) EncryptionMethod is "GenericHybrid" - as in ISO/IEC 18033 and S/MIME
>>> 2) There is a parameter set for GenericHybrid that gives
>>>    a) the key encapsulation method (EC-KEM-KTS for Elliptic Curve Key
>>>       Encapsulation Method - Key Transport Scheme (since we're doing 
>>> key
>>>       wrapping here), along with its params (derived key length and key
>>>       derivation method, leveraging the DerivedKeys schema)
>>>    b) the data encapsulation method (AES key wrap in this case)
>>> 3) The key info does *not* need the AgreementMethod even though I
>>>    suggested this earlier. I realized it is not needed as we have 
>>> already
>>>    specified the encapsulation scheme as EC-KEM-KTS, and so this
>>>    element simply contains an ECKeyValue that is the recipient's 
>>> public key
>>> 4) The CipherData is the concatenation of the ephemeral public key 
>>> of the
>>>    originator (as an octet string) and the wrapped key.
>>> For RSA, we would have the same structure, it is just that instead 
>>> of the (algorithm identifier being RSA-KEM-KTS and the) ephemeral 
>>> key we would have the CipherData consisting of the concatenation of 
>>> the public-key encrypted random value and the wrapped key.
>>> (And in addition this structure brings us pretty close to "ordinary" 
>>> RSA key transport as Pratik was asking for.)
>>> -- Magnus
Received on Monday, 8 June 2009 18:59:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:11 UTC