From f99b9dc632a2c409f5bdc01af72644fff71f90a5 Mon Sep 17 00:00:00 2001 From: Hubert Kario Date: Sat, 19 Oct 2019 01:12:07 +0200 Subject: [PATCH 1/5] update speed.py make it a bit more modular and make the output look more like OpenSSL's --- README.md | 50 +++++++++++++++++++++++++++++++++----------------- speed.py | 20 ++++++++++++++++---- 2 files changed, 49 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index 11ed0955..62d9c881 100644 --- a/README.md +++ b/README.md @@ -35,27 +35,44 @@ and 1.0.0a . ## Speed The following table shows how long this library takes to generate keypairs -(keygen=), to sign data (sign=), and to verify those signatures (verify=), on -my 2008 Mac laptop. All times are in seconds. It also shows the length of a -signature (in bytes): the verifying ("public") key is typically the same -length as the signature, and the signing ("private") key is half that length. +(`keygen`), to sign data (`sign`), and to verify those signatures (`verify`). +All those values are in seconds. +For convenience, the inverses of those values are also provided: +how many keys per second can be generated (`keygen/s`), how many signatures +can be made per second (`sign/s`) and how many signatures can be verified +per second (`verify/s`). The size of raw signature (generally the smallest +way a signature can be encoded) is also provided in the `siglen` column. Use `tox -e speed` to generate this table on your own computer. +On an Intel Core i7 4790K @ 4.0GHz I'm getting the following performance: -* NIST192p: siglen= 48, keygen=0.160s, sign=0.058s, verify=0.116s -* NIST224p: siglen= 56, keygen=0.230s, sign=0.086s, verify=0.165s -* NIST256p: siglen= 64, keygen=0.305s, sign=0.112s, verify=0.220s -* NIST384p: siglen= 96, keygen=0.801s, sign=0.289s, verify=0.558s -* NIST521p: siglen=132, keygen=1.582s, sign=0.584s, verify=1.152s +``` + siglen keygen keygen/s sign sign/s verify verify/s + NIST192p: 48 0.03183s 31.42 0.01127s 88.70 0.02253s 44.39 + NIST224p: 56 0.04304s 23.24 0.01548s 64.59 0.03122s 32.03 + NIST256p: 64 0.05720s 17.48 0.02055s 48.67 0.04075s 24.54 + NIST384p: 96 0.13216s 7.57 0.04696s 21.29 0.09400s 10.64 + NIST521p: 132 0.25805s 3.88 0.09329s 10.72 0.18841s 5.31 + SECP256k1: 64 0.05677s 17.61 0.02073s 48.23 0.04067s 24.59 +``` -For comparison, a quality C++ implementation of ECDSA (Crypto++) typically -computes a NIST256p signature in 2.88ms and a verification in 8.53ms, about -30-40x faster. +For comparison, a highly optimised implementation (including curve-specific +assemply) like OpenSSL provides following performance numbers on the same +machine. Run `openssl speed`: +``` + sign verify sign/s verify/s + 192 bits ecdsa (nistp192) 0.0002s 0.0002s 4785.6 5380.7 + 224 bits ecdsa (nistp224) 0.0000s 0.0001s 22475.6 9822.0 + 256 bits ecdsa (nistp256) 0.0000s 0.0001s 45069.6 14166.6 + 384 bits ecdsa (nistp384) 0.0008s 0.0006s 1265.6 1648.1 + 521 bits ecdsa (nistp521) 0.0003s 0.0005s 3753.1 1819.5 +``` Keys and signature can be serialized in different ways (see Usage, below). For a NIST192p key, the three basic representations require strings of the following lengths (in bytes): to_string: signkey= 24, verifykey= 48, signature=48 + compressed: signkey=n/a, verifykey= 25, signature=n/a DER: signkey=106, verifykey= 80, signature=55 PEM: signkey=278, verifykey=162, (no support for PEM signatures) @@ -76,13 +93,12 @@ more for the wrapper. To run them all, do this: tox -e coverage -On my 2014 Mac Mini, the combined tests take about 20 seconds to run. On a -2.4GHz P4 Linux box, they take 81 seconds. +On an Intel Core i7 4790K@4.0GHz, the combined tests take about 8 minutes to +run. One component of `test_pyecdsa.py` checks compatibility with OpenSSL, by -running the "openssl" CLI tool. If this tool is not on your $PATH, you may -want to comment out this test (the easiest way is to add a line that says -"del OpenSSL" to the end of test_pyecdsa.py). +running the "openssl" CLI tool, make sure it's in your `PATH` if you want +to test it. ## Security diff --git a/speed.py b/speed.py index 3f05309b..09bc04b8 100644 --- a/speed.py +++ b/speed.py @@ -1,5 +1,6 @@ import six import timeit +from ecdsa.curves import curves def do(setup_statements, statement): # extracted from timeit.py @@ -13,8 +14,17 @@ def do(setup_statements, statement): break return x / number -for curve in ["NIST192p", "NIST224p", "NIST256p", "SECP256k1", - "NIST384p", "NIST521p"]: +prnt_form = ("{name:>10}{sep:1} {siglen:>6} {keygen:>9{form}}{unit:1} " + "{keygen_inv:>9{form_inv}} {sign:>9{form}}{unit:1} " + "{sign_inv:>9{form_inv}} {verify:>9{form}}{unit:1} " + "{verify_inv:>9{form_inv}}") + +print(prnt_form.format(siglen="siglen", keygen="keygen", keygen_inv="keygen/s", + sign="sign", sign_inv="sign/s", verify="verify", + verify_inv="verify/s", name="", sep="", unit="", + form="", form_inv="")) + +for curve in [i.name for i in curves]: S1 = "import six; from ecdsa import SigningKey, %s" % curve S2 = "sk = SigningKey.generate(%s)" % curve S3 = "msg = six.b('msg')" @@ -31,5 +41,7 @@ def do(setup_statements, statement): import ecdsa c = getattr(ecdsa, curve) sig = ecdsa.SigningKey.generate(c).sign(six.b("msg")) - print("%9s: siglen=%3d, keygen=%.3fs, sign=%.3fs, verify=%.3fs" \ - % (curve, len(sig), keygen, sign, verf)) + print(prnt_form.format( + name=curve, sep=":", siglen=len(sig), unit="s", keygen=keygen, + keygen_inv=1.0/keygen, sign=sign, sign_inv=1.0/sign, verify=verf, + verify_inv=1.0/verf, form=".5f", form_inv=".2f")) From 0ae46e4224a338c8bb65d5752a2e306cc92fa83e Mon Sep 17 00:00:00 2001 From: Hubert Kario Date: Sat, 19 Oct 2019 01:12:37 +0200 Subject: [PATCH 2/5] rephrase Features --- README.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 62d9c881..48080af2 100644 --- a/README.md +++ b/README.md @@ -15,12 +15,13 @@ into other protocols. ## Features This library provides key generation, signing, and verifying, for five -popular NIST "Suite B" GF(p) curves, with key lengths of 192, 224, 256, 384, -and 521 bits. The "short names" for these curves, as known by the OpenSSL -tool (`openssl ecparam -list_curves`), are: prime192v1, secp224r1, -prime256v1, secp384r1, and secp521r1. It also includes the 256-bit curve used -by Bitcoin, whose short name is secp256k1. No other curves are included, but -it would not be too hard to add more. +popular NIST "Suite B" GF(p) (_prime field_) curves, with key lengths of 192, +224, 256, 384, and 521 bits. The "short names" for these curves, as known by +the OpenSSL tool (`openssl ecparam -list_curves`), are: `prime192v1`, +`secp224r1`, `prime256v1`, `secp384r1`, and `secp521r1`. It also includes the +256-bit curve used by Bitcoin, whose short name is `secp256k1`. No other curves +are included, but it would not be too hard to add support for more curves +over prime fields. ## Dependencies From 9f2ac4cb3ff120dbdad250a0a2425584ff2e35ac Mon Sep 17 00:00:00 2001 From: Hubert Kario Date: Sat, 19 Oct 2019 01:26:06 +0200 Subject: [PATCH 3/5] typos, format updates, missing references, etc. --- README.md | 68 +++++++++++++++++++++++++++++++------------------------ 1 file changed, 38 insertions(+), 30 deletions(-) diff --git a/README.md b/README.md index 48080af2..98d09027 100644 --- a/README.md +++ b/README.md @@ -27,11 +27,11 @@ over prime fields. This library uses only Python and the 'six' package. It is compatible with Python 2.6, 2.7 and 3.3+. It also supports execution on the alternative -implementaions like pypy and pypy3 +implementations like pypy and pypy3 To run the OpenSSL compatibility tests, the 'openssl' tool must be on your -$PATH. This release has been tested successfully against both OpenSSL 0.9.8o -and 1.0.0a . +$PATH. This release has been tested successfully against OpenSSL 0.9.8o, +1.0.0a, 1.0.2f and 1.1.1d (among others). ## Speed @@ -110,48 +110,53 @@ a system where os.urandom() is weak. ## Usage -You start by creating a SigningKey. You can use this to sign data, by passing -in a data string and getting back the signature (also a string). You can also -ask a SigningKey to give you the corresponding VerifyingKey. The VerifyingKey -can be used to verify a signature, by passing it both the data string and the -signature string: it either returns True or raises BadSignatureError. +You start by creating a `SigningKey`. You can use this to sign data, by passing +in data as a byte string and getting back the signature (also a byte string). +You can also ask a `SigningKey` to give you the corresponding `VerifyingKey`. +The `VerifyingKey` can be used to verify a signature, by passing it both the +data string and the signature byte string: it either returns True or raises +`BadSignatureError`. ```python from ecdsa import SigningKey sk = SigningKey.generate() # uses NIST192p -vk = sk.get_verifying_key() +vk = sk.verifying_key signature = sk.sign(b"message") assert vk.verify(signature, b"message") ``` -Each SigningKey/VerifyingKey is associated with a specific curve, like +Each `SigningKey`/`VerifyingKey` is associated with a specific curve, like NIST192p (the default one). Longer curves are more secure, but take longer to use, and result in longer keys and signatures. ```python from ecdsa import SigningKey, NIST384p sk = SigningKey.generate(curve=NIST384p) -vk = sk.get_verifying_key() -signature = sk.sign("message") -assert vk.verify(signature, "message") +vk = sk.verifying_key +signature = sk.sign(b"message") +assert vk.verify(signature, b"message") ``` -The SigningKey can be serialized into several different formats: the shortest +The `SigningKey` can be serialized into several different formats: the shortest is to call `s=sk.to_string()`, and then re-create it with `SigningKey.from_string(s, curve)` . This short form does not record the -curve, so you must be sure to tell from_string() the same curve you used for +curve, so you must be sure to tell `from_string()` the same curve you used for the original key. The short form of a NIST192p-based signing key is just 24 bytes long. If a point encoding is invalid or it does not lie on the specified -curve, `from_string()` will raise MalformedPointError. +curve, `from_string()` will raise `MalformedPointError`. ```python from ecdsa import SigningKey, NIST384p sk = SigningKey.generate(curve=NIST384p) sk_string = sk.to_string() sk2 = SigningKey.from_string(sk_string, curve=NIST384p) -# sk and sk2 are the same key +print(sk_string.hex()) +print(sk2.to_string().hex()) ``` +Note: while the methods are called `to_string()` the type they return is +actually `bytes`, the "string" part is leftover from Python 2. + `sk.to_pem()` and `sk.to_der()` will serialize the signing key into the same formats that OpenSSL uses. The PEM file looks like the familiar ASCII-armored `"-----BEGIN EC PRIVATE KEY-----"` base64-encoded format, and the DER format @@ -159,7 +164,7 @@ is a shorter binary form of the same data. `SigningKey.from_pem()/.from_der()` will undo this serialization. These formats include the curve name, so you do not need to pass in a curve identifier to the deserializer. In case the file is malformed `from_der()` -and `from_pem()` will raise UnexpectedDER or MalformedPointError. +and `from_pem()` will raise `UnexpectedDER` or` MalformedPointError`. ```python from ecdsa import SigningKey, NIST384p @@ -169,22 +174,22 @@ sk2 = SigningKey.from_pem(sk_pem) # sk and sk2 are the same key ``` -Likewise, the VerifyingKey can be serialized in the same way: +Likewise, the `VerifyingKey` can be serialized in the same way: `vk.to_string()/VerifyingKey.from_string()`, `to_pem()/from_pem()`, and -`to_der()/from_der()`. The same curve= argument is needed for +`to_der()/from_der()`. The same `curve=` argument is needed for `VerifyingKey.from_string()`. ```python from ecdsa import SigningKey, VerifyingKey, NIST384p sk = SigningKey.generate(curve=NIST384p) -vk = sk.get_verifying_key() +vk = sk.verifying_key vk_string = vk.to_string() vk2 = VerifyingKey.from_string(vk_string, curve=NIST384p) # vk and vk2 are the same key from ecdsa import SigningKey, VerifyingKey, NIST384p sk = SigningKey.generate(curve=NIST384p) -vk = sk.get_verifying_key() +vk = sk.verifying_key vk_pem = vk.to_pem() vk2 = VerifyingKey.from_pem(vk_pem) # vk and vk2 are the same key @@ -192,29 +197,30 @@ vk2 = VerifyingKey.from_pem(vk_pem) There are a couple of different ways to compute a signature. Fundamentally, ECDSA takes a number that represents the data being signed, and returns a -pair of numbers that represent the signature. The hashfunc= argument to +pair of numbers that represent the signature. The `hashfunc=` argument to `sk.sign()` and `vk.verify()` is used to turn an arbitrary string into fixed-length digest, which is then turned into a number that ECDSA can sign, and both sign and verify must use the same approach. The default value is -hashlib.sha1, but if you use NIST256p or a longer curve, you can use -hashlib.sha256 instead. +`hashlib.sha1`, but if you use NIST256p or a longer curve, you can use +`hashlib.sha256` instead. There are also multiple ways to represent a signature. The default `sk.sign()` and `vk.verify()` methods present it as a short string, for simplicity and minimal overhead. To use a different scheme, use the `sk.sign(sigencode=)` and `vk.verify(sigdecode=)` arguments. There are helper -funcions in the "ecdsa.util" module that can be useful here. +functions in the `ecdsa.util` module that can be useful here. -It is also possible to create a SigningKey from a "seed", which is +It is also possible to create a `SigningKey` from a "seed", which is deterministic. This can be used in protocols where you want to derive consistent signing keys from some other secret, for example when you want three separate keys and only want to store a single master secret. You should -start with a uniformly-distributed unguessable seed with about curve.baselen -bytes of entropy, and then use one of the helper functions in ecdsa.util to +start with a uniformly-distributed unguessable seed with about `curve.baselen` +bytes of entropy, and then use one of the helper functions in `ecdsa.util` to convert it into an integer in the correct range, and then finally pass it into `SigningKey.from_secret_exponent()`, like this: ```python +import os from ecdsa import NIST384p, SigningKey from ecdsa.util import randrange_from_seed__trytryagain @@ -226,7 +232,9 @@ seed = os.urandom(NIST384p.baselen) # or other starting point sk1a = make_key(seed) sk1b = make_key(seed) # note: sk1a and sk1b are the same key -sk2 = make_key("2-"+seed) # different key +assert sk1a.to_string() == sk1b.to_string() +sk2 = make_key(b"2-"+seed) # different key +assert sk1a.to_string() != sk2.to_string() ``` ## OpenSSL Compatibility From ff18c096874eab6730419b2bff0ee2ebf1364003 Mon Sep 17 00:00:00 2001 From: Hubert Kario Date: Sat, 19 Oct 2019 01:26:25 +0200 Subject: [PATCH 4/5] update Security section --- README.md | 32 +++++++++++++++++++++++++++++--- 1 file changed, 29 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 98d09027..bc448ecc 100644 --- a/README.md +++ b/README.md @@ -103,11 +103,37 @@ to test it. ## Security -This library does not protect against timing attacks. Do not allow attackers -to measure how long it takes you to generate a keypair or sign a message. +This library was not designed with security in mind. If you are processing +data that needs to be protected we suggest you use a quality wrapper around +OpenSSL. [pyca/cryptography](https://cryptography.io) is one example of such +a wrapper. The primary use-case of this library is as a portable library for +interoperability testing and as a teaching tool. + +**This library does not protect against side channel attacks.** + +Do not allow attackers to measure how long it takes you to generate a keypair +or sign a message. Do not allow attackers to run code on the same physical +machine when keypair generation or signing is taking place (this includes +virtual machines). Do not allow attackers to measure how much power your +computer uses while generating the keypair or signing a message. Do not allow +attackers to measure RF interference coming from your computer while generating +a keypair or signing a message. Note: just loading the private key will cause +keypair generation. Other operations or attack vectors may also be +vulnerable to attacks. **For a sophisticated attacker observing just one +operation with private key will be sufficient to completely +reconstruct the private key**. + +Please also note that any Pure-python cryptographic library will be vulnerable +to the same side channel attacks. This is because Python does not provide +side-channel secure primitives (with the exception of +[`hmac.compare_digest()`][3]), making side-channel secure programming +impossible. + This library depends upon a strong source of random numbers. Do not use it on -a system where os.urandom() is weak. +a system where `os.urandom()` does not provide cryptographically secure +random numbers. +[3]: https://docs.python.org/3/library/hmac.html#hmac.compare_digest ## Usage You start by creating a `SigningKey`. You can use this to sign data, by passing From a21c00045116c35a0d68da295ff2c369aad8823a Mon Sep 17 00:00:00 2001 From: Hubert Kario Date: Sat, 19 Oct 2019 02:04:23 +0200 Subject: [PATCH 5/5] update openssl compatibility --- README.md | 55 ++++++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 44 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index bc448ecc..d4b238ae 100644 --- a/README.md +++ b/README.md @@ -269,24 +269,57 @@ To produce signatures that can be verified by OpenSSL tools, or to verify signatures that were produced by those tools, use: ```python -# openssl ecparam -name secp224r1 -genkey -out sk.pem +# openssl ecparam -name prime256v1 -genkey -out sk.pem # openssl ec -in sk.pem -pubout -out vk.pem -# openssl dgst -ecdsa-with-SHA1 -sign sk.pem -out data.sig data -# openssl dgst -ecdsa-with-SHA1 -verify vk.pem -signature data.sig data -# openssl dgst -ecdsa-with-SHA1 -prverify sk.pem -signature data.sig data +# echo "data for signing" > data +# openssl dgst -sha256 -sign sk.pem -out data.sig data +# openssl dgst -sha256 -verify vk.pem -signature data.sig data +# openssl dgst -sha256 -prverify sk.pem -signature data.sig data -sk.sign(msg, hashfunc=hashlib.sha1, sigencode=ecdsa.util.sigencode_der) -vk.verify(sig, msg, hashfunc=hashlib.sha1, sigdecode=ecdsa.util.sigdecode_der) +import hashlib +from ecdsa import SigningKey, VerifyingKey +from ecdsa.util import sigencode_der, sigdecode_der + +with open("vk.pem") as f: + vk = VerifyingKey.from_pem(f.read()) + +with open("data", "rb") as f: + data = f.read() + +with open("data.sig", "rb") as f: + signature = f.read() + +assert vk.verify(signature, data, hashlib.sha256, sigdecode=sigdecode_der) + +with open("sk.pem") as f: + sk = SigningKey.from_pem(f.read(), hashlib.sha256) + +new_signature = sk.sign_deterministic(data, sigencode=sigencode_der) + +with open("data.sig2", "wb") as f: + f.write(new_signature) + +# openssl dgst -sha256 -verify vk.pem -signature data.sig2 data ``` -The keys that openssl handles can be read and written as follows: +Note: if compatibility with OpenSSL 1.0.0 or earlier is necessary, the +`sigencode_string` and `sigdecode_string` from `ecdsa.util` can be used for +respectively writing and reading the signatures. + +The keys also can be written in format that openssl can handle: ```python -sk = SigningKey.from_pem(open("sk.pem").read()) -open("sk.pem","w").write(sk.to_pem()) +from ecdsa import SigningKey, VerifyingKey + +with open("sk.pem") as f: + sk = SigningKey.from_pem(f.read()) +with open("sk.pem", "wb") as f: + f.write(sk.to_pem()) -vk = VerifyingKey.from_pem(open("vk.pem").read()) -open("vk.pem","w").write(vk.to_pem()) +with open("vk.pem") as f: + vk = VerifyingKey.from_pem(f.read()) +with open("vk.pem", "wb") as f: + f.write(vk.to_pem()) ``` ## Entropy