
OpenPGP best practices - ashitlerferad
https://help.riseup.net/en/security/message-security/openpgp/best-practices
======
sourpoi
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.
    

..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.

~~~
lmm
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.

~~~
r0muald
Wouldn't this be the case for the commonly stolen laptop where you had the
only copy of your signing key?

~~~
lmm
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?)

------
schwarrrtz
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]

[0] [http://www.thoughtcrime.org/blog/gpg-and-
me/](http://www.thoughtcrime.org/blog/gpg-and-me/)

[1]
[https://news.ycombinator.com/item?id=9104562](https://news.ycombinator.com/item?id=9104562)

~~~
pmoriarty
What's a good alternative?

~~~
ashitlerferad
moxie's stuff is, but it is designed for the always-online mobile world:

[https://whispersystems.org/](https://whispersystems.org/)

~~~
simoncion
> ...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...)

~~~
Freak_NL
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.

~~~
masklinn
1\. that's not a property of the protocol, it's the way they implemented
verification

2\. it absolutely doesn't require _a smartphone_ , just a routable phone
number, that can be a cell phone, a landline, a voip number or a google voice
number: [http://support.whispersystems.org/hc/en-
us/articles/21247611...](http://support.whispersystems.org/hc/en-
us/articles/212476118-Will-any-phone-number-work-How-do-I-get-a-verification-
number-)

------
Freak_NL
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](https://en.wikipedia.org/wiki/OpenPGP_card)
[1]:
[https://developers.yubico.com/PGP/Importing_keys.html](https://developers.yubico.com/PGP/Importing_keys.html)

~~~
nickik
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.

~~~
hollander
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-...](https://www.yubico.com/2015/02/big-
debate-2048-4096-yubicos-stand/)

> _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._

~~~
andreareina
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?

~~~
hollander
It's probably marketing.

------
imrehg
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.

~~~
ashitlerferad
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.

~~~
imrehg
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?

------
xaduha
[https://github.com/philipWendland/IsoApplet](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.

[https://developers.yubico.com/ykneo-
openpgp/Releases/](https://developers.yubico.com/ykneo-openpgp/Releases/)

------
secfirstmd
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...](https://play.google.com/store/apps/details?id=org.secfirst.umbrella)

 __ _Ends blatant plug :)_ __

------
archycockroach
Parcimonie's SSL cert is 760+ days expired... Do we trust it either?

~~~
rahiel
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.

[1]:
[https://packages.debian.org/stretch/parcimonie](https://packages.debian.org/stretch/parcimonie)

------
zimbatm
Most of these steps should be defaults. This is the reason PGP is not popular,
the UX is just terrible.

