Hi, first of all please accept my apologizes, I know this is a question
more related to OpenVPN, but I think that the problem lies in the cert
authority and client/server certificate generation step with OpenSSL, so
I'm also posting it here, hoping for a solution.

I'm trying to make an OpenVPN setup with Elliptic Curves cryptography
and SHA-512 on Linux Debian. This seems to be very hard, I didn't find
any howto on the web :( if and when I will manage to get the whole thing
up and running I will write a detailed howto, so any help is appreciated!

As a premise: yes, I've recompiled OpenVPN using the latest OpenSSL
version (see below). My suspect is that I made some mistake in the
certificate generation process but I can't find it.

I also posted this issue at https://forums.openvpn.net/topic8404.htmlbut there I included a lot of information more strictly related to my
OpenVPN configuration, I will include here just the steps I used to
setup the PKI with OpenSSL. Here is what I did:

1) downloaded OpenSSL 1.0.0, configured and installed in
/usr/local/openssl (to avoid removing the already installed openssl
0.9.8 which looks like it's a crucial packet for everything on my
system) with:
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
I am calling the new openssl version with the "openssl-new" alias

My OpenVPN configuration does not work, I receive this error in the logs:
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
TLS_ERROR: BIO read tls_read_plaintext error: error:1408A0C1:SSL
routines:SSL3_GET_CLIENT_HELLO:no shared cipher
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
but, as I said, this is more related to OpenVPN and it is detailed in
the forum post I linked above. What I'd like to know from more
experienced OpenSSL users here is: did I perform correctly steps
1)...7)? Please help, I'm really in need of this ._. I will write a
complete and detailed howto as a small compensation for the community!

When i searched on it, it seemed that ECDH requires specified named curve, and openVPN does not have a means of specifying it. Also, it seems that ECDSA works only with SHA-1 (I also would like to know, why it cannot take any 160 bit hash). I searched about it few weeks ago and relevant messages were few months old.

On 07/11/2011 05:27 AM, [hidden email] wrote:
> When i searched on it, it seemed that ECDH requires specified named
> curve

You need to specify the curve's name, like this:

openssl ecparam -name sect571k1

but this should only be done in the parameters generation stage, the
generated certificates should contain this information by themselves, so
I don't think specifying it to OpenVPN should be needed.

> Also, it seems that ECDSA works only with SHA-1

This has been marked as a bug and it was fixed in the most recent
versions of OpenSSL. I've met this issue with OpenSSL 0.9.8x (I don't
remember the "x"), this version is indeed the deafult one for both
Debain Squeeze and Ubuntu Natty, so this is quite annoying (I like
Debian a lot, but its repos are often too much outdated). As I've
written before, I've manually compiled OpenSSL v1.0.0 and I can read the
following for my certificate, as expected:

ECDSA is the elliptical curve (discrete-logarithm-based) variant of DSA, the Digital Signature Algorithm. DSA was developed by the US National Security Agency as a means of creating prime-factorization-based signatures without providing code paths which would permit the encryption of arbitrary data.

The curve in use can be named (reducing the size of the subjectPublicKeyInfo), or it can be specified explicitly (like the above).

(I included the hash to show that it is indeed legitimate to have a different hash size. I should note that I didn't generate this with OpenSSL, and I don't know how OpenSSL generates the sPKI.)

Also, note the large number of 0xff bytes in the prime. These can be eliminated if you're willing to pay Certicom's "point compression" patent license fee.

The patent situation around Elliptical Curve is a bit murky, but (IANAL) I am proceeding as though the narrow interpretation promoted by the RSA Crypto FAQ is correct: the patent situation is the opposite of what was the case for DH and RSA: the algorithm itself is not specifically described in any particular patent, only particular efficient implementations of it -- such as 'an efficient algorithm using only left-shift and add instructions'. The reason why there's murkiness is because everyone who does things is pretty much counseled to avoid looking at the patents -- if the patents are known, then it's evidence of willful (rather than accidental) infringement and any punitive damages for such are tripled. However, Professer Dan J Bernstein says that his prime at 256 bits is unpatented and there's prior art from several years before the Certicom patents were filed -- and there was an infringement lawsuit brought by Certicom against Sony, which was dismissed in 2009.

> When i searched on it, it seemed that ECDH requires specified named curve,
> and openVPN does not have a means of specifying it. Also, it seems that
> ECDSA works only with SHA-1 (I also would like to know, why it cannot take
> any 160 bit hash). I searched about it few weeks ago and relevant messages
> were few months old.
>
>
> Citējot Gaglia <[hidden email]>:
>
> On 07/05/2011 03:23 PM, Gaglia wrote:
>> I'm trying to make an OpenVPN setup with Elliptic Curves cryptography
>> and SHA-512 on Linux Debian.
>
> No idea anybody, really? :(
>

> ECDSA is the elliptical curve (discrete-logarithm-based) variant of DSA, the
> Digital Signature Algorithm. DSA was developed by the US National Security
> Agency as a means of creating prime-factorization-based signatures without
> providing code paths which would permit the encryption of arbitrary data.
>
> ANSI X9 has object identifiers for ECDSA with a variety of hashes.
>
> [SNIP]
>
> The patent situation around Elliptical Curve is a bit murky, but (IANAL) I
> am proceeding as though the narrow interpretation promoted by the RSA Crypto
> FAQ is correct: the patent situation is the opposite of what was the case
> for DH and RSA: the algorithm itself is not specifically described in any
> particular patent, only particular efficient implementations of it -- such
> as 'an efficient algorithm using only left-shift and add instructions'. The
> reason why there's murkiness is because everyone who does things is pretty
> much counseled to avoid looking at the patents -- if the patents are known,
> then it's evidence of willful (rather than accidental) infringement and any
> punitive damages for such are tripled. However, Professer Dan J Bernstein
> says that his prime at 256 bits is unpatented and there's prior art from
> several years before the Certicom patents were filed -- and there was an
> infringement lawsuit brought by Certicom against Sony, which was dismissed
> in 2009.

Dismissed or withdrawn? It seems to me Certicom stopped bitting a hand
that feeds it.

Jeff

> On Sun, Jul 10, 2011 at 8:27 PM, <[hidden email]> wrote:
>>
>> When i searched on it, it seemed that ECDH requires specified named curve,
>> and openVPN does not have a means of specifying it. Also, it seems that
>> ECDSA works only with SHA-1 (I also would like to know, why it cannot take
>> any 160 bit hash). I searched about it few weeks ago and relevant messages
>> were few months old.
>>
>>
>> Citējot Gaglia <[hidden email]>:
>>
>> On 07/05/2011 03:23 PM, Gaglia wrote:
>>>
>>> I'm trying to make an OpenVPN setup with Elliptic Curves cryptography
>>> and SHA-512 on Linux Debian.
>>
>> No idea anybody, really? :(
>>
>
>

Excuse me, I got lost somewhere... Does this mean that it is not
possible to use EC crypto with OpenSSL because the algorithms are
patented? If so, why OpenSSL does provide support to EC crypto?

Sorry, I don't want to start a religion war, but as an EU citizen (and
as like as many other humans too, I guess), I find unbelievably absurd
the idea of patenting the mathematical description of an algorithm.

Let's put it in this way: in the unlikely and deplorable event of an
user willing to illegally use patented EC cryptography with OpenSSL for
personal use (hence assuming responsibility for any consequence), could
he/she use OpenSSL? Is OpenSSL able to handle this kind of crypto? I
guess yes, for (as in the first post of the thread) I managed to
apparently do a lot of things with the curve of my choice... My question
is, apart from legal considerations: did I do something wrong in the
certificate generation process?

ECDSA public key token to/from binary

I have to extract a binary (unsigned char
*) representation of a public key from an ECDSA openssl key structure.
Later, I want to use that binary to reconstruct an openssl public
key structure that I can use to verify a signature. The curve is
fixed - P521.

I don't need any certificates, just
a public key that I can embed in the verifier.

Version of ECDSA available in openssl 1.0.0d supports only SHA1. (maybe there are patches, which adds other hash functions, but default build on win32 supports only sha1).ECDH and ECDSA are not guaranteed to use the same curve. At least with s_server curve for ECDSA is specified in certificate, but curve for ECDH is specified by -named_curve argument. Other programs probably use something similar. Last time i searched openvpn forums for anything ECC related, did not found anything (probably bad keywords, but also might be lack of ECC support).

ECDSA is the elliptical curve (discrete-logarithm-based) variant of DSA, the Digital Signature Algorithm. DSA was developed by the US National Security Agency as a means of creating prime-factorization-based signatures without providing code paths which would permit the encryption of arbitrary data.

The curve in use can be named (reducing the size of the subjectPublicKeyInfo), or it can be specified explicitly (like the above).

(I included the hash to show that it is indeed legitimate to have a different hash size. I should note that I didn't generate this with OpenSSL, and I don't know how OpenSSL generates the sPKI.)

Also, note the large number of 0xff bytes in the prime. These can be eliminated if you're willing to pay Certicom's "point compression" patent license fee.

The patent situation around Elliptical Curve is a bit murky, but (IANAL) I am proceeding as though the narrow interpretation promoted by the RSA Crypto FAQ is correct: the patent situation is the opposite of what was the case for DH and RSA: the algorithm itself is not specifically described in any particular patent, only particular efficient implementations of it -- such as 'an efficient algorithm using only left-shift and add instructions'. The reason why there's murkiness is because everyone who does things is pretty much counseled to avoid looking at the patents -- if the patents are known, then it's evidence of willful (rather than accidental) infringement and any punitive damages for such are tripled. However, Professer Dan J Bernstein says that his prime at 256 bits is unpatented and there's prior art from several years before the Certicom patents were filed -- and there was an infringement lawsuit brought by Certicom against Sony, which was dismissed in 2009.

Again, I'm not a lawyer. I just read things. See e.g. the links from http://en.wikipedia.org/wiki/ECC_patents , which do a reasonably comprehensive roundup of the issues involved for the layperson.

-Kyle H

On Sun, Jul 10, 2011 at 8:27 PM, <[hidden email]> wrote: > When i searched on it, it seemed that ECDH requires specified named curve, > and openVPN does not have a means of specifying it. Also, it seems that > ECDSA works only with SHA-1 (I also would like to know, why it cannot take > any 160 bit hash). I searched about it few weeks ago and relevant messages > were few months old. > > > Citējot Gaglia <[hidden email]>: > > On 07/05/2011 03:23 PM, Gaglia wrote: >> I'm trying to make an OpenVPN setup with Elliptic Curves cryptography >> and SHA-512 on Linux Debian. > > No idea anybody, really? :( >

On Fri, Jul 15, 2011 at 10:32 AM, Gaglia <[hidden email]> wrote:
> On 07/15/2011 08:23 AM, Kyle Hamilton wrote:
>> ...
>
> Excuse me, I got lost somewhere... Does this mean that it is not
> possible to use EC crypto with OpenSSL because the algorithms are
> patented? If so, why OpenSSL does provide support to EC crypto?

EC is considered to be a patent minefield. Some people (RSA Data
Security) say that it's possible to implement EC cryptography using
different types of algorithms which are not covered by the patents.
Other people (Bruce Schneier, US NSA) say that the mechanism itself is
patented, not simply specific algorithms for calculation.

The US NSA licensed from Certicom the right to sublicense the EC
algorithms used in "Suite B". My understanding is that OpenSSL
received a gift from Sun Microsystems of its EC sublicense from NSA.

> Let's put it in this way: in the unlikely and deplorable event of an
> user willing to illegally use patented EC cryptography with OpenSSL for
> personal use (hence assuming responsibility for any consequence), could
> he/she use OpenSSL? Is OpenSSL able to handle this kind of crypto?

Yes. And, given OpenSSL's EC sublicense gift, the user of OpenSSL (if
my understanding is correct, IANAL!) is also licensed.

> I
> guess yes, for (as in the first post of the thread) I managed to
> apparently do a lot of things with the curve of my choice... My question
> is, apart from legal considerations: did I do something wrong in the
> certificate generation process?

Nobody can know unless you post the certificate in question, or at the
least the dump of the x509 structure you have.

One thing that might cause a problem is if you enabled EC point
compression in your OpenSSL compile, as I don't believe OpenSSL has a
license for that.

On 07/15/2011 05:36 PM, Kyle Hamilton wrote:> ...
>
> EC is considered to be a patent minefield. Some people (RSA
Data
> Security) say that it's possible to implement EC cryptography
using
> different types of algorithms which are not covered by the
patents.
> Other people (Bruce Schneier, US NSA) say that the mechanism
itself
> is patented, not simply specific algorithms for calculation.

I'll make just one comment here: U.S. patent law, at least as
applied to software, is a festering cesspool.
> The US NSA licensed from Certicom the right to sublicense the
EC
> algorithms used in "Suite B". My understanding is that
OpenSSL
> received a gift from Sun Microsystems of its EC sublicense
from NSA.

OpenSSL (in the guise of its corporate manifestation, the OpenSSL
Software Foundation), is a direct NSA sublicensee
(http://opensslfoundation.com/testing/docs/NSA-PLA.pdf). Note that
sublicense only covers some prime field ECC; for the rest of it
"seek competent legal advice". Also note the license is
nontransferrable.

> On Fri, Jul 15, 2011 at 10:32 AM, Gaglia <[hidden email]> wrote:
>> On 07/15/2011 08:23 AM, Kyle Hamilton wrote:
>>> ...
>>
>> Excuse me, I got lost somewhere... Does this mean that it is not
>> possible to use EC crypto with OpenSSL because the algorithms are
>> patented? If so, why OpenSSL does provide support to EC crypto?
>
> EC is considered to be a patent minefield. Some people (RSA Data
> Security) say that it's possible to implement EC cryptography using
> different types of algorithms which are not covered by the patents.

Consider the source: RSA's strongest competition is ECC and Certicom
(or should we say ECC's past competition was RSA?). RSA Data Security
managed to implant RSA into DSA with heavy lobbying, but RSA's glory
days are behind them or gone. The SecurID scandal is another testament
to the fact.

I often wonder why open source implementations even care: (1) the
implementations are often available through out the world, where US
patent law does not apply, (2) for US domestic uses, push the burden
of licensing compliance onto the user (or #define out any code found
to be offense by *real* lawyers), and (3) most implementors don't have
the money to make it worthwhile to litigate.

For (3), Certicom most likely won't make a dime, so there's no
monetary relief or benefit even if they incur loss or damages. And at
best, they will probably be granted an injunction against US
distribution. Guess wheat folks will do in that case (what did they do
with RSA - download form Australia or Germany or ...).

Also, in documentation on pkeyutl program is mentioned, that ECDSA supports only sha1http://www.openssl.org/docs/apps/pkeyutl.html#(subsection "EC ALGORITHM")Documentation on dgst program did not mention any limitations for choice of hash, there only was said, that sha1 is preferred choice.

That EC key used in failed example above is based on secp521r1 and was generated by openssl.

sha256 worked. (both for dgst and for req)If i understand correctly, ECDSA algorithm only needs hash as a defined lengthbitstring, so adapting ripemd in place of sha1 should have been easier than sha256 (because ripemd has the same length as sha1, sha256 is longer).

where EC_GROUP is setup for P-521 (have a look at
EC_GROUP_new_by_curve_name), EC_POINT is the public key from the
previous call; it dumps the coordinates to x and y, where you can use
BN_bn2bin or whatever you like. You'd reverse it with

While this is the manual way to do it that you've asked for, there are
a few caveats that can affect security so if possible I'd consider
standard (ANSI? P1363?) methods like EC_POINT_point2bn and so on.
Those also easily allow point compression if that's needed. In
general, poke around in include/openssl/ec.h and there is lots of
useful functionality, although not as much documentation.

> I have to extract a binary (unsigned char *) representation of a public key
> from an ECDSA openssl key structure. Later, I want to use that binary to
> reconstruct an openssl public key structure that I can use to verify a
> signature. The curve is fixed - P521.
>
> I don't need any certificates, just a public key that I can embed in the
> verifier.
>
> Can someone point me toward sample code? Or, can someone give me some
> hints?
>
> --
> Ken Goldman [hidden email]> 914-784-7646 (863-7646)
>

*ecPubKey = EC_KEY_new(); group = EC_GROUP_new_by_curve_name(nid); ec_point = EC_POINT_new(group); EC_KEY_set_group(*ecPubKey,
group); EC_POINT_oct2point(group,
ec_point,
publicKey,
publicKeyLength,
NULL); EC_KEY_set_public_key(*ecPubKey,
ec_point);
> int EC_POINT_set_affine_coordinates_GFp(const EC_GROUP *, EC_POINT
*,
> const BIGNUM *x, const BIGNUM *y, BN_CTX *);
>
> followed by
>
> int EC_KEY_set_public_key(EC_KEY *, const EC_POINT *);
>
> While this is the manual way to do it that you've asked for, there
are
> a few caveats that can affect security so if possible I'd consider
> standard (ANSI? P1363?) methods like EC_POINT_point2bn and so on.
> Those also easily allow point compression if that's needed. In
> general, poke around in include/openssl/ec.h and there is lots of
> useful functionality, although not as much documentation.