unsubscribe
___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Newbie question on GPG and PHP running from a webpage
"Griffin Cheng [CLIB]" wrote: >Hello, > >I am new to GPG, especially writing programs to decrypt stuff. Is this >the right mailing list to ask? gnupg-users is for most discussions and gnupg-devel is for programming/development specific questions. HTH. Cheers, --Paul -- PGP: 3DB6D884 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust your corporation for keyowner identification?
>On Tuesday 5 November 2013 at 11:03:19 PM, in >, Paul R. Ramer wrote: > >> But if you sign it with an exportable >> signature, you are saying to others that you have >> verified the key. > >In the absence of a published keysigning policy, isn't that an >assumption? Signing is to be an attestation to the validity of the key. But, yes, in absence of a keysigning policy (or in some other way of knowing how that person signs keys) it is just an assumption as to what that signature means. I would not assume what the value of a signature is without knowing how that person signs keys, and I would still need to believe that person's methods are acceptable to me. Cheers, --Paul -- PGP: 3DB6D884 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Newbie question on GPG and PHP running from a webpage
Hello, I am new to GPG, especially writing programs to decrypt stuff. Is this the right mailing list to ask? Regards, Griffin CHENG. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Quotes from GPG users
On 6/11/13 2:40 AM, Sam Tuke wrote: >> Feel free to use any of my public comments on the topic, either on my >> blog or on Twitter. > > Those are great resources I hadn't seen before, thanks for the links! > > What do you think about these two? I had a hard time finding quotes > from your articles that fit into 130 chars, Yeah, I can be a bit of a wordy bastard sometimes. ;) > so I reworded them: > > "GnuPG provides encrypted email and file encryption...this > technology is an integral part of the survival skills of the digital > age" > Source: > http://www.adversary.org/wp/2012/09/20/protecting-yourself-in-a-surveillance-state/ > > "Scalps have been claimed in Australian politics due to forged > emails, yet GPG has been able to prevent this for years" > Source: > http://www.adversary.org/wp/2011/08/20/preventing-political-blunders-with-digital-signatures/ I approve them both! :) Especially after seeing which paragraphs you converted into that. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust your corporation for keyowner identification?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 5 November 2013 at 11:03:19 PM, in , Paul R. Ramer wrote: > But if you sign it with an exportable > signature, you are saying to others that you have > verified the key. In the absence of a published keysigning policy, isn't that an assumption? > Collusion is the only way that I know of, I guess coercion would fit, as well. - -- Best regards MFPAmailto:expires2...@ymail.com The greatest of faults is to be conscious of none. -BEGIN PGP SIGNATURE- iPQEAQEKAF4FAlJ5kaRXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pyMMD/37UAP0abP2L6tVKQPbH/ie77fo79Pg4OKop jKwDuzBGFrdxKhgV1Y4+Q6h4u8N/xyahtp6yqBjlEj74K+8UBSEtvc8qbNw4g2BU hk3meLpwJw9N92fLJxOvoUQamuotLBOt8ebbKMy3PZgh1jKPponrc54YfoHQ0zI+ tlo6P27m =SN+2 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust your corporation for keyowner identification?
On 11/05/2013 09:26 AM, Leo Gaspard wrote: > On Tue, Nov 05, 2013 at 12:40:11AM -0800, Paul R. Ramer wrote: >> I don't know how I can explain it any better than I have. I think you are >> confusing assertion with verification. Unless you can differentiate between >> the two in this case, I don't think you will see what I am talking about. >> >> [...] >> >> I guess all I can say is that one should have a key signing policy to let >> others know how he verifies keys. >> >> There. I said it all over again, just differently (and a whole lot more). > > OK, I think I understood your point. (That is, assertion is not as strong as > verification.) > > However, I think in this case (assuming there are no more UID on key 2 than on > key 1), assertions are sufficient, *because* there are two assertions, one in > both ways. > > I mean : > * Owner of Key 1 says (s)he is owner of Key 2 (through signed message saying >you so) > * Owner of Key 2 says (s)he is owner of Key 1 (through signed UID on Key 2) > > So, except in case of collusion between owners of Keys 1 and 2, I believe > there > is no way one can be wrong in signing Key 2 (of course, if Key 1 is signed). There could be collusion with only one key. Verification of the key details cannot address this. > IIUC, your point is that verification would enable one to avoid collusion, as > it > is the only flaw I can see in this verification scheme. > Except collusion can not be avoided in any way, AFAIK. No. Avoiding collusion is impossible here. It just comes down to you vouching through your signature on the second key that you have *verified* it. Nothing more, nothing less. If you didn't follow all of the steps to verify it, why would you sign it with an exportable signature? You could just sign it with a local signature for your use, because you believe the key to be valid. But if you sign it with an exportable signature, you are saying to others that you have verified the key. It is reasonable to expect that if you signed someone's key you did verify it without skipping any steps (whether you felt they were unnecessary in this case or not). Signing keys with exportable signatures is not for your benefit. It is for others you may extend ownertrust to your signatures. I have communicated with plenty of people via email who I believe were who they said that they were, that they did have control of their accounts, and that if they did have an OpenPGP key, it seemed to me to be valid. Would I sign their keys with exportable signatures to tell others that I have checked their keys and believe them to be valid when I have not fully verified their keys? No. > If that is not your point, could you exhibit a scenario in which there is a > signed UID on Key 2, a signed statement from Key 1 owner saying he owns Key 2, > and Key 2 not being usable by Key 1 owner ? (Of course, excepting collusion, > which as stated above can not be avoided.) Collusion is the only way that I know of, and there is nothing you can do about it if it is happening. Cheers, --Paul -- PGP: 3DB6D884 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm and expired certificates
Hi On Monday 4 November 2013 at 10:43:43 PM, in , Uwe Brauer wrote: > - NSA (among others) has abused its resource to > read emailworldwide at a very large scale. Indeed. > - so if a lot of people, say 30 % of all users > would encrypt theiremail, then NSA statistical > approach would *not* work that smoothand this > is a good thing. Why do you describe it as a statistical approach? I guess 30% was plucked out of the air. It would seem self-evident that if a sizeable proportion of emails travelled encrypted, the NSA etc. would have to do more work to read them. > - so encrypting email should be easy and look > trustful for amajority of users I like the idea, but have a bit of an issue with security made too easy. Security has to be inconvenient; just a lot more so for a would-be attacker than for the person using the security. > - usually public/private key based methods are > considered relativesecure (Even Snowden claimed > that you could rely on them), thisdoes not mean > that the NSA could not read your email. They would > usually try to enter your machine installing a > keylogger orsomething like this. But this is > beyond the statistical method Imentioned above. Hopefully, if it was more effort and more cost to read an individual's mail, that individual might be left alone unless they are a suspect. But what about an individual two or three communication hops from a suspect? > - if I understand correctly the real problem is > not security of thethe cipher but the > authenticity of the sender and so the most > common attack is a man in the middle attack. This > is true forboth smime and gpg. So comparing > fingerprints of public key is agood thing, > which most of us, I presume, don't do. For most people's communication, it is not encrypted so the main problem is simply being read in transit, and/or stored. Once you start encrypting, even without putting the effort in for sender authentication, it takes more effort to snoop on your mail than on the majority of people's. > - from my own experience I am convinced that smime > is much easierthan gpg[2] for reasons I am not > going to repeat here. (I got 7out of 10 of my > friends/colleagues to use smime, but 0 of 10 to > use gpg.) Depending on the software people are using. I'm willing to accept that there are probably more people for whom S/MIME is easier to use. > - one of the reasons some of them hesitated was > the fact that thecertificates were offered by > some commercial company they did notknow and > trust.[3]They would have had installed it from > a government basedorganisation, say the > ministry of justice though. I think "know" is the key factor, but "know and trust" is even better. I suspect a whole lot of people would also be perfectly comfortable if a certificate were available from the company that supplied their operating system, or their email application or webmail account. Or maybe from their bank or ISP. > - so if some government based organisation would > do what say commododoes it would send a signal > to the public that it takes privacyseriously > and I think it would encourage more people to use > smime. The actions of governments and government organisations in so many countries send signals that they are anti-privacy, or at least not pro-privacy. I think this small contradictory signal would be in severe danger of being drowned out. But now I understand what you meant. > - Private certificates, are unfortunately no > solution. Yes it ispossible with openssl to > generate them, I have done thatmyself. However > it is very difficult till impossible to convince > the main email programs, such as outlook, > thunderbird or Applemail to use them or to use > public keys sent by suchcertificates. [4] The email app I am using to write this message can (almost trivially) generate and use self-signed certificates for the email accounts it has configured. The difficulty is getting other people to persuade their MUA to accept them. > Footnotes: [1] I must add that I don't share your > general view about government based organisations. > I still hope that abuse is the exception not the > rule.. I think I mentioned in one of my other postings that I was using hyperbole to make my point. I'm not quite _that_ paranoid, but I believe in exercising a healthy skepticism. -- Best regards MFPAmailto:expires2...@ymail.com Experience is the name everyone gives to their mistakes smime.p7s Description: S/MIME Cryptographic Signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
bug-like: strange behaviour of addrevoker
Hello, I have created another key for me (higher security level) so its user ID has obviously the same name like the ones of my old key. I did this with Knoppix 7.2 (i.e. gpg 1.4.x). After key creation I wanted to add the keys to each other as designated revokers. But that didn't work as expected. After entering the command "addrevoker" I was asked to enter the user ID of the respective key. Why the user ID and not the key ID or fingerprint? Does that make any sense? However, gpg has a quite strange user ID matching behaviour here. If I enter the complete user ID Hauke Laging (Standardadresse) then it is not found. If I enter just "Hauke Laging" I get a clever error message that a key cannot be its own designated revoker... Neither 1a571df5 nor 0x1a571df5 works. Even worse: The email address doesn't work either (both ha...@laging.de and ). So I had to create a new user id (and throw the others away in order to avoid changes to the other key). With the new name it worked. I assume this is a bug as you would expect it to happen quite often that there are several keys with the same name. Probably this feature is rarely used. CU Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 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: trust your corporation for keyowner identification?
On Tue, Nov 05, 2013 at 12:40:11AM -0800, Paul R. Ramer wrote: > I don't know how I can explain it any better than I have. I think you are > confusing assertion with verification. Unless you can differentiate between > the two in this case, I don't think you will see what I am talking about. > > [...] > > I guess all I can say is that one should have a key signing policy to let > others know how he verifies keys. > > There. I said it all over again, just differently (and a whole lot more). OK, I think I understood your point. (That is, assertion is not as strong as verification.) However, I think in this case (assuming there are no more UID on key 2 than on key 1), assertions are sufficient, *because* there are two assertions, one in both ways. I mean : * Owner of Key 1 says (s)he is owner of Key 2 (through signed message saying you so) * Owner of Key 2 says (s)he is owner of Key 1 (through signed UID on Key 2) So, except in case of collusion between owners of Keys 1 and 2, I believe there is no way one can be wrong in signing Key 2 (of course, if Key 1 is signed). IIUC, your point is that verification would enable one to avoid collusion, as it is the only flaw I can see in this verification scheme. Except collusion can not be avoided in any way, AFAIK. If that is not your point, could you exhibit a scenario in which there is a signed UID on Key 2, a signed statement from Key 1 owner saying he owns Key 2, and Key 2 not being usable by Key 1 owner ? (Of course, excepting collusion, which as stated above can not be avoided.) Cheers, Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Quotes from GPG users
> Feel free to use any of my public comments on the topic, either on my > blog or on Twitter. Those are great resources I hadn't seen before, thanks for the links! What do you think about these two? I had a hard time finding quotes from your articles that fit into 130 chars, so I reworded them: "GnuPG provides encrypted email and file encryption...this technology is an integral part of the survival skills of the digital age" Source: http://www.adversary.org/wp/2012/09/20/protecting-yourself-in-a-surveillance-state/ "Scalps have been claimed in Australian politics due to forged emails, yet GPG has been able to prevent this for years" Source: http://www.adversary.org/wp/2011/08/20/preventing-political-blunders-with-digital-signatures/ > If you make a hashtag for this topic, let me know so I can point my > fellow Pirates at it all. We've got some very good people on our > social media team. Great - I am planning to use one, and I'll keep you posted. Sam. -- Sam Tuke Campaign Manager Gnu Privacy Guard 0044 78680 77871 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Sharing a card reader between pkcs11 and gnupg card?
Hello, I'm having some troubles using both a PKCS #11 accessed card (national electronic ID card) and an OpenPGP card in the same computer. I haven't really looked deep into this yet, but it looks like the smart card reader is claimed by the driver that is first started (scdaemon or the national ID card driver) and the other one doesn't see any readers. Is this the expected beahvior, i.e. I can't share one card reader between different card types without stopping/starting services when changing from one card to another? I have several card readers, so I could use two readers at the same time and I understand I should be able to dedicate one reader for one card type by configuration. But for laptop use that gets clumsy, especially when you have (one) integrated reader already in the laptop. I'm running 12.04 LTS Ubuntu with the packaged gnupg (2.0.17-2ubuntu2.12.04.3). Tapio ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm and expired certificates
>> "MFPA" == MFPA writes: Hello > There are already several private sector CAs who provide free S/MIME > certificates in the hope that punters may take one of their paid > products instead or in addition. Potential sales is their incentive to > provide some products free. What would be a government's incentive to > provide them free of charge instead of charging for the admin? And > what would a government based CA bring to the party that is not > already available? > If all we are talking about is email encryption to protect people's > email from being read in transit, a self-signed certificate takes care > of the encryption without the need for a CA. The only value in using a > recognised CA rather than a self-signed certificate is convenience for > the recipient, whose MUA is likely to automatically "trust" a > recognised CA but would need to be "told" to accept a self-signed > certificate. Ok let me try to answer this point by point. Before doing I want to emphasise that I am taking a very pragmatic point of view here.[1] - NSA (among others) has abused its resource to read email worldwide at a very large scale. - so if a lot of people, say 30 % of all users would encrypt their email, then NSA statistical approach would *not* work that smooth and this is a good thing. - so encrypting email should be easy and look trustful for a majority of users - usually public/private key based methods are considered relative secure (Even Snowden claimed that you could rely on them), this does not mean that the NSA could not read your email. They would usually try to enter your machine installing a keylogger or something like this. But this is beyond the statistical method I mentioned above. - if I understand correctly the real problem is not security of the the cipher but the authenticity of the sender and so the most common attack is a man in the middle attack. This is true for both smime and gpg. So comparing fingerprints of public key is a good thing, which most of us, I presume, don't do. - from my own experience I am convinced that smime is much easier than gpg[2] for reasons I am not going to repeat here. (I got 7 out of 10 of my friends/colleagues to use smime, but 0 of 10 to use gpg.) - one of the reasons some of them hesitated was the fact that the certificates were offered by some commercial company they did not know and trust.[3] They would have had installed it from a government based organisation, say the ministry of justice though. - so if some government based organisation would do what say commodo does it would send a signal to the public that it takes privacy seriously and I think it would encourage more people to use smime. - Private certificates, are unfortunately no solution. Yes it is possible with openssl to generate them, I have done that myself. However it is very difficult till impossible to convince the main email programs, such as outlook, thunderbird or Apple mail to use them or to use public keys sent by such certificates. [4] Uwe Brauer Footnotes: [1] I must add that I don't share your general view about government based organisations. I still hope that abuse is the exception not the rule.. [2] although pgp seems technically better, since some implementations of smime allow a relative short symmetric key [3] (Besides these companies have a certain business model and their free certificates last short and expire usually after one year.) [4] I finally managed to use them in thunderbird, but is was complicated not something the regular user would like to do. smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trust your corporation for keyowner identification?
Leo Gaspard wrote: >> You are right. Decryption is sufficient to demonstrate control of >the private key, because if he can decrypt, he can also sign. What I >said, "decrypt and sign," was redundant. > >Well... I still do not understand why decryption is sufficient to >demonstrate >control of the private key and not adding a UID (note I'm talking about >signed >UID's, not unsigned ones, of course). >Sorry. I don't know how I can explain it any better than I have. I think you are confusing assertion with verification. Unless you can differentiate between the two in this case, I don't think you will see what I am talking about. The process of certifying someone else's key involves the following: (1) He claims that a key with n number of UIDs and fingerprint of x is his key. (2) You verify his identity and compare it with the information in his UID(s). (3) You send encrypted emails to each email address in his UIDs. (4) He replies with the decrypted messages that you sent. (5) If all went well, you certify his key. In the case that we have been discussing, it is assumed that all of those steps have been followed for the first key. With the second key, only the first two steps, and part of the third, have been followed. And now you are assuming that the second key (being independent from the first) is valid without following through all of those steps simply because you have validated the first key which, according to what you are suggesting, was used to sign the second key. Simply, assertion is not verification; probability is not certainty. If you didn't verify control of the key (wasn't that the point behind signing someone's key?), then your signature on his key will be baseless. If on the other hand we were talking about a new UID on the first key, we would just need to verify control of the email address in the new UID if the UID contains the same name as the other UIDs. No one is going to stop you from signing someone's key if that person sends you an email saying, "Hey, would you sign my other key?" But if I know you sign any keys without following the same thorough verification process each time, don't expect me to assign ownertrust to you. I guess all I can say is that one should have a key signing policy to let others know how he verifies keys. There. I said it all over again, just differently (and a whole lot more). --Paul -- PGP: 3DB6D884 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
BitMail.sf.net v 0.6 - Secure Encrypting Email Client
Hello, can BitMail.sf.net as a p2p email tool for encrypted Email (and hybrid with IMAP-Email) be regarded as a reference model for research to create a secure Email Client? as it uses both, gnupg and openssl! http://bitmail.sourceforge.net/ https://sourceforge.net/projects/bitmail/files/BitMail_0.6_2088RC1/ Does anyone know, if it runs over Tor? Sincerely, Robert ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
BitMail.sf.net v 0.6 - Secure Encrypting Email Client
Hello, can BitMail.sf.net as a p2p email tool for encrypted Email (and hybrid with IMAP-Email) be regarded as a reference model for research to create a secure Email Client? as it uses both, gnupg and openssl! http://bitmail.sourceforge.net/ https://sourceforge.net/projects/bitmail/files/BitMail_0.6_2088RC1/ Does anyone know, if it runs over Tor? Sincerely, Robert ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
