OTOH, it's defense in depth, and there are some vulnerabilities which could allow to exfiltrate keys without non-sandboxed-RCE

https://blog.mozilla.org/security/2015/08/06/firefox-exploit...

I reckon that a passphrase protected key would be safe from this attack (modulo offline brute-forcing)

Yup. IMO not using a passphrase is nuts, considering there is practically no convenience loss (ssh-agent, OS X keychain, pageant) and fairly significant benefit. Protects against:

- accidentally exposing the private key (it happens, accidental wildcard in the shell), and

- attacks that aren't after your keys specifically, e.g. your home directory gets stolen.

I have since discarded these products (and others should too), but they do exist.

Why are ED25519 keys better than RSA, how compatible are they with different systems, and are they worth the hassle and risk of generating and using a new one?

Two reasons: 1) they are a lot shorter for the same level of security and 2) any random number can be an Ed25519 key. To generate an RSA you have to generate two large random primes, and the code that does this is complicated an so can more easily be (and in the past has been) compromised to generate weak keys.

What I don't get then is how can a short key be secure, that goes against what I was taught in college. Aren't shorter keys more prone to collisions and bruteforce attacks?

Given the same cipher, more or less, yes. Between ciphers, though, key-lengths are less relevant, and the differences in those ciphers become more so.

EDIT: Think of it in terms of Shannon Entropy: because RSA requires a pair of primes, the keyspace is so much sparser — that is to say, more "predictable" (if, granted, at a mostly theoretical level) — so keys need to be that much larger to be secure.

Contrarily, with ED25519, keys can be smaller, because the keyspace is denser.

(Or am I just talking out my ass here?)

EDIT 2: s/smaller/sparser/, s/bigger/denser/, regarding keyspaces. Thanks, 'lisper!

The other factor (no pun intended) that makes RSA keys large is that there are more efficient algorithms for factoring than there are for solving the elliptic curve discrete log problem, e.g. https://en.wikipedia.org/wiki/General_number_field_sieve If you crunch the numbers on this you will find that a 2000-bit RSA key has a security level of about 100 bits, i.e. it takes about 2^100 operations to factor a 2000-bit RSA key using GNFS.

Exactly. Generating random primes is not terribly difficult in theory, but in practice it is very tricky, which makes it hard to answer the question: how do you know you can trust your keys? Sure, you can verify that your primes are prime, but how do you know how much entropy they have? The only way to figure that out is the audit the code. (And then you have the problem of making sure that the code you're running is the code you audited.)

Generating random numbers is also tricky, but a lot less so than generating random primes: take an entropy source and run it through a whitener, i.e. feed it to sha512. As long as you have a reliable estimate of the lower bound of the quality of your entropy source, you're good. A lot fewer moving parts.

OpenSSH already has support built in, as does Mosh, and therefore, I do think it's worth it.

I do sometimes disagree with using keys though, despite everyone pushing it so hard, there are cases where I think passwords are the way to go, but thats a long post for another time.

Also, I really like usin pam auth mods, such as yubikeys or google auth for two factor. That combined with regular hardening, and yes Ill admit it, non standard ports (reduces log alert fatique) does a pretty good job.

That sounds interesting, could you elaborate on that?

ECC and RSA are both ultimately going to fall to practical quantum computing, and probably over a time frame short enough that it won't matter which cipher you picked.

All that being said, thats a certain level of paranoia which i dont think is productive.. but perhaps for targets of the state or what have you, I'd rather not chance it.

To put it in perspective, if you were logged out completely and tried to login remotely, you would be forced to use a password login initially. If it was more like my desktop where I'm logged in and the screen in locked, the home folder is unlocked, so I can remotely ssh in using just my keys.

AFAIK the main benefit is: if you want to run a multi-user or headless system, you need the network stack brought up before a password is entered - which home directory encryption provides and FDE can't.

It does not give any extra benefit because tmpfs only resides in RAM, and disk encryption typically only concerns data at rest.

If you come to a point where you want to have /tmp/ encrypted, you would rather encrypt the whole RAM. (Does anyone actually do that?)