Which cryptographic signing approach?

I used to work for the US Government, and I shipped cryptographic solutions in a bunch of places – when the US Government makes it hard on it’s own employees, we shouldn’t go out of our way to encourage their mistakes.

In any event, stdlib vs. not-stdlib isn’t relevant to almost any projects/agencies. If you’re concerned about the US Government’s ability to use crypto, FIPS 140 is the dominant concern.

Fortunately, with recent updates to FIPS and other NIST SPs, Ed25519 is now acceptable. Given it’s good design choices, slim API surface, performance, and ease of implementation, it’s the obvious choice for any signature scheme.


Paul Kehrer informed me that PyCA has a pure Python implementation for Ed25519 signature validation. This makes Ed25519 the obvious choice. I can add a C wrapper for OpenSSL’s Ed25519 to Python’s stdlib for maximum performance and compliance. pip can fall back to pure Python implementation for older Python versions.

PEP 458 reference list update erratum:
“[24] …ed25519 …” mistakenly points to warner/python-ed25519, while it should point to pyca/ed25519.

I contemplated that old ed25519 library briefly. IIRC, the vulnerability warnings are related to side-channel attacks when signing allowing some exposure of the signing key. That’s not a natural concern in this context:
The signing is done repo-side, and that tooling really doesn’t profit from only-Python constraints. (i.e. you can use heavier libraries like NaCl for it). On the client side, there is no risk from the concerns motivating those warnings on signature verification – there’s no private key to expose. Even using the library on the server side, you could probably mitigate these attacks without too much effort.

That said, I opted not to go with that ed25519 implementation anyway, for other reasons – and that it is not maintained is certainly a consideration.

This is encouraging, and we’ve been waiting for this for a long time. I’m working on something similar for another group, and when all is said and done, I’ll provide a breakdown of the cost in time, but that’ll be far too late for this RFI. :slight_smile:

I guess I would only say… If you go with a model that does not involve developer signing, like the minimum security model, try to leave room in the design (the metadata spec in particular, at least) for the ability to expand later. (TUF would do that for you, but you could do it otherwise, if you’re not going to use TUF as-is.)

1 Like

ed25519 is sort of maintained – which is to say if there were bugs we are available to fix them. There just haven’t been any, nor any users. If pip were using it we could absolutely give it more love.


Thanks for the feedback, everyone. So Sep 18 not far away. What is the consensus?

@trishankatdatadog There are some more voices who will be speaking up here before Sept. 18th, such as @EWDurbin and (I’m predicting) @woodruffw – it’s ok if we don’t have a consensus yet. :slight_smile:


A few thoughts on this:

  • I’m still a pretty big fan of using TUF for PyPI and I’ve yet to see something that I feel like would be a better fit. I’m happy to look at other options and have folks attempt to persuade, but so far I’m still pretty sold on TUF.
  • I think the rough idea of PEP 458 -> PEP 480 is solid. I haven’t yet looked at in-toto to know if it’s something that would be generally useful for us or not.
  • The Pure Python ed25519 library is perfectly safe to use for signature verification, just not for signature creation. If I remember my history correct the entire reason it exists was when we started talking about this years ago the Pure python djb code was really slow so we took it and improved it to see if it was possible to get something fast “enough” for signature verification. It likely has no real users at this point but I have no doubts in PyCA’s ability to maintain it if we were to use it in pip.
  • In my mind I think I was planning on using RSA for the root keys because of hardware support for them, that was years ago though so perhaps ed25519 has good hardware support now for realtively cheap HSMs we can use for the root keys.
1 Like