tl;dw - ed25519 keys are now the default
this post was submitted on 04 Dec 2023
244 points (90.4% liked)
Linux
47342 readers
1392 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Thanks for reducing the click bait.
From the thumbnail I was wondering if it was this. Thanks for saving me the watch.
Oh nice! That's the key type I use anyway, so nice to know I don't have to pass as many options in now
load more comments
(2 replies)
Woah peertube federating with lemmy is actually really cool!
right!? the fediverse is so cool!
i don't think I've created an RSA key since 2017
A surprising amount of services (including Azure last I tried) can only handle RSA keys, so after trying ecdsa only for a while I ended up adding a RSA key again.
With that said - it's 2023, in almost all cases you should have your keys in a hardware module nowadays, in which case you'd use a different command for keygeneration.
ed25519 ≠ ecdsa
Do you have a link for storing keys in hardware? I have no idea how you'd do that.
Easiest and most affordable is probably a security key like the Nitrokey or the https://www.yubico.com/. I personally don't like the company behind yubikey much, but if you want something small you can always leave in the device that's pretty much your only option.
For "cheaper, but a bit more effort" would be just getting a smartcard blank, a card reader (if you're not lucky enough to have a notebook or computer with one built in), and then either write your own applet, or use one of the available opensource ones, and upload it to the card. A variant of that would be the Fidesmo card, where you get a card and their applet.
Or you just use the TPM you may have in your system - though you'll need to be careful with that: Typically one reason for using a hardware token is to make sure keys can't get extracted, while TPMs often do allow key extraction. Software to make that work would be opencryptoki.
Generally you'd use PKCS#11 to have the various components talk to each other. On your average Linux pretty much everything but GnuPG place nice. with PKCS#11. Typically you end up with pcscd to interface with the smartcard (the above USB tokens are technically also just USB smartcards), OpenSC as layer to provide PKCS#11 on top, and software (like OpenSSH) then talks to that.
All of that should be available as packages in any Linux distribution nowadays - and typically will also provide p11-kit configured to use a proxy library to make multiple token sources easily available, and avoid blocking on concurrent access.
ssh-add supports adding keys from pkcs#11 providers to the SSH agent (search pkcs11 in ssh-add manpage), with some distribution (like RedHat) also carrying patches allowing you to only select individual tokens for adding.
If you're also using GnuPG it gets more complicated - you pretty much have two options: Stick with PKCS#11, in which case you'd replace GPGs own smartcard agent with gnupg-pkcs11-scd, or you use GPGs own card implementation, in which case you can forget pretty much everything I wrote above, and just follow the security key manual for setting up a GPG card, enable SSH agent support in the GPG agent, and just use that for SSH authentication.
🤯
Thanks!
I had to create one this year after discovering that connectbot (ssh client on Android) didn't support agent forwarding otherwise.
considered harmful
In 2005, Curve25519 was first released by Daniel J. Bernstein.[5] (https://en.wikipedia.org/wiki/Curve25519)
DJB? Nice! Always been a fan.
Yeah, look at the curves on that guy.
It says that
Starting in 2014, OpenSSH defaults to Curve25519-based ECDH.
So what changed recently? (I didn't watch the video, in fairness).
ssh-keygen now defaults to ed25519 so you don't have to do ssh-keygen -t ed25519 anymore. The default since 2014 is for key exchange when connecting.
Got it, thank you!
TL;DR: It'll use a new, more secure key type.
Nice no ChatGPT anymore to remember how that damn Algorithm is spelled.
Why not just call it RSB ? People, really!
Here is an alternative Piped link(s):
https://piped.video/tdfBbpJPTGc
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source; check me out at GitHub.
Isn't elliptic curves cryptography sensitive to quantum computers attack? Shor's algorithm etc
Yes, though OpenSSH has already switched to a quantum resistant algorithm for key exchange (Streamlined NTRU Prime, combined with x25519 in case SNTRUPrime turns out to be weak), and that's the stuff that needs to be switched as soon as possible to preserve forward secrecy. Authentication keys are less urgent.
Yes, it is. ed25519 depends upon discrete log for its security, which Shor's algorithm can (theoretically, of course, not like it's ever been done) efficiently solve.
The post-quantum algorithms are in active research right now. I don't blame anyone for avoiding those at least until we've quantum computers big enough to solve baby toy elliptic curves.