Working with ED25519 Security Keys

What is ed25519?

#

ed25519 is a new-ish cryptography solution that implements the Edwards Curve Digital Signature Algorithm (EdDSA). I say new-ish because ed25519 dropped 5 years ago. It should not be considered as a technology that is particularly bleeding-edge at this point but at the time of writing it is the preferred one to use from a security standpoint.

In the world of encryption keys, we have several popular options available to us:

• DSA: UNSAFE, and no longer supported since OpenSSH version 7. If you have one of these upgrade ASAP!
• RSA: POTENTIALLY UNSAFE. These depend on the key’s size. 1024-bit is considered unsafe. 3072 or 4096-bit length is “so-so” for now. You should probably upgrade if you have this one as well if you can, honestly.
• ECDSA: This one depends on how well your machine can generate random numbers that will be used in the creation of your signature. There’s a trustworthiness concern on the NIST curves that are being used by ECDSA. I think it’s a little spooky, I don’t use this one personally.
• Ed25519: Ed25519 is a strong choice for security due to its high level of performance, offering fast signature generation and verification while maintaining strong security guarantees. It provides robust resistance to common cryptographic attacks, such as side-channel attacks, and is based on well-studied mathematical foundations. Additionally, Ed25519’s simplicity and deterministic nature reduce the risk of implementation errors, making it both secure and efficient for modern cryptographic needs. It’s the most recommended public-key algorithm available and what we will be exploring today!

What’s the big deal? Why should I care?

#

How does ed25519 stack up against the most popular type of SSH key (RSA)?

• Much faster for both generating the key and verifying it.
• Security is way better.
• Collision resilience makes this type of key much stronger against hash-function collision attacks (a type of attack where large numbers of keys are generated with the hope of getting two different keys with matching hashes).
• Smaller keys, making them easier to transfer.

It is also very important to note that RSA is considered not safe if it’s generated with the key smaller than 2048-bit length so if you're using an RSA key and you're in doubt, it's probably a good idea to change over to something like ed25519 just in case.

How to do it

#

Use this to generate a basic ed25519 key:

ssh-keygen -t ed25519 -C "[email protected]"

That's it! Let's check out what it generated in our .ssh folder...

The id_ed25519.pub file in your .ssh directory contains your public key which you will share with people and with your server, you can give this to anyone you want. The id_ed25519 is your private key, and you shuld never under any circumstances give this to anyone. in our case above, you should be able to find your key here:

~/.ssh/id_ed25519.pub

now we just need to copy this to your server and start using your key via SSH. You should guard the private key (usually this is something like ~/.ssh/id_ed25519) and ensure that nobody but you has access to it.

Tweaking the key

#

There is one last thing that you can do to your key to tweak it's resilience a bit. If you are a highly paranoid type (I commend you) you can add a twist to the above command to add KDF (Key Derivation Function) rounds. Beware though that the higher the number you put in here, the slower overall your passphrase verification will be, but this has the effect of increasing your key's resillience vs a brute-force attack to crack it should your private-key be stolen. I find this barely adds a second or two to my logins and I like the added peace of mind so I usually recommend doing it but this is very much an optional step.

An example of how you would generate a key with a strong KDF:

ssh-keygen -a 100 -t ed25519 -C "[email protected]"

What if I want multiple keys?

#

One usecase that may come up is when you need to have a couple of keys for work and home, or a new dev environment that you will need separate credentials for. You can have multiple keys when you are asked to enter a location with the following prompt:

since you will be generating two keys you want to make sure the default names aren't set here. Set this to whatever name you want by giving it a path, or in our case here we would use /Users/test-bench/.ssh/file_name. I named mine id_ed25519_personal. here you can see it listed alongside the original one we made a little bit earlier.

Note that your key will always have it’s own key pair – both a private key and a coresponding public .pub version every time you generate a new one.

Bonus tip: ssh-agent and .ssh/config

#

One final tip you can use to not have to enter your password for your key every time you use SSH is to simply type ssh-add and the location of the key you'd like to use. For instance:

or just ssh-add if you only have one key and you keep it in the default .ssh location:

Either one should work fine. Keep in mind though that you'll still have to run the ssh-add command for the ssh-agent process whenever you start a new session with this method. it's a nice convenience that will store your password for your current session and cease bugging you about it if you want to get into the zone and not be bothered.

Some additional tricks for ssh-add

ssh-add -d file   removes the key file from your agent.

ssh-add -D   clears out all of your keys, resetting it to square one.

ssh-add -l   list currently loaded keys and display the fingerprints.

ssh-add -L   list currently loaded keys and display the entire public key.

ssh-add -x   Will lock out usage of your keys with a password until you unlock them again.

Your keys will not be able to be used until you issue a ssh-add -X command like so:

ssh-add -t   Will set a time to automatically expire your session with ssh-agent. Example:

A note about ssh-add for MacOS users

#

For MacOS users, ssh-add is conveniently integrated with your system keychain. If you use ssh-add -K when you are adding a key your password will be automagically added to your keychain. As long as the keychain remains unlocked the agent shouldn’t be required to load a password. All of your stored passwords in the keychain will automatically get loaded when you run ssh-add -A, and this happens automatically on login.

It should be noted that this is a sacrifice of security for convenience. Keep in mind if you use this method that anyone with access to your Mac will have access to your keys which is no bueno. One approach is to use this feature for keys that are more or less everyday use, and leave your high security keys out of the keychain entirely just as a precaution.

ssh-add -K -d will remove a key from the agent as well as from keychain. If you leave off the -K it will not affect the keychain so just keep that in mind. ssh-add -D will silently ignore the -K.

A more permanent solution

#

If you are the type that's constantly developing stuff in GitHub (or anything else really) and you are tired of having to input your password every single time you want to push a commit to the repo from your dev machine for instance, you can also do something like this in your .ssh/config file:

The agent is really useful if you want to avoid having to create some huge number of configurations in that .ssh/config file (basically, any connection will attempt to use a key found in the agent). It should also be noted that it's also useful for allowing remote SSH sessions to reach back to your local machine if you need the necessary keys for something.

Adding your key to Services

#

If you use Github it's pretty straightforward to add it to your information.

• Go to your github account then go to settings -> SSH and GPG keys. Click on New SSH key button.

• Copy and paste your key using the method below into there and save.

Copying your public key

#

To find our key we'll use the tool called Cat. Cat is short for concatenate. It can be used to append information to the end of a file or manipulate text files, but lets use it to see the contents of a file in the terminal.

Go to your terminal and run this command:

cat ~/.ssh/yourfilename.pub

replace yourfilename with whatever name you have given your key. In this case mine is id_ed25519.pub.

After running the commands above, you'll see something like this: