Operational PGP(gist.github.com)
gist.github.com
Operational PGP
https://gist.github.com/grugq/03167bed45e774551155
27 comments
What could possibly go wrong
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.
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.
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?
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?
Yes.
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
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
[deleted]
>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.
Has anybody been successful in buying one? I can never seem to locate a store that sells to the US.
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).
kernelconcepts.de sells them and ships to the U.S.
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.
If you're expecting trouble from state actors, then yes, you may want to consider other options.
> 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.
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.
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).
It's still trivial for any state level adversary.
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/
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/
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.
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...
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...
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?
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?
Sure, #lavaboom on Freenode is mirrored on our Slack. Hit us up anytime :)
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?
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?
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).
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).
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.
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.
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.
I can't wait for the day when we have something extremely secure, simpler, and easier to use that has wide adoption.
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.
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.
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)
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)
I'm using this for the subject line of all my emails from now on.