▲ 142 points
back
51 comments
Regarding expiration, from the article:
you can always extend your expiration date, even
after it has expired! This “expiration” is actually
more of a safety valve or “dead-man switch” that will
automatically trigger at some point. If you have access
to the secret key material, you can untrigger it.
If you forget your passphrase or if your private key is
compromised or lost, the only hope you have is to wait
for the key to expire (this is not a good solution), or
to activate your revocation certificate by publishing
it to the keyservers.
Only in cases where you have both lost access to the signing key and lost confidentiality of the signing key at the same time, which seem pretty unlikely.
Wouldn't this be the case for the commonly stolen laptop where you had the only copy of your signing key?
If your key was stored with no passphrase (or you're using the agent and had signed something just that minute) and you think there's a realistic possibility the thief will do something other than wipe the laptop immediately and you have no other copy, sure, I guess. I wouldn't expect a state-like adversary that wanted to steal your signing key to use such an attack (much more visible and riskier than just taking the key and leaving the laptop). And I'd expect the kind of person who takes their keys with them on a laptop to have copies in other places.
(I mean ideally you'd always back up your keys and/or revocation certificate, but it's always a question of risk factors. Allowing "unexpiration" definitely induces some risks; the question is are they higher or lower (given the costs) than not allowing it?)
If you follow riseup.net's recommendation you'll keep your signing key backed up and offline. The only key on your laptop would be a subkey that could be revoked using the offline key or its backup.
Moxie on GPG:
> The protocol reflects layers of cruft built up over the 20 years that it took for cryptography (and software engineering) to really come of age, and the fundamental architecture of PGP also leaves no room for now critical concepts like forward secrecy. [0]
> We could try to slap a GUI on top of it, but I don't believe great products are made that way. Good UX requires thinking about interactions all the way down to the protocol. [1]
>> We could try to slap a GUI on top of it, but I don't believe great products are made that way. Good UX requires thinking about interactions all the way down to the protocol.
unsure if I agree. A lot of the user-space Unix/Linux Gui applications are built that way: command line interface first and GUI to control that. (the opposite of windows where often a cmdline interface is built to control the functionality provided by the GUI application).
So by that logic the majority of applications that have a GUI are labelled "not great products". Hmmmm ...
I think what he means is that building a GUI wrapper around a CLI can't make up for deficiencies in the CLI itself. I don't think he's against GUIs in general.
> So by that logic the majority of applications that have a GUI are labelled "not great products". Hmmmm ...
When it comes to Linux GUI applications, that's a pretty fair description. Understated and over-praising if anything.
What's a good alternative?
moxie's stuff is, but it is designed for the always-online mobile world:
That's not an alternative to PGP. PGP is not meant for streaming data, it is for store and forward systems (traditional email, signing packages, etc.).
Alternatives to PGP should probably include S/MIME and Signify, depending on what you want to do with it.
> ...it is designed for the always-online mobile world
Soft disagree with that. Signal text and voice chat works just fine if all of your communicating party's machines are offline. (Well, I mean, obviously your voice call won't be answered, but otherwise...)
You can't use Signal without a smartphone running Android or IOS. Even the webapp requires a linked smartphone; a phone number is a hard requirement of Signal.
moxie's stuff is great (I use it), but it's not ideal. Among the issues is that it essentially ignores some hard problems like identity (or seems to): AFAICT everything is keyed off of phone numbers; if I control a number then I control its identity, and anyone who talks to me has to use the identity Open Whisper Systems publishes, or not talk to me at all.
minilock (https://github.com/kaepora/miniLock/), see the video for a good overview of how easy it is to use.
I'm with moxie and Matthew Green (http://blog.cryptographyengineering.com/2014/08/whats-matter...), I think that we should seriously thank PGP for what it's done, understand what to do and what to not do (I believe Web of Trust is part of these) and take advantage of the fact that PGP has relatively few users to create something better.
Unfortunately there isn't really one at this point that I know about. There are some in development. The one I am most hopeful about is briar: https://briarproject.org
Amateurs aren't allowed to write any crypto, so unless one of the few accredited elite like djb decide to write an alternative, we're all out of luck.
Look at how OTR was created. It failed the first version hard, but it was fixed in later versions because authors published their protocol and it was reviewed by "elite". Now it is an easy to use and secure protocol, which "elite" builds upon. TextSecure is based on OTR.
That's not true. Everyone's allowed to write crypto as long as they understand what they're doing. The difference is that if djb releases new crypto code, I believe it will be correct and he's going to publish a few papers on why it's correct.
If anyone else does it, they better write some really good papers about it and get reviews from the trusted people. (and they usually don't)
Good solid set of tips.
One thing I would like to see a summary of is the use of secure USB-keys to keep your private key off your computing device using the smart-card functionality in GnuPG [0]. It seems that this is possible with devices such as Yubico's Yubikey Neo [1]. Having your GPG private key with you as a physical 'key' — with all private operations performed via the USB-key — seems like a great way to increase security and prevent loss of your private key.
[0]: https://en.wikipedia.org/wiki/OpenPGP_card [1]: https://developers.yubico.com/PGP/Importing_keys.html
Yes. I use a Yubikey 4 Nano and I have it always plugged in to may Laptop. The Master key however is not on the Yubikey. It is only available on external encrpyted USB drive that I only use for certification.
Currently their is no way to use your 4096bit key over NFC. The Yubikey NEO only supports 2048bit keys and the Yubikey 4 does not support NFC. So you have to either use a secondary key or expose yourself and put your private key on your phone.
I fully expect Yubico to realease a Yubikey 4 with NFC sometime this year, and this would enable my optimal solution:
I have a Smartphone and a Laptop. To securly use them, I should have 3 Yubikeys, 1 of them a Nano plus 2 USB Sticks. The Nano is always plugged into my laptop, exept for exeptional situations. One of the large Yubikeys is on my keyring, the other is at home as a backup. One USB stick is only for the Master Key and I would bring it along if I expected to use certification. The other USB Stick is a poor backup and savly stored at home, it also contains the Revocation Key.
All this is pretty expensive and not really all that easy to set up but if you do it you have the great benefits, like ähh well äähh I guess other crypto nerds might think its cool.
Yubico themselve say that the 4096 bit key only adds 16% more security. So the Neo is practically as safe as the 4.
https://www.yubico.com/2015/02/big-debate-2048-4096-yubicos-...
> While it is true that a longer key provides better security, we have shown that by doubling the length of the key from 2048 to 4096, the increase in bits of security is only 18, a mere 16%. Moreover, besides requiring more storage, longer keys also translate into increased CPU usage and higher power consumption.
18 additional bits of security means a bruteforce attack is 2^18 (262144) times harder. Quite a long way away from "16% more security". Yubico is intentionally obfuscating their words here by talking about the percentage increase between number of bits of security so that people will walk away with this exact misunderstanding.
There is argument to be made that 4096-bit RSA keys are unnecessary. But this isn't it.
The math behind the security gain by increasing the key length of an RSA key seems slighly more complicated then one might expect. Here is a (short) introduction by the GnuPG folks:
https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa40...
Shorter version: RSA-4096 is roughly 28bits over RSA-2048 (112 vs 140 bits).
Thats not the point. I already had a 4096 key and its already distributed and certified by people. I will not change all of my system back to 2048 just so I can use a SmartCard.
If I had started with Yubikeys when I started with GPG I would have used 2048 and updated when the Smartcard technology improved.
Additionally I have not a huge need for gpg messages on my Smartphone, so its not a big problem.
18 bits translates to a ~250k-fold increase in effective security. Am I missing something, or is this just bad math on Yubico's part?
It's probably marketing.
Why don't you use read-only media (CDs, DVDs) for your master key (backup)?
Those are very hard to temper with, while USB sticks are trivial to temper with (be it accidentally or by someone with malicious intent).
I dont have the hardware to do that but it would be a good idea.
Nice set up.
It's all about proportionality. If your GPG-key (and SSH-key) grants you access to servers containing sensitive data placed there in good faith (think medical records), then having your private keys stored somewhere they can't be copied from without physically obtaining (and destroying) the keys is totally justified.
And if you are doing it because, well, you can, then you are helping in making this knowledge available to the wider community.
I have not jet transitioned to using SSH-keys from the Yubikey. I have some issues with the ssh-agent understanding that I use a PIV interface.
I think pushing the bounds and evaluating usablity, maybe finding bugs is important. I still mostly do it for fun. I really like thinking threw different thread models and security systems.
For example, compare the security gained by keybases new system (NaCL, device keys, tracking) with my old gpg/smartcard/wot system.
I don't trust the YubiKey Neo because of the security flaw that allowed anyone to trivially bypass PIN authentication and GPG sign stuff just by waving their RFID-enabled phone past your YubiKey, and because they insisted it didn't really matter because an attacker might have been able to learn your PIN anyway[1]. This is a general downside of smart card based devices; they're generally designed so that the only thing enforcing the use of the PIN/password is an if statement somewhere in the code, and if that contains a logic flaw or can be bypassed...
[1] https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory...
Nobody will ever make a 100% secure system. What are the alternative NFC Smartcards that I can use?
Yubico did not behave badly. Their products continue to improve in secuirty.
What is your alternative setup that provides anything close the same usablity?
That's not true. The whole point of a smart card is that it's NOT just an "if statement".
I'm afraid it is in many cases. The whole point of a smart card is to wrap enough hardware anti-tamper measures around that if statement in order to stop you from bypassing it.
What happens if you lose the card / key, or in case it becomes non-functional? How do you back-up the private key?
Maybe read this post of mine: https://news.ycombinator.com/item?id=11437413
Indeed, didn't think about having another stick for the backup.
Nitrokey provides an open hardware implementation of OpenPGP Card, keeping your private keys off machine.
Yeah, I'm trying to follow these practices, and lot of good ideas. In the process there were some surprising things (to me at least) implementing "Use an expiration date less than two years." It's reasonable advice, while I did not predict, that in that case, the key file (e.g. the public key) size will increase every time the key is renewed. I know it's kilobytes, so should not matter. But in web interfaces where you would paste the key (such as today's Github update) I'm not sure if they have set a max-size. If using a strong key (many bits), and renewing every year (or every 2 years), I'm sure that public key will balloon... Also, now that GPG keys are used in many different settings, likely have to remember to upload the renewed key not just to the keyservers, but to keybase.io / github / etc, otherwise end up with strange breakages, I don't think expiring keys are expected in general.
Expiring and revoking keys is a core part of how OpenPGP is meant to work.
Export just the valid self-sigs:
--export-options parameters
export-minimal
Export the smallest key possible. This removes all
signatures except the most recent self-signature on
each user ID. This option is the same as running
the --edit-key command "minimize" before export
except that the local copy of the key is not modi-
fied. Defaults to no.I know it is supposed to work like that, though in practice that's not how people seem to use it (ie. the issue of "you are holding it wrong").
Thanks for this parameter, did not know that before, and this should help a lot! :) I guess it should be something to be pointed out in the docs as well as relevant feature?
https://github.com/philipWendland/IsoApplet is a thing that you can load to your own blank Javacard.
Come to think of it, you should be able to load ykneo-openpgp to your card also.
Very useful guide and a lot of great work being done by the folks at Riseup.
Begins blatant plug -If anyone is looking for a mobile app with of ton of similar digital and physical security guide then we launched Umbrella. It's an open source Android mobile app with advice on everything from sending a secure email to dealing with a kidnap. Take a look here:
https://play.google.com/store/apps/details?id=org.secfirst.u...
Ends blatant plug :)
Parcimonie's SSL cert is 760+ days expired... Do we trust it either?
Parcimonie's author is also the maintainer of the package in Debian [1], apt checks PGP signatures on packages so you could trust that. I'll contact the author about the SSL issue.
Most of these steps should be defaults. This is the reason PGP is not popular, the UX is just terrible.