[red_admiral]

People migrating to djb's curves, or at least allowing them as a first-class citizen, include

  - SSH (which includes git over SSH - github suggests djb's Curve 25519 as default: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent)
  - TLS (recommended in n1.3)
  - NIST (allows Curve25519, but isn't the default choice) 
  - various cryptocurrency crap

The people not on djb's curves yet are PGP/GPG/OpenPGP (available as an "advanced" option but not by default, for backwards compatibility) and as a consequence, debian's package signing (that mostly uses GPG with RSA, afaik). So ubuntu is in good company, even if it makes their job of working with "upstream" harder. [EDIT: apparently changed now - GPG has joined the ranks of djb-by-default]

It's only like migrating from C to rust for the person implementing the crypto package and singature verifier. For the average package maintainer, they just have to generate a new key and pass a new command line flag to their sign command.

[normaler]

GPG is using ed25519 keys as default since 2.3

https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/0004...

[mike_hearn]

Yes, but SSH isn't e.g. forbidding you from connecting to servers that use RSA or secp256r1, whereas they want to make apt refuse to access repositories that aren't using djb's curves.

[red_admiral]

SSH by default isn't, but admins can set up their own list of allowed ciphers in their config file. Github, for example, has banned ssh_dss - I think they still support ECDSA, but they only mention Curve25519 and RSA (with caveats) on their SSH keys page.

[throw0101a]

> SSH by default isn't

Yes, and that's fine. But if SSH mandated a certain thing and disallowed even admins to change it it would be the equivalent problem.

It's Ubuntu preventing the use of anything but "SafeCurves" that's the problem.

If Ubuntu/Canonical want to use them—fine. (Maybe.†) But don't disable the functionality for admins.

† Some regulated industries need to use certain Approved Algorithms, which may or may not include your favourite ones. Further there may be all sorts of other (workflow) tooling that may not support your favourite ones either, and forcing your favourites on other people (especially taking away other options) is a jerk move.

[red_admiral]

So, I'm mostly with you here, but I'd say disallowing e.g. MD5 (horribly broken) or anything involving Dual_EC (horribly suspicious) by force would be reasonable. ECDSA/secp* curves, that's more controversial.

The TLS 1.2 -> 1.3 upgrade also disallowed a lot of previously used things, and this was generally considered to be a great improvement (though of course TLS endpoints can be backwards-compatible).