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.
..and later:
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.
If we respect un-expiration then expiration offers no protection at all against a compromised signing key ..leaving the revocation certificate as our only hope.
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.
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.
> 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.
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.
> Even the webapp requires a linked smartphone; a phone number is [currently] a hard requirement of Signal.
I never said otherwise. What I said was:
> Signal text and voice chat works just fine if all of your communicating party's machines are offline.
This was in response to an assertion that Signal was designed for the "always-online" world. Signal works just fine when your contact is completely offline for extended periods of time.
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.
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
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)
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.
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.
> 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:
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.
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...
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.
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?
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:
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.
