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). Citējot *Kyle Hamilton <aerow...@gmail.com> [1]*: > 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. > > 1.2.840.10045.4.3. and then one of the following: > > 1: ECDSA with SHA-224 > 2: with SHA-256 > 3: SHA-384 > 4: SHA-512 > > The information on the curve in use is part of > subjectPublicKeyInfo: > > Subject Public Key Info: > Public Key Algorithm: id-ecPublicKey > Public-Key: (521 bit) > pub: > 04:00:ef:07:81:ff:79:01:d3:10:a4:42:6b:d5:37: > a9:ed:6b:a4:1d:20:8a:20:b6:44:34:09:d9:3d:f0: > 69:0f:b2:65:3f:d9:dd:68:72:a7:2b:cd:d4:70:e9: > cb:21:dd:05:34:1b:4e:42:0f:65:63:5e:b9:24:a6: > 40:f6:cc:22:94:ea:3b:01:7f:65:38:09:33:b0:0d: > b3:91:b6:1d:4a:a7:9f:17:2e:56:4d:ff:14:d3:aa: > 65:5d:3a:3d:ba:c2:d9:30:30:41:73:14:3e:6e:c7: > 01:ae:af:52:b6:cc:31:6d:26:dd:39:dc:60:c8:b9: > 07:fb:21:38:ec:75:dc:0f:3b:b7:9d:44:35 > Field Type: prime-field > Prime: > 01:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: > ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: > ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: > ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: > ff:ff:ff:ff:ff:ff > A: > 01:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: > ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: > ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: > ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: > ff:ff:ff:ff:ff:fc > B: > 51:95:3e:b9:61:8e:1c:9a:1f:92:9a:21:a0:b6:85: > 40:ee:a2:da:72:5b:99:b3:15:f3:b8:b4:89:91:8e: > f1:09:e1:56:19:39:51:ec:7e:93:7b:16:52:c0:bd: > 3b:b1:bf:07:35:73:df:88:3d:2c:34:f1:ef:45:1f: > d4:6b:50:3f:00 > Generator (uncompressed): > 04:00:c6:85:8e:06:b7:04:04:e9:cd:9e:3e:cb:66: > 23:95:b4:42:9c:64:81:39:05:3f:b5:21:f8:28:af: > 60:6b:4d:3d:ba:a1:4b:5e:77:ef:e7:59:28:fe:1d: > c1:27:a2:ff:a8:de:33:48:b3:c1:85:6a:42:9b:f9: > 7e:7e:31:c2:e5:bd:66:01:18:39:29:6a:78:9a:3b: > c0:04:5c:8a:5f:b4:2c:7d:1b:d9:98:f5:44:49:57: > 9b:44:68:17:af:bd:17:27:3e:66:2c:97:ee:72:99: > 5e:f4:26:40:c5:50:b9:01:3f:ad:07:61:35:3c:70: > 86:a2:72:c2:40:88:be:94:76:9f:d1:66:50 > Order: > 01:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: > ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: > ff:ff:ff:fa:51:86:87:83:bf:2f:96:6b:7f:cc:01: > 48:f7:09:a5:d0:3b:b5:c9:b8:89:9c:47:ae:bb:6f: > b7:1e:91:38:64:09 > Cofactor: 1 (0x1) > Seed: > d0:9e:88:00:29:1c:b8:53:96:cc:67:17:39:32:84: > aa:a0:da:64:ba > Signature Algorithm: ecdsa-with-SHA256 > 30:81:87:02:41:7b:7d:88:a9:56:e8:d5:a0:f6:38:e7:85:4c: > f5:1c:81:64:de:92:25:37:42:2d:31:cb:8b:af:04:32:7b:d7: > 06:19:4a:eb:a9:ca:9d:88:38:11:99:bc:2e:2b:35:e6:69:1c: > ca:1c:8c:86:7d:74:bc:dd:96:20:8e:38:01:63:15:8b:02:42: > 01:66:42:70:5f:2e:cc:fb:1f:f3:d4:96:54:e9:b7:0a:3b:82: > ec:b7:90:45:19:c0:ac:4c:ef:82:3d:77:07:e1:4d:13:81:d3: > 12:23:bc:84:4f:9b:ac:55:c4:a1:3b:85:08:5a:2f:ae:ad:45: > 3f:5f:da:cd:80:45:c9:79:58:d3:79:a2 > > 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, <y...@inbox.lv> 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 <san...@paranoici.org>: > > > > 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? :( > > -- Tavs bezmaksas pasts Inbox.lv
Links: ------ [1] mailto:aerow...@gmail.com
