Subject: [COSE] ECIES key transport?

From: Laurence Lundblade <[email-masked]>
Date: Wed, 22 Nov 2017 21:59:09 +0000

Has anyone done any work on ECIES key transport for COSE?

LL

---

From: Jim Schaad <[email-masked]>
Date: Wed, 22 Nov 2017 22:13:44 -0800

I am not sure what you mean by this, however from the brief description on
Wikipedia I think you are looking for the Direct ECDH algorithm w/ the AEAD
encryption algorithm (Section 12.4).

Jim

From: COSE [mailto:[email-masked]] On Behalf Of Laurence Lundblade
Sent: Wednesday, November 22, 2017 1:59 PM
To: cose <[email-masked]>
Subject: [COSE] ECIES key transport?

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 23 Nov 2017 18:19:31 +0000

I'm looking for a scheme that uses elliptic curves where the sender encrypts and the receiver decrypts. The receiver has given the sender some key material out of band in a one-time exchange that is secured by some other means.  The sender can't decrypt with the key material given by the receiver.

I understand how to do this with RSA and CMS  -- RSA OEAP to wrap an AES CEK, but not yet how to do it with EC and COSE.

The integration of both integrity protection and data enveloping is nice, but it's mostly the data protection I'm after.

I did look at 12.4, but ephemeral-static nor static-static seem right. 12.5 seems closer.

Thanks!

LL

________________________________
From: COSE <[email-masked]> on behalf of Jim Schaad <[email-masked]>
Sent: Wednesday, November 22, 2017 10:13 PM
To: Laurence Lundblade; 'cose'
Subject: Re: [COSE] ECIES key transport?

I am not sure what you mean by this, however from the brief description on Wikipedia I think you are looking for the Direct ECDH algorithm w/ the AEAD encryption algorithm (Section 12.4).

Jim

LL

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 23 Nov 2017 21:42:55 +0200

> I did look at 12.4, but ephemeral-static nor static-static seem right. 12.5 seems closer.

Something like this might do (enveloped structure, as simple encrypted
does not seem to suffice):

84                                       -- Top level array
    51                                   -- Wrapping bstr, 17 bytes.
        A2                               -- Two headers
            01 03                        -- AES-256-GCM
            05 4C                        -- IV, 12 bytes
                <12 bytes of random IV>
   A0                                    -- Empty unprotected
   <ciphertext, including bstr header>
   A3                                    -- Recipients
       40                                -- Empty protected
       A3                                -- Unprotected
           01 38 18                      -- ECDH-ES+HKDF-256
           20 A3                         -- Ephemeral key, 3 fields.
               01 01                     -- OKP
               20 04                     -- X25519
               21 58 20                  -- X25519 public key.
                   <32 bytes pubkey>
       F6                                -- NULL

That seems to be 85-93 bytes of overhead (60 of those are crypto)
depending on the message size.

-Ilari