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

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 Wednesday, 3 June 2009 19:44:53 UTC