How to generate a shorter private key for ECDSA (secp256k1) in Python Cryptography

Question

I'm trying to learn how to create a bitcoin address by following this guide. If you scroll down, the first step, step 0, is to have a 256 bit (64 hex) long ECDSA key. I looked into Python Cryptography and am using the code below to test generating keys, but the saved key is always a long (180 characters) base 64 string.

I've tried to read the docs and look at the functions I'm calling on Github but I don't see where I can specify how long the key should be. On line 216 of this file, it says that the key size for secp256k1 is 256 bits by default. Does that mean I'm exporting it wrong?

Alternatively, I've considered generating a random hex string 64 characters long within the range of secp256k1,( 0x1 to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140 ), but I don't see where I can create a private key instance from a string or hex value

gentest.py

from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.serialization import load_pem_private_key


def gen_key():
    private_key = ec.generate_private_key(
        ec.SECP256K1(), default_backend()
    )
    return private_key


def save_key(pk, filename):
    pem = pk.private_bytes(
        encoding=serialization.Encoding.PEM,
        format=serialization.PrivateFormat.PKCS8,
        encryption_algorithm=serialization.NoEncryption()
    )
    with open(filename, 'wb') as pem_out:
        pem_out.write(pem)

def load_key(filename):
    with open(filename, 'rb') as pem_in:
        pemlines = pem_in.read()

    private_key = load_pem_private_key(pemlines, None, default_backend())
    return private_key

if __name__ == '__main__':
    pk = gen_key()
    filename = 'privkey.pem'
    save_key(pk, filename)
    pk2 = load_key(filename)

privkey.pem

Martijn Pieters · Accepted Answer · 2018-09-08T15:05:39.057

If you do not have an opaque private key (I think that'd involve specialist hardware, so not likely), you can get access to the private numbers information via the key.private_numbers() method of the private key object, at which point you can access the value itself as an integer number; the .private_numbers() method produces a EllipticCurvePrivateNumbers object with a .private_value attribute, a Python int. Format that value as a 64-character zero-padded hex with format():

>>> key = gen_key()
>>> key.private_numbers()
<cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePrivateNumbers object at 0x110a6b828>
>>> key.private_numbers().private_value
1704732612341385685752055250212403073347894734334856205449544619169914419683
>>> format(key.private_numbers().private_value, '064x')
'03c4d82ee8e4c9d245f5a5ceae513569fb5693a0c3cca223b198c6944521f9e3'

or encode it to bytes with int.to_bytes() in big or little endian order (the integer hex output is in big-endian order):

>>> key.private_numbers().private_value.to_bytes(32, 'big')
b'\x03\xc4\xd8.\xe8\xe4\xc9\xd2E\xf5\xa5\xce\xaeQ5i\xfbV\x93\xa0\xc3\xcc\xa2#\xb1\x98\xc6\x94E!\xf9\xe3'
>>> key.private_numbers().private_value.to_bytes(32, 'big').hex()
'03c4d82ee8e4c9d245f5a5ceae513569fb5693a0c3cca223b198c6944521f9e3'

All this is a little convoluted because that's not normally needed to operate the cryptography module, which works with OpenSSL or other cryptography backends via data structures that keep this information in library-friendly, not Python-friendly formats.

And yes, the key you produce is 256 bits long, you can verify this by looking at the .key_size attribute of the private key:

>>> key.key_size
256

The DER format could be another path, because that's machine-readable information. The traditional OpenSSL format makes it relatively easy to fish the info out of the X.690 ASN.1 structure manually, without installing a ASN.1 parser, but this is not exactly fool-proof. You'd look for the 04 20 byte sequence (4 is an octet string, 20 hex means it's 32 bytes long), and the value would be the second element in a sequence with the first an integer; this means the private key will always start at the 8th byte:

der_bytes = key.private_bytes(
    encoding=serialization.Encoding.DER,      
    format=serialization.PrivateFormat.TraditionalOpenSSL, 
    encryption_algorithm=serialization.NoEncryption())
assert der_bytes[5:7] == b'\x04\x20'
key_bytes = der_bytes[7:39]

I'm not 100% certain if those assertions hold however, and just accessing the private numbers is much simpler.

Thank you for the detailed and quick response! You mentioned that doing this is convoluted since typically the developer doesn't need access to the actual private key. Do you think that means I'm going about it the wrong way, or do you think my use case of creating a bitcoin key complex enough to warrant me digging into the library? Thanks again for your help. — mucle6, Sep 08 '18 at 14:50
also something that might help out others that try to do the same thing, once I have the private value, I can load it in using `derive_private_key(pk, ec.SECP256K1(), default_backend())` instead of `generate_private_key(ec.SECP256K1(),default_backend()` — mucle6, Sep 08 '18 at 14:57
@mucle6: the developers using the use-cases for which this library was designed don't need to have access to the key in this format. For bitcoin, you need it, so it's fine doing this. — Martijn Pieters, Sep 08 '18 at 15:07
@mucle6: I note that the [first Python bitcoin library source code I can find](https://github.com/laanwj/python-bitcoinlib/blob/master/bitcoin/key.py) just exposes the raw private key bytes directly from the OpenSSL API. — Martijn Pieters, Sep 08 '18 at 15:09

How to generate a shorter private key for ECDSA (secp256k1) in Python Cryptography

1 Answers1