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
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: message signature types
Charly Avital: auto15963931 jv92pc$ct5$1...@dough.gmane.org July 31, 2012 2:47:22 PM wrote: If this is the wrong place to ask, please point me in the right direction. Where can I learn more about importing, if such a thing is even done this way, and making use of message signatures which utilize an smime.p7s file? I got a message from someone who uses this, and I need to learn about verifying and downloading from a keyserver files like this. Especially important for me is learning how to check whether it had been revoked, etc. Where is a support group for this sort of signature if this is not it? Thanks. S/MIME = Secure Multipurpose Internet Mail Extensions is a standard for public key encryption and signing of e-mail encapsulated in MIME. It achieves goals that are similar to GnuPG's but uses different means. The use of GnuPG requires the installation of GnuPG software, and some kind of module that will enable interaction between that software and the e-mail client one is using. GnuPG per se enables its user to generate and manage certificates (aka keys). S/MIME does not require the installation of any such software but needs to obtain and install a certificate/key that is issued by a Certificate Authority (CA). The certificate that is issued by the CA of your choice has to be imported into your e-mail client (if it has S/MIME capability) or into your browser. You might try http://www.comodo.com. I am sure members of this list will provide more accurate information. Charly OS X 10.8 (12A269} MacBook Intel C2Duo 2GHz-GnuPG 1.4.12-MacGPG2-2.0.17-9 Thunderbird 14.0 Enigmail 1.5a1pre (20120727-2257) So the last question is just how do I go about checking whether one of these smime.p7s certificates has been revoked. What is the process of revocation in general? Thanks. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: message signature types
Werner Koch: On Wed, 1 Aug 2012 16:50, auto15963...@hushmail.com said: So the last question is just how do I go about checking whether one of these smime.p7s certificates has been revoked. What is the process of revocation in general? Thanks. There are three ways: - Using a CRL. The address of the CRL is usually part of the certificate and used by GPGSM. - Using OCSP Responder. That is kind of online check of a CRL. You can enable this in GPGSM. - Use a list of revoked CAs which comes with todays browsers. Now the question is now to get your certificate into a CRL. Technically this is easy. But how can a user ask a CA to put his certificate on the CRL is an open question. You need to ask your CA. I already have Gpg installed, as well as GPA, but I have not used them for smime, which is, I think, what I hear you say I can do? In any case, when I right-click the certificate in Win7, I see no option that would lead me to believe that my system is currently capable of viewing this certificate. I opened it in a text viewer application, but it appears to be binary, not really a text file that I can see. So, what would I need to do at this point to take a looksy at this certificate file, which I detached from the message of which it was part? Thanks. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
message signature types
If this is the wrong place to ask, please point me in the right direction. Where can I learn more about importing, if such a thing is even done this way, and making use of message signatures which utilize an smime.p7s file? I got a message from someone who uses this, and I need to learn about verifying and downloading from a keyserver files like this. Especially important for me is learning how to check whether it had been revoked, etc. Where is a support group for this sort of signature if this is not it? Thanks. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pinentry
On 4/4/2012 9:50 PM, Hauke Laging wrote: This does not happen here (Linux, though). Hauke, hello. I expect when I get to the bottom of it all, I will find the fault is caused not by Windows but by my error or need for an adjustment of some kind. I was hoping that my description would trigger someone's idea about a similar experience so that they could provide a pointer to jump start my fixing the issue. Anyway, I have made some progress. [snip] However, much of the time I find that using this procedure does not cause the pinentry dialogue to move from one key to another but instead causes the dialogue window to close after either the first or second clicking on the cancel button instead of continuing on down through the complete list of keys I have available. It just fails to decrypt. This failure occurs mostly when I first try to use the procedure, but then it starts working properly after a few tries even though I do exactly the same steps each time. Why does it fail initially? Is this a known issue? This part of the problem still exists. Individually trying to decrypt a file encrypted with throw-keyids will fail, often but not always, to try all the keys before aborting the effort. I can prevent the problem by using --try-all-secrets; but, so far as I can see, this problem arises only during individual file decryption and not during batch decryption procedures. At least, this has been my experience up to now. It is a puzzling phenomenon and not apparent to me what is behind it. It almost seems like a memory thing or caching issue, but I'm not sure, yet. I have noticed a number of instances of failures during batch decryption too, even though the pinentry dialogue does not arise of course. These failures result in the --status-file indicating that the decryption failed although in fact I can find the decrypted message present. This part I have solved. My batch routine was overwriting the good output after the routine looped through the files again. I have changed it now to circumvent the occurences and I get the correct results. -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
pinentry
I use gpg on Windows OS. On the command line when I use this command: gpg -d filename.asc a pinentry window pops up requesting my passphrase. If it happens that the message was encrypted with the option --throw-keyids, then the pinentry window, not knowing which key was used, starts with one of my keys arbitrarily and requests the passphrase for it. I have two questions about this procedure. First, if I know which key was used and I want to select it, I can click the Cancel button at the time I see the arbitrary key dialogue window, and then the program will select another key, again apparently arbitrarily, and so on in succession, until it gets to the one I want, at which time I can enter the correct passphrase and get the decrypted result. However, much of the time I find that using this procedure does not cause the pinentry dialogue to move from one key to another but instead causes the dialogue window to close after either the first or second clicking on the cancel button instead of continuing on down through the complete list of keys I have available. It just fails to decrypt. This failure occurs mostly when I first try to use the procedure, but then it starts working properly after a few tries even though I do exactly the same steps each time. Why does it fail initially? Is this a known issue? I have noticed a number of instances of failures during batch decryption too, even though the pinentry dialogue does not arise of course. These failures result in the --status-file indicating that the decryption failed although in fact I can find the decrypted message present. Secondly, what is the correct way to handle this sort of procedure under these circumstances so that indeed all the keys would be tried each time? My initial thought is to include the option -- try-all-secrets in order to prevent the failure and premature closing of the decryption attempts during batch processes. Thanks. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [admin] Re: signature verification data
On 3/27/2012 12:55 PM, Werner Koch wrote: Hi, please remember to strip your quotes down to a reasonable size. Shalom-Salam, Werner Shalom to you likewise. My bad, Werner! Thanks for the reminder about your preferences. What is this url for: gmane-disc...@hawk.netfonds.no? How is it different from this one: gmane.comp.encryption.gpg.user? I mean, do they differ merely in having different routing protocols but have the same distribution destinations? Thanks. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: signature verification data
On Sun, 25 Mar 2012 13:18:37 + Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 03/25/2012 02:33 AM, auto15963...@hushmail.com wrote: When an encrypted file sent to me is both encrypted and signed, when I use a command like this: gpg -o file-out -d file-in I can see the signature verification data appear as standard output, in the terminal, while the file-out contents are separated from it. Is there a way to have the signature verification data appended to the file-out text message itself or possibly some other way of preserving this verification data and keeping them together? I am referring to the command line interface, but I noticed that GPA also keeps them separated. Thanks. you can use the --status-fd or --status-file arguments to direct machine-readable signature verification messages wherever you like. But sending it to the same file as the text is a bad idea. Don't do it. For example, here's me dumping the decryption to stdout so that it flows around the message: 0 dkg@pip:~$ gpg --status-fd 1 -d x x.2 gpg: Signature made Sun 25 Mar 2012 09:01:48 AM EDT gpg:using RSA key 0xCCD2ED94D21739E9 gpg: please do a --check-trustdb gpg: Good signature from Daniel Kahn Gillmor d...@fifthhorseman.net gpg: aka Daniel Kahn Gillmor d...@openflows.com gpg: aka [jpeg image of size 3515] gpg: aka Daniel Kahn Gillmor d...@debian.org 0 dkg@pip:~$ cat x.2 [GNUPG:] PLAINTEXT 74 0 test [GNUPG:] SIG_ID chNvlYWvyBS3mjoLtZ3oEC2SQho 2012-03-25 1332680508 [GNUPG:] GOODSIG CCD2ED94D21739E9 Daniel Kahn Gillmor d...@fifthhorseman.net [GNUPG:] NOTATION_NAME issuer- f...@notations.openpgp.fifthhorseman.net [GNUPG:] NOTATION_DATA 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 [GNUPG:] VALIDSIG 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 2012-03- 25 1332680508 0 4 0 1 10 01 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 [GNUPG:] TRUST_ULTIMATE 0 dkg@pip:~$ Here's why this is a bad idea: Once you've stuck the verification data into the same file as the message, how do you tell which parts are message body ends and which are verification data? You might assume that all the lines prefixed with [GNUPG:] are from the gnupg signature verification process; but what if the original message contained such lines (e.g. what if you were piping this message through the signature verification process)? By combining the data you're trying to verify with the results of the verification, you open yourself to pretty easy exploitation from anyone who chooses to craft their message in a certain way. For example, i could just insert lines in my message that imply a good signature from you, and place a well-formed (but bogus) cleartext signature around them. Your verification process would emit my data into the file, including my fake claims of verification. Someone scanning that file later will believe that you signed it. So yes, there's a way to do what you're asking. But you shouldn't do it. Daniel, hello. Okay, I can accept that. But I have a couple of questions still. First, in response to your scenario for the deception. It sounds like a prudent recommendation if the intention was to deceive someone else; however, if the goal was to have a record only for myself so that I could later review it to see whether I had gotten a message that was legitimately signed, then my combining them does not seem capable of misleading me since the message, if it had been falsified with bogus signature information, would also contain accurate information from the real process, showing me whether the signature was valid or not. Would it not? I mean, if there had been no signature in the first place, then the validation process I put the message through would indicate as much. Nevertheless, I do prefer your suggestion and I intend to adopt it in all cases, if possible. Secondly, I am having a little difficulty getting the signature validation information that I need. I can get the information when I am decrypting in a single file mode, but not when decrypting in batch mode. I need this to work in batch mode. I am working with it in a Windows OS. Here is the command I used in decryption of a single file: (dir /b file-in status.log) echo:password|gpg --verbose -- status-fd 1 file-in status.log 21 Using that command my file is decrypted, and, along with the name of the file itself, the signature validation information and decryption information is put into the file named status.log. Specifically, the information that comes from using --status-fd as an option does indeed present the signature information needed. The reason I use the first part of the command (i.e., dir /b file- in status.log) is so that the name of the file is also put into the status.log file, since the information coming from --status- fd, so far as I can tell, includes everything I need except for the name of the file it is pertaining to.
signature verification data
When an encrypted file sent to me is both encrypted and signed, when I use a command like this: gpg -o file-out -d file-in I can see the signature verification data appear as standard output, in the terminal, while the file-out contents are separated from it. Is there a way to have the signature verification data appended to the file-out text message itself or possibly some other way of preserving this verification data and keeping them together? I am referring to the command line interface, but I noticed that GPA also keeps them separated. Thanks. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
invalid gpg key revocation
___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: invalid gpg key revocation
Okay, there are a lot of responses, and I need to get to the bottom of this as quickly as possible, but I also want to do so methodically. Let me respond to the points raised as best I can until this is resolved. -Original Message- From: gnupg-users-boun...@gnupg.org [mailto:gnupg-users- boun...@gnupg.org] On Behalf Of Robert J. Hansen Sent: Monday, March 05, 2012 11:27 AM To: gnupg-users@gnupg.org Subject: Re: invalid gpg key revocation On 3/5/12 12:12 PM, auto15963...@hushmail.com wrote: I am 99.9% sure no one has gotten access to my machine or my keys. Whenever anyone ascribes 99.9% certainty to a belief, my knee-jerk reaction is to think the only 99.9% certainty is they've got the wrong confidence interval. :) There are really only a few possibilities here: 1. User error. You did it yourself by accident and didn't realize it. 2. Someone has access to your private key and passphrase and revoked your user ID. 3. GnuPG has a critical, showstopper bug. 4. The algorithm you used has a critical cryptographic flaw that someone exploited. I can't tell you how likely #1 or #2 are, but #s 3 and 4 both seem like fairly low-probability events. I would begin by checking to see if either #1 or #2 are in fact the case. If you want me to believe #3 or #4 are the case, you're first going to have to convince me it could not have been #1 or #2. I agree that user error is a possibility, but I am not certain how to prove it. I can reproduce another public key just like the one that was revoked except using a different name. I can use the same program, same method and same machine, and I can post it to an email here just as I posted it to the other site I mentioned. This way you can see the result plainly. At least we can determine whether the key is getting made correctly. I have to reiterate, but not eliminate the posibility, that someone having access to this machine is extremely unlikely. This machine is not in a public place or workplace. It is at my home, and I do not have any guest accessing it. My family members would not, and could not do this anyway. It is fully encrypted and well protected. I have a good deal of anti-malware and firewall protection. Impossible, no; improbable, highly so. -Original Message- From: gnupg-users-boun...@gnupg.org [mailto:gnupg-users- boun...@gnupg.org] On Behalf Of David Shaw Sent: Monday, March 05, 2012 12:40 PM To: auto15963...@hushmail.com Cc: gnupg-users@gnupg.org GnuPG Subject: Re: invalid gpg key revocation On Mar 5, 2012, at 12:12 PM, auto15963...@hushmail.com wrote: What can be looked at on the revoked key to see how or under what circumstances it was revoked? Thanks. A revocation appears as a signature on the key. Anyone who has (write) access to the key can add such a signature (if it exists). However, only the holder of the secret key can generate such a signature. In other words, if you really never made a revocation (many howto documents recommend making one and saving it when you generate your key), and the revocation you found on your key is genuine (if gpg confirms it is revoked), then I recommend you check if someone has access to your secret key. You can examine the revocation certificate with: gpg --export (your key id) | gpg --list-packets Looking at this instruction, I think you assume that I have imported the revoked key onto my keyring. I have not done so. On my keyring is the valid key, which is not revoked. The revoked key appears to be on a keyserver. When I do a search and view the result online, I can see my key ID number and user ID plainly identifying this key as having now been revoked. I have not imported it. The really wierd part is that I never publicly put it on a server myself. I guess someone else did that as part of this malice after I put it on a website for importing. I am reluctant to import the bad one because it might mess up the good one. So, I am not sure how to look at the certificate with your command, which appears to require that I export it. Does it not? The piece you are interested in will look like this. It's usually the second packet in an exported key: :signature packet: algo 1, keyid 7296AD3DA736CEC5 version 4, created 1330970459, md5len 0, sigclass 0x20 digest algo 2, begin of digest 74 51 hashed subpkt 2 len 4 (sig created 2012-03-05) hashed subpkt 29 len 10 (revocation reason 0x01 (foobar)) subpkt 16 len 8 (issuer key ID 7296AD3DA736CEC5) data: [2047 bits] Note the sigclass is 0x20, which is the revocation class. The keyid would be that of your key (or it's a revocation for someone else, and is not relevant to your key). Created is the epoch timestamp of when the revocation was supposedly generated, echoed in sig created. The revocation reason is the reason given when generating the revocation: 0 ==
Re: invalid gpg key revocation
-Original Message- From: gnupg-users-boun...@gnupg.org [mailto:gnupg-users- boun...@gnupg.org] On Behalf Of Ingo Klöcker Sent: Monday, March 05, 2012 3:37 PM To: gnupg-users@gnupg.org Subject: Re: invalid gpg key revocation On Sunday 04 March 2012, Robert J. Hansen wrote: On 3/4/2012 4:13 PM, auto15963...@hushmail.com wrote: Hello. Supposing I create a key with an arbitrary user ID... This seems to me to be a simple question wrapped up in a lot of unnecessarily specific details: How is it possible for a non-authorized person to revoke a user ID? 1. Mathematical weakness in the underlying algorithms (unlikely but possible) 2. Critical bug in GnuPG (unlikely but possible) 3. Someone's swiped your private key (disturbingly possible) 4. He has left his laptop unlocked and unattended for a very short period of time and he is using gpg-agent with a cache-ttl 0. I do in fact use gpg-agent and a cache 0, but this machine is not in a workplace or public location. It is in my home, in a place where visitors have no access, and my family would not have been able to do this. My machine has considerable security. I am not saying it would be 100% impossible to get access, but I am saying that if there is a possibility, I am not aware of it and I need to be so that I can prevent it recurrence. I do believe that there is another more plausible explanation. For instance, what procedure occurs at the server itself that allows the revocation to occur? Is it a fully automated event? Is there a way for a person without a key to issue a command to the server in any way to make this happen? I have verified that one can generate a revocation certificate without entering a passphrase if one has previously signed something (e.g. an email). So, it was probably just a very nasty prank. This is good information, but I personally would give it a stronger name than prank. Maybe gpg shouldn't use the cached signing passphrase (or any cached passphrase) for generating a revocation certificate. This does sound like a reasonable consideration, in my opinion. At least, I would like to have that option configurable. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: invalid gpg key revocation
I am 99.9% sure no one has gotten access to my machine or my keys. If they had, I have to believe that there would have been more damage done than this, and that does not appear to have happened. I mention the details, which may seem irrelevant, only because sometimes the devil is in the details. This event has in fact occurred, and I need to figure out how to explain it and prevent it. There was no revocation certificate for the key in question. There has to be another explanation. If this was user error, then I want to find that as well. What can be looked at on the revoked key to see how or under what circumstances it was revoked? Thanks. On Sun, 04 Mar 2012 22:29:30 + Hauke Laging mailinglis...@hauke-laging.de wrote: Am Sonntag, 4. März 2012, 22:13:58 schrieb auto15963...@hushmail.com: how is it then possible that someone else would be able to get the key revoked even while I had not published it to a key server at all? I mean, suppose someone wanted to mess around with me and have my key revoked. How could that have been done? Can it be prevented? Thank you. The interesting question about that is not about you publishing the public key but about how the person could get access to your private key. It is not possible to revoke a key without the private key. That answers your question how to prevent that: Pay attention to it that nobody gets access to your private keys. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
invalid gpg key revocation
Hello. Supposing I create a key with an arbitrary user ID, and it contains an email address that is not real but exists only for sake of having a key to use for signing and encrypting with a pseudonym, and supposing I make the public key available by putting a copy of it on an anonymous website so that others can import it and be able to identify things I have written and signed as valid and legitimately belonging to me, how is it then possible that someone else would be able to get the key revoked even while I had not published it to a key server at all? I mean, suppose someone wanted to mess around with me and have my key revoked. How could that have been done? Can it be prevented? Thank you. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
