
An update on GnuPG - jlgaddis
https://lwn.net/SubscriberLink/735840/11066f48be7a5f92/
======
squashmode
I agree with the statement in the article that the current Web-of-Trust model
is broken. I think that is one thing that the folks at keybase (keybase.io)
understand, and I like their model. I like it enough, in fact, to actually use
it, something that I cannot say about GPG despite having tried it on numerous
occasions over the years.

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?

~~~
dward
Last time I tried to use keybase it required me to paste my private key into a
browser before using any of the advanced features like chat. This seems
unnecessary and doesn't make any sense from a security perspective. Has the
situation changed? I won't use their service until this is fixed.

~~~
jonafato
If I recall correctly, you can choose to let keybase store your password-
protected private key for the purposes of decrypting messages through the
website, but that's not required, and the advanced features (e.g. chat) don't
work without a local install. Everything that can be delegated to the app (GUI
or command line) generally is. The keybase team seems to take this quite
seriously, and they've had documentation on how to use the platform without
giving their servers any information since at least when I joined in early
2014.

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.

------
RJIb8RBYxzAMX9u
> Support for 4096-bit RSA keys has been in GnuPG for some time, but Koch
> contends that real security will require 16Kb keys [...]

Could someone corroborate or cite sources? I thought 2048-bit is still
considered secure, and 4096-bit slightly overkill.

~~~
ekianjo
yes, is there any reliable place to look for the current "best" practices for
keys generation? (as in, good enough for the foreseeable future)

~~~
pfg
[https://www.keylength.com/](https://www.keylength.com/) presents the
recommendations from various best-practice documents for many key types and
cryptographic operations.

~~~
RJIb8RBYxzAMX9u
If I'm using the comparison tool correctly, then it shows that 2048-bit keys
would be fine up to 2020 ~ 2030, and 4096-bit keys beyond ~2022. This is in
line with my understanding.

FWIW, ssh-keygen(1) generates 2048-bit RSA keys by default[0]. Generally if I
had to appeal to authority over security matters, I refer to the OpenBSD /
OpenSSH guys.

[0] [https://man.openbsd.org/ssh-keygen#b](https://man.openbsd.org/ssh-
keygen#b)

~~~
brians
SSH Keys are for login authentication. If tomorrow we crack RSA-2047, you can
replace them before we get to 2048 bits.

GPG Keys are for secrecy. If the adversary gets a ciphertext, he can hold it
until 2030 and decrypt then. Very different model!

~~~
foo101
I am not convinced they are very different models.

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?

~~~
heavenlyhash
Yes. It is, forgive me for being blunt, nearly completely wrong.

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.

------
confounded
> _Historically, using HSMs has meant smartcards, but Koch noted that even
> though these implement an open standard they do it with proprietary code,
> leaving us no current choice but to evaluate the vendors for
> trustworthiness, and then choose a product. Though this is what Koch himself
> does now, he 'd like more freedom, and is working to bring to market the
> Gnuk token._

As far as I’ve understood, the NitroKey[0] is fully open and commercially
available. Why not it?

[0]: [https://www.nitrokey.com/](https://www.nitrokey.com/)

------
goerz
Just updated to the newest version, which seems to change quite dramatically
how gpg-agent works. I can no longer figure out how to limit a gpg-agent to
the current shell (the old version relied on environment variables which were
easy to keep local). It bothers me that now, if I do anything with gpg, any
other program on the computer can just decrypt information at will. Any
solutions for this?

------
oconnore
In a world where we measure webpage size in megabytes, why do people consider
key size to be so important? I can see TLS caring due to latency, but gpg? I
could attach a McEliece quantum 8MB key to every email I ever send, so your
"large" RSA keys aren't a big deal.

Edit: oh, smart cards...

~~~
tscs37
Protocols.

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.

~~~
diafygi
Heh. The way web bloat is going, I can totally see a framework "optimizing"
this by showing the user a spinner over HTTP while an ajax request does the
first tls handshake, then redirects the user to the https version of the site.

~~~
stephenr
That defeats the purpose of https - the code/response that dictates the
redirect can be intercepted and redirect the user to a malicious site.

------
sneak
Does it still use a ridiculously low number of iterations of a KDF that is
neither time- nor memory-hard for deriving symmetric keys from passphrases?

~~~
dewyatt
No, I believe it uses a calibration routine to pick the number of iterations
nowadays:

[https://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gnupg.git;a=blob;...](https://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/protect.c;h=9b262a97886c3ca515eb2f446ad6c445df5f6211;hb=refs/heads/master#l161)

So it depends on the hardware it is run on, and has a lower limit as well.

~~~
sneak
But still not an appropriate PBKDF for 2017 - and the lower limit is only 65k
iterations.

------
earenndil
> RSA, he said, is not likely to stay secure for much longer without really
> large keys

Anyone got any more info or a source on this?

~~~
confounded
I wasn’t at the talk, but I imagine this is may be related to beliefs around
quantum computing gradually moving from ‘if’ to ‘when’, in the last few years.

~~~
Quiark
The problem is that when QC come, ECC will not be in any better position than
RSA...

------
theyregreat
Awesome news. Also, instead of ssh private keys, I use monkeysphere which
stores them in gpg instead. With git and ssh scripts, it’s easy to make it
automatically ask for your psssphrase on first use.

~~~
roblabla
I use gpg-agent's ssh support and a yubikey to store my SSH private key. It's
a pretty nice experience, being able to switch between computers having my SSH
key always with me.

~~~
krullie
I'm using it like that as well, It's a really nice experience once you
convince all the applications using ssh to use the gpg-agent's socket.

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 ('-_-).

~~~
jlgaddis
I asked a similar question the other day:
[https://news.ycombinator.com/item?id=15431299](https://news.ycombinator.com/item?id=15431299)

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.

~~~
jlgaddis
> _The first that happens ..._
    
    
      s/first/worst/

