Silk Road forums
Discussion => Security => Topic started by: pine on March 24, 2013, 03:29 am
-
Hello folks.
Some people know this and some don't, so this is in the nature of a PGP public service announcement.
As kmfkewm recently pointed out to a forum poster a ciphertext can have identifiers embedded into it. This is how it works, try this at home with your own PGP key on a test message to see for yourself.
Example:
This is a PGP ciphertext encrypted to myself using the PGP Club public key.
-----BEGIN PGP MESSAGE-----
hQGMA7pmVyGp4Z9uAQv/Y7fCVqUChMnji1g4Tm4zirTSoBvzoaoB8pmshcFVFYMh
Mx0W8fKVrMOU/TxzSjIhaUvVmxRTAF4MxMNrLg7ncTBWVDeBjrOQCNYUMCrGt//d
0u/HqWn6EfUCADuaxLd52WmF1CIs2ezXJo6XXfwfJCStiel0tek0vpKINlllXwlx
YdgvUZKB3BpE3K2abNfSkaeBHlPvRgUGWI+VAkNpwsNq+y1RXOIVyC0p38Rcpxuv
Bp6iMKoxE30SPOVzYR29bCA8I/+/sRvlOSDTKnDEkiFl7/rezheBJT2+OiJlOIkx
6wTv1HSeWNtrH9jnOGfGUKUgId0eEyKUgnHh1Z9IJlMqnvCNIUreTuylI4/v0izh
5oqA6dHO7S2YPrm1TtDnihBsVrexq6/fv0mBApTR9LChP/0pkDHVKdfkuoUYXjg2
E30Je4iyPSnfD1J597/Aqvv+cOlj5JyAkQ2vFnywYw5s6O/DB93h2jz4XU8KYZmZ
3+slR6o1wV/kDEKg/iFe0lIBdHmum3nEzfSN8kFqRAT/1sMyDBPPs7g7phNPe7lP
NACp4iUHdca8n419dDFDCoqJIXeM4gYqaj5njVvETt73car1l/p/h/GMKptK+CH/
nzlv
=tTJA
-----END PGP MESSAGE-----
If you store this as a text file such as encrypted_msg.asc somewhere, and then open the terminal/command line and type this code:
gpg -v encrypted_msg.asc
The result is this information:
gpg: public key is A9E19F6E
gpg: encrypted with RSA key, ID A9E19F6E
A9E19F6E is the key ID for my public key.
Of course, normally we do not encrypt messages using our own public keys. But there are possible negative consequences for anonymity due to this feature of PGP.
--
Many PGP or GPG software products (most Macintosh software appears to be setup this way for example) automatically encrypt a message to yourself as well as the other person you're sending the message to. So if anybody knows an association between you and your public key e.g. you uploaded it to a key server, or you use the same PGP key for both life inside and outside of SR, then if they intercept your message they'll know it is from you. They won't know what is inside the message, but they'll know it is you who sent it. Not good.
The point is that you really want 1 PGP key for SR, and only SR. Never use that key anywhere else otherwise you'll be linkable between those two places.
Note: One thing that can catch people out is signing. Unless you sign a public key locally, the signature will be uploaded to a keyserver automatically as part of a Web of Trust deal. This is pretty standard among most PGP/GPG software. So, if you are signing people's public keys, ensure you only do this locally. There is an option for this. Otherwise you can be hypothetically traced back from the keyserver. Yes, you could Torify your GPG client, but that's a whole other discussion.
--
Finally, consider that if a message is encrypted to somebody else's public key, that if the Feds know the source of the message, then they have evidence for a connection between you and that person. Sometimes that is all that is required.
-----BEGIN PGP MESSAGE-----
hQGMA7pmVyGp4Z9uAQv9EvfKCl1k8lEDcfgQNR7t/iNg1RaGaQyEShmfgBFkFVWx
r4wjOTxo2Pl5I826Rhzv8axbSom/+K41WRRV38LiHT65RNrPQmyozV/vWOmo18eE
coXqdBzmuOIVbqUkd/oV0bgSxESmbSVc/cTmXDrniZZ/svcD+jbd+oSUCl8yp4U7
xor7ojdpAcL5QFPz8jy7sDU/+7fsDCsgoHW8OTPwcrPckqpFJUZFJd7/9qbbwdE6
BuyJYDmvFgqQAjB8qecYcpzUMzQzvYEbzMP1QHZ1XaAPIy2mB2FYXF44Am4JNgXY
sA7/FG27CPwd9RkxzPQrldMMgZuhs8x8/vVGxf7/tUusrQrSCMHnlRKE95vT5ffY
f2NsDvs24dOLZjCx2jfrr9W1MREUkja0wZPWaIjzhjAuKTaPWRQFWFVjOzacz3ca
6EYEzWFO09VRvb3RBBNIXJcJCM1HdfVcNtGSj7gspSlr1YWJSA1WuMmHzhy4KWNH
nfGUzY/8rAzinhT3AG9jhQEMA5jmn5iuBkvEAQf/b6ZunD7Sfwu+N2UEujF2WQGk
QsOfzAoy4bMSEt5l7bLLXzvjtsvCPWQIlbxQO2qZqUucGKH/rBwmakPtFoqNo03S
d/FCJts8Wtrxd5QNV8GhYSn3+fij6MHIkG2GjCSL344CAR/NQakQhEyvDPJNBUhH
Gmns7grYQXAWoG0ClIHrYIkFIH6L2pMvUBxfGXN2Hq2MiG735CLbKnT8aIUhIDib
/b4SFQ74LqV5L7E5g9P5e7iX/95Cro+SYCkAchpXtJlqtTscWBXWC426bW+3Q2rP
bPzLpageTiDiqGJJgWb8LzI2Zp3hKNbqLYm5vvSqfQAnh53K1Q0P6ZaDKPvKYtJL
AXidPBUIYvzDpC3N/8mdM4GRXOenVeXVGc9SBfxcyoYxis4syC9UcQ7Regl7m7Si
lpOVHOnHR1mPMwiZbJxas1WBQWqcTTb7UUA4
=D12u
-----END PGP MESSAGE-----
The above message is encrypted to my public key and some random member of Club PGP. The result is:
gpg: public key is A9E19F6E
gpg: public key is AE064BC4
gpg: encrypted with RSA key, ID AE064BC4
gpg: encrypted with RSA key, ID A9E19F6E
Which proves that Pine sent a message to the person with PGP key ID AE064BC4, in this case AnonymousMan.
Now, if AnonymousMan knew Pine in real life, and the Feds knew AnonymousMan, they could beat on AnonymousMan to give up Pine. Fortunately this is not the case.
The point remains though, that this embedded Key ID business is an unhappy affair for us denizens of the Darknet. The next post shall address how to circumvent this inconvenience.
-
Continuing with my example of encrypting a message to myself and AnonymousMan. This message has been encrypted to us both.
-----BEGIN PGP MESSAGE-----
hQEMA5jmn5iuBkvEAQf/W/0+u3mm6TH7HoJ/QdWwEFXVCW1O61hGIGahKol1y8D+
wxM2fRE1ZJydJ6XY/jC2kF8vXcHyqNZxRgrftho9ydUrBDBNiy4lPB5PeA5IIkKg
wulKIOtvCDhDkZgybP21LtF9T5fBOsANYmIU9y9clc7enUooqHoHYmldOsS/0Uwx
MCDKEgT2NUN4FATk1Mp0yA4IIoLP11SBt1y+yqAppXE+b40Cx/0YMywk3VaSOIeB
sjrA/LLRIyIZs7q2pIhekp2aeGzNt41ghvz4sy+xx/90O24otNONWmfohiOmLS+s
nGKtp+F8KTYdqx1R/qhPocIKhb+k9OLHiDMf9ThR/YUBjAMAAAAAAAAAAAEL/0S3
EW+X1KAwm8wKH6Akmm5fE7vbGZ5ePKl0NEUOIrbN5BW1LsmPPaznFRQDBraZ5mOZ
vctOToYat2WGU8uNp0U4zcXoQEY+6Xzlk9aeCm0Spx7a+1dn0qEulrHrMxE7rj0e
RqGUQveoDdWe6woV2Jd2RdItphtMxhKjtLtGnuFygL0eLS/rd85xis+ebzZCOEf4
yjggAHkOtrDR4Gg1OOh7Ux2dX6Qm4cvSkLjgl1X0fg404NYuuoPaFO/EDxYyoG9k
4isaSMaYhLbDqq/t1jUFwV4fImadqP/0d6yHmASjo2U46esSHW41GAf0nzuLa8cY
9ZJIfvz5wF70f55gnhZWc+pvO0/EH80ojJPHj2b1IjCFmlfwEiJMfKDvK4NGD5Ql
GlMCZzF1pr4SHK1xHQdsUaDSulX4QqGoAF3Br7/YGz3yIgOMb59LHNTEmbmhNBj/
JdLTpxr71Msz37VoqrghWoHM5J1cMoSg55MYVBkLcsqi7WnR61lTEZC5mpIPLNJT
AcSFPV2fLpvAbgzctptRUC/6M2/7tSSEtQPrQJD/yEbzayVkq0VDuc7rRMo9EPlG
T+46ipMv3luhFTCxs229Da5rPe4o4F9G+TmbtTiKY2R3N/o=
=Sm8m
-----END PGP MESSAGE-----
Let's open the command line/terminal and run gpg -v again on a file containing this message.
gpg -v encrypted_msg.asc
The result is:
gpg: public key is AE064BC4
gpg: public key is 00000000
gpg: encrypted with RSA key, ID 00000000
gpg: encrypted with RSA key, ID AE064BC4
Interesting! WTF is a public key with an ID of 00000000? Anonymous, that is what. There is no way to prove that Pine encrypted that message. Of course I'm telling you that I did so. But there is absolutely no evidence for it.
How did I achieve this?
There exists a configuration file in your PGP or GPG setup called gpg.conf or similar. If you don't know the location of this file on your computer, google "gpg.conf" and the name of your GPG or PGP distribution and you should find it. The location differs from operating system and PGP/GPG setup, so I won't describe where it generally hides out here.
In any case, open it with a plaintext text editor like Notepad or Gedit and append this line to the file, then save it.
hidden-encrypt-to <YOUR GPG PUBLIC KEY ID HERE>
The result is twofold.
1. All messages you now encrypt to others can be decrypted by yourself also e.g. in case you needed to add something and only remembered after you encrypted it, a common occurrence. Or to correct spelling. Whatever.
2. There is no evidence your public key was used to encrypt the message.
Highly useful I think.
-
Nice explanation, pine. You can also use throw-keyid to anonymize all recipients.
Since you mentioned gpg.conf, here are some other options that make working with gpg easier, safer, or less annoying:
trust-model always
utf8-strings
no-greeting
no-emit-version
no-comments
no-mdc-warning
armor
-
Great info, both of you!
-
There is one outstanding issue.
In some situations, with very sensitive emails perhaps, you do not want 'AnonymousMan' to be identified either. So in this situation a Fed coming across a message encrypted in this way would not be able to tell either the sender nor the receiver. Ideal! (but there is a caveat)
Append this line to the gpg.conf file.
throw-keyids
The result when I encrypt to myself and AnonymousMan?
-----BEGIN PGP MESSAGE-----
hQEMAwAAAAAAAAAAAQgAlxsQMCvYXE9niDYUrdIonSomWxWcNBKEZ2Z/BoH3YF9M
lD2Kgs70evqVvUvMCFS4cwbW0lraT4lkNTChkNydyFK/xWkY23TqeoPBrkAV3mL5
teo1758jfRE0l77PSjP45dupQCWSR53IGlkIfxvauMCmIxIdDhBSshK/r+V2hGKz
85WJ79CGmbmCRWGs6MZ8/CAFJLkDEYj2N7z00Q84GIIc2wx4+J07Y1zchBLbCzYA
2ds3u47TbjyvvG7MWtHs5IZFfpNndtrWM/kOJAUUB7UX5WydPD3vVqIeRILflAyn
IAAEYvF9qKxD9DkWWgTE5lmUboC3bjv9MFSsuhOyPYUBjAMAAAAAAAAAAAEL/i8D
GIDvraq6+9OuwzXHBZ3CMNTwqd53Zyi9G+1pJhVAADJOY4IDoQRDkSRxVI5GDRoJ
F/8I/72C7F19Cmlnj/tLJPrhfqiYRmvfG5tl9a7NKLefhKo6D5/5XzlwHBFuEJ2V
8ZxyzrQgB24701pxAhDhN8V4lrBCVk4YyCnTIIDd7By5nu15kXzoyyOP+KEyBUCW
IDG9N4eZJEsgxP95pQqk1GLpyswkydHlWXZA12+FSF/tKjHumNiiEhv9mWOOphD7
6nGC/ZAI7uT5i6uJ4S9V531gc1xWlIPSaZkx3ogGXyhE5xPWLh4VbhEa6UL76KkV
PIpYQngiwmSNAziL5Pzd3IV0fxN5JoJt1T8VTwbIKCepqn/uR7EKVFZE8PEBfb+l
VIdr7jueJVaSxFwFq8WHV3QAVPSx7KBFUbaWSSlkbCU4kIRaqJQXKsRZU9/nIqfQ
PWhzzQjDY9FCbXWxv2OBwW3TOhDBjb7y3HBsKCga16pKueEyFfFtjKW1JF/nvNJB
AbuPpTjcitnSN63dIbvmDeUMr8qc+1zDXYb6gxVva/gNgIuPQDG9l7XRSchLpVHH
JmPhz4c/1buwGPSaQlB60C8=
=oyUv
-----END PGP MESSAGE-----
for which gpg -v only gives us:
gpg: public key is 00000000
gpg: public key is 00000000
gpg: encrypted with RSA key, ID 00000000
gpg: encrypted with RSA key, ID 00000000
Perfect! Anonymity all around.
As I said, there is a caveat. It's that to decrypt the message, GPG or PGP will have to try every single private key in your keychain (or the recipient's keychain), which appears alarming at first due to a dozen or so password requests, and then just plain annoying. But that is a small inconvenience really, unless you have a lot of private keys on your keychain, which to be honest you shouldn't, I would recommend you keep your PGP SR key all by its lonesome and use an entirely different copy of GPG for work/other purposes. Having a portable copy of GPG for a memory stick is a good way to achieve that. Then fat finger errors are not possible, like encrypting with your SR public key as well as to your boss, with your PGP public key up on SR for all to see.
Finally if you don't want to use the gpg.conf file (good for setting up long term, consistent, default options) I do believe you can use throw-keyids and hidden-encrypt-to statements as flags on the command line/terminal so they are invoked only for the encryption of specific messages.
Long live the platypus and the association of aquatic mammals. Our enemies fear the tread of our furry paws and inquisitive noses. Oh yes.
-
Nice explanation, pine. You can also use throw-keyid to anonymize all recipients.
Ack, didn't see you'd already posted before I duplicated the same information. I suppose given the lack of awareness it is no harm. Spent too long supping coffee, a duck-bill can be most inconvenient sometimes. In any case you're right, throw-keyid is a very useful command, one some of us should use long and often, certainly when using email, even or perhaps especially Tormail-like anonymity services.
Since you mentioned gpg.conf, here are some other options that make working with gpg easier, safer, or less annoying:
trust-model always
utf8-strings
no-greeting
no-emit-version
no-comments
no-mdc-warning
armor
Yes absolutely, I, as you can tell from my PGP messages, am quite fond of not shouting what edition/version of GPG I'm using (AAM strength encryption, which is over 9000 bits at all times). I am certain clandestine creatures have gone to the death for not knowing some of this information, imagine you are a spy, your messages are intercepted and you are the only one who uses an OSX version of PGP! Admittedly in this case the use of a Mac moderates some of my sympathy, but even so. :D
Great info, both of you!
Cheers! The Revolution rumbles on. PGP or Death! :)
-
subbed.. there's a wealth of information in this thread. Very informative.
-
Yeah, sorry I scooped you on throw-keyid. Your explanation was more thorough anyway. :)
-
You two - astor and pine - make the most awesome security contributions to this community.
-
subbed.
-
imagine you are a spy, your messages are intercepted and you are the only one who uses an OSX version of PGP! Admittedly in this case the use of a Mac moderates some of my sympathy, but even so. :D
I did an analysis of the Version strings in the PGP keys that have been posted in the "Post PGP keys here" thread. Many of them are unique.
http://dkn255hz262ypmii.onion/index.php?topic=98140.msg693758#msg693758
-
imagine you are a spy, your messages are intercepted and you are the only one who uses an OSX version of PGP! Admittedly in this case the use of a Mac moderates some of my sympathy, but even so. :D
I did an analysis of the Version strings in the PGP keys that have been posted in the "Post PGP keys here" thread. Many of them are unique.
http://dkn255hz262ypmii.onion/index.php?topic=98140.msg693758#msg693758
Thanks, looks like a great thread, I have it bookmarked and will read it closely later.
-
Great info..
Thanks..
-
@pine
i can not locate my gpg.conf location.., could you please help me. im using Mac OS X
-
What if LE is sitting in your neighborhoods central office monitoring your activity?
They'd see everything. Your PGP codes, every keystroke, becomes "Exhibit A" for evidence in your prosecution.
Assuming you're doing something illegal, of course.
It's like locking your front door.
If they really want to get in. They're going to get in.
Just a reality check. There are no absolutes in life.
Except death and taxes of course.
-
Replying so I can come back and read this in more detail later. Thanks for the information.
-
As long as you have a Tormail account used exclusively for illicit business and all traces of PGP tools, TorBrowser, Vidalia, etc. are well encrypted, disguised, and hidden then you're fine. And besides, I view the Bitcoins trail and messaging as ancillary evidence to an actual package. You won't get indicted because of a plaintext email discussing drugs, certainly not a PGP encrypted one signed with your public key. You'll get indicted because you have a kilo of coke on your doorstep.
Nonetheless, it is important that when you do get arrested (and everyone should be ready for it ;) ), everything is going in your favor. Having a clean record of activity on your computer is vital, so thanks for the info pine. I wasn't aware that you could trace who encrypted a message.
-
Anonymizing the key IDs doesn't offer extra protection in some cases. For example, if you send a message to a vendor, or an email to someone on TorMail, anyone with access to the SR or TorMail servers knows who the recipient is, so there's no reason to hide the key IDs from them.
However, I can think of cases where it is useful. A vendor may want to send an encrypted announcement to several customers, but he doesn't want them to know who the others are. That's as much for their protection as his. The recipients would only be able to deduce the number of other recipients, but they couldn't compare the key IDs to people in their key chain.
Another example is if someone gains access to your computer, but not your TorMail account. Let's say you saved encrypted messages in a text file, as a back up. Then the attacker would only know how many messages you sent, but not who the recipients are.
BTW, if you think you can only be charged for physical drugs in your possession, you should review the Farmers Market case. They were charged for a lot of shit that they talked about in their Hushmail accounts, and that was the only evidence of those crimes. An email counts as a confession.
-
BTW, if you think you can only be charged for physical drugs in your possession, you should review the Farmers Market case. They were charged for a lot of shit that they talked about in their Hushmail accounts, and that was the only evidence of those crimes. An email counts as a confession.
There was a lot more evidence than just emails. They used Paypal and Western Union, and the records for transactions were dug up. And, of course, upon being raided, the houses of suspects were found filled with drugs.
-
@pine
i can not locate my gpg.conf location.., could you please help me. im using Mac OS X
....
Many PGP or GPG software products (most Macintosh software appears to be setup this way for example) automatically encrypt a message to yourself as well as the other person you're sending the message to.
....
I don't think there ever can be the degree of customization command line flags and argument's afford a linux user. If there's anything you can do to alter your completely packaged GUI Mac program you'll just have to go hunting through it's settings and whatnot and hope the app you're using is either highly customizable or can be accessed to append flags and argument's to the app's configuration files.
That's why Linux is superior to all other OS's (cept UNIX from which it came, but the number of distro's and open community openness of linux makes it a better operating system then UNIX).
If you're interested in taking these ultra steps with GPG (what they've suggested isn't REQUIRED, but they're definitely nice way's of covering your tracks). If you want to use tor on linux I suggest you go download Liberte (believe it's based off of Debian Linux) or Tails (dunno what distro it uses ... Fedora?)
Oh and thanks Pine and Astor. I was never aware that it was that easy to obtain the public key ID used to encrypt a msg. I'm definitely a noob when it comes to GPG and know the basics + a tiny bit more. Given it's simplicity to do though I might have to take your advice into consideration on some msgs.
I thought I was a weirdo hyper paranoid hypocrit because i've always kept my ONE AND ONLY key in one place and would alway's use another instance of GPG with my keychain (I keep it small, moreso actually to remember the really good vendor's i've worked with). But you just put my mind at ease, now i'm just a weirdo hyper paranoid ... human being, no more hypocrisy !
-
Let's open the command line/terminal and run gpg -v again on a file containing this message.
gpg -v encrypted_msg.asc
The result is:
gpg: public key is AE064BC4
gpg: public key is 00000000
gpg: encrypted with RSA key, ID 00000000
gpg: encrypted with RSA key, ID AE064BC4
Forgive me for being ignorant at this level of expertise... Is there a way to do/check this in Gpg4win? (I cannot find it)
Nice explanation, pine. You can also use throw-keyid to anonymize all recipients.
Since you mentioned gpg.conf, here are some other options that make working with gpg easier, safer, or less annoying:
trust-model always
utf8-strings
no-greeting
no-emit-version
no-comments
no-mdc-warning
armor
Could you explain more about these commands please? Obviously the "no-emit-version" hides the version info when a message is encrypted, but I'm not clear about the rest of those. I tried to do some searching on my own, but only come up with: (which really doesn't explain much)
"4.2.6 Doing things one usually doesn't want to do."
http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Esoteric-Options.html#GPG-Esoteric-Options
For Gpg4win... just adding "no-emit-version" to the config file does work, I just don't know what these other commands you listed really do for me. And from testing, it appears my encrypted messages do not encrypt in one of my keys along with the receiver (thank god)... which personally I'd prefer. I cannot "edit" encrypted messages to recipients. Anyhow, If I need to edit messages to people, I'll just rewrite the whole thing... no need to give LE another crumb imo. So my question is; it would only be redundant to use "hidden-encrypt-to <YOUR GPG PUBLIC KEY ID HERE>", correct? Or if I were to use that command to be extra safe, I would need multiple lines... one line for each key?
Oh... and how would someone make use of the command "secret-keyring"? Or even make multiple keyrings?
Thanks in advance
-
If you're interested in taking these ultra steps with GPG (what they've suggested isn't REQUIRED, but they're definitely nice way's of covering your tracks). If you want to use tor on linux I suggest you go download Liberte (believe it's based off of Debian Linux) or Tails (dunno what distro it uses ... Fedora?)
Tails is based on Debian and Liberte is based on Gentoo. Both offer security hardened features that mainstream distros don't, such as scrambling RAM on shut down. Liberte uses a specially hardened kernel, too, though I don't know the details of that. The trade off is that these specialist "distros" are experimental and can be buggy.
Forgive me for being ignorant at this level of expertise... Is there a way to do/check this in Gpg4win? (I cannot find it)
Windows GUIs don't have these advanced options in their interface. It's been a while since I've used GPG4Win, but it *should* come with gpg.exe, I know GPG4USB does. You can run these options at a command prompt.
gpg -v encrypted_msg.asc
becomes
gpg.exe -v encrypted_msg.asc
in whatever folder gpg.exe is located.
Could you explain more about these commands please? Obviously the "no-emit-version" hides the version info when a message is encrypted, but I'm not clear about the rest of those. I tried to do some searching on my own, but only come up with: (which really doesn't explain much)
For Gpg4win... just adding "no-emit-version" to the config file does work, I just don't know what these other commands you listed really do for me.
Edit: I'm replacing what I wrote here before with my current recommended gpg.conf:
o-greeting # suppress the copyright notice in command line gpg
no-emit-version # remove the version string from keys and messages
no-comments # remove the comment lines from keys and messages
utf8-strings # interpret all command line arguments as UTF-8 encoded
armor # ASCII armor encrypted output
expert # allow incompatible actions
trust-model always # suppress warnings about unsigned keys
no-mdc-warning # suppress warnings about MDC integrity protection, since no one uses it
## Ordered lists of preferred ciphers. Your GPG will pick the first one that it supports,
## which should be the first one on each list.
personal-cipher-preferences AES256 TWOFISH CAMELLIA256 AES192 CAMELLIA192 AES CAMELLIA128 CAST5 3DES BLOWFISH
personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 SHA1
personal-compress-preferences BZIP2 ZLIB ZIP Uncompressed
cert-digest-algo SHA512
default-key <keyid> # set this if you have multiple keys. newbies should not use multiple keys!
#encrypt-to <keyid> # automatically encrypt with a specific key
## Optional
#throw-keyid # anonymize all recipients by zeroing out the key IDs
#hidden-encrypt-to # anonymize a specific key ID
## Use the IndyMedia key server hidden service. This prevents accidentally connecting over clearnet.
## You need an HTTP proxy like Privoxy listening on port 8118, or adjust the lines below accordingly.
## The HTTP proxy forwards to Tor's SockPort. Here's a Privoxy config for that:
## https://trac.torproject.org/projects/tor/wiki/doc/PrivoxyConfig
keyserver hkp://2eghzlv2wwcq7u7y.onion
keyserver-options http-proxy=http://127.0.0.1:8118,debug,verbose
Oh... and how would someone make use of the command "secret-keyring"? Or even make multiple keyrings?
You can, but it's too easy for newbs to fuck up and deanonymize themselves, or mix up their identities. It's better to extract GPG4USB in separate folders and use them separately. Name one folder MY ILLEGAL IDENTITY and the other MY REAL IDENTITY, so you absolutely don't mix them up. :)
Oh, and don't name any folder "ILLEGAL" unless it's on an encrypted volume.
-
Seems to me we need to have privacy-enabled version of software we can get that is already set up with the changes suggested in the OPs as defaults rather than options. Or, a handy user interface with buttons to push to implement these changes. Maybe sell the software on SR ? :-)
-
MOTION TO PIN THREAD..
LET THE I'S HAVE IT
I
-
BTW, if you think you can only be charged for physical drugs in your possession, you should review the Farmers Market case. They were charged for a lot of shit that they talked about in their Hushmail accounts, and that was the only evidence of those crimes. An email counts as a confession.
Charged sure, but convicted? They love to charge you with as much shit as they can dream up, making it stick in court is a whole different story. Any info on where their cases stand ATM?
-
Good knowledge to have. Thanks!
-
subbed..Awesome information! Thank you guys
-
Very interesting information Pine & Astor,
I've always known PGP keys were a unique identifier - it's part of the point - I'd taken it as the price to be paid for having secure communications. Its useful to see a way to remove this downside (for SR).
Is there a way to set the config file to ensure that when decrypting messages it tries a particular private key first?
There exists a configuration file in your PGP or GPG setup called gpg.conf or similar.
In any case, open it with a plaintext text editor like Notepad or Gedit and append this line to the file, then save it.
hidden-encrypt-to <YOUR GPG PUBLIC KEY ID HERE>
The result is twofold.
1. All messages you now encrypt to others can be decrypted by yourself also e.g. in case you needed to add something and only remembered after you encrypted it, a common occurrence. Or to correct spelling. Whatever.
2. There is no evidence your public key was used to encrypt the message.
Is there a way to get 2 without 1? I'm not keen on the ability to decrypt messages I encrypt to others.
Most of these options are only relevant to command line gpg. They get rid of annoyances like the greeting, which you don't need to see every time you run the program. Here's a run down.
no-greeting -- removes the greeting, which as I said can be annoying
no-emit-version -- removes the version string
no-comments -- removes the comment line, both of these reduce your anonymity set, see my previous analysis about version strings
armor -- forces ASCII armor encoding of encrypted messages
This may be a silly question astor but what's the difference between the version, greeting & comments.
All I can see that would fit the bill is
Version: GnuPG v2.0.17 (MingW32)
but that's just one line, the version. What is the comments & greeting line?
-
Is there a way to set the config file to ensure that when decrypting messages it tries a particular private key first?
Setting a default key should force gpg to try it first. Add this to gpg.conf:
default-key <key ID>
In any case, testing all the keys should take less than a second. Here's what the decryption process looks like, along with the processing time:
$ time gpg -d anon_message.pgp
gpg: anonymous recipient; trying secret key [REDACTED] ...
gpg: anonymous recipient; trying secret key [REDACTED] ...
gpg: anonymous recipient; trying secret key [REDACTED] ...
gpg: anonymous recipient; trying secret key [REDACTED] ...
gpg: anonymous recipient; trying secret key [REDACTED] ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with RSA key, ID 00000000
gpg: encrypted with RSA key, ID 00000000
gpg: encrypted with RSA key, ID 00000000
It worked!
real 0m0.513s
user 0m0.508s
sys 0m0.004s
So, half a second in this case. It will take less time if the message has been decrypted with fewer keys, or you have fewer private keys to test, or it hits a match sooner.
Is there a way to get 2 without 1? I'm not keen on the ability to decrypt messages I encrypt to others.
If you don't encrypt the message with your key, then your key ID won't be in it. 2 is automatic without 1.
This may be a silly question astor but what's the difference between the version, greeting & comments.
All I can see that would fit the bill is
Version: GnuPG v2.0.17 (MingW32)
but that's just one line, the version. What is the comments & greeting line?
Comments are just that, you can make a comment about the message, yourself, whatever, but they are usually used to advertise for the PGP program, like this:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
The greeting is a splash screen with copyright info that looks like this:
gpg (GnuPG) 1.4.11
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Now why would you want to see that every time you run the program?
-
You two - astor and pine - make the most awesome security contributions to this community.
"Hero member"s indeed. =)
-
Windows GUIs don't have these advanced options in their interface. It's been a while since I've used GPG4Win, but it *should* come with gpg.exe, I know GPG4USB does. You can run these options at a command prompt.
gpg -v encrypted_msg.asc
becomes
gpg.exe -v encrypted_msg.asc
in whatever folder gpg.exe is located.
Thanks, Astor... Gpg.exe was there and worked as mentioned. (yet the output was quite bit more verbose than the linux example)
-
MOTION TO PIN THREAD..
LET THE I'S HAVE IT
I
i
-
@pine
i can not locate my gpg.conf location.., could you please help me. im using Mac OS X
Sorry for delay, overlooked your message. It should be under "~/.gnupg/gpg.conf". This is an address, you need it (without quotations) to find the file but since you're using OSX, you'll need extra steps to find the address bar.
http://superuser.com/questions/174297/how-can-i-get-an-address-bar-in-finder
Read that, find one of their solutions and then copy paste that line into your address bar and it should take you to the folder in which the gpg.conf file is located in.
If you choose to navigate to the file through the GUI manually, then you'll need to turn on the Show Hidden Files option in Mac, wherever that is. The ~ character is whatever your home directory is e.g. if your account is called "geezy" then the "geezy" directory is the home directory.
Macs are perfectly easy to use until you want to do something Steve Jobs himself didn't think of personally.
Anonymizing the key IDs doesn't offer extra protection in some cases. For example, if you send a message to a vendor, or an email to someone on TorMail, anyone with access to the SR or TorMail servers knows who the recipient is, so there's no reason to hide the key IDs from them.
Yes, it very much depends on your use of this feature.
To newbs: If I wrote down an encrypted message using throw-key-ids, put it into a letter and posted it to a friend with his address on the front of the envelope and mine on the back of it, then using throw-key-ids to prevent traffic analysis would be somewhat pointless. However, if I wrote a message using a one time account on SR, then you would successfully be able to communicate without revealing your (SR) identity to traffic analysis if LE hack the server. You'd use a new account per instance of a two way chat communication. Although this sounds like work, it's probably worth the trouble for very important communications. That way only the compromise of the recipient can possibly leak information about the sender. You'd have to mix up what algorithms and key lengths you were using as well for each new public key, since throw-key-ids doesn't get rid of that information (persistently using the same settings for each key would be a giveaway).
The reason why I mention server hacking is important: nobody should assume that their messages will be 'hidden' unless they are encrypted. If you were ordering a large amount from a vendor, you almost certainly should be using such methods as these. If a vendor doesn't 'get' it, find one that does.
Encryption can do more than merely hide your messages, if used properly it can also make it impossible to associate any identity with transmission importance within the network. That is the death knell for LE teams, there is then no earthly way to prioritize their pattern analysis algorithms beyond wild guesswork. They spend a great deal of time building a "Who's Who" of Darknet participants and they'll be infuriated if lots of people start adopting practices which remove PGP key ID information out of existence.
Another good use of this feature is when using anonymous remailers (for the final message the sender receives). This is a network of email servers that serves to send anonymous email, a sort of pre-Tor anonymity project for email.
I thought I was a weirdo hyper paranoid hypocrit because i've always kept my ONE AND ONLY key in one place and would alway's use another instance of GPG with my keychain (I keep it small, moreso actually to remember the really good vendor's i've worked with). But you just put my mind at ease, now i'm just a weirdo hyper paranoid ... human being, no more hypocrisy !
It's good to pay attention to your instincts, they are there for a reason.
Seems to me we need to have privacy-enabled version of software we can get that is already set up with the changes suggested in the OPs as defaults rather than options. Or, a handy user interface with buttons to push to implement these changes. Maybe sell the software on SR ? :-)
I think so too. Although selling the software would be impossible. APG (anonPG) or something. It could have a list of requirements like:
1. The inability to communicate with keyservers. Or route all such traffic via Tor with explanatory warnings.
2. Puts public keys you haven't used into a password protected encrypted volume after 30 days of non-use.
3. Transparent way to encrypt anonymously for you, and another option for your recipient
4. No meta data within the PGP headers.
5. 8912 bit available as standard.
6. Open source for code inspection. (hence the difficulty of selling it)
7. Steganography options for embedding message into audio, video, images etc.
8. Ability to setup anonymous remailers with ease.
9. Self destruct feature.
I'm sure you guys can think of lots of other things. Simply making it obvious what is what would lift a huge burden on the amount you have to know before you're doing what you want to be doing. Some of it sounds like heavy lifting like the steg and remailers, but actually most of this already exists in the form of open source projects, it's mostly a matter of building a clever GUI to let people access the power of such tools. I don't have the time for it, but it'd make a great project for somebody.
-
I think so too. Although selling the software would be impossible.
You can sell FOSS that uses the GPL. You can sell Linux too. I'm not saying anyone will buy them, but you can do it.
-
I think so too. Although selling the software would be impossible.
You can sell FOSS that uses the GPL. You can sell Linux too. I'm not saying anyone will buy them, but you can do it.
Yes, this was discussed extensively during the LouisCypher vendor software debacle.
It's that some software written for use by members of this forum has to be rigorously examined for backdoors, exploits etc, so it cannot be 'open source' to a small group of people in case of conspiracy exploiting vendor ignorance. So when I say open source I am referring to the colloquial understanding of the term: free software with source available to all to view. The moment we start appointing authorities to verify software, or we only release that software to those who almost certainly can't read the code we've invented a systemic weakness.
-
I think so too. Although selling the software would be impossible.
You can sell FOSS that uses the GPL. You can sell Linux too. I'm not saying anyone will buy them, but you can do it.
Yes, this was discussed extensively during the LouisCypher vendor software debacle.
It's that some software written for use by members of this forum has to be rigorously examined for backdoors, exploits etc, so it cannot be 'open source' to a small group of people in case of conspiracy exploiting vendor ignorance. So when I say open source I am referring to the colloquial understanding of the term: free software with source available to all to view. The moment we start appointing authorities to verify software, or we only release that software to those who almost certainly can't read the code we've invented a systemic weakness.
Somehow I totally missed that entire LouisCyphre thing; I wasn't even aware he existed until today when I went looking for what you're talking about. I think I started really hanging around the forums very shortly after that. I also noticed that he and I sound very similar... I mean even some of our punctuation is almost identical. And I released a program as well, and popped up about a month after that whole affair.
Frankly, Pine, I'm a little surprised that you haven't mentioned any suspicions about me being the same person as him and just coming back to try again or something. Honestly I only mention it because it really does seem plausible. I mean I'm certainly not him and didn't even know he existed, but after looking him up I'm a little surprised that not a single person has even mentioned it.
-
bump!
Everybody should read this! Not a theoretical exercise!
Forewarned is forearmed. Blah blah blah. Do it. :)
-
Pretty interesting, I'm gonna use "throw-keyid" from now on. If you use "hidden-encrypt-to" however, won't the recipient need your public key to decrypt your message?
-
Pretty interesting, I'm gonna use "throw-keyid" from now on. If you use "hidden-encrypt-to" however, won't the recipient need your public key to decrypt your message?
No. Because that is not how public key cryptography works.
Here is a link to a post I made to a fellow who made an identical mistake to yours:
http://dkn255hz262ypmii.onion/index.php?topic=107219.msg1131314#msg1131314
-
Frankly, Pine, I'm a little surprised that you haven't mentioned any suspicions about me being the same person as him and just coming back to try again or something. Honestly I only mention it because it really does seem plausible. I mean I'm certainly not him and didn't even know he existed, but after looking him up I'm a little surprised that not a single person has even mentioned it.
haha, how did I miss this.
I was convinced that pine and LC knew each other in real life, because they both disappeared around the same time and showed up on the same night, months later. I was not the only one who noticed this coincidence. It looked like they planned it. Also, the sexual tension in the "LC is LE" thread is unmistakable. ;)
Since then it's pretty much been proven to me that they don't know each other. And no, I never thought you were LC either. IDK, your styles and technical expertise are distinctly different to me.
-
Interesting!
-
in case of losing URL
-
Pretty interesting, I'm gonna use "throw-keyid" from now on. If you use "hidden-encrypt-to" however, won't the recipient need your public key to decrypt your message?
No. Because that is not how public key cryptography works.
Here is a link to a post I made to a fellow who made an identical mistake to yours:
http://dkn255hz262ypmii.onion/index.php?topic=107219.msg1131314#msg1131314
I would've thought so since you also encrypt the message to yourself when using the "hidden-encrypt-to [your key]". I wasn't aware you could encrypt a message to different people at the same time and that they could decrypt it without the others' keys. In the link to your post, the person thought you needed his key to decrypt a PGP message that was only encrypted to you (as far as I know), which is not what my question was about.
-
Pretty interesting, I'm gonna use "throw-keyid" from now on. If you use "hidden-encrypt-to" however, won't the recipient need your public key to decrypt your message?
No. Because that is not how public key cryptography works.
Here is a link to a post I made to a fellow who made an identical mistake to yours:
http://dkn255hz262ypmii.onion/index.php?topic=107219.msg1131314#msg1131314
I would've thought so since you also encrypt the message to yourself when using the "hidden-encrypt-to [your key]". I wasn't aware you could encrypt a message to different people at the same time and that they could decrypt it without the others' keys. In the link to your post, the person thought you needed his key to decrypt a PGP message that was only encrypted to you (as far as I know), which is not what my question was about.
Ah! Now I understand how you made that mistake, yes, that makes perfect sense.
This is actually a very interesting thing. To understand it you need to know a little more about PGP. Here is how it works:
Normally, Alice encrypts to Bob's public key. Only Bob can read it.
So what is happening with encrypted messages to multiple recipients?
It turns out Pine is lying a bit by telling you guys that PGP is for encryption. Well, it is used for that, but it's far from the whole story. What is really happening is that PGP is a hybrid cryptosystem. It is composed of several parts, not just an encryption algorithm. If it were just an encryption algorithm we wouldn't be able to do a fraction of the things we do with it.
When you encrypt a message with PGP, your message is encrypted using a symmetric block cipher, something like AES. This is very fast and very secure. If we used a public key algorithm such as RSA then it would take considerably longer to encrypt and decrypt data.
However, we cannot send a symmetric key over the internets. If we did that, we wave the protection of encryption goodbye. So we encrypt the symmetric key (called a session key) with RSA, an asymmetric public key algorithm. A symmetric key is tiny, so this is much less data to encrypt than a typical message, and so it happens all in good time.
Then, the symmetrically encrypted data and the asymmetrically encrypted session key are bundled into what we're calling a PGP message.
At arrival, the encrypted session key is decrypted via the magic of public key cryptography. The decrypted symmetric session key is then used to decrypt the main body of the message. Results!
Now for the clever part. In order to encrypt to multiple recpients, you only need to encrypt the message 1 time with the session key. You then encrypt the session key, a tiny amount of information, to each recipient's public key individually. If you encrypted to a 1000 people, then there are 1000 encrypted session keys in the PGP message (and it looks a good bit larger!). This way, everybody can decrypt it, and it doesn't matter whether it's 1 kilobyte or 1 terabyte of data.
-
You can actually see that this is going on with PGP, even with the padding.
If you encrypt to 3 people, copy paste the result into a plaintext file.
Now encrypt individually to 3 people. Copy paste and append the results together into a different plaintext file.
Now compare the lengths. Even though it is the same information, it is clear that the first plaintext file is much shorter than the second one.
Compression can only account for so much since ciphertexts are intended to look as much as possible like random noise to prevent cryptanalysis. So now you know why :-)
-
Holy cow Pine! Youd be harder to find then Bin Laden!
This thread blows my mind, gunna read it again tomorrow when the vitamin K wears off wowsers!
-
Pretty interesting, I'm gonna use "throw-keyid" from now on. If you use "hidden-encrypt-to" however, won't the recipient need your public key to decrypt your message?
No. Because that is not how public key cryptography works.
Here is a link to a post I made to a fellow who made an identical mistake to yours:
http://dkn255hz262ypmii.onion/index.php?topic=107219.msg1131314#msg1131314
I would've thought so since you also encrypt the message to yourself when using the "hidden-encrypt-to [your key]". I wasn't aware you could encrypt a message to different people at the same time and that they could decrypt it without the others' keys. In the link to your post, the person thought you needed his key to decrypt a PGP message that was only encrypted to you (as far as I know), which is not what my question was about.
Ah! Now I understand how you made that mistake, yes, that makes perfect sense.
This is actually a very interesting thing. To understand it you need to know a little more about PGP. Here is how it works:
Normally, Alice encrypts to Bob's public key. Only Bob can read it.
So what is happening with encrypted messages to multiple recipients?
It turns out Pine is lying a bit by telling you guys that PGP is for encryption. Well, it is used for that, but it's far from the whole story. What is really happening is that PGP is a hybrid cryptosystem. It is composed of several parts, not just an encryption algorithm. If it were just an encryption algorithm we wouldn't be able to do a fraction of the things we do with it.
When you encrypt a message with PGP, your message is encrypted using a symmetric block cipher, something like AES. This is very fast and very secure. If we used a public key algorithm such as RSA then it would take considerably longer to encrypt and decrypt data.
However, we cannot send a symmetric key over the internets. If we did that, we wave the protection of encryption goodbye. So we encrypt the symmetric key (called a session key) with RSA, an asymmetric public key algorithm. A symmetric key is tiny, so this is much less data to encrypt than a typical message, and so it happens all in good time.
Then, the symmetrically encrypted data and the asymmetrically encrypted session key are bundled into what we're calling a PGP message.
At arrival, the encrypted session key is decrypted via the magic of public key cryptography. The decrypted symmetric session key is then used to decrypt the main body of the message. Results!
Now for the clever part. In order to encrypt to multiple recpients, you only need to encrypt the message 1 time with the session key. You then encrypt the session key, a tiny amount of information, to each recipient's public key individually. If you encrypted to a 1000 people, then there are 1000 encrypted session keys in the PGP message (and it looks a good bit larger!). This way, everybody can decrypt it, and it doesn't matter whether it's 1 kilobyte or 1 terabyte of data.
Wow PGP is a lot more complicated than I thought!
But why can we send symmetric keys over teh internetz? How would that compromise the encryption? SSL is encrypted using AES so if it wasn't secure over the internet, why would we use it?
Thanks for this great explanation!
-
SSL/TLS session keys are negotiated with asymmetric cryptography, usually RSA or ECDH. You pretty much never use a symmetric algorithm for multi-party communications without also using a key exchange algorithm (or without sharing an original key face to face at least). Usually the only time you use symmetric algorithms alone is for encrypted data storage like FDE or Truecrypt containers.
-
Is there a way to get this technique to work with windows?
-
The point is that you really want 1 PGP key for SR, and only SR. Never use that key anywhere else otherwise you'll be linkable between those two places.
Pine, I understand what you're saying here, and I by no means claim to have known what you have presented here previously, but wasn't this fact just understood already? Even without all of this "ciphertext" business, couldn't one identify someone just via the name on the PGP key? I mean, most will put their username on their PGP key, to my knowledge, because it makes it easier for one with a large keyring to identify them (I believe you've brought this up before as well). Plus, just based on the basic rules of SR, you don't associate anything you do here with your real life identity. Thank you, however, for going more into detail on this. It definitely bolsters our safety ideology here on SR.
-
Hey Guys
Pretty new to SR and trying to keep my security to a maximum! I have read pine's very informative post and have attempted to configure my Gpg4win program with hidden-encrypt-to as well as throw-keyid.
After many attempts and many, many hours of attempting to configure, evidence that my key was used to encrypt the message is still evident in command prompt. I am obviously appending the lines to the configuration file incorrectly.. I am using gpg-conf.skel - should I add the lines in at the beginning of that file, the middle somewhere or at the end?
Sorry if its a silly question - i'm not a real computer wizz. Any help anyone can give would be great!
Many thanks in advance :)
-
hitit, did you rename the file to gpg.conf?
It doesn't matter where you put it in the file, as long as it doesn't a # at the beginning.
-
One thing I noticed is that zeroing out the key ID breaks some (crappy) PGP programs. Rather than testing every available private key, they just fail to decrypt the PGP block. Keep that in mind. If you use it all the time, even when you don't have to, you may get complaints or people will think you don't know how to create a PGP message and they may ignore you for wasting their time.
-
@astor
You are a real legend mate - you have been on numerous posts of mine providing very valuable assistance and asking nothing in return. If I could +1 I would :)
No I never renamed the file - that sounds like it is the problem then! Although I am now considering GPG4USB as apparently you can create a stronger-bit key with that program. Would I have those aforementioned problems with it? What configuration file would I be looking at using if I switched to this?
-
It's the same configuration file for GPG4USB. It's located at \wherever\you\extracted\gpg4usb\keydb\gpg.conf
-
Awesome - too easy. Thanks again astor :D
-
This is all fine and dandy, but.... are you reeeeaally a lady pine?
Completely irrelevant but completely on my mind.
-
Just chiming in... I happened upon this thread and wanted to subscribe for further parsing, and in the course of subscribing to also say some thanks for the OP and other technically factual folk posting here in this forum.
For what it's worth, again I say a truly heartfelt "Thanks"
-
Excellent post.
... now if only I could figure out thow to emit the pgp version on TAILS (seahorse)
-
I'm having a difficult time locating the gpg.conf file on TAILS ... can anyone help?
-- never mind, found it! --
-
I've appended the gpg.conf file as follows:
hidden-encrypt-to <my key id>
throw-keyid
use-agent
no-auto-key-locate
trust-model always
utf8-strings
no-greeting
no-emit-version
no-comments
no-mdc-warning
armor
The output looks like this <<I have redacted the key ids >>:
gpg -v Test.asc
gpg: public key is 00000000
gpg: anonymous recipient; trying secret key 18XXXXXX ...
gpg: anonymous recipient; trying secret key 2EXXXXXX ...
gpg: using subkey 2EXXXXXX instead of primary key 18XXXXXX
gpg: anonymous recipient; trying secret key 65XXXXXX ...
gpg: anonymous recipient; trying secret key 6CXXXXXX ...
gpg: using subkey 6CXXXXXX instead of primary key 65XXXXXX
gpg: anonymous recipient; trying secret key B1XXXXXX ...
gpg: anonymous recipient; trying secret key 6DXXXXXX ...
gpg: using subkey 6DXXXXXX instead of primary key B1XXXXXX
gpg: public key is 00000000
gpg: anonymous recipient; trying secret key 18XXXXXX ...
gpg: anonymous recipient; trying secret key 2EXXXXXX ...
gpg: anonymous recipient; trying secret key 65XXXXXX ...
gpg: anonymous recipient; trying secret key 6CXXXXXX ...
gpg: anonymous recipient; trying secret key B1XXXXXX ...
gpg: anonymous recipient; trying secret key 6DXXXXXX ...
gpg: encrypted with RSA key, ID 00000000
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: secret key not available
Any help very welcome!
pb.
-
Astor,
You have some mistakes in your config ...
trust-model always -- prevents gpg from confirming to use a key, which it will if you haven't signed it (or there's no web of trust behind it)
Users should not use 'trust model always' by default, it hides changed keys. Better is for them to locally sign the key.
utf8-strings -- ensures you use a standard character encoding, if everybody uses that there will be fewer fuck ups based on char encoding
That affects the cli arguments, not the message body. From the man page:
'utf8-strings Assume that command line arguments are given as UTF8 strings.'
no-mdc-warning -- removes a warning about the PGP block not being message digest protected, which nobody in my experience uses anyway
NO NO NO, don't do this!!!!
The mdc is a security check for message integrity, from the man page:
"disable-mdc Disable the use of the modification detection code. Note that by using this option, the encrypted message becomes vulnerable to a message modification attack."
Any user who has no-mdc-warning in their config file should remove it.
JofSpades
-
I've appended the gpg.conf file as follows:
hidden-encrypt-to <my key id>
throw-keyid
use-agent
no-auto-key-locate
trust-model always
utf8-strings
no-greeting
no-emit-version
no-comments
no-mdc-warning
armor
The output looks like this <<I have redacted the key ids >>:
gpg -v Test.asc
gpg: public key is 00000000
gpg: anonymous recipient; trying secret key 18XXXXXX ...
gpg: anonymous recipient; trying secret key 2EXXXXXX ...
gpg: using subkey 2EXXXXXX instead of primary key 18XXXXXX
gpg: anonymous recipient; trying secret key 65XXXXXX ...
gpg: anonymous recipient; trying secret key 6CXXXXXX ...
gpg: using subkey 6CXXXXXX instead of primary key 65XXXXXX
gpg: anonymous recipient; trying secret key B1XXXXXX ...
gpg: anonymous recipient; trying secret key 6DXXXXXX ...
gpg: using subkey 6DXXXXXX instead of primary key B1XXXXXX
gpg: public key is 00000000
gpg: anonymous recipient; trying secret key 18XXXXXX ...
gpg: anonymous recipient; trying secret key 2EXXXXXX ...
gpg: anonymous recipient; trying secret key 65XXXXXX ...
gpg: anonymous recipient; trying secret key 6CXXXXXX ...
gpg: anonymous recipient; trying secret key B1XXXXXX ...
gpg: anonymous recipient; trying secret key 6DXXXXXX ...
gpg: encrypted with RSA key, ID 00000000
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: secret key not available
Any help very welcome!
pb.
Looks like it tested all of your private keys, and none were the complement of the public key. Did you encrypt the message with your own public key? Or if someone else wrote it, did they encrypt it one of your public keys?
-
JofSpades, that one is months old. I have an updated version here:
http://dkn255hz262ypmii.onion/index.php?topic=114141.msg1130505#msg1130505
-
Looks like it tested all of your private keys, and none were the complement of the public key. Did you encrypt the message with your own public key? Or if someone else wrote it, did they encrypt it one of your public keys?
Hi astor, and thanks for helping.
I encrypted a message using my key first, and then my key and a random public other for another test. I've tried all my keys now and I get the same output ... ?
-
If you encrypt with your own public key, and you have the private key available in your key ring, then it should test all of them and find the right one. Don't know what else to tell you, except make sure the private key is there and you're encrypting with the right public key.
-
JofSpades, that one is months old. I have an updated version here:
http://dkn255hz262ypmii.onion/index.php?topic=114141.msg1130505#msg1130505
That's good but your earlier posts in this active thread still has errors and people are duplicating them.
See the post by PrincessButtercup a few posts back for just 1 example.
I humbly suggest that you fix the errors in your posts in this thread because not everybody will read to page 5 before
changing their config.
JofSpades
-
Subbed, will read later.
-
I don't consider there to be any errors. Some of the comments were wrong, which were fixed in the other version, but I'll copy it over to this thread.
-
You learned PGP from the documentation. I configured my client to work in the real world, specifically the anonymous darknets.
Users should not use 'trust model always' by default, it hides changed keys. Better is for them to locally sign the key.
We don't use a web of trust here, so it's irrelevant. You have no need to re-import a key multiple times, as none of them are signed, and signing them yourself is a useless chore. The whole key signing mechanism can and should be ignored with trust-model always.
That affects the cli arguments, not the message body. From the man page:
'utf8-strings Assume that command line arguments are given as UTF8 strings.'
That comment was fixed in a newer version that I posted a few months ago.
The mdc is a security check for message integrity, from the man page:
"disable-mdc Disable the use of the modification detection code. Note that by using this option, the encrypted message becomes vulnerable to a message modification attack."
Any user who has no-mdc-warning in their config file should remove it.
Since most PGP programs don't use it, you will constantly see these warnings, and they will be false positives. They are mostly useless and can be ignored.
-
sub'ing for later use... but damn, this is hot!
-
You learned PGP from the documentation. I configured my client to work in the real world, specifically the anonymous darknets.
GPG is GPG, darknet or clear
=== snip stuff I don't care to argue about ====
The mdc is a security check for message integrity, from the man page:
"disable-mdc Disable the use of the modification detection code. Note that by using this option, the encrypted message
becomes vulnerable to a message modification attack."
Any user who has no-mdc-warning in their config file should remove it.
Since most PGP programs don't use it, you will constantly see these warnings, and they will be false positives. They are
mostly useless and can be ignored.
The gpg developers state that this option makes messages vulnerable to attack.
I don't see how you can continue to recommend it to new users if you care about their security.
Do whatever you want, I've said my piece.
JofSpades
-
GPG is GPG, darknet or clear
It makes a big difference in use cases. We will never attend key signing parties. We don't upload our keys to key servers. The web of trust as envisioned by the PGP developers doesn't work here.
The gpg developers state that this option makes messages vulnerable to attack.
I don't see how you can continue to recommend it to new users if you care about their security.
Do whatever you want, I've said my piece.
Because, as I stated, the vast majority of PGP programs don't use it. Blame their developers. The MDC integrity feature is already disabled on their end, my option just turns off the warning, so it doesn't annoy you every time you see it, which would be every time you decrypt a message.
-
Not sure what MDC is but I am going to go out on a limb and guess that it has to do with message authentication codes, in which case it should be left enabled. I don't know if some GPG programs don't use it or not, but if they don't it is a security flaw on their end.
Okay just looked up MDC
A modification detection code (MDC) is a message digest that can prove the integ-
rity of the message. A message authentication code (MAC) ensures the integrity of
the message and the data origin authentication. The difference between an MDC
and a MAC is that the second includes a secret between Alice and Bob.
So pretty much the MDC is to make sure that the ciphertext is not modified in such a way that the plaintext changes. All in all I don't think it is a huge threat but MDC detects it.
It is probably something like hashing the plaintext message and then concatenating the hash to the plaintext prior to encryption, and during decryption removing the hash then hashing the plaintext and comparing the hash to the concatenated hash.
-
It makes a big difference in use cases. We will never attend key signing parties. We don't upload our keys to key servers. The web of trust as envisioned by the PGP developers doesn't work here.
Yeah that is true. We use GPG significantly differently than many others do.
-
thank you for posting this.
-
Thanks.
Probably some reasons went into calling it Pretty Good Privacy rather than Best Ever Privacy.
-
**subbed**
excellent information here for those upgrading to TAILS 0.20 - might as well adjust the GPG config as well!
pb.
-
bump
-
subbed
-
subbed, thanks for the info