- From: Pratik Datta <pratik.datta@oracle.com>
- Date: Mon, 08 Jun 2009 11:59:04 -0700
- 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 http://csrc.nist.gov/groups/ST/toolkit/documents/SP800-56Arev1_3-8-07.pdf 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. Pratik 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