Better understanding of EC encryption API

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Better understanding of EC encryption API

Matt Loah
Hi all,

While the public key in the context of OpenSSL Elliptic Curves algorithm is stored as a EC_POINT pointer... and the private key as a BIGNUM pointer... which functions (or which kind of them) should be called to encrypt & to decrypt a message in C/C++ ?

Matt L.

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Better understanding of EC encryption API

Matt Caswell-2


On 26/11/15 19:18, Matt Loah wrote:
> While the public key in the context of OpenSSL Elliptic Curves algorithm
> is stored as a EC_POINT pointer... and the private key as a BIGNUM
> pointer... which functions (or which kind of them) should be called to
> encrypt & to decrypt a message in C/C++ ?

OpenSSL only supports ECDH and ECDSA, neither of which can be used to
perform encryption.

Matt
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Better understanding of EC encryption API

Jan Danielsson-3
In reply to this post by Matt Loah
On 26/11/15 20:18, Matt Loah wrote:
> While the public key in the context of OpenSSL Elliptic Curves algorithm is
> stored as a EC_POINT pointer... and the private key as a BIGNUM pointer...
> which functions (or which kind of them) should be called to encrypt & to
> decrypt a message in C/C++ ?

   OpenSSL doesn't support it out of the box.  What you're looking for
is something akin to
https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme.

   Ladar Levison has written an implementation which uses OpenSSL as a
backend.  I tried finding it for you, but my connection (mobile, on
train) is so bad that I couldn't be bothered to keep trying.

   If you google for it I'm sure you'll find it pretty easily.  If you
can't find it -- it's not difficult to do it from scratch using that
wikipedia page and the OpenSSL reference manuals.

   /Jan

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Better understanding of EC encryption API

Viktor Dukhovni
In reply to this post by Matt Caswell-2
On Thu, Nov 26, 2015 at 07:59:22PM +0000, Matt Caswell wrote:

> On 26/11/15 19:18, Matt Loah wrote:
> > While the public key in the context of OpenSSL Elliptic Curves algorithm
> > is stored as a EC_POINT pointer... and the private key as a BIGNUM
> > pointer... which functions (or which kind of them) should be called to
> > encrypt & to decrypt a message in C/C++ ?
>
> OpenSSL only supports ECDH and ECDSA, neither of which can be used to
> perform encryption.

This is not entirely true, in sufficiently recent versions of
OpenSSL, ECDSA keys can be used with CMS to encrypt keys.

Just create an ECDSA private key and email cerficate (example
attached), and then encrypt and decrypt some data:

    $ printf "%s\n" sesame |
        openssl cms -binary -outform DER -aes-128-cbc -encrypt -recip cert.pem |
        openssl cms -binary -inform DER -decrypt -recip cert.pem -inkey key.pem
    sesame

Examining the structure we see ECDSA enveloped keys
( https://tools.ietf.org/html/rfc3278.html#section-3.1 ):

    $ printf "%s\n" sesame |
        openssl cms -binary -outform DER -aes-128-cbc -encrypt -recip cert.pem |
        openssl asn1parse -inform DER
    0:d=0  hl=4 l= 263 cons: SEQUENCE
    4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-envelopedData
   15:d=1  hl=3 l= 249 cons: cont [ 0 ]
   18:d=2  hl=3 l= 246 cons: SEQUENCE
   21:d=3  hl=2 l=   1 prim: INTEGER           :02
   24:d=3  hl=3 l= 178 cons: SET
   27:d=4  hl=3 l= 175 cons: cont [ 1 ]
   30:d=5  hl=2 l=   1 prim: INTEGER           :03
   33:d=5  hl=2 l=  81 cons: cont [ 0 ]
   35:d=6  hl=2 l=  79 cons: cont [ 1 ]
   37:d=7  hl=2 l=   9 cons: SEQUENCE
   39:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   48:d=7  hl=2 l=  66 prim: BIT STRING
  116:d=5  hl=2 l=  24 cons: SEQUENCE
  118:d=6  hl=2 l=   9 prim: OBJECT            :dhSinglePass-stdDH-sha1kdf-scheme
  129:d=6  hl=2 l=  11 cons: SEQUENCE
  131:d=7  hl=2 l=   9 prim: OBJECT            :id-aes128-wrap
  142:d=5  hl=2 l=  61 cons: SEQUENCE
  144:d=6  hl=2 l=  59 cons: SEQUENCE
  146:d=7  hl=2 l=  31 cons: SEQUENCE
  148:d=8  hl=2 l=  26 cons: SEQUENCE
  150:d=9  hl=2 l=  24 cons: SET
  152:d=10 hl=2 l=  22 cons: SEQUENCE
  154:d=11 hl=2 l=   3 prim: OBJECT            :commonName
  159:d=11 hl=2 l=  15 prim: UTF8STRING        :Viktor Dukhovni
  176:d=8  hl=2 l=   1 prim: INTEGER           :01
  179:d=7  hl=2 l=  24 prim: OCTET STRING      [HEX DUMP]:54480EC3C3C51599E1A058B4B8C467643E49067C9ED810C3
  205:d=3  hl=2 l=  60 cons: SEQUENCE
  207:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
  218:d=4  hl=2 l=  29 cons: SEQUENCE
  220:d=5  hl=2 l=   9 prim: OBJECT            :aes-128-cbc
  231:d=5  hl=2 l=  16 prim: OCTET STRING      [HEX DUMP]:D7A3A11E3A6ADE4A36050CCF7E123377
  249:d=4  hl=2 l=  16 prim: cont [ 0 ]

--
        Viktor.

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

cert.pem (672 bytes) Download Attachment
key.pem (246 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Better understanding of EC encryption API

Tim Hudson
In reply to this post by Jan Danielsson-3
On 27/11/2015 8:26 AM, Jan Danielsson wrote:

> On 26/11/15 20:18, Matt Loah wrote:
>> While the public key in the context of OpenSSL Elliptic Curves algorithm is
>> stored as a EC_POINT pointer... and the private key as a BIGNUM pointer...
>> which functions (or which kind of them) should be called to encrypt & to
>> decrypt a message in C/C++ ?
>    OpenSSL doesn't support it out of the box.  What you're looking for
> is something akin to
> https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme.
>
>    Ladar Levison has written an implementation which uses OpenSSL as a
> backend.  I tried finding it for you, but my connection (mobile, on
> train) is so bad that I couldn't be bothered to keep trying.

http://www.mail-archive.com/openssl-dev@.../msg28042.html

Tim.

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Better understanding of EC encryption API

Matt Caswell-2
In reply to this post by Viktor Dukhovni


On 27/11/15 04:07, Viktor Dukhovni wrote:

> On Thu, Nov 26, 2015 at 07:59:22PM +0000, Matt Caswell wrote:
>
>> On 26/11/15 19:18, Matt Loah wrote:
>>> While the public key in the context of OpenSSL Elliptic Curves algorithm
>>> is stored as a EC_POINT pointer... and the private key as a BIGNUM
>>> pointer... which functions (or which kind of them) should be called to
>>> encrypt & to decrypt a message in C/C++ ?
>>
>> OpenSSL only supports ECDH and ECDSA, neither of which can be used to
>> perform encryption.
>
> This is not entirely true, in sufficiently recent versions of
> OpenSSL, ECDSA keys can be used with CMS to encrypt keys.

Well, perhaps I should modify the statement to say
"OpenSSL only supports ECDH and ECDSA, neither of which can be used *by
themselves* to perform encryption."

Clearly you can use them in combination with other algorithms to achieve
encryption - but they don't do encryption themselves.

I'm not particularly familiar with CMS but from my very quick reading of
what is going on in your example is that the EC key is being used by
ECDH to agree a shared secret (in combination with a KDF). Then AES128
key wrapping is used to encrypt the CEK, followed by AES to actually
encrypt the data. So ECDH is not encrypting anything directly (it can't
- its not an encryption algorithm - it a key agreement algorithm).

Matt
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Better understanding of EC encryption API

Matěj Cepl
In reply to this post by Tim Hudson
On 2015-11-27, 09:28 GMT, Tim Hudson wrote:
> http://www.mail-archive.com/openssl-dev@.../msg28042.html

That’s
http://article.gmane.org/gmane.comp.encryption.openssl.devel/17997/ 
for those afflicted with gmane’s mangling of anything looking
like an email address.

Matěj

--
https://matej.ceplovi.cz/blog/, Jabber: [hidden email]
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
See, when the GOVERNMENT spends money, it creates jobs; whereas
when the money is left in the hands of TAXPAYERS, God only knows
what they do with it. Bake it into pies, probably. Anything to
avoid creating jobs.
    -- Dave Barry

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Better understanding of EC encryption API

Jeffrey Walton-3
In reply to this post by Jan Danielsson-3
>    OpenSSL doesn't support it out of the box.  What you're looking for
> is something akin to
> https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme.

+1 on ECIES.

If OpenSSL provided one additional, non core feature, ECIES would be
at the top of my list. Its hard to use incorrectly, and easy to use
correctly. Its also IND_CCA2, which provides a number of desirable
security properties.

In my day job, I recommend it whenever I come across a home grown
scheme rolled by the developers.

>    Ladar Levison has written an implementation which uses OpenSSL as a
> backend.  I tried finding it for you, but my connection (mobile, on
> train) is so bad that I couldn't be bothered to keep trying.
>

Speaking from experience, be careful of interop issues. I know of two
libraries that support ECIES out of the box. They are BouncyCastle and
Crypto++.

In the past BouncyCastle and Crypto++ could not interop even though
they both claim to follow P1363. IEEE did not publish test vectors, so
each library had a misinterpretation that ensured they did not
interop. Here were the issues for each library:

  * BouncyCastle
      - Label should be 8 octets

    * Crypto++
      - Length of the label specified in bits

BouncyCastle fixed their issue in version 1.53 (about 2 months ago).
Crypto++ is fixing their issue at 5.7 (in about 2 months).

If you need a "gold" standard, then use BouncyCastle's implementation,
version 5.7 or above.

Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Better understanding of EC encryption API

Viktor Dukhovni
In reply to this post by Matt Caswell-2
On Fri, Nov 27, 2015 at 09:36:41AM +0000, Matt Caswell wrote:

> >> OpenSSL only supports ECDH and ECDSA, neither of which can be used to
> >> perform encryption.
> >
> > This is not entirely true, in sufficiently recent versions of
> > OpenSSL, ECDSA keys can be used with CMS to encrypt keys.
>
> Well, perhaps I should modify the statement to say
> "OpenSSL only supports ECDH and ECDSA, neither of which can be used *by
> themselves* to perform encryption."

Of course, but I generally interpret requests for "encryption" with
EC to mean the ability to exchange encrypted messages with the
holder of an EC public key.  In which case, CMS provides a broadly
interoperable mechanism to do so.

> I'm not particularly familiar with CMS but from my very quick reading of
> what is going on in your example is that the EC key is being used by
> ECDH to agree a shared secret (in combination with a KDF).

Correct.

> Then AES128
> key wrapping is used to encrypt the CEK, followed by AES to actually
> encrypt the data. So ECDH is not encrypting anything directly (it can't
> - its not an encryption algorithm - it a key agreement algorithm).

Correct, as described in RFC 3278 the KEK from the key agreement
encrypts the CEK.  This supports multi-recipient messages with a
single CEK and (unavoidably) a separate KEK for each recipient
derived from the ephemeral-fixed key agreement.

The CMS API takes care of the internal details, but can be difficult
to learn because of its flexibility (signed or unsigned, encrypted
or unencrypted, detached signatures, ...).

--
        Viktor.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Better understanding of EC encryption API

Jeffrey Walton-3
In reply to this post by Jeffrey Walton-3
> In the past BouncyCastle and Crypto++ could not interop even though
> they both claim to follow P1363. IEEE did not publish test vectors, so
> each library had a misinterpretation that ensured they did not
> interop. Here were the issues for each library:
>
>   * BouncyCastle
>       - Label should be 8 octets
>
>     * Crypto++
>       - Length of the label specified in bits
>
> BouncyCastle fixed their issue in version 1.53 (about 2 months ago).
> Crypto++ is fixing their issue at 5.7 (in about 2 months).
>
> If you need a "gold" standard, then use BouncyCastle's implementation,
> version 5.7 or above.

That should be BouncyCastle 1.53 or above.

Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users