Silk Road forums
Discussion => Security => Topic started by: LouisCyphre on July 03, 2012, 03:52 pm
-
Recently there have been a couple of threads started by people concerned that if they encrypt something to a vendor, like their address in an order, there is the risk that the encrypted file might be used against a buyer if LE manages to get the message. This is a brief explanation of how to encrypt a message that cannot be checked to see who it is encrypted to.
For this demonstration I'm going to need a volunteer from the audience. So a big thankyou to Guru who just got volunteered. ;)
Firstly there's the address I'm encrypting to Guru in the file address.txt:
Mr. L. Cyphre
666 Hell's Highway
9th Circle
Hades
Secondly my configuration is set to use my key (0xDD7B4576) as the default key, which is always encrypted to. And thirdly I have Guru's key (0x886855CA) for our demonstration recipient. I'm also using the verbose flag ("-v") so you can see exactly what happens.
To encrypt the above address normally the command would be:
bash-3.2$ gpg -v -ea -r 886855CA address.txt
gpg: using subkey D677EF45 instead of primary key DD7B4576
gpg: using subkey 048FB30D instead of primary key 886855CA
gpg: No trust check due to `--trust-model always' option
gpg: reading from `address.txt'
gpg: writing to `address.txt.asc'
gpg: RSA/AES256 encrypted for: "048FB30D Guru <Guru@SR>"
gpg: ELG-E/AES256 encrypted for: "D677EF45 Louis Cyphre <lcyphre@tormail.org>"
bash-3.2$
Which results in this:
-----BEGIN PGP MESSAGE-----
hQIMA/+VT6MEj7MNAQ/9GFt/J9yTRQ6xBzNFnZi1CSjGmqGlj0kpuBOzJ2F7NihY
IBSm96UkAgatnDE5IzHdljn5iyOa57n72Sgx4qxDugaZj4vjEN7d2/19rtJwHFAx
sd5zz/NTCKU4g3ziAFL+MWXaq/CXf/YOd8h4VleL9HfkliypvzQ4gElTPLokHZiO
Y2Hy+KAv/92HnjaV25Gorm6vhHg7wmW3cSAfIQLSXIbGBwQu5JweDMDxYubYDpeX
9YAqTqtOADe1nemN5VOiGtztDPguHczsO2DjiG0CaSOUn1RFvb6QOAngGn8sB+Mp
whm5Z4GUHpxvD7qDD4GObjJ3H+iKeaYg5Jon6eMk3QvkS3gO8tTPNXx8W8GgSCZH
OnxCTmcORw6FSssljwl3VFhnRKh0vSoQLGqjNZB77tc+/S/dfc+Iobhvv6IvHQpq
CgzP+DmM5yj15LarEJmmXpCG+ZZBJ1L7eI9W1TSEDId04eHDn1OXe/RGUF1uUd23
hHYySrPgtNM0r2UDCrQSxQU7O06Wi3Yb9KlBNcC7VOxiIauETykWCUaAJBTHRnRs
ZFnDlPOEdZpmvnE+ny9Hgl4eKf9RJpjSNWUuyBHR+GTd5qJpejyP+YRHSXuLLP8/
BduW8d85T5qTGxPKnYymg/apH4stnc+qKhJYPqWPKPTltvaoyUHaSx0k8jsYE6mF
BA4DAKz20tZ370UQEADbaOWfBeIrkb2wGrAaN/NNGO1LDjgmvyUWJiT99ha3hxIv
mSkJp42llvdAxwzDR8b5VyjDTbjLXaxkiWPzhkHzMQJzJpL/PsDXlXxsEOOnAcNk
DZsKm1EWflzHS9LnSHaEUCx+6IzUF4VFQH/TFAzH0RDTnphGJKll6JuNpQNMWt2w
SNQacCDevdX6lDUJHHUY1wIICavEMWWY90MYUqv4wsWP5dw0wDwtJzvU1CoCgqgq
1gF7gTyZBL4mi+Dn4/x+szAws/YFvHh7fyJ+vzIBdoFCM9UjocUXhOLLE7mYD3/5
Oky8mNBzELrXVGf7pvWJ5I/DD5ZjU3ov/XkD/w4dwePIVdO232ka9lISAAp5rjBM
5F7okubR7Oo3JBrkL8cO4M3azC4audcotzk4sSMQFCKGkbP+055wO4n5UPxs1ubA
12UvRtlvfv5rA98kIEhUyxyu8BovuwpUbtYHiVy5JhFKxZ5J4q5w2pd9uR7X/i3N
UPWsYTwAVXERfq1iuBnFw8R2d1YWmXTTY1WVJVwHNzsH2whmi5bUbyBZEdtHdUhX
B3S0/4VACvXFLsSK3iz8+XN5bKqlldfzxcosevvi9xlRcjbsGCRy3QFAn8wpSJKv
hFDLq0NmVBNuxXLjB5/OtJhP0FtM96gHH49VeLHZHAWadrtMnJz2OT4zDAZpKA/9
GV3BATtOWwtJMVCt9dTLbyuaGZlRNgRPRJXEOwy9ER9t4vT00pwi7Mf//o96Nsik
VHNDqkr/82FUVwSKoPWkFMnqIDSuivIdGojgOzr/v3sH02VBRKEB4PMpDXfIkyLi
UgiQblZo+atRSxw4Vvv0AD/H8JCmGbyWXRl8tqFTlY24XIuLLEZzHSsicIL5t0PZ
xeCuUA+YDGe5y/3duJpHUgExvtxcadAd+caNEwn9UE38L7rYbFoLl4gr6TYkJKLC
4EuJeJVjFjxAx/eWeU9GPneXa3hz2ZBpmzQ9nnGLNMBFV0mu6StdFxSQTwDeSDMs
R1UmBgwAp8WQ01qpviZGehJtPJ46Yf8ODHn/nH3ecL3OJrXrbSyqvVjO15FWHa72
FnAMlnYeTtE6FGghly7F1eUQZRUKJhS96pvyR5ui0wJpYSca+FmbIdvx+Nwoz/R0
Keyg2661o9how9Wi03DUPZANTi//dOlQdOPnu2ebPhLIyBjCc1U6goSPB+xQ9vtf
sKv/PyRV+1U+UjTiDUcnkkFS1s2rpzoAGzCXyXBm2O9mNrbRA/MztY96KHEqNpUr
ndmRZUt2k40TN35bVWD4fXUj0XaRkT5/dUKzzjrRrUssfpaHGK7iMCPLX+8aezQm
4mrimcUXIjB6YtsqmgFD/sxqYPHNY5HzjhOpIIX+pg/SeAGJOGhID/58497jEcqe
ax/DYDV2hgd18Ef7SzlKtTUP3K7ljLLSocNYWeyTQLlz4R1o3QlPFBwDh3BaIn7a
fB6Oe6+U8c84SqRAKbmVIKWniHqDZTxKhOM9Zr5xmCm+7xRsNMJwa9b0/28MD6CC
3xFAPV1Y3mrioQ==
=0TN2
-----END PGP MESSAGE-----
Now only Guru and I can decrypt that, but anyone else running it through gpg (with the "gpg -v" option) will see that the message is encrypted to Guru's key and mine. If they have either of our keys in their public keyring then they will see that data matched.
When I decrypt the file I am, of course, prompted for my passphrase and with the verbose flag I can see all the keys the message is encrypted to:
bash-3.2$ gpg -v address.txt.asc
gpg: public key is 048FB30D
gpg: public key is D677EF45
gpg: using subkey D677EF45 instead of primary key DD7B4576
You need a passphrase to unlock the secret key for
user: "Louis Cyphre <lcyphre@tormail.org>"
gpg: using subkey D677EF45 instead of primary key DD7B4576
4096-bit ELG-E key, ID D677EF45, created 2012-06-16 (main key ID DD7B4576)
gpg: using subkey 048FB30D instead of primary key 886855CA
gpg: encrypted with 4096-bit RSA key, ID 048FB30D, created 2012-05-11
"Guru <Guru@SR>"
gpg: encrypted with 4096-bit ELG-E key, ID D677EF45, created 2012-06-16
"Louis Cyphre <lcyphre@tormail.org>"
gpg: AES256 encrypted data
gpg: original file name='address.txt'
bash-3.2$
Now, since I don't want anyone who manages to obtain this message to even know who it is encrypted to, there is an option to conceal that data. That option is the "throw-key" option.
bash-3.2$ gpg -v -ea --throw-keyid -r 886855CA address.txt
gpg: using subkey D677EF45 instead of primary key DD7B4576
gpg: using subkey 048FB30D instead of primary key 886855CA
gpg: No trust check due to `--trust-model always' option
gpg: reading from `address.txt'
gpg: writing to `address.txt.asc'
gpg: RSA/AES256 encrypted for: "048FB30D Guru <Guru@SR>"
gpg: ELG-E/AES256 encrypted for: "D677EF45 Louis Cyphre <lcyphre@tormail.org>"
bash-3.2$
The encrypting process appears the same, which is as it should be. The output, however, is not:
-----BEGIN PGP MESSAGE-----
hQIMAwAAAAAAAAAAAQ//S6ugUxPasaLRcQoo8MKq6q+30upiQAa+yLCmUj64CYGj
sxnmu3qGMYBToDIJpv5/T4ufpoB2MTROh9Z/MNISKHXiuKVrBWymWMCvNO3c57bO
nUfyabhCAkM8K7iHwJSEhLLLl7ACL3DdBWFkirMCRRLKTPr1HqHuGY2iddY53ioe
WGb2jn7Sjwu8zUM9tNK+0/2k1ViuCc7CkJJA8hqixXZi07FMK+M2++kGoB76AoFR
amKHKsKR8ddLrZwGJERUELsPxC4SI98GRrF/DlQO/Mfd088O1gl/Q+RArHgEdJnc
wWoVQDC0SH8NpjIGgf50pgd4oNBZEORZfEsx03TJgh8CFD+0W064vdmcNcMarz0G
BcB9ycY/CoFujrHXD9NovGnH6oTCyqUhoe3TMZ4bO0MQAjbbo4iBuBqxD3C/THSw
/SYxlqSpJV9OTsqS9n60ERcc1SAZG+O1SwlGUilYYWIqI029ba71zvmGE3WxRk2J
HIsagTfote6sLN8ii1eSFidQI9MCDjRGVY1vRx1GEd+Wj8KNq/1Mlp5V5S6N6BNq
93Y7HOl04Axx+IUdM7PbJM4lrieHkIocAEq9s8Z467yuJba0Vo65qRD5PxE2n1X4
uibycdmCW0ZsuvL+Mf5CMYDngYG3idgvvs7jYIPbFI/3Ane0qS5MhApbYdrI9VyF
BA4DAAAAAAAAAAAQEAC1ChaYQ8Ev+KxX2SrV7k8wlHVCinrj2Ta7hYuDTLbniQia
lOwOoq0sdfjBtPqN6jKGe5I/2pNHoOYg2jiuqX8MkUCfX78244JKWzvzUFSzfYbf
mWulHZZadTmvIe261AnbQeCi3Jx6kHBExhnB+5T0QGNbe5npq7OA/6eNB8JEIfJb
je8sUmjfoXanZAyVJW/8Ea145C/xW5Yj7S+4nhvEHG2GPUDS+ZLOPF+i/EyKnpdt
mJUkjdQ38LVJieQuhfK4EF2Xn+aZlrw7DWCLUP0jNF6WfdHDbsYT4PZIJG9yJyVC
fsVqoaKVR/vrL2mHDL0hatQnwiZwUKzhp89xlrpOFnKvqLCma0wjTR7jHg6b6EjM
3cYVgg7IfN9fhPO9Ll4pdhGpdetMuK7sWKZJB4MvnM2/kaB1unuCGViNt5A7SAz3
R0IJYdf+x86t3vPJhs4TInMKOnIx9VufZBvP7AAVxQbHm7NCDMA0dyByE5koHYJC
F7vHWisltqAGz04lbgbMQogiF0cYAlKqHlYHAEzc1+k+4TIH8zNt29tvj8Ze+810
Ie460Ucs5hXS09OXUyxa7Bqk2lLbRfx5JBG4FQQl1cmxdBjRsJHefeYxXf7JA5eT
/LKCI17hrv3qF+ZeL+YQeVXbIwUdg/14/itDedBxEQSzhlQymB2EzLpUSFAMXxAA
uTUJPsmVJvza52STtscCkx9DzjE3oYeE2PqR5f0PKU7BTg+WTr15HsPtyahn6Uen
F3pw7qKqxEcv5Z+WEXyCnk6TBnLzt0l8picB1InF0CHZlqprIspcu4UCOQgdljje
Z+ZH+iSK4/hwgl0UPt8qi9dhTcpL51KhWJM3AyutaVeRkFJTD5aPRHbM5t5MVwbO
1wOkoTB9ffvMPUQhgQwbJAOADd5AVdBfGLH+a8g5f9FeQgFN3FSDYtQoTsg+484b
E6z0D3YJE65xiBLzVbXLBBq030vJMz1gc88NzBMWQVvi7SlRlA1G8Fy9at2t6Oxb
LmEXaD8iCqs3chh0OQL0tgnE0U9ATVY4T/uMZgPRk4x8Uq6QoA5ecxWmKw58XJyt
5KmusWJJpoT2K7QJXdzKe9ieilopE8V2AKibzsfdaMls7RlJnf4Rgp/NApajydh3
dxBeR03i98LyDL7Teuj/pejijZq8XMidXbhsrpcCWjxGtBQkx9z/zQoVBwWWnt2y
ouE6dZz4kNpBI863jUQu079jTl2X4Znj/C4seTsFwg/+OKMqTcf0m4Sus0u5SGkB
KTzlPx1sHukbRxbGGycQ5PJOiPjnIwwvaAVbRTfS+2YRN1Raa+dVGxRNKm0g5R5q
7SIDREeLMcntYU/Q2lZnThAip9aHv6OjjO4bOf5RkErSeAHS5pfBRfEUnDD2J3hS
qS9zzd4QeSM4s1QTgVKUWl/+sgiP+BOQBcHbfqBD5YhggB4+ZjnhGYcFeHPAQWPT
dTlf7ZgIEEyRJgFscvldFx9QaVwT1HIj41xMVQs6RBuKbc3hFHiuTZr+eul5+1GM
ggf6FoVTCV2ivQ==
=0Wvt
-----END PGP MESSAGE-----
This shows clearly when the message is decrypted or a decryption attempt is made:
bash-3.2$ gpg -v address.txt.asc
gpg: public key is 00000000
gpg: anonymous recipient; trying secret key DD7B4576 ...
gpg: anonymous recipient; trying secret key 195D71B8 ...
gpg: public key is 00000000
gpg: anonymous recipient; trying secret key D677EF45 ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with RSA key, ID 00000000
gpg: encrypted with ELG-E key, ID 00000000
gpg: AES256 encrypted data
gpg: original file name='address.txt'
bash-3.2$
The file is decrypted, but we cannot see who the recipients are. Only that there were two recipients, one with an RSA key and one with an Elgamal key (Guru's and mine, respectively).
The description of the "throw-key" option in the GPG manual describes exactly what is happening here, why it may be advantageous to use it sometimes and what the major drawback is:
Do not put the keyid into encrypted packets. This option hides the receiver of the message and is a countermeasure against traffic analysis. It may slow down the decryption process because all available secret keys are tried.
When decrypting a message which has been encrypted with "throw-key" GPG will try every secret key in the secret keyring in sequence until either a match is found or all keys have been tried.
NOTE: People with lots of secret keys will find this very annoying if it is used too much. Silk Road, however, is a fine example of where using the option may be of real benefit with some messages.
I recommend everyone attempt to decrypt the two messages above, regardless of whether or not you've got my key or Guru's key in your public keyrings. Compare the output GPG generates and remember, if it were LE doing this they would not even be able to determine the recipients of the second cipher block.
When encrypting an address to include in an order, I recommend combining this with the "for-your-eyes-only" option:
gpg -ea --throw-keyid --for-your-eyes-only -r $RECIPIENT_1 -r $RECIPIENT_2 address.txt
Now you can encrypt your address to a vendor in the order, but be sure that the information relating to that order cannot be used against you via traffic analysis.
-
what does the "for-your-eyes-only" option do exactly?
-
what is the best PG encryption windows program? Right now I am using GNU Privacy Assistant-GPA. GPA crashes ALOT! Is this one sufficient or is there something better I could be using?
-
many guis will shit bricks when trying to decrypt a message using --throw-keyids, especially if the target key isn't the first one
Even when there's only one or two secret keys in the keyring?
I'll admit that I normally hate it with my regular config, because I've got a lot of keys for it to cycle through all with different passphrases and if I forget one of the old ones it's a real pain.
Or is the issue specific to the GUIs being used? I've no doubt that my method of using GPG here differs from most.
-
what is the best PG encryption windows program? Right now I am using GNU Privacy Assistant-GPA. GPA crashes ALOT! Is this one sufficient or is there something better I could be using?
I've heard from a number of people that GnuPG Shell, an alternative frontend, is very good:
http://www.tech-faq.com/gnupg-shell.html
I haven't used it myself, though.
-
Recently there have been a couple of threads started by people concerned that if they encrypt something to a vendor, like their address in an order, there is the risk that the encrypted file might be used against a buyer if LE manages to get the message. This is a brief explanation of how to encrypt a message that cannot be checked to see who it is encrypted to.
GUI alternative is adding "no-throw-keyids" to gpg.conf, correct ?
Can you post "-v" output of the first message (hQIMA/+...) before decrypting. Mine seems a bit poor, lacking your nick.
gpg: public key is 048FB30D
gpg: public key is D677EF45
gpg: encrypted with ELG key, ID D677EF45
gpg: using subkey 048FB30D instead of primary key 886855CA
gpg: encrypted with 4096-bit RSA key, ID 048FB30D, created 2012-05-11
"Guru <Guru@SR>"
gpg: decryption failed: No secret key
what is the best PG encryption windows program? Right now I am using GNU Privacy Assistant-GPA. GPA crashes ALOT! Is this one sufficient or is there something better I could be using?
WinPT
GPG4USB
Cryptophane
-
GUI alternative is adding "no-throw-keyids" to gpg.conf, correct ?
No, the "no-throw-keyid" (or "no-throw-keyids") option is used to disable the "throw-keyid" (or "throw-keyids") option. By default "throw-keyid" is disabled, but if it is added to the gpg.conf then "--no-throw-keyid" can be used on the command line to override it.
The entry from the manual (http://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html) is here:
--throw-keyids
--no-throw-keyids
Do not put the recipient key IDs into encrypted messages. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis.1 On the receiving side, it may slow down the decryption process because all available secret keys must be tried. --no-throw-keyids disables this option. This option is essentially the same as using --hidden-recipient for all recipients.
The footnote says:
[1] Using a little social engineering anyone who is able to decrypt the message can check whether one of the other recipients is the one he suspects.
Social engineering might be a little more difficult on SR, though, especially when it comes to obtaining the specifics of an order from a buyer or vendor.
Can you post "-v" output of the first message (hQIMA/+...) before decrypting. Mine seems a bit poor, lacking your nick.
I did, it was this bit:
bash-3.2$ gpg -v address.txt.asc
gpg: public key is 048FB30D
gpg: public key is D677EF45
gpg: using subkey D677EF45 instead of primary key DD7B4576
You need a passphrase to unlock the secret key for
user: "Louis Cyphre <lcyphre@tormail.org>"
gpg: using subkey D677EF45 instead of primary key DD7B4576
4096-bit ELG-E key, ID D677EF45, created 2012-06-16 (main key ID DD7B4576)
gpg: using subkey 048FB30D instead of primary key 886855CA
gpg: encrypted with 4096-bit RSA key, ID 048FB30D, created 2012-05-11
"Guru <Guru@SR>"
gpg: encrypted with 4096-bit ELG-E key, ID D677EF45, created 2012-06-16
"Louis Cyphre <lcyphre@tormail.org>"
gpg: AES256 encrypted data
gpg: original file name='address.txt'
bash-3.2$
Note, the "-v" flag can be added to any GPG operation to get more detail of whatever it is doing.
gpg: public key is 048FB30D
gpg: public key is D677EF45
gpg: encrypted with ELG key, ID D677EF45
gpg: using subkey 048FB30D instead of primary key 886855CA
gpg: encrypted with 4096-bit RSA key, ID 048FB30D, created 2012-05-11
"Guru <Guru@SR>"
gpg: decryption failed: No secret key
That shows that you've got Guru's key in your public keyring, but not mine. So you can see at least one of the parties a message is encrypted to, even if you can't see the content of the message.
If you import my key to your keyring then the output of attempting to decrypt that first cipher block would look similar (deryption would still fail because you don't have the secret key), but GPG would identify both recipients.
-
ADDENDUM
As explained in this post: http://dkn255hz262ypmii.onion/index.php?topic=33621.msg398864#msg398864
Hiding the recipients of a message will prevent mass decryption of files using the --allow-multiple-messages option. Users needing to decrypt multiple messages simultaneously should NOT hide recipients and, more importantly, tell their correspondents not to do so either.
-
Recently there have been a couple of threads started by people concerned that if they encrypt something to a vendor, like their address in an order, there is the risk that the encrypted file might be used against a buyer if LE manages to get the message. This is a brief explanation of how to encrypt a message that cannot be checked to see who it is encrypted to.
Excellent post, Louis.
However, one risk that you haven't addressed arises because of the way PGP/GPG works. I'm referring to the fact that, in order to encrypt to someone's key, that key has to reside on the sender's PGP/GPG keyring. While the existence of particular keys on a person's keyring does not prove anything, in and of itself, it nevertheless provides evidence of possible contact between individuals.
Traffic analysis of intercepted messages, based on PGP/GPG Key-IDs: is a minor risk, and as you correctly pointed out, can be avoided through the --throw-key-ids directive.
In my view a much larger risk potentially arises from insecure storage of PGP/GPG keyrings on the part of vendors. If a vendor is raided, and his or her keyrings are not securely stored, then the authorities, by merely listing all the keys in the vendor's public keyring, can obtain a list of whom he or she has potentially been communicating with. Vendors therefore need to take appropriate precautions to secure their keyrings from exposure.
I agree. We should all be storing our GPG home directories (containing keyrings and config) in an encrypted volume of some kind. Vendors especially need to do this, of course.
-
New working hypothesis: Guru & Louis (fiends!) are plotting to break poor pine's printer :P :D
A good few trees have been murdered anyhow!
-
New working hypothesis: Guru & Louis (fiends!) are plotting to break poor pine's printer :P :D
A good few trees have been murdered anyhow!
Ah, you're on to our cunning plan! ;)