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

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