[Cryptography-dev] Loading a Curve25519 X.509 key

[Saurabh Kapoor]

Hi Paul,

Thanks for your suggestions. I dug up a bit further and found the main
problem is the distinction between Curve25519 and X25519!
Here's what I found:

   1. They, using BoncyCastle, generate a Curve25519 public, private key
   and serialize it. This is serialized as a *generic *EC key with all the
   parameters contained within it.
   2. OpenSSL can work on these keys and even generate the derived key! I
   tried using the following command: openssl pkeyutl -derive -inkey
   <our_private_key> -peerkey <peer_public_key>
   3. OpenSSL supports X25519 keys but these are different from Curve25519.
   4. In Python, we support X25519 but not loading generic EC keys

Given all the above, I'll be more pushing towards getting them to use the
standard X25519 exchange format instead of that of a generic EC curve.
BouncyCastle supports that quite well.

regards,
Saurabh


On Sun, Mar 14, 2021 at 5:34 AM Paul Kehrer <paul.l.kehrer at gmail.com> wrote:

> OpenSSL can sort of parse these but it isn't capable of recognizing
> (at least via the typical loading paths) what the key type actually
> is. I'd suggest looking at the bouncycastle API to see if there's a
> way to serialize these in a more standard fashion or if you can simply
> export the raw bytes of the private key (which cryptography is
> perfectly capable of importing).
>
> You could also parse the ASN.1 yourself to get it, but looking briefly
> at the format it appears it's likely embedded as a value inside an
> ASN.1 sequence that is itself encoded within an ASN.1 octet string.
>
> -Paul
>
> On Thu, Mar 11, 2021 at 2:20 AM Saurabh Kapoor <saurabh at fintify.com>
> wrote:
> >
> > Thanks Alex and Paul.
> >
> > The functions load_pem_{public,private}_key work well for x25519 keys
> that are written out using openssl's key generator:
> >
> > For private key: `openssl genpkey -algorithm x25519 > pri_key.pem`
> > For public key: `openssl pkey -in pri_key.pem -pubout -out pub_key.pem`
> >
> > However, we receive this public key from a service written in Java,
> which uses BouncyCastle's library to encode the key.
> > Apparently, in these keys the curve is not explicitly named and that
> causes load_pem_{public_private}_key to fail with the following error (call
> stack attached in callstack.txt):
> >
> > NotImplementedError: ECDSA keys with unnamed curves are unsupported at
> this time
> >
> > These same public/private keys generated by the sender can be opened
> using `openssl asn1parse ..` command and what's more, when I generate the
> public key from the private key using `openssl pkey -in <> -pubout -out <>`
> I get the exact same public key back ! (attached the sample
> java_pri_key.pem and java_pub_key.pem). That confirms that at the openssl
> layer it's able to recognize the private key and output a public key in the
> same format.
> >
> > So my question is: how can I load the sender's pub_key.pem into a
> X25519PublicKey? If that's not possible, any suggestions for how else can
> I, in Python, load the keys and decrypt data received from the Java service?
> >
> > regards,
> > Saurabh
> >
> > On Thu, Mar 11, 2021 at 12:47 AM Paul Kehrer <paul.l.kehrer at gmail.com>
> wrote:
> >>
> >> Yes, load_{pem,der}_{public,private}_key can load
> >> ed25519/ed448/x25519/x448 keys as well as long as they are in
> >> PKCS8/subjectPublicKeyInfo formats. We should fix those docs.
> >>
> >> -Paul
> >>
> >> On Wed, Mar 10, 2021 at 11:05 AM Alex Gaynor <alex.gaynor at gmail.com>
> wrote:
> >> >
> >> > Hi Saruabh,
> >> >
> >> > I think
> https://cryptography.io/en/latest/hazmat/primitives/asymmetric/serialization.html#cryptography.hazmat.primitives.serialization.load_pem_public_key
> >> > should work. Notwithstanding the docs, I believe it'll load an
> >> > X25519PublicKey :-) If that works for you, let us know and I'll make
> >> > sure we fix those docs.
> >> >
> >> > Alex
> >> >
> >> > On Wed, Mar 10, 2021 at 11:56 AM Saurabh Kapoor <saurabh at fintify.com>
> wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > A service we communicate with sends us their Curve25519 public key
> as a PEM file. The key is DER encoded and the format is X.509's
> SubjectPublicKeyInfo.
> >> > >
> >> > > We would like to create a
> cryptography.hazmat.primitives.asymmetric.x25519.X25519PublicKey for this
> object but I am unable to find the routines to load such keys.
> X25519PublicKey.load_public_bytes(..) expects a raw key.
> >> > >
> >> > > Using the following openssl command I can examine the key: openssl
> asn1parse -in pub_key.pem
> >> > >
> >> > > Any suggestions on how my service written in Python can load this
> kind of a public key? I've also posted a slightly more detailed question
> here:
> https://stackoverflow.com/questions/66492939/python-decoding-an-ecdh-curve-25519-public-key-encoded-as-a-pem-file
> >> > >
> >> > > regards,
> >> > > Saurabh
> >> > > _______________________________________________
> >> > > Cryptography-dev mailing list
> >> > > Cryptography-dev at python.org
> >> > > https://mail.python.org/mailman/listinfo/cryptography-dev
> >> >
> >> >
> >> >
> >> > --
> >> > All that is necessary for evil to succeed is for good people to do
> nothing.
> >> > _______________________________________________
> >> > Cryptography-dev mailing list
> >> > Cryptography-dev at python.org
> >> > https://mail.python.org/mailman/listinfo/cryptography-dev
> >> _______________________________________________
> >> Cryptography-dev mailing list
> >> Cryptography-dev at python.org
> >> https://mail.python.org/mailman/listinfo/cryptography-dev
> >
> > _______________________________________________
> > Cryptography-dev mailing list
> > Cryptography-dev at python.org
> > https://mail.python.org/mailman/listinfo/cryptography-dev
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cryptography-dev/attachments/20210315/5afbbf11/attachment.html>