11–20 of 41 posts
Never trust strangers on advices to change your cryptographic algos, do your own research... BTW Ed25519 is not even quantum safe :-)
Nobody ever claimed that ecdsa/eddsa was quantum safe, it obviously isn't.
I'm not sure if I understand the reasoning here. The article says a 1024-bit RSA key is considered unsafe, but still says you should "probably want to upgrade" if you're on a 2048-bit key. Why would that be the case? The given arguments, key size, speed etc, are complete non-arguments to me as compared to going through my keys and updating them everywhere where necessary.
Even if the underlying ciphers have not changed, the value of a stolen key will decay when there is a planned sunset. In the lack of a rotation strategy, a stolen key is a gift that keeps on giving.
OpenBSD introduced the signify command, and a 6-month key rotation, that will allow trust when the OS is downloaded over insecure channels (cleartext FTP and http).
https://www.openbsd.org/papers/bsdcan-signify.html
Debian is migrating to the conceptually-similar aptsign.
https://blog.jak-linux.org/2021/06/20/migrating-away-apt-key...
Additionally some major openpgp packages (notably Golangs) does (or did not) support ED25519 at the time of writing either.[0]
This caused the death of a bit of software I was working on because one engineer insisted on using his ED25519 key which my software could not cope with and I was not smart enough to fix it in the upstream module.
> If it was more than five years ago and you generated your SSH key with the default options, you probably ended up using RSA algorithm with key-size less than 2048 bits long. It's closer to 16 years, for OpenSSH [1]. > Open up your terminal and type the following command to generate a new SSH key that uses Ed25519 algorithm: > Generate SSH key with Ed25519 key type That's broken in an amusing way. But speaking of br…
The much nicer part about Ed25519 is that you can realistically type it out over a serial console or over a monitor-keyboard without access to copy-paste directly. They're small and fast and convenient.
In addition to that, the cryptography behind Ed25519 is much simpler to implement than RSA without causing massive side channel leaks, so that is one less thing to worry about.
In terms of Anti-QC Resistance, I wouldn't worry about it until we complete the current qc-resistant crypto competition, which should give us a nice set of primitives to use.
Never trust strangers on advices to change your cryptographic algos, do your own research... BTW Ed25519 is not even quantum safe :-)
OpenSSH quietly adopted the tinyssh approach as an experimental feature. Some time later, after interaction with DJB, the OpenSSH algorithm for NTRU was changed, and tinyssh followed suit.
If you want quantum-secure Ed25519, then enable sntrup761x25519 on a supported client and server.
Never trust strangers on advices to change your cryptographic algos, do your own research... BTW Ed25519 is not even quantum safe :-)
Was wondering if Azure ever fixed that issue of requiring RSA, but of course good ol' Microsoft doesn't support it yet: https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-...
GCP didn't either last year. Not sure about Azure but on GCP it was very non obvious that you couldn't connect to the Compute instance because of a not supported key type.
behead those who still use rsa.
behead those who still use rsa.
I'd way rather use a hardware-backed RSA key with proof of presence support than a dirty in-RAM software key.
(not saying there are no ed25519 hardware things, but I did say "widely", and as someone who's banged his head on PKCS#11 and other fun things I stand by my statement)