Re: how vulnerable is hidden-encrypt-to
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Monday 20 August 2012 at 9:42:31 PM, in mid:20120820204231.2fbace6...@smtp.hushmail.com, ved...@nym.hush.com wrote: The simplest way to do that is to send the message encrypted to only one recipient at a time. If I recall correctly, the QDPGP plugin for using PGP with Pegasus Mail does that. I don't know about the GnuPG version, QDGPG. http://www.grt.net.tt/qdgpg.html - -- Best regards MFPAmailto:expires2...@rocketmail.com Ballerinas are always on their toes. We need taller ballerinas! -BEGIN PGP SIGNATURE- iQCVAwUBUDVDCaipC46tDG5pAQpVKgP/bhVnEQXpld09uguIT8uvhm05EuXxXzj8 wYF2uZThmYVBN3phHr0l808MBtZTT1VbI95ZgGrkrN5MYrkIJb0YInZw4B+2Y+0F JuyiFgeOfN8870hPtQGazucxJs62Mkv5ZiUjd16ZgpsG3cXMSfY8EJe/lczanc67 Rcz33NY8HYE= =+cz/ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
On Mo, Aug 20 2012, ved...@nym.hush.com wrote: On Mon, 20 Aug 2012 13:57:41 -0400 Jens Lechtenboerger clou...@informationelle-selbstbestimmung-im-internet.de wrote: In contrast, I interpreted the original question in terms of recipient anonymity: Bob wants to encrypt a message to some undisclosed list of recipients (say, including Alice and Eve), and nobody should be able to figure out who (else) is on the list. Clearly, the fact whether I can decrypt the message tells me whether I'm on the list or not; however, I should not be able to learn more than that. In particular, I should not be able to identify any other recipient. The simplest way to do that is to send the message encrypted to only one recipient at a time. That's correct, but severely restricted. Now, if the sender *wanted* to mislead, she could, in addition to sending encrypted messages to the 'real' people she wanted to send to, she could also use hidden-encrypt to anyone else's public key, and send people on a wild chase of trying to see who else it was encrypted to. I'm not convinced. First, I don't want to enable lots of unnecessary parties to read those messages. Second, I may be interested in real protection, not just in having fun with false traces. In that situation, my previous posting was meant to suggest that Eve (if she has access to the public RSA key of Alice used by Bob) will be able to figure out that the message was also encrypted to Alice. = I'm not sure about this. The way RSA works, is that the session key has *padding* added before it is encrypted to a public key. It may even have *different* padding for each public key it is encrypted to in the same gnupg command. (Maybe those who really know about this, could comment if the padding is the same or different for each public key RSA encrypted packet in one encrypted gnupg message). If so, and there is different padding, then you will not be able to determine whose key it is just by trying to re-encrypt the session key to a trial list of public keys, and comparing the ciphertext. Also, different would need to be random and of sufficient length... Even if it is not so, (i.e. that there is no 'different' padding), it will not be easy for an average user to re-encrypt, as (afaik), gnupg doesn't list the padding upon decryption. (It could be done though, by decrypting that packet directly with RSA tools, but probably not by the averaqe user :-) ... ) I'm not concerned whether the average user can do this right now or not. I'm concerned about experts (that could also provide attack tools to average users). Many thanks for your input! Jens ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
On Tue, 21 Aug 2012 11:59:20 -0400 Jens Lechtenboerger clou...@informationelle-selbstbestimmung-im-internet.de wrote: Also, different would need to be random and of sufficient length... = It is. See RFC4880, (it's one of the 'MUST' implementations for all open-pgp's) http://tools.ietf.org/html/rfc4880 (specific sections will be quoted below) = I'm not concerned whether the average user can do this right now or not. I'm concerned about experts (that could also provide attack tools to average users). = Even the experts should not be able to. See the quoted sections below. =[ begin quoted sections ]= 5.1. Public-Key Encrypted Session Key Packets (Tag 1) ... Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, the implementation MUST make a new PKCS#1 encoding for each key. ... 7.2 RSAES-PKCS1-v1_5 * It is recommended that the pseudorandom octets in step 2 in Section 7.2.1 be generated independently for each encryption process, especially if the same data is input to more than one encryption process. Haastad's results [24] are one motivation for this recommendation. * The padding string PS in step 2 in Section 7.2.1 is at least eight octets long, which is a security condition for public-key operations that makes it difficult for an attacker to recover data by trying all possible encryption blocks. ... 13.1.1. EME-PKCS1-v1_5-ENCODE Input: k = the length in octets of the key modulus M = message to be encoded, an octet string of length mLen, where mLen = k - 11 Output: EM = encoded message, an octet string of length k Error: message too long 1. Length checking: If mLen k - 11, output message too long and stop. 2. Generate an octet string PS of length k - mLen - 3 consisting of pseudo-randomly generated nonzero octets. The length of PS will be at least eight octets. 3. Concatenate PS, the message M, and other padding to form an encoded message EM of length k octets as EM = 0x00 || 0x02 || PS || 0x00 || M. 4. Output EM. =[ end quoted sections ]= vedaal n.b. If you are interested in looking into this rigorously further, I recommend you contact Professor Dan Boneh. http://crypto.stanford.edu/~dabo/ (He is an authority on RSA, teaches a free online Cryptography course at Stanford University, and has a clear style and is reasonably accessible.) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
On Sa, Aug 18 2012, Daniel Kahn Gillmor wrote: On 08/17/2012 11:16 AM, Hauke Laging wrote: Am Fr 17.08.2012, 09:56:56 schrieb auto15963931: or what key ID had been used in conjunction with that option? Thanks. You need the private recipient key in order to find out that key ID. It's the use of this option that you cannot get this information in another way. It's worth observing that you can still detect the algorithm used and the size of the key, even when the keyid is all zeros. So if someone has a particularly unusual key size (or is an early adopter of an unusual key type, like ECC), the pool of possible known recipients could actually be pretty small. In addition, as explained by Barth et al. in 2006 in http://www.adambarth.com/papers/2006/barth-boneh-waters.pdf When GPG generates an ElGamal public key, it does so in the group of integers modulo a random prime. Thus, different principals are very likely to have public keys in different groups, making GPG encryptions vulnerable to passive key privacy attacks. [...] GPG could defend against these attacks by using the same prime for every public key, for example one standardized by NIST What is the state of this recommendation? Has it been implemented? I'm not a crypto expert but I also think the following: Encryption is performed symmetrically using a randomly generated session key K, that is encrypted to the public keys of all (hidden) recipients. Thus, if a message M is encrypted to you and other recipients using RSA, then you are of course able to obtain the session key K. Now, if you suspect Alice to be a recipient then you download her public key from a key server and encrypt the session key K under her public key. If the result matches one of the encrypted session keys contained in M, then Alice is a recipient of M. If I'm not mistaken this attack works with RSA but not with ElGamal (as ElGamal does randomized encryption). Best wishes Jens ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
On Mon, 20 Aug 2012 09:38:49 -0400 Jens Lechtenboerger clou...@informationelle-selbstbestimmung-im-internet.de wrote: if a message M is encrypted to you and other recipients using RSA, then you are of course able to obtain the session key K. Now, if you suspect Alice to be a recipient then you download her public key from a key server and encrypt the session key K under her public key. If the result matches one of the encrypted session keys contained in M, then Alice is a recipient of M. = The one sending the message really is in control here ;-) The sender can use hidden encrypt to ANY public key. i.e. if Alice is sending the message and wants to hide her identity, nothing prevents her from using throw-keyid with Bob's public key instead of her own, or NIST's, or PGP Corporation's, or any onyone else's. If the message is unsigned, the receiver cannot tell, (assuming it's sent from an appropriately anonymized e-mail address), and if it is signed, then the throw -keyid doesn't hide the sender's identity from the receiver. vedaal (sorry about thread-breaking ;-(( sent from a site that doesn't allow e-mail clients) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
On Mo, Aug 20 2012, ved...@nym.hush.com wrote: On Mon, 20 Aug 2012 09:38:49 -0400 Jens Lechtenboerger clou...@informationelle-selbstbestimmung-im-internet.de wrote: if a message M is encrypted to you and other recipients using RSA, then you are of course able to obtain the session key K. Now, if you suspect Alice to be a recipient then you download her public key from a key server and encrypt the session key K under her public key. If the result matches one of the encrypted session keys contained in M, then Alice is a recipient of M. = The one sending the message really is in control here ;-) The sender can use hidden encrypt to ANY public key. i.e. if Alice is sending the message and wants to hide her identity, nothing prevents her from using throw-keyid with Bob's public key instead of her own, or NIST's, or PGP Corporation's, or any onyone else's. [...] I'm not sure whether I understand you correctly. If I'm not mistaken then you are referring to sender anonymity. In contrast, I interpreted the original question in terms of recipient anonymity: Bob wants to encrypt a message to some undisclosed list of recipients (say, including Alice and Eve), and nobody should be able to figure out who (else) is on the list. Clearly, the fact whether I can decrypt the message tells me whether I'm on the list or not; however, I should not be able to learn more than that. In particular, I should not be able to identify any other recipient. In that situation, my previous posting was meant to suggest that Eve (if she has access to the public RSA key of Alice used by Bob) will be able to figure out that the message was also encrypted to Alice. Thus, hidden-encrypt-to, throw-key-id, and hidden-recipient do not help here. I'd be happy to be corrected if I'm missing something, though... Best wishes Jens ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
= The one sending the message really is in control here ;-) The sender can use hidden encrypt to ANY public key. i.e. if Alice is sending the message and wants to hide her identity, nothing prevents her from using throw-keyid with Bob's public key instead of her own, or NIST's, or PGP Corporation's, or any onyone else's. If the message is unsigned, the receiver cannot tell, (assuming it's sent from an appropriately anonymized e-mail address), and if it is signed, then the throw -keyid doesn't hide the sender's identity from the receiver. vedaal I got a bit intrigued by this discussion, having posted a question once relating to it. I'm not sure if this input really shows anything or is of any real contribution to the discussion, but to me it seems all recipients, including your own are hidden for you when you decrypt a message or a file? (You get how many keys, but only ID for each). Note that the file was not signed. So I made a test in my GPG workshop (where I have four 'dummy' keys I created just for testing things out). A file was encrypted with --hidden-recipients ( -R ); a friend's key, one of my dummy keys [key four], playing the recipient and sender, plus two keys serving as 'red herrings', random keys I downloaded from The Guardian (UK newspaper) and Deutsche Telekom. I then ran a --decrypt and got this output: gpg: anonymous recipient; trying secret key [key one] ... gpg: anonymous recipient; trying secret key [key two] ... gpg: anonymous recipient; trying secret key [key three] ... gpg: anonymous recipient; trying secret key [key four] ... gpg: cipher algorithm 122 is unknown or disabled gpg: anonymous recipient; trying secret key [key one] ... gpg: anonymous recipient; trying secret key [key two] ... gpg: anonymous recipient; trying secret key [key three] ... gpg: anonymous recipient; trying secret key [key four] ... gpg: anonymous recipient; trying secret key [key one] ... gpg: anonymous recipient; trying secret key [key two] ... gpg: anonymous recipient; trying secret key [key three] ... gpg: anonymous recipient; trying secret key [key four] ... gpg: anonymous recipient; trying secret key [key one] ... gpg: anonymous recipient; trying secret key [key two] ... gpg: anonymous recipient; trying secret key [key three] ... gpg: anonymous recipient; trying secret key [key four] ... gpg: okay, we are the anonymous recipient. gpg: encrypted with RSA key, ID gpg: encrypted with RSA key, ID gpg: encrypted with RSA key, ID gpg: encrypted with RSA key, ID /Sin T. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
On Mon, 20 Aug 2012 13:57:41 -0400 Jens Lechtenboerger clou...@informationelle-selbstbestimmung-im-internet.de wrote: In contrast, I interpreted the original question in terms of recipient anonymity: Bob wants to encrypt a message to some undisclosed list of recipients (say, including Alice and Eve), and nobody should be able to figure out who (else) is on the list. Clearly, the fact whether I can decrypt the message tells me whether I'm on the list or not; however, I should not be able to learn more than that. In particular, I should not be able to identify any other recipient. = The simplest way to do that is to send the message encrypted to only one recipient at a time. Now, if the sender *wanted* to mislead, she could, in addition to sending encrypted messages to the 'real' people she wanted to send to, she could also use hidden-encrypt to anyone else's public key, and send people on a wild chase of trying to see who else it was encrypted to. = In that situation, my previous posting was meant to suggest that Eve (if she has access to the public RSA key of Alice used by Bob) will be able to figure out that the message was also encrypted to Alice. = I'm not sure about this. The way RSA works, is that the session key has *padding* added before it is encrypted to a public key. It may even have *different* padding for each public key it is encrypted to in the same gnupg command. (Maybe those who really know about this, could comment if the padding is the same or different for each public key RSA encrypted packet in one encrypted gnupg message). If so, and there is different padding, then you will not be able to determine whose key it is just by trying to re-encrypt the session key to a trial list of public keys, and comparing the ciphertext. Even if it is not so, (i.e. that there is no 'different' padding), it will not be easy for an average user to re-encrypt, as (afaik), gnupg doesn't list the padding upon decryption. (It could be done though, by decrypting that packet directly with RSA tools, but probably not by the averaqe user :-) ... ) vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 18 August 2012 at 3:36:21 PM, in mid:502fa865.80...@fifthhorseman.net, Daniel Kahn Gillmor wrote: And it's also possible to rule out a given person as an intended recipient, e.g. if they have a 2048-bit RSA key and the ESK packet targets 4096-bit el gamal. You can rule out a key. But not a person can have more than one key. - -- Best regards MFPAmailto:expires2...@rocketmail.com Reality is nothing but a collective hunch. -BEGIN PGP SIGNATURE- iQCVAwUBUDD3BKipC46tDG5pAQr1ZgQAvpRfGjPFNUfpFAfsxkhuNdH1TNAG7vUI +yfF0tYTB9sm1HTP+JxMpAzMD//mqsnkecShy4AU5ZStTLueE9Fy60O+w3K7/nKp VrSogWdNMl6FFCNE46VvIqs1sZUkkGC6es1ZjO1FX8PS2V1HbLmMhynDaRUTpWHO FXAJsur920g= =Z93Y -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
On 08/17/2012 11:16 AM, Hauke Laging wrote: Am Fr 17.08.2012, 09:56:56 schrieb auto15963931: or what key ID had been used in conjunction with that option? Thanks. You need the private recipient key in order to find out that key ID. It's the use of this option that you cannot get this information in another way. It's worth observing that you can still detect the algorithm used and the size of the key, even when the keyid is all zeros. So if someone has a particularly unusual key size (or is an early adopter of an unusual key type, like ECC), the pool of possible known recipients could actually be pretty small. And it's also possible to rule out a given person as an intended recipient, e.g. if they have a 2048-bit RSA key and the ESK packet targets 4096-bit el gamal. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
Am Sa 18.08.2012, 10:36:21 schrieb Daniel Kahn Gillmor: It's worth observing that you can still detect the algorithm used and the size of the key, even when the keyid is all zeros. So if someone has a particularly unusual key size (or is an early adopter of an unusual key type, like ECC), the pool of possible known recipients could actually be pretty small. And it's also possible to rule out a given person as an intended recipient, e.g. if they have a 2048-bit RSA key and the ESK packet targets 4096-bit el gamal. I think these hints should be added to the documentation. Hauke -- ☺ PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
how vulnerable is hidden-encrypt-to
Is there any way on heaven or earth for someone to discover from a message, one sent to them or to another person, whether the encrypted message had been made with an option hidden-encrypt-to or what key ID had been used in conjunction with that option? Thanks. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
Am Fr 17.08.2012, 09:56:56 schrieb auto15963931: Is there any way on heaven or earth for someone to discover from a message, one sent to them or to another person, whether the encrypted message had been made with an option hidden-encrypt-to Sure. start cmd: LC_ALL=C gpg --list-packets test.gpg :pubkey enc packet: version 3, algo 1, keyid 8E75E2184AD27C5B data: [4095 bits] :pubkey enc packet: version 3, algo 1, keyid data: [2046 bits] gpg: anonymous recipient; trying secret key 0x25D4FD8B ... or what key ID had been used in conjunction with that option? Thanks. You need the private recipient key in order to find out that key ID. It's the use of this option that you cannot get this information in another way. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
Hauke Laging: Am Fr 17.08.2012, 09:56:56 schrieb auto15963931: Is there any way on heaven or earth for someone to discover from a message, one sent to them or to another person, whether the encrypted message had been made with an option hidden-encrypt-to Sure. start cmd: LC_ALL=C gpg --list-packets test.gpg :pubkey enc packet: version 3, algo 1, keyid 8E75E2184AD27C5B data: [4095 bits] :pubkey enc packet: version 3, algo 1, keyid data: [2046 bits] gpg: anonymous recipient; trying secret key 0x25D4FD8B ... or what key ID had been used in conjunction with that option? Thanks. You need the private recipient key in order to find out that key ID. It's the use of this option that you cannot get this information in another way. Hello, Hauke Apparently, that it was used could be seen, but to whom it had been encrypted could not unless one happened to have that key. In the example of yours it appears as though the message was encrypted to two different keys, one of which was hidden and the other not. Is that right? Incidentally, when I looked at your reply and noticed it was signed, I tried verifying the signature. However, the signature appeared to be invalid according to the message I got: OpenPGP Security Info Error - signature verification failed gpg command line and output: gpg2.exe gpg: Signature made 08/17/12 10:16:27 Central Daylight Time gpg:using RSA key 5BA0F8B53A403251 gpg: BAD signature from Hauke Laging ha...@laging.de [unknown] Why is the signature failing? Thanks. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
Am Fr 17.08.2012, 21:05:32 schrieb auto15963931: In the example of yours it appears as though the message was encrypted to two different keys, one of which was hidden and the other not. Is that right? That is right. --hidden-encrypt-to needs other recipients. But you may use ‑‑throw-keyids or --hidden-recipient instead. Incidentally, when I looked at your reply and noticed it was signed, I tried verifying the signature. Why is the signature failing? Thanks. That's a bug in my MUA which is triggered by the email being encoded as ascii: https://bugs.kde.org/show_bug.cgi?id05171 This bug (or rather: problem) has been discovered here on the list – it occurs almost only in English emails. I have added a non-ASCII char to my text signature thus forcing a charset different from ascii. Thus the signature of this email should be OK. Hauke -- ☺ PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how vulnerable is hidden-encrypt-to
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hauke Laging wrote: Am Fr 17.08.2012, 21:05:32 schrieb auto15963931: In the example of yours it appears as though the message was encrypted to two different keys, one of which was hidden and the other not. Is that right? That is right. --hidden-encrypt-to needs other recipients. But you may use ‑‑throw-keyids or --hidden-recipient instead. Incidentally, when I looked at your reply and noticed it was signed, I tried verifying the signature. Why is the signature failing? Thanks. That's a bug in my MUA which is triggered by the email being encoded as ascii: https://bugs.kde.org/show_bug.cgi?id=305171 This bug (or rather: problem) has been discovered here on the list – it occurs almost only in English emails. I have added a non-ASCII char to my text signature thus forcing a charset different from ascii. Thus the signature of this email should be OK. Hey! OpenPGP Security Info UNTRUSTED Good signature from Hauke Laging mailinglis...@hauke-laging.de Key ID: 0x3A403251 / Signed on: 08/17/2012 10:24 PM Key fingerprint: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 - -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key:3EDBB65E 9A2FC99A Registered Machine 241939. /( )\ Shrewsbury, New Jerseyhttp://counter.li.org ^^-^^ 23:10:01 up 30 days, 3:11, 3 users, load average: 4.42, 4.42, 4.43 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org/ iD8DBQFQLwgZPtu2XpovyZoRAiU2AKDVSMsLyT5eg5DfPYLsyFAnpgQP6gCfaHlK dYa2u4OhhM8+1yLfPtM7z48= =ylCp -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
