
Operational PGP - FiloSottile
https://gist.github.com/grugq/03167bed45e774551155
======
yellowapple
> "Subject: Your Cocaine Has Shipped!"

I'm using this for the subject line of all my emails from now on.

~~~
wglb
What could possibly go wrong

------
zobzu
Most of these recommendations are pretty drastic. Not using keyservers and
using --throw-keys for example - while the author's examples are valid, i fear
that PGP needs more useability, not less, to strike a balance of "pretty good
privacy".

Too hard to use means it won't be used right or at all, thus actually does not
enhance, but instead reduces security.

I feel like that beyond this, improvements to the gpg cli, lib, et al. are
necessary for it to be used securely.

------
jrub
Legitimate question:

The whole "delete when you're done' practice is a pretty common tenant to
secure communication. However, there are plenty of cases where having that
historical data is really useful. After all, computers are excellent at
storing archival data, and being able to search and reference that archive has
saved me more times than I can count.

What practice, then, can you employ to maintain a secure archive of your
messages for future reference? Is this something that is considered rude, or
even dangerous and reckless, given that the mere existence of the archive
introduces an attack vector, thereby compromising the effectiveness of
encrypting the messages at all?

I understand that there are a lot of trade offs and sacrifices to be made in
the name of security, but is maintaining a message archive one of those
sacrifices that is expected to be made by all parties? Or is this one of those
points that can't be covered with a blanket statement, and the retention
policy is pretty much dependent 100% on the sensitivity of the content?

~~~
grugq
Yes.

~~~
grugq
To elaborate, the security precautions you take are entirely dependent on the
threat you face (or believe you face). If you're Dread Pirate Roberts,
creating a detailed diary of you criminal activities is a terrible idea [1].
If you're a 13 yr old girl, creating a detailed day by day diary is probably
not a life threatening decision.

You should take the precautions appropriate for your threat model and risk
appetite. I suggest deleting correspondence after a set period of time. I know
people that do a yearly purge of all their sensitive mail for the previous
year in January.

If you are encrypting for the sake of encrypting, as some people do (see:
cover traffic), then you can keep archives of your mail because you face no
negative outcome if your archive is compromised. There is no downside, so go
for it.

[1]
[https://www.youtube.com/watch?v=pBdGOrcUEg8](https://www.youtube.com/watch?v=pBdGOrcUEg8)

------
epistasis
>If you are going to go with option #1 then you should probably use an OpenGPG
smart card. There are a number of vendors that sell them.

Has anybody been successful in buying one? I can never seem to locate a store
that sells to the US.

~~~
cmhamill
kernelconcepts.de sells them and ships to the U.S.

~~~
patzerhacker
What's to stop your card being intercepted and replaced by a three letter
agency when it's shipped. That's why a physical store with tamper seals is
useful, or better yet when something is manufactured locally - then you can
check before you buy.

~~~
cmhamill
If you're expecting trouble from state actors, then yes, you may want to
consider other options.

------
mapgrep
> Where possible, and relevant, take control over that infomation and unlink
> it from data linked to you. For example, you can control the From field by
> creating a new email account.

I genuinely wonder, what's the point of rotating different From: addresses?

If a message has been GPG signed, it is trivial to discover the corresponding
public key. Thus, a form of identity — the public key, typically along with
email, name, and/or other "user id" information publicly associated with the
key — is available to an attacker rergardless of the content of the message.

The sender could refrain from signing the message, but then every time (s)he
rotates a new address into the From: field, (s)he must communicate through
some other trusted channel that the new address is associated with his/her
identity and existing public key.

Then there's the practical concern that most gpg implementations are going to,
by default, lookup in the keyring based on the To: address in the email and
the user-ids of the keys in the keyring. This will fail, unless the new
address is added as a user-id to the public key, which defeats the whole
purpose of rotating the From: address.

~~~
rinon
I think this is why the author recommends NOT publishing public key identity
publicly. Additionally, signing may not actually be necessary or desirable
(e.g. given out-of-band transmission of the receiver's public key and a desire
to avoid attribution).

~~~
grugq
Correct. There is a section that addresses signing. In short: don't do it.

OP: From addresses are not to be rotated. Each communications channel should
be in a compartment. Compartmentation requires minimizing the amount of
information leaked, not maximizing it by contaminating a large number of
addresses.

For more information on compartmenting and unlinking relationships, see [1].

This guide is not a complete COMSEC plan. A complete plan would be tailored to
match the circumstances and requirements of the actors involved. This is a
collection of notes and best practices. They need to be adapted and actively
applied for the situation.

A complete COMSEC plan would include things like setting up dedicated email
accounts for correspondence, creating the corresponding PGP keys. The
confederates would exchange contact information, either out of band, or via
another exist secure channel. Information exchanges would be via PGP email
with fixed subject lines and only relevant information inside the content. All
emails would be deleted in a rolling 7 day window.

[1] [http://grugq.github.io/blog/2013/03/18/the-paddy-
factor/](http://grugq.github.io/blog/2013/03/18/the-paddy-factor/)

------
na85
Yikes, I did not know about --throw-keys being necessary to discard metadata.
Kinda scary how easily you can leak information even with great tools.

------
simi_
We at Lavaboom use PGP manifests to hide most email metadata inside the
envelope [0] [1]. Inspired by [2].

0: [https://github.com/lavab/pgp-manifest-go](https://github.com/lavab/pgp-
manifest-go)

1: [https://github.com/lavab/pgp-manifest-js](https://github.com/lavab/pgp-
manifest-js)

2:
[https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.h...](https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html)

~~~
HerraBRE
Interesting to know you took my idea and ran with it!

I'd love to chat with you guys about your implementation, the whole point of
that blog post was to get people to discuss and interoperate... any chance
I'll find you on IRC?

~~~
simi_
Sure, #lavaboom on Freenode is mirrored on our Slack. Hit us up anytime :)

------
darklajid
I'm a bit tired, but can someone explain how "Publishing? Not a great idea"
and "Deniable key exchange" fit together?

It seems the former says 'just hand our your key to persons that need it',
while the latter seems to say 'make your key available ~everywhere~'? This
part even lists key servers as one of the routes others can take to verify
your key?

~~~
grugq
I am a public figure. If you want to contact me via PGP you can find my key
easily. When you contact me, you encrypt your message and include your public
PGP key. This eliminates the threat of a man in the middle attack. Only one
side needs to be authenticated (mine) and it is done publicly.

If you and a friend want to discuss something secretly, then you can create
new email accounts plus new PGP keys and exchange them out of band, e.g. via
USB stick. This will allow you to remain somewhat anonymous in that neither
email account nor key are linked to you. As long as you don't taint that
compartment, it will be secure against compromising you.

That level of secrecy might not be necessary for your given threat model. It
is up to you and your interlocutor how you want to secure your comms channel.
This guide presents best practices that can be combined into a complete COMSEC
plan.

This guide is not a strict HOWTO that presents a simple step by step solution
for everyone. No such HOWTO can exist. Instead it presents a number of
solutions to problems (and attempts to explain what problems they solve, why
and how).

------
rc4algorithm
This is a relatively minor issue, but "PGP" and "PGP-Encrypted Message" are
probably cleaner subject options. The message is obviously encrypted, so these
titles don't leak any information.

------
eyeareque
There is a lot you can get wrong when using PGP. A single mistake can cause
you to be in a load of trouble.

I can't wait for the day when we have something extremely secure, simpler, and
easier to use that has wide adoption.

~~~
lisper
You might want to look at this then:

[https://github.com/Spark-Innovations/SC4](https://github.com/Spark-
Innovations/SC4)

It's not widely adopted (yet) but it is a whole lot simpler than PGP. We're in
the process of fixing the issues uncovered by the security audit now, but it's
already in pretty good shape.

------
comrade1
Key management is one of the toughest issues for secure email. Key management
for an individual is hard enough but can you imagine how it would be for a
corporation? PGP (the second incarnation that was bought by Symantec, not the
first that was bought by RSA) had corporate tools for key management that
worked quite well.

Quite a few companies used PGP's products. I'm not sure what the state of the
customers are now that it has been bought by Symantec. I'm genuinely curious.
(I used to work for PGP)

