From: Magnus Nyström <magnus@rsa.com>

Date: Wed, 10 Jun 2009 10:51:40 +0200 (W. Europe Daylight Time)

To: XMLSec WG Public List <public-xmlsec@w3.org>

Message-ID: <Pine.WNT.4.64.0906101045150.7624@W-JNISBETTEST-1.tablus.com>

Date: Wed, 10 Jun 2009 10:51:40 +0200 (W. Europe Daylight Time)

To: XMLSec WG Public List <public-xmlsec@w3.org>

Message-ID: <Pine.WNT.4.64.0906101045150.7624@W-JNISBETTEST-1.tablus.com>

Responding to Pratik's question on use of NIST approved mechanisms. First, note that ECIES is not the same mechanism as ECIES-KEM. Sec. 7 of NIST SP 800-56 states that a key transport scheme may be obtained by combining an appropriate ECC key agreement scheme with an approved key wrapping scheme. ECIES in X9.63 provides the former (it meets item 3 on page 90) but not the latter, hence it is not approved. ECIES-KEM in 18033-2 (and hopefully soon in XMLEnc) with data encapsulation mechanism = AES-KeyWrap provides both - under the assumption that ECIES-KEM in 18033-2 fits the other requirements of NIST SP 800-56, e.g., acceptable KDF and its inputs. -- Magnus On Mon, 8 Jun 2009, Pratik Datta wrote: > 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 Wednesday, 10 June 2009 08:52:26 UTC

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