Operational PGP

https://gist.github.com/grugq/03167bed45e774551155

by FiloSottile • 11 years ago

70 26 11 years ago

gist.github.com

comrade1• 11 years ago

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)

na85• 11 years ago

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.

zobzu• 11 years ago

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.

yellowapple• 11 years ago

"Subject: Your Cocaine Has Shipped!"

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

wglb• 11 years ago

What could possibly go wrong

simi_2• 11 years ago

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

1: https://github.com/lavab/pgp-manifest-js

2: https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.h...

HerraBRE• 11 years ago

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_2• 11 years ago

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

darklajid• 11 years ago

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?

rinon2• 11 years ago

Exchanging a key pair specifically for future anonymous communication between two parties using a publicly published identity seems like a good compromise for communicating anonymously with previously unknown parties.

grugq5• 11 years ago

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

mapgrep• 11 years ago

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.

rinon2• 11 years ago

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

mentat• 11 years ago

It's still trivial for any state level adversary.

grugq5• 11 years ago

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/

epistasis• 11 years ago

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.

grugq5• 11 years ago

YubiKey now has OpenPGP smartcard functionality. The new YubiKey NEO can even operate over NFC with OpenKeychain for Android. You can use K-9 and store your PGP key on a physical token (the YubiKey). Quite useful if your threat model includes a compromised phone (e.g. malware) but not physical access (e.g. border crossings).

cmhamill2• 11 years ago

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

patzerhacker• 11 years ago

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.

eyeareque• 11 years ago

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• 11 years ago

You might want to look at this then:

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.

jrub• 11 years ago

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?

grugq5• 11 years ago

Yes.

grugq5• 11 years ago

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

rc4algorithm• 11 years ago

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.

Operational PGP

Related Stories