Comment 16 for bug 907675

> Depends, see RFC 6979.

That's a fair point. OpenSSL 1.1 implements a variant of this which essentially hashes together some random data with the private key and the message, so it's non-deterministic but should still avoid the classic attack on (EC)DSA when the RNG is weak. And, of course, PuTTY implemented something similar for its DSA implementation way back in 2001, and carried that over to ECDSA as well, so PuTTY users should be safe.

Unfortunately, OpenSSL 1.0 *doesn't* implement this strengthening of how the k parameter in (EC)DSA is generated, and OpenSSL 1.1 was a major API change that OpenSSH hasn't yet adapted to (although there has been some gradual progress on that front, and some people have applied a patch against upstream's advice; if you follow debian-devel then you've probably seen me debating what to do about that). So that still leaves a lot of clients vulnerable to this attack in practice, if their random number generator happens to be weak.

> Is this related to using Ed25519 OpenPGP keys? Or is it a separate issue?

That's separate; comment #6 has the details. The problem with Ed25519 OpenPGP keys is that they require GnuPG 2, and getting that to work in non-interactive contexts is a real pain due to the way it likes to spawn opportunistic daemon processes. I did try to get Launchpad's test suite to work with it when we were upgrading to run on Ubuntu 16.04 a while back, but I ended up giving up and forcing GnuPG 1 for now. If you need this, then it'd be a good idea to file a separate bug so that we remember that we need to work on it.