GPG is proposing going to a TOFU model (trust on first use, much like ssh works). I'll be curious to watch if that takes off, it seems like a step in the right direction.
I think 'trust' as a concept is difficult to codify into a protocol. What alternatives are there that would be better than what keybase.io does, or what GPG is proposing?
Give it a shot, it's quite painless as far as crypto products go. You can always choose not to use it if you decide it's storing too much information. Happy to provide an invite if you (or anyone else) needs one.
Could someone corroborate or cite sources? I thought 2048-bit is still considered secure, and 4096-bit slightly overkill.
There aren't any. I was also quite surprised, not sure what Werner exactly said, but I doubt he wanted to seriously question RSA-2048.
Also the various key length guides people like to cite where someone says "key length x bit is exactly secure until the year 2030" are usually nothing more than things people made up and they're not based on scientific sources.
The state of RSA security is actually relatively clear: 2048 bit is secure against all existing classical attacks. It would require massive and unlikely mathematical breakthroughs to change that. If you add in quantum computers then RSA is pretty much broken with all normal key sizes (but ECC is as well). There's a difference between 2048 and 4096, but it probably doesn't matter that much in practice.
FWIW, ssh-keygen(1) generates 2048-bit RSA keys by default. Generally if I had to appeal to authority over security matters, I refer to the OpenBSD / OpenSSH guys.
GPG Keys are for secrecy. If the adversary gets a ciphertext, he can hold it until 2030 and decrypt then. Very different model!
My argument: An attacker can save the encrypted SSH traffic going over an insecure channel, then hold the traffic until 2030 and decrypt then.
Do you find a flaw in my argument?
For starters, there's two different kinds of keys in use: symmetric and asymmetric. The ratio of "bits" to "strength" is completely different for the two categories.
Asymmetric keys are typically only used to handle identity, then bootstrap a selection of symmetric keys (which are faster to use, generally); and then the symmetric keys used are typically based on Diffie Hellman key exchange, which is a whole 'nother ball of wax.
Which bits you have to hold onto, and what you get when you compromise them, is not a flat field. Compromising the asymmetric keys used for identity at the beginning of communication means you can forge that identity in the future; but it doesn't necessarily mean you get to compromise other communications made with yet other keys which were merely agreed upon under the situational aegis of those asymmetric keys at a previous date.
There's a mathematical trick (actually these days several different ones, but the original idea is the same) which lets two people agree on a number without either of them saying what the number is OR any witnesses knowing what it is by watching the conversation. If you struggle with high school mathematics look for videos which demonstrate this trick using mixing paint, so you're not distracted by mathematics you don't understand.
This trick is routinely used in realtime communications (HTTPS, SSH, secure messaging protocols) to make a throw away transient key [actually usually two and sometimes four] used only for one conversation. Once the communication is over, both parties throw away their transient keys, and even somebody who knows the long term keys can never find out what they were because of Forward Secrecy.
Gnupg cannot do a diffie hellman key exchange to set up the session/symmetric key: one party unilaterally generates a random symmetric key (eg: aes key), encrypts the session key with the recipient's public (asymmetric, eg: RSA) key, the message with the symmetric key and sends both cipher texts as the message. A passive attacker can store this, and will only need to crack/gain access to the recipient's private key, to recover the symmetric key, and then the message.
Active/online protocols can use a key exchange: today that typically involves ephemeral (elliptic curve) diffie-hellman. The exchange is authenticated with the asymmetric key - but the session keys are independent of these "permanent" keys.
So the eg: RSA key is used to make sure you're playing "guess the number I'm thinking of (the random symmetric session key)" with the intended recipient, and not an active attacker - but when the session key is thrown away, there's no way to recover it for either of the participants or a passive attacker.
If you hold the traffic until 2030 and want to decrypt it, you have to break either the symmetric keys, or the key exchange. Breaking the "SSH key" would allow you only to forge a new signature, but that doesn't help decrypting past traffic.
That's the difference between the models: a key used for encryption, once broken, allows you to decrypt. A key used for signing, once broken, allows only forgery. And for SSH, forgery must be done while the forged key is still accepted (known_hosts or authorized_keys).
In the future, recommendations will need to be increased and less secure methods deprecated.
As far as I’ve understood, the NitroKey is fully open and commercially available. Why not it?
Edit: oh, smart cards...
You really don't want to sign every TLS packet with a 8MB signature or in this case, send 8MB key material over TLS before properly opening the session.
Even if you are the 1% with gigabit connections, that is going to induce some decent latency into the system.
It's simply wasteful.
but seems to be from the 90s. Maybe faster algorithms are merited now...
Fixed that for you.
So it depends on the hardware it is run on, and has a lower limit as well.
Anyone got any more info or a source on this?
In fact, we don't even know whether RSA security is based on something provably hard.
Have you enabled any other yubikey features while having all you gpg + ssh keys on it? Like for using U2F? I'm a bit scared I'll wipe my key ('-_-).
Basically, it all works fine (I've verified it myself). I've been using a Yubikey for both SSH and challenge/response for quite a while now. A few days ago I started messing with U2F as well. The first that happens is gpg-agent "gets confused" after U2F auth and you have to remove/insert your key and/or re-enter your GPG PIN on next use (cf. linked thread).
Next up for me is figuring out how to disable U2F on my Nano's and use separate U2F-only keys for that (without any conflicts or issues, hopefully).
N.B.: I don't use the OTP functionality at all, currently. I'll probably try out the PIV stuff soon as well and I expect no conflicts or issues with the existing stuff (GPG, C/R, etc.) I have setup.