Re: Unattended signing
On Tuesday 24 February 2015 01:36:25 Daniele Nicolodi wrote: > Hello Daniel, > > thanks for your reply. > > On 21/02/15 20:11, Daniel Kahn Gillmor wrote: > > On Wed 2015-02-18 13:46:19 -0500, Daniele Nicolodi wrote: > >> I have a sufficient trust in the security of the server where the > >> automated process runs, but I would like to reduce to a minimum the > >> risks. > > > > there are risks with unattended signing in general, related to what > > messages you allow to get passed to your system. I'm sure you've > > already thought about this, but i'll just put it out there in case > > someone else reading this later hasn't thought about it enough. > > I was not very clear on this: the unattended signing is performed by an > application that collects some sensible data and sends them by email > encrypted and signed. I can understand that you want to encrypt the sensible data. But why do you want to sign it? Regards, Ingo 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: German ct magazine postulates death of pgp encryption
On Sunday 01 March 2015 19:58:19 Jonathan Schleifer wrote: > Am 01.03.2015 um 17:45 schrieb MFPA <2014-667rhzu3dc-lists- gro...@riseup.net>: > >> and also gets rid of spam > >> by requiring a proof of work to send something. > > > > Surely, "proof of work" is evidence of performing some otherwise > > unnecessary CPU cycles. This wastes energy. In a system used by > > billions of people, lots of energy. > > That "wasted energy" is a lot less than the energy we currently waste on > spam, especially if you take into consideration the amount of human time > wasted. The majority of the e-mail traffic is used up by spam. And most spam is sent by bots. The spammers don't really care how much energy the bots burn. Yes, the amount of spam might decrease because the bots cannot hammer out that many bitmessages as SMTP messages per second, but your hypothesis that BitMessage would get rid of spam is unrealistic. Regards, Ingo 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: German ct magazine postulates death of pgp encryption
On Sunday 01 March 2015 23:43:25 Jonathan Schleifer wrote: > Am 01.03.2015 um 23:25 schrieb Ingo Klöcker : > > And most spam is sent by bots. The spammers don't really care how much > > energy the bots burn. Yes, the amount of spam might decrease because > > the bots cannot hammer out that many bitmessages as SMTP messages per > > second, but your hypothesis that BitMessage would get rid of spam is > > unrealistic. > > I don't really agree with that. The goal is that the proof of work for a > single message takes 4 minutes. On what kind of hardware? A high-end gamer PC? Or a low end mobile phone? > At that rate, sending spam really is not > profitable. In 4 minutes, spammers can currently send hundreds of > thousands of mails. At that rate, they can afford to send it to every > address they can find. With only one mail per machine every 4 minutes, > they really need to be careful where to send it. Let's assume they have > 1 machines (which is unrealistic - most machines are behind a dialup > connection from which no provider will accept mail). There are much larger bot nets, e.g the ramnit bot net apparently controlled 3.2 million (!) machines (see http://heise.de/-2559388, in German). And with regard to providers not accepting those mails you seem to be missing that the bots simply (ab)use the mail accounts of the bot owners. > That's only 2500 > mails a minute. If global spam were just 2500 spam messages a minute, > spam would hardly be a problem. Of course, 800,000 spam messages per minute is still many magnitudes less than now. I don't see BitMessage killing spam. But it will surely kill mailing lists. Regards, Ingo 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: Thoughts on GnuPG and automation
On Tuesday 03 March 2015 19:31:14 Robert J. Hansen wrote: > > This is definitely public information from the Snowden leaks. There > > is also quite a bit of information about other governments doing > > > similar things. Here's one example article: > If all encrypted traffic is deemed suspicious, then 99.999% of the > suspicious set -- Amazon transactions, Google searches, SMTP transfers, > instant messaging, OkCupid profiles, iTunes purchases, and more -- is > totally clean. You'd have statistically better odds by arresting random > people on suspicion of murder. The policy would be completely > pants-on-head absurd. After the recent terrorist attacks in Paris and Brussels some German politicians are again arguing that we need Vorratsdatenspeicherung (data retention, i.e. storage of all communication meta data for 6 months) in Germany to prevent such attacks. Obviously, 99.999 % of this data will be completely unrelated to terrorist attacks, i.e. totally clean as you put it. You'd have statistically better odds by arresting random people on suspicion of terror. Still this completely pants-on-head absurd policy will become reality if those German politicians get what they want. > This leads to a different question: "Is it more likely that this is the > real pants-on-head absurd policy, or that the _Forbes_ journo has > profoundly misunderstood the subject?" Well, the Guardian wrote "However, alongside those provisions [to minimise data collected from US persons; I.K.], the Fisa court-approved policies allow the NSA to: [...] • Retain and make use of "inadvertently acquired" domestic communications if they contain usable intelligence, information on criminal activity, threat of harm to people or property, are encrypted, or are believed to contain any information relevant to cybersecurity;" Full article: http://www.theguardian.com/world/2013/jun/20/fisa-court-nsa-without-warrant Specifically, see Exhibit B, Section 5 (3) a. http://www.theguardian.com/world/interactive/2013/jun/20/exhibit-b-nsa-procedures-document Moreover, see the recent article http://justsecurity.org/19308/congress-latest-rules-long-spies-hold-encrypted-data-familiar/ which claims "The Intelligence Authorization Act of 2015, which passed Congress this last December, should bring the question back to the fore. It established retention guidelines for communications collected under Executive Order 12333 and included an exception that allows NSA to keep ‘incidentally’ collected encrypted communications for an indefinite period of time." So, you are right, that the articles do not claim that the NSA collects and keeps all encrypted communication forever. Regards, Ingo 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: New "Everyman's software" from CeBIT in Germany
On Thursday 19 March 2015 09:18:03 Thomas F. Ruddy wrote: > Dear all, > > I'd be interested in hearing Werner Koch's take on this recent > innovation. Werner, you speak German: > > A new "Everyman's software" featuring certification, key servers, > currently Windows only (Linux planned), > > https://www.sit.fraunhofer.de/de/volksverschluesselung/ > > Said to be Open Source in this news-story, > > http://www.nzz.ch/mehr/digital/cebit-2015-fraunhofer-volksverschluesselung-1 > .18505017 Both links do not provide technical details. They talk about two things provided by their solution: A central PKI and some end-user-friendly software for certificate creation which automagically adds the certificate to the user's software (email client, browser, other software). I don't see any indication for a new crypto-standard. So their solution will either uses S/MIME or OpenPGP. I suspect it will be S/MIME because more software supports S/MIME out-of-the-box. ... I guessed correctly. It's based on S/MIME: http://www.golem.de/news/projekt-volksverschluesselung-fraunhofer-institut-vereinfacht-s-mime-einrichtung-1503-113011.html Moreover, at first one will have to use the eID feature of the new German personal identification card for requesting the certification of one's certificate. https://www.sit.fraunhofer.de/de/news/aktuelles/presse/details/news-article/verschluesselung-fuer-alle/ (also in German) Another crypto project is shown at CeBIT. It's also based on the eID feature. Governikus (developed for the German BSI) offers web application for certifying one's OpenPGP key with one's personal identification card. So it's basically key certification by the German government (for German citizen's only). https://www.governikus.com/de/pressemitteilungen#entry_6938266 Both services appear to be restricted to Germany. Regards, Ingo 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: PGP/MIME (Was: One alternative to SMTP for email: Confidant Mail)
On Wednesday 25 March 2015 21:06:53 martijn. list wrote: > On 03/25/2015 08:41 PM, Doug Barton wrote: > > On 3/25/15 11:08 AM, Bob (Robert) Cavanaugh wrote: > >> Doug, > >> Signature shows as an attachment "signature.asc". No evidence that PGP > >> actions were envoked. Work forces use of Synaptic PGP, so I cannot > >> tell if it is verified or not. > > > > Thanks Bob, that is interesting feedback. > > > > FWIW, I have received various other messages privately from people who > > have said the same thing ... They can see the attachment, but either > > message verification fails, or there is no indication on their side that > > it is a PGP-signed message at all. > > > > While this is strictly anecdotal evidence I would argue that it's a good > > indication that we may not be ready for PGP/MIME as the default. > > It looks like this is caused by the mailing list software (mailman). > Mailman adds a banner to the mail and therefore the mail is no longer a > valid PGP/MIME mail. I think mailman should be smart enough not to mess > with digitally signed mail (same thing happens with S/MIME signed email). Actually, mailman is that smart. mailman has put the body of the signed message together with the corresponding Content-type header as message part into a multipart/mixed container and has added the banner as second message part to the multipart/mixed container. My mail client (KMail) properly parses this "complex" message and shows the signed part and below the unsigned mailing list banner. So it's not mailman that's not smart enough, but the mail clients the other recipients are using. Mail clients showing a "signature.asc" attachment probably do not understand PGP/MIME (which isn't that unusual because only a handful mail clients support PGP/MIME out-of-the-box without additional plugins). Regards, Ingo 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: Proposal of OpenPGP Email Validation
On Monday 27 July 2015 07:55:03 n...@enigmail.net wrote: > Hi all, > > in March we discussed here > "German ct magazine postulates death of pgp encryption" > and Patrick Brunschwig proposed a way to validate email addresses > > I also had in mind: > > http://lists.gnupg.org/pipermail/gnupg-users/2015-March/052882.html > > In the past months I tried to come up with a concrete proposal. > I discussed it already with some people and > this is what I/we propose so far. > The proposal is not perfect and not completely worked out > but IMO it is ready for a broader discussion and review. This whole concept of a whitelist of "trusted validation servers" included in the email clients sounds a lot like the CA certificate bundles included in browsers and/or OSes. Who is going to maintain this whitelist? The email client developers? The OS manufactures? Who is going to certify "trusted validation servers", i.e. who is going to tell benign validation servers apart from malignant validation servers? Your proposal seems to repeat a lot of the (failed) concepts of the centralized CA approach. For this reason I think the approach is doomed to fail the same way the centralized CA approach has failed (even if everybody seems to ignore its failure). I'd rather put my bets on a DANE-based approach like https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ Regards, Ingo 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: Proposal of OpenPGP Email Validation
On Monday 27 July 2015 21:05:26 Ludwig Hügelschäfer wrote: > Hi Ingo, > > On 27.07.15 16:31, Ingo Klöcker wrote: > > This whole concept of a whitelist of "trusted validation servers" > > included in the email clients sounds a lot like the CA certificate > > bundles included in browsers and/or OSes. Who is going to maintain > > this whitelist? > > Whilelists: The OpenPGP-aware clients. There aren't so many of them, > so that's manageable. Speaking for KMail how can I be sure that somebody who claims that his validation server can be trusted can actually be trusted and should therefore be added to the whitelist? KDE avoids this problem for the CA certificate bundle by relying on the certificate bundles provided by the Linux distributors or by Mozilla. > > The email client developers? The OS manufactures? Who is going to > > certify "trusted validation servers", i.e. who is going to tell > > benign validation servers apart from malignant validation servers? > > There is a community providing keyservers (such as > pool.sks-keyservers.net). My impression is that this network is well > maintained and has worked reliably the last years. > > Why should there not be a similar community approach for setting up a > (smaller) network of validating key server proxies. Well, the keyservers do not make any claims with regard to the authenticity or the integrity of the keys. Those checks are left to the clients. I do not have to trust any of the keyservers. The validating key server proxies claim validity of the UIDs (to a certain degree). I can see myself marking such a proxy as trusted by adding it to my gnupg.conf (or to KMail's configuration). But I cannot see myself adding such a proxy to the whitelist that's shipped with KMail. Another problem I see with whitelist management is revocation in case the validation key of a validating proxy is compromised. Again, for the CA certificate bundles that's handled by the distributors and not by individual application developers. > > I'd rather put my bets on a DANE-based approach like > > https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ > > DANE requires write access to DNS. I don't see that the average > OpenPGP user has facilities and knowledge to achieve setting up the > required DNS records. If you can't convince the big mail providers > (e.g. Google, GMX here in Germany, ...) to provide a reasonable > interface for their users, I'm afraid that this will not be a success, I'm confident that the smaller mail providers who focus on security would be willing to add such an interface. Frankly, I do not care that much for the big mail providers. People who really value privacy should use mail providers that value privacy. Regards, Ingo 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: Proposal of OpenPGP Email Validation
On Monday 27 July 2015 20:19:07 n...@enigmail.net wrote: > Am 27.07.2015 um 16:31 schrieb Ingo Klöcker: > > This whole concept of a whitelist of "trusted validation servers" included > > in the email clients sounds a lot like the CA certificate bundles > > included in browsers and/or OSes. Who is going to maintain this > > whitelist? The email client developers? The OS manufactures? Who is going > > to certify "trusted validation servers", i.e. who is going to tell benign > > validation servers apart from malignant validation servers? > > I agree that this is a key issue/problem of the approach. > And indeed, I suggest to initially or by default give some trust > to some signatures. > > Note that I propose different things, though: > 1) A standard format for such validations. >This simply would help to be able to deal with any >validation approach. > 2) A way to establish such validations >by using a validating key server proxy. > 3) A whitelist. > > I am happy to only have 1) and 2) and to teach people > to trust e.g. specific servers (and to mistrust others). > > I only want to have a way to manage email validations > (a common technique where everybody wonders why this > is not supported). > This is the best I could come up with after discussing this > with several people. > And so far it would be a lot more than we have now. > It it might fix a problem which otherwise is a show stopper. > > If this is not appropriate, what do YOU propose instead > for email validation? > So many processes in this world are today based on email validation. > Do you think that in general email validation is not the right approach > or do you propose something different? I'm not against your proposal per se. In fact, I'm probably one of the few people who actually think that the email validation done by PGP.com has some value. Consequently, I am also seeing the value in your proposal. I'm just having reservations with regard to the whitelists. See my reply to Ludwig's reply. Regards, Ingo 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: Proposal of OpenPGP Email Validation
On Tuesday 28 July 2015 09:22:23 Neal H. Walfield wrote: > Hi, > > Did you consider user a proof-of-work scheme? For instance, the user > does a 1 week PoW, signs the result and attackes it to the key. These > would be refreshed about once a year. Which problem do you propose to address with such a scheme? I can see the zombie key issue being addressed by this, but this issue can as easily be addressed by 1-year-key-expiration (where the PoW consists of extending the expiration date). I don't see how a PoW scheme addresses the fake key issue. Someone who is motivated enough to create a fake key will most likely also be motivated enough to add a PoW (at least, for the first year). Regards, Ingo 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: Proposal of OpenPGP Email Validation
On Wednesday 29 July 2015 07:42:34 n...@enigmail.net wrote: > Am 29.07.2015 um 03:30 schrieb MFPA: > > Why not simplify the workflow:- > > > > 1. key reaches validation server. > > > > 2. for each UID containing an email address, validation server creates > >a copy of the key stripped of all other UIDs. > > > > 3. validation server signs that copy of the key. > > > > 4. validation server pastes the signed key into an email, encrypts the > >email to that key, and sends it to the email address in the UID. > > > > 5. user receives each email, decrypts it, and updates their local copy of > >their key. > > > > 6. user uploads key now bearing the validation server's signatures to > >a keyserver. > > > > There is still the same level of assurance that the email address and > > private key are controlled by the same entity. Advantages are:- > > c. Changes to the user's key are uploaded to the keyserver by the > >user, not by the validation server. > > Is this a real benefit? A possible benefit would be that the user can choose not to upload the validation signatures to the keyservers. With a minor change in step 1 (the key owner uploads his key to the validation server without uploading it to a keyserver) the UID validation would even work for keys which its owner does not want to upload to a public keyserver. Regards, Ingo 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: Proposal of OpenPGP Email Validation
On Wednesday 29 July 2015 01:48:54 MFPA wrote: > On Tuesday 28 July 2015 at 8:17:28 PM, in > , n...@enigmail.net wrote: > > AFAIK, there are not THAT many faked keys, but the > > problem exists especially for key parties of our > > internet world (a famous German magazine, at least one > > GPG tool, ...). The problem is that the German magazine > > takes this as a show stopper (both personally and > > publicly). I really want to have them back on our road > > for more encryption with OpenPGP. And the "publicity" > > we get from not validating email addresses is really a > > big problem (especially as fixing that problems sounds > > so easy and obvious). Thus, without fixing this, IMO > > the whole OpenPGP movement has a reputation problem. > > I understand what you are saying. I cannot help but think they are > making a mountain out of a molehill by characterising this minor > irritation as a "show stopper". Yes, he (not they!), the author of the article is doing exactly this. > Putting something in place to > counteract the issue is one approach. Would it not be an equally-valid > approach to educate them as to why it is a non-issue, which they could > then disseminate through their magazine? I think that the author of the article knows that it's mostly a non-issue. He still decided to write the article "Forged PGP Keys in the Wild" [1] and even an accompanying editorial titled "Let PGP Die!" [2]. I guess he simply got pissed because he received so many messages that were undecryptable with his real key. Luckily, there are also more sensible authors working for this magazine who write good articles about OpenPGP. I personally chose to ignore the stupid editorial. IMHO it does not deserve more attention than any other rant written by a random troll. OTOH, the article actually isn't that bad. It points out the issue with the missing validation of email addresses in UIDs making a bit of a fuss about it, but IIRC it also explains how to avoid falling into the trap of using a fake key. Regards, Ingo [1] http://www.heise.de/artikel-archiv/ct/2015/06/160_Die-Schluessel-Falle (German; needs to be bought) [2] https://www.heise.de/artikel-archiv/ct/2015/06/3_Editorial (German; free) 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: Proposal of OpenPGP Email Validation
On Wednesday 29 July 2015 14:09:54 Neal H. Walfield wrote: > At Wed, 29 Jul 2015 02:30:47 +0100, > > MFPA wrote: > > On Monday 27 July 2015 at 1:15:57 PM, in > > > > , Neal H. Walfield wrote: > > > Regarding the design: personally, I wouldn't have the > > > user follow a link that includes a swiss number, but > > > have the user reply to the mail, include the swiss > > > number and sign it. > > > > Why not simplify the workflow:- > > > > 1. key reaches validation server. > > > > 2. for each UID containing an email address, validation server creates > > > >a copy of the key stripped of all other UIDs. > > > > 3. validation server signs that copy of the key. > > > > 4. validation server pastes the signed key into an email, encrypts the > > > >email to that key, and sends it to the email address in the UID. > > > > 5. user receives each email, decrypts it, and updates their local copy of > > > >their key. > > > > 6. user uploads key now bearing the validation server's signatures to > > > >a keyserver. > > > > There is still the same level of assurance that the email address and > > private key are controlled by the same entity. Advantages are:- > > > > a. Nobody is asked to click links or reply to emails. > > > > b. The validation server does not need to manage a "stack" of keys > > > >awaiting feedback from the validation emails. > > > > c. Changes to the user's key are uploaded to the keyserver by the > > > >user, not by the validation server. > > Personally, I think c is the killer in this plan: people aren't going > to bother to upload it (assuming they even get that far)! If you replace "validation server" with "keysigning party participant" then you get one of the ways participants of keysigning parties get their signatures to the key owners. So, it's already done and people do upload their signed keys. I don't see why people should behave differently for validation servers. Regards, Ingo 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: Proposal of OpenPGP Email Validation
[Please do not CC me. I am subscribed.] On Wednesday 29 July 2015 13:07:20 n...@enigmail.net wrote: > I see no reason NOT to solve this problem, > but I see many reasons to solve it. > > Just saying "deal with it" simply means that > we place unneccesary burden on OpenPGP users. > IMO, that's a really bad approach. Sure. All I'm saying is that introducing a second centralized CA PKI does not strike me as a good solution. Actually, I think this is more of an educational or a social problem than it is a technical problem. The problem you have to solve is that people blindly trust the UIDs. You cannot counter people's ignorance about how OpenPGP and the WoT works with technical means. Regards, Ingo 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: Proposal of OpenPGP Email Validation
On Thursday 30 July 2015 08:04:28 Viktor Dick wrote: > Now that I think about it - if I search for the original author of the > c't article (j...@ct.de), who complained about getting mails that were > encrypted to some fake key, I would assume that the keys 38EA4970 and > E1374764 are both genuine, because they both have not only selfsigs. > BTW, they are both signed by different keys with the UID > 'pg...@ct.heise.de', so they already have a similar service in place - > of course I had to do a websearch to find if these keys are genuine, > which should probably be easier. I guess ideally the UID would contain a > weblink to a page that has the fingerprint and describes the service > shortly. I'm sorry to tell you that you have fallen into the trap. There is only one genuine pg...@ct.heise.de key the fingerprint of which is printed in each issue of the c't magazine. The other one is a fake. And the fact that the fake key with the author's email address is signed by different keys only means that a lot of people have signed this fake key without following the proper procedure of key validation (or that the trolls created even more fake keys to sign the author's fake key to make it look more credible). Regards, Ingo 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 to get your first key signed
On Wednesday 30 September 2015 15:58:51 Robert J. Hansen wrote: > > I create for myself a gpg key and want to get it signed > > More important than whether your certificate gets signed is who signs > the certificate, who they are connected to, and so on. > > Some people will sign almost anything. People who get a reputation > for signing anything develop a reputation for their signatures being > meaningless. Some people have very strong requirements before > they'll sign. Their signatures are often worth quite a lot of > credibility, but good luck getting them. > > The good news is this *can be done*. I promise. > > The best thing you can do right now is to get involved in the > community. Get engaged in the mailing lists (here, PGP-Basics, > Enigmail-Users are three good ones). And when you post, sign your > messages. Over time people will come to trust that your signature > connects to the real you, even if they can't promise that your name > really is David Niklas, or can't say what you look like. Additionally to what Robert wrote you should upload your key (0x9B75C2AE183660FF) to the keyservers. Otherwise, nobody can check your signatures. I tried to download it, but failed: # gpg --recv-keys 0x9B75C2AE183660FF gpg: requesting key 183660FF from hkp server pool.sks-keyservers.net gpgkeys: key 9B75C2AE183660FF not found on keyserver gpg: no valid OpenPGP data found. gpg: Total number processed: 0 Regards, Ingo 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: Trusting other keys a message was encrypted to
On Saturday 07 November 2015 17:31:38 MFPA wrote: > On Saturday 7 November 2015 at 12:30:53 PM, in > , Daniel Baur wrote: > > I don’t really understand what is the earn here. > > > > If I send a encrypted message to you and EvilPerson > > (together in the same eMail), you receive the email and > > gpg would warn you “Heh, you don’t trust EvilPerson!”: > > What would improve? The EvilPerson received already the > > email, neither you or I could do anything about that. > > Having it flagged up to me that "EvilPerson" can also read the message > may cause me to act differently in response to the message contents, > or to act differently in future dealings with the sender. As vedaal explained, anybody between the sender and you can add arbitrary fake ESK packets to the message, e.g. a packet for EvilPerson's key. So, the attacker could make you think that EvilPerson could also read the message even though EvilPerson can't. Lacking EvilPerson's private key you have no way of telling whether the ESK packet is genuine or fake. Consequently, drawing conclusions solely from the presence (or absence) of other ESK packets seems like a bad idea. Regards, Ingo 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: QC resistant algorithms?
On Wednesday 16 December 2015 13:41:00 Anthony Papillion wrote: > While I know it's not a big concern at the moment, we are well on the > way to a future that includes quantum computing. While some in the > computer science and crypto fields say we won't see a crypto breaking > quantum computer for another 30+ years, others are putting it closer > to 10 and even 5-6. > > Regardless of what the actual timeframe is, I'm wondering what work is > being done in GnuPG to implement QC resistant asymmetric algorithms? > Perhaps a better question, and I have done very little research into > this specifically I admit, /are/ there any QC resistant asymmetric > algorithms to implement or will we need to come up with something > completely different? Yes. You might want to continue your research at https://en.wikipedia.org/wiki/Post-quantum_cryptography Regards, Ingo 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: about cartoon in FAQ 10.1. 'Correct, horse! Battery staple!'
On Thursday 24 December 2015 17:02:54 Matthias Apitz wrote: > Hello, > > I do not fully understand why some 4 random words like > > Correct, horse! Battery staple! > > is a better passphrase like, for example > > Und allein dieser Mangel und nichts anderes führte zum Tod. > > i.e. some phrasing which could be memorized better? The second sentence is found by search engines (2 hits in DuckDuckGo). Don't use it or any other phrase that's has been published on the internet. A phrase of 4 random words has a high probability that it has not been published on the internet (or anywhere else). The tricky part is that you must never put your 4-random-words phrase into a search engine to check this. Instead of using a 4-random-words phrase you can use a proper sentence with equivalent entropy provided that you do not use a sentence that has been published anywhere. Come up with your own sentence. Ideally come up with a sentence that doesn't make any sense like "The horse was correct. You cannot staple batteries." This phrase might be easier to remember and has a similar entropy as the above mentioned 4-random-words phrase. Regards, Ingo 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: self signing the pub key
On Friday 25 December 2015 18:41:30 Matthias Apitz wrote: > Hello, > > I read that I should self-sign my pub key, but when I do this after > creation, it says: > > $ LANG=C gpg2 --sign-key Matthias > > pub rsa2048/AA1EF4741F9046D4 > created: 2015-12-25 expires: never usage: SC > trust: ultimate validity: ultimate > sub rsa2048/D6AD2EFF41863FE4 > created: 2015-12-25 expires: never usage: E > [ultimate] (1). Matthias Apitz (GnuPG v2) > > "Matthias Apitz (GnuPG v2) " was already signed by key > AA1EF4741F9046D4 Nothing to sign with key AA1EF4741F9046D4 > > Key not changed so no update needed. > > What I do wrong? You didn't do anything wrong. When you create a new key it is automatically self-signed. A long time ago this was not necessarily the case. Today the above advice is still correct, but probably no longer necessary. Regards, Ingo 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: BAD signatures for GnuPG Stable
On Thursday 28 January 2016 09:31:31 Aaron Tovo wrote: > Thanks for the info. > > Today I re-downloaded the .bz2 and .sig. And the verification worked > (see output below). I did file diffs between the new and the previous > downloads with 'diff' and they are identical. So I tried verify on the > previous download and it worked this time. Very confusing. I had a similarly confusing incident with some FLAC files intermittently being logged as corrupted by vlc. It turned out that I had bad RAM that lead to subtle differences in the files if they happened to be put onto the bad RAM by the kernel's file cache. Long story short, I suggest that you check your RAM. Regards, Ingo 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: Heuristics of gpg's output
On Saturday 13 February 2016 18:20:09 st...@mailbox.org wrote: > Hi, > > a few days ago I downloaded > > > http://gensho.acc.umu.se/cdimage/weekly-builds/amd64/iso-dvd/debian-te > sting-amd64-DVD-1.iso Resolving hostname »gensho.acc.umu.se > (gensho.acc.umu.se)«... 130.239.18.176, 2001:6b0:e:2018::176 > > from a secondary mirror located in Sweden. > [snip] > > #verifying the signature I downloaded from that very server > > LC_ALL=C gpg2 --verify SHA256SUMS.sign debian-testing-amd64-DVD-1.iso > gpg: Signature made Mon Feb 8 08:31:22 2016 CET using RSA key ID > 09EA8AC3 > gpg: BAD signature from "Debian Testing CDs Automatic > Signing Key " > [snip] > > So, what does that information tell us? > Would that information suffice to think that the iso file is/was > compromised? It doesn't tell us anything because the signature does not belong to the iso file. The signature SHA256SUMS.sign belongs to the file SHA256SUMS which contains the SHA256 hashes for the iso files. In order to check the ISO file you have to verify the signature of the SHA256SUMS file, i.e. # gpg2 --verify SHA256SUMS.sign SHA256SUMS and then check the SHA256 hash of the iso file against the hash in the SHA256SUMS file, e.g. with # sha256sum debian-testing-amd64-DVD-1.iso && grep debian-testing-amd64- DVD-1.iso SHA256SUMS See also section "How can I verify my download is correct and exactly what has been created by Debian?" on http://ftp.acc.umu.se/cdimage/weekly-builds/amd64/iso-dvd/ Regards, Ingo 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: A problem in the web of trust model or a gnupg bug?
On Friday 19 February 2016 15:12:34 Andrea Dari wrote: > 1) This is the general situation: > > http://pastebin.com/NXuJj2h5 > > User one is the user that i fully trust and has a revocation dated on > 18 February 2016 > > 2) Here you can see User one pbkey details: > > http://pastebin.com/g2tQKzPN > > 3) Here you can see that user three is treated with validity = full > even if it is signed after the revocation of User one key. > > http://pastebin.com/EEGXcNa2 > > Fortunately, this is not a real situation, but I tested it to > understand what happened in this cases; because i wasn't able to find > any documentation about it. Did you run "gpg --check-trustdb" after you revoked the key of User one? Regards, Ingo 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: Encoding of user ID strings
On Tuesday 24 May 2016 08:26:54 Werner Koch wrote: > On Mon, 23 May 2016 20:19, r...@sixdemonbag.org said: > > At first blush it appears the answer is "no, but most people use > > UTF-8."> > > If so that's fine, but I'll have to silently discard a number of > > user > > OpenPGP requires that the user id is UTF-8 encoded. Older PGP > versions did not care about encoding and used whatever the system > provided. Thus there are lot's of (e.g.) Müller with wrong > encodings. This is what GPA uses to fix the problem for most of the > western world's PGP users: > > --8<---cut here---start->8--- [snip] > --8<---cut here---end--->8--- And if you are interested in how KMail decoded user IDs (before we completely switched to gpgme) have a look at lines 682-755 of https://quickgit.kde.org/?p=kdepim.git&a=blob&h=59d0d50433455e45680d65deaffbccd3028f2169&hb=855053a0d5a07301e1627757abf8f8d56d9759eb&f=libkpgp%2FkpgpbaseG.cpp Interesting. The code appears to be GPL2+ licensed. I would have thought that it was LGPL2+. Regards, Ingo 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: Pinetry: window to small + make arrow keys cancel dialog + change number of allowed wrong passphrases
On Saturday 18 June 2016 14:46:06 Hauke Westemeier wrote: > Would it be possible to make the arrow keys (left, right, > top, bottom) cancel the pinetry dialog? Did you try pressing Esc to cancel the dialog? Regards, Ingo 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: Online-Entschlüsselung
This is the English GnuPG user mailing list. The German GnuPG mailing list is https://lists.gnupg.org/mailman/listinfo/gnupg-de On Tuesday 19 July 2016 17:58:33 Reinhard Irmer wrote: > Hi, > gibt es eine Möglichkeit gnupg-verschlüsselte Texte online zu > entschlüsseln um sie lesbar zu machen? Keys sind bekannt. Your question is very unspecific. Also you didn't tell us why you are looking for a possibility to decrypt GnuPG-encrypted texts online. Yes, you say that you want to make the texts readable, but why do you want to do the decryption online? There are ways to decrypt GnuPG-encrypted emails online, e.g. the browser extension Mailvelope [1], that's available for Chrome and Firefox. If you want to decrypt encrypted text instead of encrypted emails then one possible solution would be putting the text (ASCII armored) into an email and then use Mailvelope. Maybe Mailvelope even supports decrypting text without putting it first in an email. Alternatively, if you know how to write JavaScript then you could use OpenPGP.js [2] (which Mailvelope is based on) directly. Regards, Ingo [1] https://www.mailvelope.com/ [2] https://openpgpjs.org/ 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 to encrypt and sign with different keys
On Thursday 21 July 2016 12:27:20 d...@mielko.com wrote: > From: "Robert J. Hansen" >> gpg --recipient ID-A --local-user ID-B --encrypt --sign filename.txt > > Still need your help guys. The syntax listed below works (or I think > it does) but how do I verify that the file was encrypted with key > ID-A and signed with key ID-B? When I type "gpg filename.pgp" I get > the information about encryption key but nothing mentions ID-B > signing key. The file is first signed and then encrypted. gpg can only give you information about the signing key if you decrypt the file. > I am asking because recipient of the file claims that > the signing key was used to encrypt the file and that he can't > decrypt it. To prove/disprove this claim all you need to check is the encryption key(s) (which you already did with "gpg filename.pgp"). The output of "gpg filename.pgp" should contain gpg: encrypted with key, ID , created where is ID-A or the ID of an encryption subkey of the key with ID ID-A. Regards, Ingo 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: Key Discovery Made Simple
On Tuesday 30 August 2016 14:12:15 Robert J. Hansen wrote: > > A plain text copy is below. If you have comments, please send them as > > reply. > I hate to be the one to rain on this parade, but this seems like a mistake. > > > GnuPG 2.1 provides an simple but efficient solution to store a key > > under a well known URL and lookup it up via https. > > Most of our users don't run their own domains, don't have full authority > over the mail server, and don't have webservers that can deliver static > pages over TLS. A solution that depends on this trifecta of capabilities > should not be called "simple". Just getting TLS running on a webserver can > be a frustrating ordeal. > > IMO, GnuPG development should be guided by a concern for regular users, not > power users. I'd like it if we could aim new features at regular users. The web key discovery _is_ aimed at regular users. Werner's message suggest that KMail's development version does already support this new key discovery protocol which makes key discovery for users of KMail much easier. Moreover, apparently, KMail also supports publishing the user's key this way. I'm sure enigmail will soon also support WKS. Devil's advocate: "Regular users don't use Thunderbird+Enigmail, let alone KMail. Regular users either use webmail or a corporate email client like Outlook. WKS is of no use for them." Of course, setting up WKS for a domain is non-trivial and nothing regular users will do. But, hopefully, some email providers of those regular users will do it. I'm pretty sure that sane email providers like posteo.de, etc. will implement it. Devil's advocate: "Regular users don't use email providers that are not gratis. They use gmail, gmx, yahoo, etc. And corporate users use the mail server of their corporation. WKS is of no use for them." Then again "regular users" don't care for encryption at all. "Regular users" use facebook and whatsapp and God knows what else. Ironically, users of whatsapp get end-to-end encryption even though they don't care. As long as email encryption is not as easy as with whatsapp and other chat apps that sport end-to-end encryption without requiring any additional user interaction whatsoever, email encryption will never be used by regular users. (Incidentally, I'm currently reading Greenwald's No Place to Hide. The first chapter clearly demonstrates that even regular users who know that they would better use encryption will not take the necessary steps unless they do not have to take any necessary steps in the first place.) Regards, Ingo 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: Key Discovery Made Simple
On Wednesday 07 September 2016 22:20:42 Christopher Beck wrote: > Hi, > > just a (maybe) stupid question: the matching key to my recipient can be > fetched by keyservers and i determine the korrect key of all of the > (sometimes "wrong" keys") by vaidating the signatures according to the WoT. > So, what's the benefit of this new key service? It sounds much more > complicated (and un- trusworthy) than just using the WoT. The WoT won't help you if the key isn't part of the WoT. That's the whole point of the new tofu trust model and the EasyGPG project. This new key service complements the tofu trust model in that it (kind of) guarantees that the email address/user id on the key is legitimate (provided the provider of the key service is trustworthy). Regards, Ingo 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: What happened to this signature?
On Sunday 11 September 2016 21:17:31 Moritz Klammler wrote: > Today, I've posted a signed message (OpenPGP MIME) to a public > mailing list I'm subscribed to. When it was delivered back to me, > the signature was broken. I investigated the case and found out that > some silly MTA had un-escaped a minus-character in the message body > (quoted-printable) and added a blank line at the top. This is > annoying but is adequately explained by stupidity so it didn't alarm > me. Similar things have happened to me many times in the past. What > *did* alarm me is that a further investigation reveled that the > signature itself was changed, too. A possible explanation which does not involve any conspiracies would be that Gnus, for whatever reason, signs the copy of the message that is stored in the sent folder (which, I assume, is where you've got the "original, good, signature" from) separately from the copy of the message that it sends. Regards, Ingo 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: Test Mail
On Thursday 05 January 2017 15:56:18 Roger wrote: > Great. However I had no idea my mailing list post finally made it to > the mailing list, as the mailing list did not send a copy of my post; > even though this option is activated within the mailing list > settings. As others have pointed out in the past, that's due to Google thinking that they know better than you how you want your email to be handled. Gmail discards the copies of your own posts received from the mailing list because those posts are already in your sent-mail folder. Regards, Ingo 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: SHA1 collision found
On Thursday 23 February 2017 23:38:36 Leo Gaspard wrote: > On 02/23/2017 09:00 PM, Robert J. Hansen wrote: > > [...] > > > > To which I said, "Create two keys with the same fingerprint. Sign a > > contract with one, then renege on the deal. When you get called > > into court, say "I never signed that, Your Honor!" and present the > > second key. This collision pretty much shatters the > > nonrepudiability of SHA-1 signatures." > > > > To which Peter quite reasonably answered that the other person has a > > copy of the public key which was used to sign the document > > originally. Why should the fraudster's denial be believed? > > > > The answer is that to enforce a contract (at least here in the > > United States) you must be able to prove, based on a preponderance > > of the evidence, that the other person entered into a contract with > > you. So imagine this conversation: > > > > PLAINTIFF: "Your Honor, the defendant reneged on a $10,000 contract. > > Make him pay up." DEFENDANT: "I never signed anything, Your > > Honor." > > PLAINTIFF: "I have his key, it's right here." > > DEFENDANT: "That's not my key. This is my key." > > PLAINTIFF: "Of course that's what he claims! They have the same > > SHA-1 fingerprint! He did that in order to deny his signature!" > > JUDGE: "So these keys are uniquely identified by the fingerprint?" > > (both parties agree) > > JUDGE: "And you have two keys that are identified by the same > > fingerprint?" (both parties agree) > > JUDGE: "And there's no way to tell which key is real?" > > (both parties agree) > > JUDGE: "Then we're stuck. There's no reason to prefer one key over > > another. Plaintiff, you have failed your burden of proof in > > establishing the defendant signed the contract." > I'd like to respectfully disagree on this point. SHA1 is currently > vulnerable only to collision attacks, which means that in order to > have two keys with the same fingerprint they both have to be created > by the same person (up to a random collision). Thus the defendant. > And this is enough to prove that he did sign the contract with the > key he claims he doesn't own. > > Is there any flaw in this logic? The second key the defendant created won't have his name as user id. Moreover, after creating this second key he will have disposed of the private key (and after uploading the public key to a keyserver probably also of the public key), so that there's no proof that he was ever in possession of this key. Regards, Ingo 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: Issue with --sign option
On Saturday 17 August 2013 06:56:45 Tiwari, Ashish wrote: > I have generated a new gpg key, but I am having the below problem. > > echo |usr/local/bin/gpg --no-tty --passphrase-fd 0 -o > /apploatr/.gnupg/ashish.pgp -sign --encrypt -r Ashish > /apploatr/.gnupg/test.txt Does the following work? usr/local/bin/gpg -o /apploatr/.gnupg/ashish.pgp --sign --encrypt -r Ashish /apploatr/.gnupg/test.txt Regards, Ingo 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: Recommended key size for life long key
On Saturday 31 August 2013 11:46:31 Ole Tange wrote: > The FAQ > http://www.gnupg.org/faq/GnuPG-FAQ.html#what-is-the-recommended-key-s > ize recommends a key size of 1024 bits. > > Reading http://www.keylength.com/en/4/ I am puzzled why GnuPG > recommends that. > > Why not recommend a key size that will not be broken for the rest of > your natural life? (Assuming the acceleration of advances in key > breaking remains the same as it has done historically, thus no attack > is found that completely destroys the algorithm used). > > I just generated a 10kbit RSA key. It took 10 minutes which is long to > sit actively waiting, but not very long if you are made aware it will > take this long and just leave it in the background while doing other > work; and to me 10 minutes (or even 10 hours) is a tiny investment if > that means that I do not loose the signatures on my key by changing > key every 5 years. Now try sending a message signed with this key to yourself. And then try verifying the signature on this message. And then imagine doing the same on a mobile phone with a processor that is 10 times slower than that of your PC. I'm pretty sure that this will make you realize that a 10kbit RSA key is a PITA for everybody, for you when you sign messages or other people's keys and for others when they need to verify your signatures. Once you've realized this you might understand the recommendation in the FAQ. BTW, the FAQ recommends creating a 1024 bit DSA key; IIRC this is more or less equivalent to a 2048 bit RSA key. Regards, Ingo 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: Recommended key size for life long key
On Saturday 07 September 2013 23:35:08 Ole Tange wrote: > On Sat, Aug 31, 2013 at 11:46 AM, Ole Tange wrote: > > Why not recommend a key size that will not be broken for the rest of > > your natural life? > > Thanks for all your feed back on the list. I have now summed up the > concerns raised on the list on > http://oletange.blogspot.dk/2013/09/life-long-key-size.html > > Feel free to let me know if you feel I have left out important > concerns. I see you have checked the influence of large keys on the CPU time needed to do key operations on different hardware. But key operations with large keys not only cost lots of time (see your numbers on low end hardware), but also energy. The additional energy consumption might not be relevant ecologically, but I'm pretty sure it's relevant for the battery life of your and your communication partners' smart phones. In particular, if you and your communication partners use equally large keys and encrypt each and every email, SMS, chat message, etc. Obviously, those concerns might be irrelevant in pratice (e.g. because nobody uses encryption anyway). Regards, Ingo 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: Recommended key size for life long key
On Sunday 08 September 2013 10:29:18 Ole Tange wrote: > On Sun, Sep 8, 2013 at 12:06 AM, Ingo Klöcker wrote: > > On Saturday 07 September 2013 23:35:08 Ole Tange wrote: > >> On Sat, Aug 31, 2013 at 11:46 AM, Ole Tange wrote: > >> > >> http://oletange.blogspot.dk/2013/09/life-long-key-size.html > > > > but I'm pretty sure it's relevant for the > > battery life of your and your communication partners' smart phones. > > In particular, if you and your communication partners use equally > > large keys and encrypt each and every email, SMS, chat message, > > etc. > Assuming a new smartphone runs at 1 GHz with GnuPG 2.0 then > decryption+verify or sign+encryption will be in the order of 10 > seconds if both sender and receiver use 10kbit keys. So we are talking > about 10 seconds per RSA encrypted message. Potentially lower if the > phone is multicore and GnuPG's RSA implementation supports > parallelized RSA operations. > > If RSA is only used to negotiate the initial session key, then I would > reckon the 10 seconds is hardly noticeable from a battery > perspective. My old Nokia N900 with wifi on will let you > sign+encryption 657 messages with 10kbit keys on a full battery using > GnuPG 1.4.6. With GnuPG 2.0 that would be in the order of 1000 > messages per charge. > > So where your concern really matters would be for high volume messages > (100 per day or more) that are all RSA encrypted and are used on > battery operated slow devices. Apart from email, can you mention any > app that works like that today? Some chat software (on PCs) uses GnuPG for encryption, but I'm not sure whether they use RSA only for the initial key exchange or for every chat message. Not having a smart phone I have no idea whether there are similar apps for smart phones. Having said this, in view of Snowden's disclosures, there's definitely a need for such apps. > If I am to include the battery perspective and speculations on what > apps that _could_ be made, I should probably also include what would > happen if smartphones get a cryptochip included (which would bring RSA > operations into the millisecond range - thus rendering the battery > concern moot). Using a cryptochip might not only render the battery concern moot, but this whole discussion about life long keys because even a 1mbit RSA key is useless if the session keys created by the cryptochip are easily guessable by the NSA. Regards, Ingo 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: Sign key and export for each UID
On Monday 16 September 2013 11:57:04 Doug Barton wrote: > The way that your signer did it is _a_ standard way to do it. CAFF is > a very popular program for that, and there is another here that is > also pretty good: http://www.phildev.net/pius/news.shtml > > I have another philosophy that works for me because I prefer not to > sign uids that are not valid. I send encrypted e-mail to each uid > with a pseudo-random string and ask the person to send me back the > string in a signed message. That allows me to determine if the person > has control of all 3 elements of the uid; the e-mail address, > private, and public keys. CAFF (and apparently also PIUS) achieve same: A signed UID is sent encrypted to the UID's email address. The signature on the UID can only be retrieved by a person who controls the email address and the private key. What do you mean by having control of the public key? How does your workflow verify that the person has control of the public key? AFAICS the public key is not needed for anything in your workflow. > As a pleasant side effect it also gives me > a chance to judge their competence with PGP, which allows me to > assign a better trust value to folks I did not previously know. Granted, this is an advantage your workflow has over CAFF, but I'm not sure it's worth the additional work of verifying all replies and then selectively signing UIDs. I've been there and have done this, but CAFF is just a lot less of a hassle without losing much (if anything). Regards, Ingo 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 to find and verify a trust path?
On Monday 16 September 2013 23:00:22 Peter Lebbing wrote: > On 16/09/13 22:37, Philip Jägenstedt wrote: > > Too bad. I guess one could do it by starting at the destination and > > following signatures back using a shortest path algorithm and a lot > > of requests to the keyserver, though. > > Dijkstra's shortest path algorithm would amount to a breadth first > search. Keyserver operators might not like that, I dunno. > > > How would an attacker create n independent paths without deceiving n > > people? > > Er. by creating n keys and uploading them to the keyserver? I thought the same, but that won't work. The independent paths need to be completely disjoint (except for start and end point) _and_ they all need to start with Philip's key. The attacker would have to trick Philip into signing all n keys. Or he would have to trick n people whose keys Philip has signed (directly or indirectly) into signing his n keys. Regards, Ingo 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 to find and verify a trust path?
On Tuesday 17 September 2013 11:38:55 Peter Lebbing wrote: > On 17/09/13 11:07, Peter Lebbing wrote: > > > The independent paths need to be completely disjoint (except for > > > start and end point) _and_ they all need to start with Philip's > > > key. > > > > AFAIK, there is no such requirement in the Web of Trust. I've never > > heard of it. > > Euh... apart from the part where you said they need to start with > Philip's key. I didn't trim the quote far enough :). I meant there is > no requirement that the paths are independent. True. There's no such requirement in the Web of Trust. But Philip's question > > > > > How would an attacker create n independent paths without > > > > > deceiving n people? (which you snipped away in your reply) specifically requires the path to be independent. And that the n independent paths have to connect Philip's key and the key Philip wants to verify is an implicit requirement. Of course, the attacker could create n keys all with his correct name. Then nobody would have to be deceived because there's nothing wrong about those keys. But IMHO that's not a convincing answer because I wouldn't trust n paths all involving keys from the same person more than 1 path involving a key of that person. Of course, if somebody blindly trusts gpg to do the right thing then he probably deserves to be deceived. Regards, Ingo 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: gpgsm and expired certificates
On Saturday 02 November 2013 19:48:39 Uwe Brauer wrote: > >> "MFPA" == MFPA writes: >> Hi >> On Sunday 27 October 2013 at 2:46:05 PM, in >> , Uwe Brauer wrote: >> >> Isn't the NSA "a government based organisation?" Surely >> guilt-by-association renders every government based organisation >> just >> as nefarious as the NSA. > > Your point being? > > I presume it goes like this: NSA is "a government based > organisation" doing, among other things, violations of civil rights. > > So any other government based organisation cannot be trust, end of > argument. > > Well I just talked about a service, which provides certificates to > its citizen. That means it signs a public/private key pair, which is > generated by the, hopefully open source, crypto module of your > browser. > > So either you claim to have evidence that this modules have been > hacked and the key pair is transferred to some of these evil > organisations or I really don't see your point. Since I had exactly the same thought as MFPA (namely that the NSA is a goverment based organization), I'll explain my thoughts (which could be different from MFPA's point). You, Uwe Brauer, wrote: > I would prefer a government based organisation which provides this > service to its citizen (especially because of all which was lately > revealed about the NSA) where "this service" refers to the service a commercial, not goverment based CA like comodo offers. I interpreted "especially because of all which was lately revealed about the NSA" to refer to the NSA's ability to forge certificates issued by commercial CAs (e.g. by forcing the CAs to provide such a certificate). Now my thinking was that the NSA (or some other country's secret agency, e.g. the German BND) probably wouldn't have more problems to get forged certificates if they were issued by a government based CA. OTOH, you wrote the above in reply to Werner's > The business model of most CAs is to sell you a subscription by > setting the expiration time very low so that they can ask after a > year for another fee to create a new certificate. Here it does not > make sense to create a new private key every year. So, your point/hope probably was that a government based CA wouldn't have such a business model and would instead offer this service gratis to the people (so that more people would be protected from the NSA reading their mail). If this was your point then apparently I didn't see it when I first read your message. Regards, Ingo 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: Implementation idea of CURVE25519 for gnupg 2.1
On Friday 15 November 2013 21:33:08 Mark Schneider wrote: > Hi, > > There is GPL 3 based implementation of CURVE25519 called Pretty Curved > Privacy (pcp1). > http://www.daemon.de/PrettyCurvedPrivacy > > What do you think about using parts of the ppc1 source code to implement > such functionality into gnupg 2.1? FYi: Werner already implemented Ed25519 (based on Curve25519, but with a different signature algorithm) in GnuPG: http://www.ietf.org/mail-archive/web/openpgp/current/msg07194.html Regards, Ingo 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: Proof of possession when exchanging keys
On Friday 15 November 2013 11:39:30 Phil Calvin wrote: > On Nov 15, 2013, at 11:02, "Thomas Harning Jr." wrote: > > The general practice I follow is to verify fingerprint and ID separately > > then, in order to verify control of email address and private key, send > > the signed ID encrypted to the provided email address. > > That makes perfect sense. That's the approach I took on the most recent key > I signed. > > What attacks are mitigated by verifying control of the secret key, though? I > am having a hard time grokking the benefit for someone whose ID you have > verified to present and fingerprint a key which she does not control. By signing the UIDs connected to a key you certify that the UIDs (most commonly email addresses) belong to the same person. You and people trusting your certifications could be lead into sending an encrypted message meant for the owner of an email address not belonging to the key owner to one of the email addresses of the key owner. It may seem a bit far-fetched that somebody would use one of the email addresses of the key owner instead of the email address of the intended recipient, but a possible reason for this could be that the email address of the intended recipient stopped working (e.g. because he changed his ISP or his employer). Regards, Ingo 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: Renewing expiring key - done correctly?
On Tuesday 03 December 2013 19:03:13 Robert J. Hansen wrote: > On 12/3/2013 6:20 PM, Hauke Laging wrote: > > Imagine a certificate which is always prolonged for just one day. If > > this gets compromised then it will not be prolonged any more (at > > least not by its owner but we all love our highly secure offline > > mainkeys, don't we?) so everyone will notice that within hours. > > 1. The attacker can just extend the validity himself. He's > successfully compromised the key, after all. > > 2. As a consequence of #1, no one will notice. In your quotation you've snipped away too much of Hauke's message. Hauke gave two scenarios. In the second scenario > > b) the key has been compromised and cannot be revoked (because the > > owner has lost access to the secret mainkey and has neither a > > revocation certificate nor a (usable) designated revoker) your assertion is correct. In the first scenario > > a) the key has been compromised and revoked and you don't know that > > (because your last certificate update was before the revocation > > publishing) it is incorrect because the attacker cannot extend the validity of the revoked key. Regards, Ingo 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: Renewing expiring key - done correctly?
On Thursday 05 December 2013 19:47:57 Hauke Laging wrote: > Am Do 05.12.2013, 19:30:07 schrieb Ingo Klöcker: > > your assertion is correct. > > > > > > In the first scenario > > > > > > a) the key has been compromised and revoked and you don't know > > > > that > > > > (because your last certificate update was before the revocation > > > > publishing) > > > > it is incorrect because the attacker cannot extend the validity of > > the revoked key. > > You misunderstand the attack. No. I don't. :-) The attack involving control over the system time came up later in the thread. For every countermeasure there is an attack that circumvents this countermeasure, bribery and torture probably being the most effective attacks. But this doesn't mean that your argument for using key expiration, i.e. to "force" the users of the key to update the key regularly, is wrong. It just means that your argument doesn't work if your adversary can control your system clock. OTOH, your argument works if the key has been compromised by an adversary like me and you, e.g. by a colleague of the key owner (who does not happen to work for a three letter organization). Regards, Ingo 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
Promoting the usage of OpenPGP (was: Re: Renewing expiring key - done correctly?)
On Thursday 05 December 2013 19:47:57 Hauke Laging wrote: > BTW, OT: May I point you at this? > https://bugs.kde.org/show_bug.cgi?id=318005 > https://bugs.kde.org/show_bug.cgi?id=326476 > https://bugs.kde.org/show_bug.cgi?id=326477 I'm sometimes pondering a different approach. I'm quite pessimistic about being able to educate the general population about OpenPGP. Therefore, I'm wondering whether it wouldn't be better if we, the developers of Free Software mail clients, made the usage of OpenPGP (or S/MIME) for email as transparent to the users as possible. Ideally, the users wouldn't even have to notice that they are communicating via encrypted email. Unfortunately, I think email is a lost cause because there are so many different mail clients that will never support encryption. I think we have a much better chance to replace email with something new that has end-to-end encryption (and probably also authentication) built in than we have to fix email. Regards, Ingo 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: Promoting the usage of OpenPGP
On Friday 06 December 2013 10:10:41 Werner Koch wrote: > On Thu, 5 Dec 2013 21:38, kloec...@kde.org said: > > Unfortunately, I think email is a lost cause because there are so > > many different mail clients that will never support encryption. I > > think we > > Please name those email clients. I am not aware of any mainstream > mail cleint without encryption support (yes, Notes, but that is not > mainstream). The real problem are webmailers. Exactly. Webmailers was what I was thinking about. And probably mail clients used on mobile devices. I don't know how many of those support encryption. > > have a much better chance to replace email with something new that > > has end-to-end encryption (and probably also authentication) built > > in than we have to fix email. > > There are some groups proposing this for some time now. A few of them > have an obvious business case for their new system. > > However, mail will stay with us because everything works by mail. > Mail has replaced letters, folder and files cabinets. You can't > replace that with an online communication system, much as it is not > possible to replace documents with phone call. Mail is not done for > the communication but for documenting transactions. Where? AFAIK, in Germany, we still have to send faxes or registered letters with reply advice because email is not approved. (Well, maybe de-mail or whatever it's called is, but who's using that?) > A business needs > to retain most of its communication for 10 years and more. In > Germany you are even required to archive certain private mails for 2 > years (invoices by craftsmen). The online media is by design not > able to fulfill such requirements. What do you mean by "online media"? Is de-mail such an "online medium"? > Well, some are saying “you may send an attachment” using our system. > But in this case you are back to standard mail with just a different > transport layer (i.e. no RFC-821). RFC-822 will stay with us and it > is actual trivial to secure. Given that anonymity is very hard to > impossible to achieve using the current internet infrastructure, I > would also claim that SMTP will stay for the foreseeable future. > STARTTLS is security wise not very different from https and has a > chance to work reliable as soon as we have working mechanism to > replace PKIX. I don't dispute that. And yes, key exchange is the real challenge. Regards, Ingo 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: sign encrypted emails
On Sunday 05 January 2014 14:04:49 Peter Lebbing wrote: > [1] By the way, your statement might not even be true; how often have > you written "See the attachment" and then forgetting to attach the > file? I have done it countless times. I bet Hauke never forgot to attach the file because he is using KMail which warns him about this. Recent Thunderbirds also shows such a warning. (I suppose this also counts as technical solution for a social problem. ;-) If one always attached the file the second one wrote "See the attachment", then one'd never forget to attach it and the technical solution wouldn't be necessary.) Regards, Ingo 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: checking signature of pgp mime
On Thursday 03 April 2014 15:06:57 Tim Prepscius wrote: > Greetings, > > So as I said before, I'm working on a pgp base web mail app: > https://github.com/timprepscius/mv > > I am having problems validating the signature of a small percentage of > test cases. However GPG with apple-mail says the signatures > checkout, soo... I'm obviously doing something incorrectly. KMail also says that the signature matches. Looking at the two pastbins, it seems that you are trying to convert OpenPGP/MIME-signed messages to RFC 4880-style cleartext signed messages in order to verify the signatures. This transformation is not always possible. In this particular case the signed data contains trailing whitespace. If the sender (resp. his mail client) would have followed the RFC 3156 then this trailing whitespace wouldn't be there. But it's there. And that's what causing the trouble because the signature of a cleartext signed message is computed with trailing whitespace removed. That's why the signature does not match. You have to verify the signature the way one verifies signed data with detached signature. Regards, Ingo 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: GPG and BCC
On Thursday 10 April 2014 18:03:17 Nicolai Josuttis wrote: > Can anybody answer/explain whether there is or might be a problem or > risk if using encryption combined with bcc addresses with GPG? > And if so, what should I do/avoid to run into this problem? > I am especially interested in an answer which helps me to understand > WHY there is or might be a/no problem. > In fact: > - Does GPG reveal the number of BCC rcipients? > - Does GPG reveal BCC identities (partially)? Those questions have already been answered by the others. > If the answer depends on the browser or other components, please tell > me. > > The reason I ask is because for a UI to be programmed on top of GPG > I want to understand which warnings I should raise or > what I should deny > when users try to send encrypted emails also to bcc receivers. Apart from using the '--throw-keyids' option you could send multiple copies of the message. One copy for the public recipients which is encrypted with the keys of all public recipients (To, Cc). And n copies for the n Bcc recipients where each copy is encrypted with the key of one Bcc recipient. That's what KMail does. Regards, Ingo 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: GPG and BCC
On Thursday 17 April 2014 11:36:59 MFPA wrote: > On Friday 11 April 2014 at 9:59:21 PM, in > , Ingo Klöcker wrote: > > Apart from using the '--throw-keyids' option you could > > send multiple copies of the message. One copy for the > > public recipients which is encrypted with the keys of > > all public recipients (To, Cc). And n copies for the n > > Bcc recipients where each copy is encrypted with the > > key of one Bcc recipient. That's what KMail does. > > A few years ago when trialling various email programs, one that I > tried encrypted an individual copy for each recipient when you sent an > encrypted mail with multiple recipients. Sure. One could do this. But I don't see the point of encrypting an individual copy for each To/Cc recipient. The only additional information a single message encrypted for all To/Cc recipients gives the recipients is the list of key IDs of the other recipients. Under very special circumstances this could be undesirable, but under those special circumstances one probably also doesn't want to have all recipients listed in To/Cc. So, we are back to using Bcc or sending completely indiviual messages. Regards, Ingo 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: best practice for pgp mail service, revoking keys
On Thursday 24 April 2014 21:07:54 t...@piratemail.se wrote: > Thank you for your responses. I'm still mulling over what to do. Your > input has been revealing. > > I think I'm leaning towards the 1 year key, with a 1 year "fallow" > time. For the reasons implied by Daniel, (which I interpolated). I > would not want another user grabbing an e-mail account and posing as > a previous user. I would not allow re-usage of email addresses because even a 1 year "fallow" time might be too short, e.g. for some services you might get an invoice once a year and, since you are obviously concerned about privacy, you surely wouldn't want this message to be sent to the wrong person. IMHO used email addresses are burned for all eternity (unless, some time in the future, there will be other mechanisms, e.g. ubiquitous end-to-end encryption, that prevent the disclosure of private information in emails that have gone astray). > But at the same time, when a user renews a key, will the existing WoT > signatures become invalid? No. Each signature has an individual expiration date (or none). When you sign a user id which has an expiration date then gpg proposes to use the same expiration date for your signature, but you are free to set another expiration date (including no expiration) for your signature. > If they do, perhaps it would be better to > instead have the designated revoker (me) as described by David. If > the co-signers don't become invalid, this seems strange to me. > > -- > > I have also been thinking about how this works into the WoT. Because, > as Daniel and one other expressed, anyone can upload a key for a > user. How to differentiate. > > I'm thinking to do this: > 1. User registers, automagically creates pub/priv key. > Tells me about pub key. > I sign the pub key with the site key. > All keys from the e-mail site will be self-signed and as well have the > signature of the e-mail site key. As mentioned above you could use a 1-year-expiration for the certification of the user's key with the site key. > 2. Users can "trust", or "be-friend" another email+key. > When this happens they will sign the other's key, and will also mark > that key as the prefered encryption key. Maybe that e-mail address > will as well be placed on a white list of some sort. Definitely makes sense. > 3. The algorithm which picks the "best & default encryption key" for > an address, will, instead of picking the key with the latest date > (which it does now), will pick the key with the most number of > co-signers. (and of course which isn't revoked, or expired) Given 2. you should always take the prefered key first. If there's no prefered key, then I'd follow gpg's practise and take the newest valid key (and ask the user whether he is okay with the choice). > Does this sound about right? > > > In existing gpg mail programs, when evaluating the trust level a key, > does gpg see if there is a path between yourself and that key, "I > didn't sign it, but this other key which I already trust, signed this > other key, which signed the key I'm looking at." Or do you count > signatures. Or both? KMail relies on gpg to make the best choice. I suggest to do the same. I see no reason to invent a new trust-scheme. Regards, Ingo 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: Best practices for securely creating master RSA key
On Saturday 10 May 2014 01:23:57 Tomer Altman wrote: > To whom it may concern, > > I recall reading somewhere some best practices for creating one's > initial RSA key pair that they intend for building their Web of > Trust. I think the recommended steps were: > > 1. Find a computer that you think is relatively free of malware > 2. Download a Live Linux distro CD/DVD/USB, and verify its signatures > to make sure you are not installing a tainted version > 3. Launch the verified Linux distro. > 4. Use GnuPG to create private RSA key, and two subkeys (signing & > encrypting) > 5. Strip the master private key from the keychain, saving on an > encrypted medium (e.g., encrypted USB stick) And/or store it on a smart card. > 6. Create necessary revocation certificates, also save on encrypted > USB stick Storing the revocation certificate together with the master private key is suboptimal. If you lose the USB stick or it stops working then you won't be able to revoke your master key. I suggest printing the revocation certificate on a piece of paper and storing it at a safe place. You could even print multiple copies and store them in different safe locations to reduce the risk of losing it through fire/water/theft/whatever. The worst that can happen if somebody gets hold of one of the copies is that he can revoke your key. That'd be annoying, but your data would still be protected. > 7. Copy over GnuPG keychain without master private key to work > computer, personal laptop, etc. And/or copy the private subkeys to a smart card. > 8. Store encrypted USB stick somewhere safe Regards, Ingo 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: Reiner SCT Cyberjack go : Display languge question
On Thursday 29 May 2014 10:03:52 tux.tsn...@free.fr wrote: > Hello All, > > Here the official Renier SCT support answer : > > "This product is mainly developed for German market, therefore it is > necessary to keep the Secoder2 specs. All PIN messages are definied > there, so they will ALWAYS be in German. The cardreader are primary > for German Market, so the language will be German. It is not possible > to use English Secoder2 text. And we will and can not change this." > > It's very shame, because if this company done a little effort to > translate display messages min in English, not very hard to do it, > and little more verbose as normal usage (same as other cardreader), > it will be a nice very small pinpad cardreader, but it's the life ... IMHO, the real shame is that this device (as probably most other similar devices) doesn't have an open-sourced Free Firmware. (Or does it?) Regards, Ingo > - Mail original - > De: "tux tsndcb" > À: gnupg-users@gnupg.org > Envoyé: Lundi 26 Mai 2014 14:26:00 > Objet: Reiner SCT Cyberjack go : Display languge question > > Hello all, > > I wanted to know, if people who use this cardreader have english > language on display. > > Because on display I've done this configuration : > > Menu -> Setting -> Language -> German > > >English I've selected it > > but all display messages are in German for exemple when cardreader > boot and a smartcard is plug on it : > > Bitte Karte > entnehmen > > so no in English > > Other questions : > > - On display I can see in permanence : Secoder 2 V2.2.1, is it > possible to don't see It ? > > - On my Vega cardreader, when I use it, I can see these : > > - When no smartcard insert : > Insert card > > - when PIN code is requested : > Enter PIN > 3 retries left > > - when I don't put PIN code on time > Time Out > > But with this cardreader I see nothing only PIN when PIN code is > requested and nothing for the other things > > Thanks in advance for your feeback with it. > > Best Regards > > > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users 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: adele
On Thursday 12 June 2014 09:06:05 Mark H. Wood wrote: > On Thu, Jun 12, 2014 at 09:34:51AM +0200, Werner Koch wrote: > > On Thu, 12 Jun 2014 02:45, jer...@jerome.cc said: > [snip] > > > > any copyright issue we might have to use another name, at least > > > until we get approval to use the traditional Adele name from the > > > copyright holder.> > > A name is not copyrightable, in particular not a common name like > > that of Peter's Grandma. In any case, if it is really GPL, it is > > not a problem at all. > > Copyright isn't used for names, but a name in association with a > business or service can, in some jurisdictions, be protected by > *trademark* or *service mark*. In Germany resp. the EU "Adele" does not seem to be a registered trademark for computer software. (I've quickly checked this via https://register.dpma.de/DPMAregister/marke/einsteiger?lang=en.) Regards, Ingo 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 to verify a signed mail (silly question maybe, sorry ;)
On Wednesday 02 July 2014 19:38:41 Linux DEBIAN wrote: > Hello all, > > > now I use KMail post client where it's alla automatically checked > but when I am on the webmail where the signing and verifying is not > "built-in" supported and when I receive an e-mail with an attchement > "signature.asc", how can I verify the signature, please ? I think you've left out a few constraints. When you are on webmail, what tools are available to you? It seems obvious to me, that Linux is not available to you (because otherwise you'd most likely also have KMail available). What else is not available to you? What is available to you? Why do you only have webmail? Regardless of your answers to those questions, my suggestion is to switch to a webmail solution with built-in support for OpenPGP/MIME. Alternatively, if you do not want to make a complete switch, then still create an account at a webmail provider that does support OpenPGP/MIME and then forward signed messages for verification to this webmail solution. Regards, Ingo 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: [fa...@ariis.it: Re: How to verify a signed mail (silly question maybe, sorry ; )]
On Thursday 03 July 2014 08:49:12 Linux DEBIAN wrote: > Hello, > > thanks for your reply. > > Maybe I do soemthing wrong and following the instructions, still > receiving 'bad signature'. I'm not surprised. It seems that Francesco Ariis has left out a crucial step (or you have removed it when you quoted his message). RFC 3156 reads = Upon receipt of a signed message, an application MUST: (1) Convert line endings to the canonical sequence before the signature can be verified. This is necessary since the local MTA may have converted to a local end of line convention. (2) Pass both the signed data and its associated content headers along with the OpenPGP signature to the signature verification service. = > It's my mail and my signature (for testing purposes) so I'm sure > signature is ok, btw. > > Does it matter if in the beginning of the part is: > > Content-Type: Text/Plain; > charset="utf-8" > Content-Transfer-Encoding: quoted-printable No. > and the whole copied part ends with: > > =3D It shouldn't matter. > Also, when I copy the text, when using Kate (text editor for KDE, > Linux), I always use utf-8 for opening/saving documents. > Shall I change to another charset ? > There is no choice for exactly 'ascii', just e.g. western european ISO > 8859-1 and many others. The charset should be irrelevant because quoted-printable encoded text does not contain any non-ASCII characters. Concerning (1) in the excerpt of RFC 3156 quoted above, you have to tell Kate to switch the line endings to Windows line endings (Tools->End of Line->Windows/DOS) before saving the text to a file. Or run unix2dos on the saved text to convert the line endings on the command line. If you do all of this correctly, then you might be lucky that the signature verification succeeds. You might not be so lucky when the next signed message arrives. IMHO trying to verify an OpenPGP/MIME-signed message by hand is at most a nice exercise, but it's certainly nothing one should do regularly. Regards, Ingo 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: ./configure ...error
On Saturday 05 July 2014 21:05:36 Yahoo wrote: > Further to my last email I ran the script > sh gpg-error-config --version and it gave 1.10 so this is why its > not being accepted ? I have installed version 1.13? I don't know how > this happens but what should i do to get an installation of > gpg-error-config of 1.11 or greater ? What distribution are you using? How did you install gpg-error 1.13? Regards, Ingo 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: GPG4Win question
Hi David, On Saturday 12 July 2014 09:02:09 da...@gbenet.com wrote: > > > > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > [snip] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - class="moz-txt-link-freetext" > href="http://www.enigmail.net/";>http://www.enigmail.net/ > iJwEAQECAAYFAlPA62MACgkQPsGd8ZKwe+f+pgQAlV7P/TqmX47kU5dt3xrW4c > Jg > rpFuCr1KVKUJHE4WOvv1LI/FN9QUejK9M1+7OmfO5xpBrJDbOeiJMovwaTFQ4aEz< > br> > FITE3eiNGt57hhuZp/F5LOdLTnuaVx23mTXAHSV4fGQxtjTGSgtK9CPi2I5X6Uol > LUBORhgPEu2L0pSUDd8= > =P4Ev > -END PGP SIGNATURE- > > > You are sending your mails in HTML format and you are trying to use inline PGP signatures. This doesn't work. The HTML formatting breaks the inline PGP signatures. There are two ways to make it work: a) Tell Thunderbird to send plain text messages instead of HTML messages. b) Tell the Enigmail-plugin to use OpenPGP/MIME instead of inline OpenPGP for signatures. The third option you have is to do a) and b), i.e. send OpenPGP/MIME- signed plain text messages. That's what I do. Regards, Ingo 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: symmetric email encryption
On Friday 18 July 2014 02:03:24 Hauke Laging wrote: > Hello, > > is there any OpenPGP mail client which supports symmetric encryption? KMail does not. At least, KMail does not support creating such messages. It's possible that KMail would be able to read such messages since the decryption is delegated to gpgme. And for the odd message (containing an inline PGP MESSAGE block) sent to this list gpg-agent asks for a symmetric encryption password when I open the message in KMail. > I think that would be a nice feature for recipients who don't have an > asymmetric key (those 99%). Many new communication systems have a > fallback option for symmetric encryption in case the preferred way is > unavailable. And, quite important: It would not require serious > development effort as this possibility is built-in with GnuPGP. I think you underestimate the development effort. Besides, AFAIK, there is no standard for this. > Anyone > using Linux (and a mail client with OpenPGP support) could use that > directly. The others would just have to install e.g. Gpg4win and > Enigmail but would not have to configure it. > > Is there any reason *not* to support symmetric-only encryption in a > mail client? There are plenty of reasons. I already mentioned the lack of a standard. Then there's the problem of key exchange which you completely ignore. Related to this, you did not answer Robert's question "if you already have a secure channel over which you can send a key, why not just use that channel for your communications?". Instead of support for symmetric encryption I'd rather love to see automatic asymmetric encryption to be added to mail clients: OpenPGP keys are created and uploaded to some key server automatically, and they are looked up and used automatically (e.g. with trust-on-first-sight similar to SSH keys) when sending a message. I'd prefer this to be done in an opt-out fashion, i.e. unless the user explicitly tells the mail client not to do it, the mail client would simply do it. Regards, Ingo 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: symmetric email encryption
On Friday 18 July 2014 19:21:05 Hauke Laging wrote: > Am Fr 18.07.2014, 09:46:14 schrieb Doug Barton: > > Hauke, > > > > I think you skated past a previous question about your idea, and I'm > > also interested in the answer so I'll ask it again. :) > > > > If you have a secure channel of communication by which you can > > exchange the symmetric password (which you would need to make your > > scheme work), why don't you use that channel for communication, > > rather than e-mail? > > If I have understood everything right then this is not the same > question. > > But I am really surprised that you ask why you should communicate via > email with someone "though" you e.g. meet him once per month. Or with > someone whom you could call instead. Is that really your question? > > Symmetric keys and fingerprints have to be exchanged through a secure > channel only once. Sure. But the fingerprint is only used once (for verifying the key). And it's not even secret information, so exchange via an insecure channel is not an issue (at least, not a severe issue). OTOH, symmetric keys really should be exchanged via a secure channel. Moreover, reusing a symmetric key is a big no-no. And exchanging a new symmetric key for each new message is completely impractical (unless you use assymmetric keys for this). Exchanging a large number of symmetric keys at the same time is a bit less impractical, but then you need to keep track of which symmetric key is used next. Long ago people have found a good solution for all those problems concerning the exchange of symmetric keys: Assymmetric encryption. Regards, Ingo 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: symmetric email encryption
On Friday 18 July 2014 21:01:54 Peter Lebbing wrote: > On 18/07/14 15:40, Ingo Klöcker wrote: > > OpenPGP keys are created and uploaded to some key server > > automatically, and they are looked up and used automatically > > This creates a privacy issue with key lookup. It exposes > correspondents to the keyserver, including time-of-use. Sure. But the NSA already knows the correspondents of all of our mail anyway. Keyserver lookups do not add any additional data (except of the information that you are trying to look up a key resp. that you are talking to a keyserver). Okay, the keyserver owner may collect data. But the keyserver (owner) has to be trustworthy anyway. > Also, you need to define some negative-acknowledge time to live > (terminology borrowed from DNS). If on first contact an address does > not exist at the keyserver, when do you re-check? And since it can, > in unfavourable circumstances, take a while for a public key to > propagate through the keyserver network, if somebody just created an > e-mail address and key and uploaded it, then starts communicating, > people will check a keyserver and not see the key. Now their client > will wait the defined period before re-checking, adding even more to > the propagation delay. So what? My scheme is not supposed to work instantaneously. It is supposed to work eventually, i.e. it will work after the propagation delay has passed. This is way better than our current status quo: No encryption at all for almost all email. > Thirdly, if this is the default mode of operation, I think you need > automatic decryption before storing the mail, because searching mail > is an important feature, and searching encrypted mails a big > usability issue. Good point. Automatic decryption should be possible for those that want it. My scheme is mostly meant as in-transit encryption which again is way better than our current status quo. > An e-mail system with a default big usability issue > will get swapped out for a more pleasant to use one. Exactly. > Finally, I think people might take issue with their e-mail address > automatically being posted to a public keyserver. And if it catches > wind, and many, many people use it, I think spammers might look again > at harvesting addresses versus generating them. Now it's a small pool > to fish from, but if most people have their address on the keyserver > network, the odds might change. How exactly does one harvest email addresses from the keyservers? Can I ask keyservers to give me all keys it has in storage? Or do I need to search for keys matching a certain substring? I honestly don't know. Anyway, if this really becomes a problem than key lookup probably needs to be made as inconvenient as trying to send email probes to randomly generated email addresses. For my scheme to work the keyservers would only need to return keys where the email address part of a uid exactly matches the recipient's email address. Moreover, for my scheme to work no key certification is necessary, i.e. crawling from one key to the next via certification signatures wouldn't be possible. The scheme has more issues: For example, there's no message integrity protection (via signing) whatsoever. But that's the current status quo anyway. Regards, Ingo 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: symmetric email encryption
On Friday 18 July 2014 17:20:27 Hauke Laging wrote: > Am Fr 18.07.2014, 15:40:34 schrieb Ingo Klöcker: > > > And, quite important: It would not require serious > > > > > > development effort as this possibility is built-in with GnuPGP. > > > > I think you underestimate the development effort. > > That is easily possible. But what would have to be done (at least)? > > a) You need a new button. Yeah. Let's add yet another button to the UI. Let's add an "Encypt symmetrically" button and let's rename the "Encrypt" button to "Encrypt assymmetrically". If we add enough buttons then users will eventually start pressing them. (Sorry, for being sarcastic, but I really don't see how adding another button can possibly improve the users' willingness to use email encryption.) > b) Pressing this button would replace > > --recipient 0x12345678 --encrypt > > by > > --symmetric > > in gpg terms – I am not familiar with gpgme but for obvious reasons it > has to be quite similar. There is a difference between symmetric and assymmetric encryption that could make it a bit more difficult than simply calling a different gpgme function. The latter doesn't require any user input, hence it can be done synchronously. OTOH, the former requires user input, the password to use for symmetric encryption, so it's advisable to do it asynchronously. BTW, additionally to the above mentioned new button the user has to press he also has to enter a password for each message he wants to send encrypted. How this additional inconvenience is going to win us more OpenPGP users is beyond me. > > Besides, AFAIK, there is no standard for this. > > Of course, there is. Otherwise you would not be asked for a symmetric > password for certain messages, would you? This is for inline OpenPGP and that's not part of any standard about email encryption I know of. Since you are also using KMail I invite you to test whether KMail is able to decrypt symmetrically encrypted OpenPGP/MIME messages out-of-the-box. It might just work, but I'm too lazy and too tired to test this right now. > > > Is there any reason *not* to support symmetric-only encryption in > > > a > > > mail client? > > > > There are plenty of reasons. > > I would be satisfied with a single one. > > > I already mentioned the lack of a standard. > > Yeah > > > Then there's the problem of key exchange which you > > completely ignore. > > Which I can easily ignore as it is out of the scope of message > handling. How have users ever successfully exchanged encrypted ZIP > archives without ZIP providing an infrastructure for key exchange...? Probably by using the same trivial password for all encrypted ZIPs they exchange with anybody. Which brings me to another issue I have with your proposal: How do you want to prevent the users from using the same trivial symmetric encryption password for all "encrypted" messages? And what's your threat model, i.e. what do you want to achieve by your symmetric email encryption scheme? > Why does OpenPGP cover symmetric encryption without providing an > infrastructure for symmetric key exchange...? Let's check the PGP 2.6.3i User's Guide (ftp://ftp.pgpi.org/pub/pgp/2.x/doc/pgpdoc1.txt). = Using Just Conventional Encryption -- Sometimes you just need to encrypt a file the old-fashioned way, with conventional single-key cryptography. This approach is useful for protecting archive files that will be stored but will not be sent to anyone else. Since the same person that encrypted the file will also decrypt the file, public key cryptography is not really necessary. To encrypt a plaintext file with just conventional cryptography, type: pgp -c textfile This example encrypts the plaintext file called textfile, producing a ciphertext file called textfile.pgp, without using public key cryptography, key rings, user IDs, or any of that stuff. It prompts you for a pass phrase to use as a conventional key to encipher the file. This pass phrase need not be (and, indeed, SHOULD not be) the same pass phrase that you use to protect your own secret key. [...] = Apparently, Phil Zimmermann had a specific use-case in mind for "conventional encryption". And this specific use-case does not require any symmetric key or passphrase exchange with a second user. I doubt that Phil Zimmermann meant "conventional encryption" to be used for exchanging encrypted messages. > Users are capable of exchanging sheets of paper or having phone calls. > The typical ways for safe fingerprint exchange are safe enough for > password exchange, too. I very much disagree, but I
Re: symmetric email encryption
On Saturday 19 July 2014 03:46:56 Hauke Laging wrote: > I guess this discussion does not go well because of a misunderstanding > or wrong expectations. > > > You and Ingo are talking about "real crypto" issues. Actually, concerning your proposal, I'm more talking about usability. To encrypt a message using your proposal the sender needs to * write the message, * tell his mail client that he wants to encrypt the message, * come up with and enter the password that should be used for encrypting the message, (-> minor inconvenience) * tell the recipient the password, (-> major inconvenience) * and, finally, send the message. That's three more steps than for sending an unencrypted message. And for one of those steps a completely different communication channel needs to be used. This is so inconvenient that I cannot see this helping our cause. Regards, Ingo 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: Automatic e-mail encryption
Hi Peter, please do not send me direct replies. I am subscribed so reply-to-list is sufficient. (I wouldn't ask this of you if I'd receive two copies of your replies, but I only receive the direct replies and this means I cannot use reply-to-list. The mailing list is correctly configured, so I blame a fancy deduplication feature of the receiving Exchange mail server.) On Saturday 19 July 2014 14:26:44 Peter Lebbing wrote: > Here's an idea: when elliptic curve becomes ubiquitous, simply include > your public key in the header of every e-mail you send. That's way > closer to how SSH works, since it uses only one channel, in this case > the e-mails themselves. Perhaps it would be a good idea to only > include the actual EC public key, and not the whole OpenPGP packet, > to keep it small. I like this idea. > You say signing isn't covered... I don't see why not. Just as you > automatically decrypt; automatically sign. It doesn't feel right to automatically sign messages with automatically created keys. Also, signing is irrelevant for my use case: end-to-end encryption. > There still is the large issue of private key distribution. I have > several machines all connected to my e-mail account. It seems to me > there's a *lot* of infrastructure still missing for this to be almost > transparent to the end-user. Yeah. Usage of multiple machines/devices is an unsolved problem. > This topic, if discussed at all, should > be discussed by itself and not as some kind of counter-offer to > symmetric encryption, because the problem space is vastly different. Right. I guess I simply grabbed the opportunity. > By the way: if we had a working alternative to SSL/TLS, all the mail > servers could talk to eachother securely without eavesdropping. That > way the contents of e-mails is only exposed on the sending SMTP > server and the receiving SMTP and mailbox servers (f.e., IMAP). The > mailbox server already knows when you use automatic decryption to > facilitate searching, unless the decrypted messages are only stored locally. Yes, this would break server-side searching and is problematic on devices with limited storage capacity. > and the receiving SMTP server is probably under > the control of the same people that control the receiving mailbox > server. So they are probably about equally difficult to access. And > likewise, the sender will have a decrypted copy in his Sent folder on > his mailbox server, unless ... > and the sending SMTP server is again close to > that server. So if only we had a way to properly authenticate SMTP > servers, I think we get almost the same effective protection for the > users, albeit without signatures. And this requires only changes to a > "couple of" servers, instead of to all endpoints. Good news: I think we do have such a way. It's called DANE (DNS-based Authentication of Named Entities) [1]. Support for DANE has been added to Postfix a few months ago and a few German mail providers recently started using it. Regards, Ingo [1] https://tools.ietf.org/html/rfc6698 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: symmetric email encryption
On Saturday 19 July 2014 04:37:56 Hauke Laging wrote: > Am Sa 19.07.2014, 01:42:19 schrieb Ingo Klöcker: > > Since you are also using KMail I invite > > you to test whether KMail is able to decrypt symmetrically encrypted > > OpenPGP/MIME messages out-of-the-box. It might just work, but I'm > > too > > lazy and too tired to test this right now. > > It does work. It seems not to work with Thunderbird/Enigmail though. > But maybe I have done something wrong. The Enigmail console output > looks good to me... > > I have prepared a mail file for those who want to give this a try: > > http://www.crypto-fuer-alle.de/docs/mail-symmetric/mail.cr-lf.eml Thanks for testing (also to Mirimir and MFPA). > > And what's your threat model, i.e. what do you want to achieve by > > your symmetric email encryption scheme? > > Same answer: This is for users who don't need any threat model > consideration. Huh? Why would those users want to encrypt a message if they don't have a threat in mind? I'm not replying to anything else because I think I have nothing more to add. Regards, Ingo 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: Difference between clearsign and detached signatures?
On Thursday 28 August 2014 22:53:52 TJ wrote: > I've recently been digging deep into the source-code trying to > understand what the differences are between --clearsign and > --detach-sign signatures. The RFC is probably much easier to read than the source code: http://tools.ietf.org/html/rfc4880 > This came about whilst writing code that calls on "gpg --verify" on > detached signatures; specifically Debian APT archives that contain > "Release" (plaintext) and "Release.gpg" (detached signature). > > The aim/hope was to combine the plaintext and detached signature into > the armored clearsign format and thus avoid needing to write one of > them to the file-system (the other can be supplied via stdin). > > I had thought that the message digest hash (in this case SHA512) > should be the same since the input data is the same which-ever > signing method is used. This didn't work as I had expected so I have > been digging into the source-code to figure out what is different > between the two signing methods. In general the message digest hashes will differ. The reason for this is a different canonicalization of the signed text (provided the detached signature is a text document signature; if it's a binary document signature no canonicalization is applied). A main difference is the stripping of trailing whitespace in the text (which is done for cleartext signatures but not for text document signature). For details see http://tools.ietf.org/html/rfc4880#section-5.2.4 and http://tools.ietf.org/html/rfc4880#section-7 Regards, Ingo 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: Difference between clearsign and detached signatures?
On Thursday 28 August 2014 22:53:52 TJ wrote: > I've recently been digging deep into the source-code trying to > understand what the differences are between --clearsign and > --detach-sign signatures. > > This came about whilst writing code that calls on "gpg --verify" on > detached signatures; specifically Debian APT archives that contain > "Release" (plaintext) and "Release.gpg" (detached signature). > > The aim/hope was to combine the plaintext and detached signature into > the armored clearsign format and thus avoid needing to write one of > them to the file-system (the other can be supplied via stdin). You can probably use another approach than trying to create a clearsigned text from a signed text and its detached signature. On the command line one can provide both, the detached signature and the signed text, one after the other via stdin by running gpg --verify - - You need to separate the detached signature and the signed stuff with an EOT, e.g. on the console first you enter the armored detached signature and terminate it with Ctrl+D, then you enter the signed text and terminate it with Ctrl+D. BTW, which language do you want to write the code in? Regards, Ingo 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: Difference between clearsign and detached signatures?
On Saturday 30 August 2014 23:11:17 TJ wrote: > On 30/08/14 22:20, Ingo Klöcker wrote: > > BTW, which language do you want to write the code in? > > Well, I'm working in C to add another option to gpg, but the code that > needs this is a Python library (that imports python-gnupg) that > enables the regular verification of the GPG signatures of APT archive > 'Release' files in all Debian/Ubuntu/related-distro mirrors > world-wide. I strongly suggest that you have a look at using some Python binding for gpgme instead of messing around with gpg. gpgme is _the_ library for using GnuPG in other programs. The following message from last year lists two Python bindings: http://lists.gnupg.org/pipermail/gnupg-users/2013-April/046477.html Regards, Ingo 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: key length/size RSA discussion/recommendations in the wiki
On Wednesday 29 October 2014 22:18:13 Peter Lebbing wrote: > On 2014-10-29 21:49, ved...@nym.hush.com wrote: > > Surely Peter knows this too ;-) > > > > More likely 128 was a typo for the more common older RSA key of 1028 > > ... > > No, I'm using a strict definition of brute force. > > For p = 2^63 to 2^64-1 >For q = 2^63 to 2^64-1 > If p * q == n: >Break >Next > Next If anything then I'd do For p = 2^63 to 2^64-1 If n modulo p == 0: Break Next q = n / p which is O(n^(1/2)), but IMO still brute force (even in your strict definition), while yours is O((n^(1/2)^2) = O(n). "brute force" doesn't mean that you have to use the most naïve algorithm. > I don't feel the method outlined by Rob is still brute force. That > brute actually is using his brain. Possibly his brain resembles a > sieve, but still :). Am I too strict? Actually, that brute doesn't seem to be using his brain. If he'd use his brain then he'd use he fists to brute force the secret out of you. ;-p Regards, Ingo 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: Encryption on Mailing lists sensless?
On Tuesday 18 November 2014 22:43:18 MFPA wrote: > On Tuesday 18 November 2014 at 6:15:57 PM, in > , Mirimir wrote: > > As long as messages were separately encrypted to each > > recipient, no third parties would be involved. > > For an email message with multiple recipients, I think most mail > clients and OpenPGP encryption agents that I have looked at encrypt > the message to all addressees at once. I only recall one combination > that encrypted an individual copy for each addressee, and am not sure > I correctly remember which it was. KMail encrypts an individual copy for each BCC recipient. I thought Thunderbird+Enigmail would also do this. Any mail client not doing this completely subverts BCC (unless --throw-keyids or --hidden-recipient is used, but even throwing the key IDs still leaks the number of hidden recipients). Regards, Ingo 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: Encryption on Mailing lists sensless?
On Thursday 20 November 2014 14:36:35 Schlacta, Christ wrote: > On Nov 20, 2014 1:58 PM, "Ingo Klöcker" wrote: > > On Tuesday 18 November 2014 22:43:18 MFPA wrote: > > KMail encrypts an individual copy for each BCC recipient. I thought > > Thunderbird+Enigmail would also do this. > > > > Any mail client not doing this completely subverts BCC (unless > > --throw-keyids > > > or --hidden-recipient is used, but even throwing the key IDs still leaks > > the > > > number of hidden recipients). > > There's nothing preventing a list server or mail client from intentionally > adding a pseudo random quantity of invalid or junk keys to the recipient > list, thus obfuscating the number of additional recipients, only providing > an upper bound to the estimate. Adding additional junk keys doesn't help if the recipient (or the recipients) expect a certain number of recipients. If the message is encrypted to more than (expected number of recipients)+1 (for encrypt to sender) then the recipients most likely will wonder who the other recipients are. You'll have a hard time convincing them that the "other recipients" are just fakes to confuse a third party intercepting the messages. Regards, Ingo 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: Pros and cons of PGP/MIME for outgoing e-mail?
On Sunday 23 November 2014 13:12:47 Bjarni Runar Einarsson wrote: > Hello gnupg-users! > > I am the lead dev on Mailpile, a free software e-mail client where we're > doing our best to improve the usability of PGP-encrypted e-mail. I have > been pondering for quite some time the relative merits of various ways > of formatting otugoing encrypted mail, and this weekend I took the time > to summarize my findings and opinions in a blog post: > > https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html > > The "tl;dr" is that it might be worth dropping PGP/MIME for outgoing > encrypted mail and instead use a more ad-hoc approach which > interoperates with more mail clients. How do you plan to encrypt multipart messages with "a more ad-hoc approach which interoperates with more mail clients"? PGP/MIME solves this problem in a standardized way that all mail clients that support PGP/MIME can handle. > I'm also tentatively proposing an > approach to reducing the header metadata leakage (Subject, From, To, > etc. being sent in the clear). Sender address and recipient address are part of the mail envelope. As long as you use SMTP there's not much point in trying to hide the From and the To header. OTOH, due to SMTP's nature simply putting some dummy email addresses into From and To is trivial. I just think that it serves no real purpose. Who do you want to hide the From and To headers from who does not have access to the mail envelope? Also, Werner Koch has mentioned several (?) times on this list that the obvious solution for this to attach the actual message to a wrapper message and encrypt the whole thing with PGP/MIME. Any fully MIME- and PGP/MIME- capable mail client will be able to decrypt and display such a message out-of- the-box. Regards, Ingo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Pros and cons of PGP/MIME for outgoing e-mail?
On Sunday 23 November 2014 18:05:03 Bjarni Rúnar Einarsson wrote: > Hi Samir, > > Samir Nassar wrote: > > I would care more about the arguments if you were able to re-state them > > while dropping references to legacy email clients. I don't think new mail > > clients have an obligation to be backwards compatible. > > > > If you, and others, think the PGP/MIME RFC is incomplete or invalid, > > then that's a conversation I want to hear. > > Oh, I absolutely do. I think it's fundamentally lacking. Key points: > > 1) It tightly couples MIME parsing and PGP processing, making it hard to > compose "does one thing well" type tools and requiring quite invasive > plugin APIs in order for people to be able implement PGP/MIME from a > plugin. Why? All it takes is one API call which takes a MIMETree and returns another MIMETree. > 2) It is hard to implement correctly. The white-space handling > particularly hairy. I don't understand what you mean. Do you refer to the removal of trailing white-space? What's hairy about that? > Flaws 1) and 2) are why we still keep seeing new mail applications > written that do not support PGP/MIME, and still see PGP email projects > that can't do it either. See Mailvelope, APG/K9, more. The developers of > these projects are not lazy, the standard is just a pain in the ass to > implement. I know, I've done it. So you've come to realize that writing an email client isn't all fun? Welcome to the real world. > Flaw 3) is one of the reasons why big > chunks of the security community write off PGP and e-mail as a lost > cause. The key of this statement is that they write off "e-mail as a lost cause" because this is unfixable in SMTP. The only solution is not to use SMTP. > I am disappointed that you think it's okay to just ignore real world > compatibility and dismiss all the mail clients that don't implement > PGP/MIME as "legacy". That's a very lonely ivory tower, and with that > attitude our community will never help the masses communicate securely. I'm sorry to disappoint you, but you won't help the masses communicate securely by writing yet another mail client. The masses won't use your mail client (or any other niche mail client). The public masses use Google mail, the corporate masses use Outlook/Exchange, and the smartphone masses use whatever mail client comes with their smartphone. If you want an achievable goal, then don't aim for the masses but for those people who really need means for secure communication. I expect those people to use PGP/MIME-capable mail clients (or no e-mail at all) and not some other mail clients with non-standard, homebrew encryption. Regards, Ingo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Randomized hashing
On Thursday 27 November 2014 17:10:08 NdK wrote: > Il 27/11/2014 11:28, Peter Lebbing ha scritto: > > [Resending to list] > > > Perhaps I should add that it takes real research and formal proof to show > > that this randomized hashing doesn't add attack vectors, and I have been > > glossing over that. But that is because at a glance it looks like such > > research has been done. That doesn't mean it's a fact that there are no > > significant attack vectors, but it does give the scheme credibility. > > Well, I'm no expert, but it gives me the feeling of being potentially > dangerous, since once the attacker have your signature for a document > s=E(Prk, H(RMX(M,r))) , r > (note that r is not signed, as the rhash scheme suggests and the paper > confirms!) he *might* be able to calculate r' so that RMX(M',r') == > RMX(M,r) then 'recycle' your signature for M'. Remember that RMX is > proposed to be a simple block-xor! For very short (less than a single > hash block) messages it's trivial, if I'm not badly mislead by the > graphic description in the site: > RMX(0, 1) == RMX(1, 0) I think you missed that according to the diagram RMX(M, r) = (r, ...), i.e. it starts with r. Consequently, RMX(M',r') = RMX(M,r) => (M',r') = (M,r), i.e. RMX is injective. Regards, Ingo 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: Setpref is not working or is it a bug or something?
On Friday 28 November 2014 15:04:56 gnupgp...@on.yourweb.de wrote: > > -Original Message- > > From: Peter Lebbing [mailto:pe...@digitalbrains.com] > > Sent: Wednesday, November 26, 2014 8:16 PM > > To: gnupgp...@on.yourweb.de; gnupg-users@gnupg.org > > Also, @g, as you > > apparently call yourself, you seem to start a new thread with each post, > > could you try to get your e-mail client to properly thread?) > > I am sorry, all my replies are sent to gnupg-users@gnupg.org only, > without touching the subject. > I am new to mailing lists, so is this the right procedure? Yes, that's the right procedure. The problem Peter mentioned is caused by the fact that your replies lack the message headers (In-reply-to and References) that usually link replies to the replied-to messages. It seems that either your mail client doesn't add those message headers or that the GPGrelay thingy that you appear to be using removes those message headers. Regards, Ingo 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: Setpref is not working or is it a bug or something?
On Sunday 30 November 2014 10:46:40 gnupgp...@on.yourweb.de wrote:
> >> I am sorry, all my replies are sent to gnupg-users@gnupg.org only,
> >
> > Yes, that's the right procedure.
> > The problem Peter mentioned is caused by the fact that your replies lack
> > the message headers (In-reply-to and References) that usually link
> > replies to the replied-to messages.
>
> Yes, that's true, SMTP-Filter is running for outgoing mails:
> http://lab1.de/Central/Software/Internet/E-Mail/SMTP-Filter/
>
> It deletes for security/privacy reasons:
> IN-REPLY-TO:
> MESSAGE-ID:
> ORGANIZATION:
> REFERENCES:
> THREAD-INDEX:
> THREAD-TOPIC:
> X-MAILER:
> X-MIMEOLE:
> X-MSMAIL-PRIORITY:
> X-Relayed-By: GPGrelay
>
> Hidden header 'In-Reply-To: <1CD78A.547AEDEA.0002@machine>':
> IN-REPLY-TO and REFERENCES for example include ...@machine, which is always
> the same... This is not wanted because of the possibility of tracking cross
> over the web ("who posts which content...")
IMHO that's nonsense. Those headers do not identify your machine. Those
headers reference the messages you reply to, so if anything then those headers
identify the machine of the person you reply to.
> So, how to deal with this behavior?
I suggest that you stop deleting the In-reply-to and the References header.
> Keeping subject untouched seems to be enough for identifying and associating
> to thread, isn't it?
Yes. At least for email clients that also thread messages by the Subject
header. But even those mail clients usually don't know which original message
your reply belongs to and therefore those mail clients will put your message
below an arbitrary other message in the thread. This makes reading longer mail
exchanges with multiple participants (e.g. like here on this mailing list) a
PITA.
Regards,
Ingo
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: [Announce] GnuPG 2.1.1 released
On Thursday 18 December 2014 10:59:09 Dave Pawson wrote: > Running Fedora 21, 64 bit. > ./configure gave error > missing ksba > Downloaded. > ./configure gave libgpg-error is needed. > > # yum install --disablerepo=Dropbox libgpg-error > Loaded plugins: langpacks > Package libgpg-error-1.13-3.fc21.x86_64 already installed and latest version > Nothing to do > > Circular error? I guess you are lacking the development package of libgpg-error. It's probably called libgpg-error-devel. Whenever you want to build something yourself you have to install the development packages of all dependencies. Normal users don't need them. Therefore they are usually not installed by default. Regards, Ingo 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: GPG (v. 1.4.12) is not user-friendly
On Thursday 01 January 2015 04:59:37 Kelly Dean wrote: > Getting the fingerprint should not require importing the key. Getting the > fingerprint should not require writing to any file at all. It should only > require reading. I haven't tried with gpg 1.4, but with gpg 2.0.22 it's as easy as # gpg --with-fingerprint key.gpg Regards, Ingo 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: gpg vs smime, snowden etc
On Thursday 01 January 2015 19:19:58 Uwe Brauer wrote: > Hello > > I am sorry if this is a little off-topic but I am not sure where to ask. > I use both, gpg and smime (the later either with gpgsm or with > thunderbird) > > Recently the German news magazine «Der Spiegel» [1] published more of > the «Snowden files», which reveal that gpg is NSA safe[2]. > > Does anybody know whether smime has the same level of security? There > are at least two possible weak spots. > > - the generation and sign of the certificate, ideally the >generation of the keypair should be done by the crypto module of >the browser, but that could be hacked... > > - the length of the key for the symmetric encryption. > > Maybe there are others. The PKI resp. the CAs are the weakest spot of S/MIME (if you rely on the S/MIME PKI for certificate verification). Regards, Ingo 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: Some thoughts on working with GnuPG
On Monday 09 February 2015 20:27:09 Werner Koch wrote: > Back in October Smári posted an article with the problems he encountered > while integrating GnuPG into mailpile. See > https://www.mailpile.is/blog/2014-10-07_Some_Thoughts_on_GnuPG.html . > > I asked him whether I may comment on this over at gnupg-user and with > 2.1.0 out of the way I started to draft a response. However, I then > figured that 2.1 bug fixes are more important and thus I did not > finished that response. Find below what I already wrote. I yanked the > text from the browser, thus there may be formatting issues; I also > skipped parts which are not relevant for my comments. > > > One of the things I'm largely to blame for in Mailpile is the GnuPG > > interface. It's a chunk of Python code that executes the GnuPG binary, > > tosses information at it, and figures out what to do with the > > output. There are lots of libraries for doing this, but after a great > > deal of exploration I found that all of the Python libraries that did > > this were insufficient for our needs, and the only thing crazier than > > manually forking out GnuPG in our situation would be to use the PGPME > > library. Hehe. This reminds me of the time when I improved KMail's support for GnuPG, PGP 2, PGP 5 and PGP 6 parsing the human readable output (with LANG=C to avoid breakage due to i18n). But that was more than 15 years ago. I wish there would have been something like gpgme back then. Regards, Ingo 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: (bug?) Revoked keys and past signatures
On Tuesday 10 February 2015 10:37:38 Hugo Osvaldo Barrera wrote: > On 2015-02-10 13:30, Kristian Fiskerstrand wrote: > > On 02/10/2015 01:24 PM, Peter Lebbing wrote: > > > On 10/02/15 12:52, Kristian Fiskerstrand wrote: > > >> No, the signature is still valid: > > > Why? The key was revoked because it was superseded or has been > > > retired, not because it was stolen or compromised. > > > > Unless you rely on a trusted third party to provide signature stamps, > > signature dates can be forged. A key revocation should result in > > immediate questioning of all aspects of the key, as it currently does. > > There is no reason to assume that the signature has been forged if the key > has not been compromised. > > Also, I see no reason why I should not be able to assign a trust to a > revoked key - I might trust it even if the author revoked it as superseded: > > > $ gpg --edit 1BFBED44 > [... info on revoked key ...] > gpg> lsign > Key is revoked. Unable to sign. > > I believe the reason matters. I can even sit down with the owner of the key > and verify his ID and fingerprint and sign it, meaning "this key belongs to > this person, but was superseeded a week ago". If actually influences the > validity of anything he signed up to a week ago. Use gpg --lsign --expert 1BFBED44 to sign the key despite the revocation. But this won't change the validity of the key. The validity of a revoked key is (and remains for all times) "revoked" (as far as gpg is concerned). Regards, Ingo 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: Just one gpg-agent
On Friday 06 March 2009, Thomas Bohn wrote: > I currently try to get the gpg-agent to start just one time and not > to get one more gpg-agent session each time I log in, but it doesn't > work. > > Even the hint in the gpg-agent man page won't work, I still get more > than one gpg-agent process and more than one gpg-agent directory. I suppose we are talking about Linux or some Unix derivative. I run the following two commands on session start: = killall gpg-agent 2>/dev/null eval "$(gpg-agent --daemon --default-cache-ttl 36000)" = Since I'm using KDE they are in a file called start-gpg-agent.sh that I've put into ~/.kde/env. Before that I used a custom ~/.xsession script. Regards, Ingo 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: offtopic: need help from Mac owner
On Sunday 29 March 2009, Hardeep Singh wrote: > Hi All > > I need someone with a Safari browser to test something for me: it > wont take more than 3 min. > > I have a webpage that unjumbles words, and which is somewhat popular. > I am building a new version which is AJAX based and the prototype is > ready. I have tested it on Opera, IE, Firefox (on Windows and Linux) > but do not have a way to test on Safari. Please do the following: > > 1. Navigate to http://unjumble.seeingwithc.org/unjumx.php. > 2. In the text box, enter 'llarec' (without quotes) and press enter. > A wait icon should be shown, and afterwards 'caller' should be > displayed. > 3. In the text box, enter 'otalt' and this time, instead of pressing > enter - press the Unjumble button. Same thing should happen, 'lotta' > should be displayed. > > In no case should the form reload. Please let me know what happens. FWIW, it also works (as described above) with Konqueror 3.5.9. But it fails to unjumble "setec astronomy". :-) Regards, Ingo 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: keyservers
On Saturday 18 April 2009, Robert J. Hansen wrote: > Faramir wrote: > >> And my last question is how to find for a specific key ? > > > > I am not sure, the GUIs I use do that for me. > > gpg --keyserver x-hkp://pool.sks.keyservers.net --recv-key [keyID] Or, if you do not know the key ID: gpg --keyserver x-hkp://pool.sks.keyservers.net --search-key [names] From gpg's man page: Search the keyserver for the given names. Multiple names given here will be joined together to create the search string for the keyserver. Option --keyserver must be used to give the name of this keyserver. Keyservers that support different search methods allow using the syntax specified in "How to specify a user ID" below. Note that different keyserver types support different search methods. Currently only LDAP supports them all. Regards, Ingo 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: Just a thought
On Saturday 25 April 2009, John Clizbe wrote: > david wrote: > > Hi all, > > > > Late here in Cyprus, in Thunderbird, OpenPGP I can sign and encrypt > > - but say I cc'd to a few people - because if those people are in > > my key ring will it encrypt for each? > > If a valid key can be located for each recipient, the message will be > encrypted to all. If a single recipient cannot be matched with a key, > the message will be sent in the clear. > > The message will be encrypted once with a symmetric cipher and > session key. Then the session key is encrypted to each recipient's > public key and the encrypted session keys are attached to the > message. > > For each recipient the first valid key with matching email address is > the one selected. If this is not the preferred key, then Enigmail's > Per-recipient rules may be setup to specify the correct key to use. How does Thunderbird/Enigmail handle bcc'd recipients? Does it create several differently encrypted copies of the message in case of bcc'd recipients, i.e. one copy of the message encrypted with the keys of all public recipients and additional copies of the message (one per bcc'd recipient) encrypted only with the key of the corresponding bcc recipient (and probably with the sender's key)? Regards, Ingo 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: Question about gpg-agent
On Wednesday 06 May 2009, Steven W. Orr wrote: > I'm running Fedora 10 (if anyone cares) with > gnupg2-2.0.10-1.fc10.i386. > > I'm up and rolling, but I'd like to know more about configuring the > agent. I started the agent via the recommended incantation: > > eval "$(gpg-agent --daemon)" > > in my ~/.kde/AutoStart AFAIK, this should be ~/.kde/env, so that the environment variable set by gpg-agent is available to everything running in the X session. FWIW, I have killall gpg-agent 2>/dev/null eval "$(gpg-agent --daemon --default-cache-ttl 36000)" in ~/.kde/env/start-gpg-agent.sh. > and I set > > use-agent > > in my ~/.gnupg/gpg.conf > > I'm not seeing a place that defines what the default values are for > the gpg-agent. I wanted to change the default TTL for a passphrase so > I said > > default-cache-ttl 6000 See my example above. Regards, Ingo 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: problems with PGP/MIME
On Saturday 16 May 2009, webmas...@felipe1982.com wrote: > I will do my best to describe as succinctly and clearly as possible. > To begin, I use openSUSE, openoffice for documents, and [usually] > kmail for email. I created a document in OOo and clicked on the > 'email' button to send it to my "other" email address > x...@student.qut.edu.au [backup]. I sent the file signed and encrypted. > The other address has only a web interface, and as such, has no > support for PGP/MIME. As expected, I see two attachments, > application/pgp-encrypted "VERSION 1" file, and > application/octet-stream (my encrypted .odt file). The application/octet-stream attachment does not only contain your encrypted .odt file, but the whole MIME structure of your message (after signing and before encryption) including the attached .odt file. > It isn't actually > binary, it appeares in ASCII when downloaded and opened in text > editor. I ran it through Kgpg, and also separately through gpg > command line, and was disappointed that I did not recover my original > .odt file. > > The top portion contains email header information stuff (stuff I > don't want, or care to understand). There is a signature at the very > bottom, but verification fails (it is *my*own* pub/priv key pair). That's because KGpg probably does not know how to verify PGP/MIME signatures correctly. > In > the middle, above the signature, and below the email header stuff, > there is an ascii-armoured portion of data. I have not yet attempted > to select it all, copy, paste, decrypt, because I thought to myself, > "there must be a better (read: easier) way to do this..." So, is > there? The "ascii-armoured portion of data" is most likely the base64 encoded .odt attachment. Try running it through base64 -di < "ascii-armoured portion of data" >foo.odt base64 is part of the coreutils. > I forwarded the message back to my x...@felipe1982.com address, and > viewed it in kmail (which as you all know, supports cool things like > pgp/mime). But it (after submitting my passphrase) will not decrypt! Hmm. No idea unless you did not make sure that the message is also encrypted with your own key. > Is this the normal behaviour of pgp/mime. I did read a little (albeit > quickly and not in detail) of rfc3156 (is this the most recent?). In theory, PGP/MIME allows arbitrary complex hierarchies of signed and encrypted body parts. In practice, KMail (and probably most other PGP/MIME capable email clients) encrypt the whole message (except for the email headers) after the optional signing step, i.e. the text and all attachments. Now, if you decrypt the encrypted "attachment" in the received message, you will get something like you write above. I'm not sure what your use-case is. If it's for backup purposes (as indicated above), then I suggest to sign and encrypt the .odt file with KGpg and then attach this signed&encrypted attachment to a message. This message should then not be encrypted because otherwise you'll have the same situation as above. Signing the message should be okay. Regards, Ingo 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: Avoid pinentry-gtk-2 when using console!
On Monday 01 June 2009, Roger wrote: > On Sun, 2009-05-31 at 22:52 +0100, Benjamin Donnachie wrote: > > 2009/5/31 Roger : > > > I know this sounds ridiculous, but when you consider a > > > console/terminal to be as good look'n as a girl, and then you're > > > made to a X window and forced to type in it, it just feels > > > ridiculous. Think most folks whom praise the console Gods, feel > > > the same way. > > > > Enable passphrase caching, just enter it the once and be done with > > it. > > > > Ben > > This is why I disabled gpg-agent. As little as I use Gnupg/PGP, I > would always have to enter the passphrase at Evolution PIM startup... > even though I had no intentions of using gpg for the entire session. > (It's because a lot of the passwords are put in a gpg keyring ... or > something.) It sounds wrong that Evolution asks for the passphrase on startup. I'm using KMail and I don't have to enter the passphrase when I start it. Only when I want to send a signed message or decrypt an encrypted message does the pinentry dialog pop up. Just like it should be. Regards, Ingo 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: the preference of signing keys question
On Saturday 06 June 2009, Kārlis Repsons wrote: > On Saturday 06 June 2009 13:30:08 David Shaw wrote: > > On Jun 6, 2009, at 5:26 AM, Kārlis Repsons wrote: > > > Hi, > > > still I have questions :) > > > This time: is there some gnupg dictated way of setting preference > > > of which > > > signing/encrypting key to use? For example, I have a long RSA > > > subkey, which I > > > created just in case. What do you mean by "just in case"? Do you want to use the RSA subkey for certain messages? > > > I'd like to use DSA now, but my mailer > > > somehow preferred RSA subkey. > > > > GPG will use the most recent valid subkey for a given purpose (i.e. > > the most recent valid signing key, the most recent valid encryption > > key). If you want to force the use of a particular key, instead of > > specifying your key as XXX (the key id), specify the exact key > > or subkey you want as ! (the key id plus an exclamation > > mark). > > > > David > > This ends up with me willing to assert about the possible > combinations: > > Three sets from which to combine: > set 1: > --export-secret-subkeys, --export-secret-keys, --export > > set 2: > used XXX, used XXX! > > set 3: > master key, subkey > > A] Which normal cases will export only the XXX subkey keypair > (pub+sec)? Are they > --export-secret-subkeys, XXX!, subkey? > > B] Which normal cases will export all of the subkey pairs? Or master > keypair will be included? > Are they > --export-secret-subkeys, XXX, subkey? > > A2] Which normal cases will export only the XXX master keypair > (pub+sec)? Are they > --export-secret-keys, XXX!, master key? > > B2] Which normal cases will export all of the keypairs? > Are they > --export-secret-keys, XXX? > > C] Does --export works on the particular key ID, if XXX! is used? > > > Could you, please, explain a little about how mail clients interact > with gpg - they use library, right? I guess that depends on the mail client. KMail uses the gpgme library. > Or simply execute the gpg with the proper arguments and options? (I > see, my KMail can't accept '!', so I ended up curious about it) KMail does not support the selection of a specific subkey. Regards, Ingo 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: GPG4WIN and GnuPG smartcard, Claws
On Monday 08 June 2009, Werner Koch wrote: > On Sat, 6 Jun 2009 22:52, malte.g...@gmx.de said: > > Does the GPG4Win package support the GnuPG smartcard? Of course, > > given there is a reader and its driver installed first... > > Yes. > > > And, how powerful is the Claws client? Does it support multiple > > pop, smtp accounts and IMAP? > > The German c't magazine, issue 3/2009, run a test of several mail > clients (Claws, Evo, Kmail, Thunderbird) with Claws being the only > one with a '+' in all categories. Closely followed by Kmail. Yes, > multiple accounts are possible with all protocols. I was a bit disappointed of this article. I don't know why but the author of the article "forgot" four checkmarks. And it's not like the corresponding features are hidden from the user, e.g. there's an "Include sub-folders" checkbox in the Search dialog, but KMail still got a '-' for this feature. Given this KMail clearly deserves a '+' in the IMAP category IMNSHO, bringing it pretty much on par with Claws. (I don't understand why Claws has a ++ for security, but KMail only a +. Is it because Claws cannot render HTML (without some plugin)?) Anyway, kudos to the developers of Claws for writing such a nice email client. It's nice to have a such worthy competitor. :-) Regards, Ingo 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: "Signature verification failed"
On Sunday 21 June 2009, Michel Messerschmidt wrote: > On Sun, Jun 21, 2009 at 02:42:45AM -0500, John Clizbe wrote: > > Joel C. Salomon wrote: > > > gpg command line and output: > > > C:\\Program Files\\GNU\\GnuPG\\gpg.exe --charset utf8 --batch > > > --no-tty --status-fd 2 --keyserver-options auto-key-retrieve > > > --keyserver pool.sks-keyservers.net --verify > > > gpg: Signature made 06/19/09 23:53:14 using DSA key ID 69274BBB > > > gpg: BAD signature from "Thomas BOHN " > > > > > > Where does this problem come from? > > > > It would appear to be an issue with how GPGMail constructs PGP/MIME > > messages. > > Hm, I get a good signature here: Same here (using KMail): Message was signed by tho...@bohnomat.de (Key ID: 0x61C7F5B569274BBB). The signature is valid, but the key's validity is unknown. Regards, Ingo 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: Using gpg-groups in gnome?
On Thursday 27 August 2009, debianfeed wrote: > Hello > > does anybody here know a possibility to use gpg key-groups under > gnome? groups defined in the gpg.conf > (e.g. "group mygroupname = 0x9DB0 0x9540") > do not show up in nautilus' seahorse extension. > > kgpg is capable of dealing with groups, but as it is a > KDE-application it ist not usable via the nautilus context menu. I doubt very much that kgpg cannot be added to the Nautilus context menu. I'm pretty sure any application can be added to the Nautilus context menu. It's a common and hard to kill misconception that just because an application is based on the KDE libraries it does not work in Gnome and vice-versa. Regards, Ingo 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: choosing an encryption target from a User ID
On Wednesday 23 September 2009, Daniel Kahn Gillmor wrote: > On 09/23/2009 12:17 PM, Werner Koch wrote: > > Please keep in mind that using a user ID is just to help the user > > in the most common case. Any proper mail tool won't accept such a > > solution but either presenr the user a list of matching keys and > > let him select a key or auto select the key based on such > > information. > > Has this been made this clear to collaborating MUA/plugin developers? > I think the "auto select a key" step for MUAs or plugins is often > implemented as "let gpg pick the key based on the user ID". I'm pretty sure that this will break horribly as soon as the user ID contains non-ASCII characters (as does my user ID). For exactly this reason I made KMail use the key ID instead of the user ID about 7 years ago. Is enigmail really still using the user ID? Regards, Ingo 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: choosing an encryption target from a User ID
On Thursday 24 September 2009, Daniel Kahn Gillmor wrote: > On 09/23/2009 06:04 PM, Ingo Klöcker wrote: > > I'm pretty sure that this will break horribly as soon as the user > > ID contains non-ASCII characters (as does my user ID). For exactly > > this reason I made KMail use the key ID instead of the user ID > > about 7 years ago. > > What makes you think that non-ASCII characters would break a match? > Presumably, all the tools are passing UTF-8 strings to each other, > and GPG can easily find a match based on such a string. Does it also work with keys like 0xCB0D4CAF or 0xAB1BC4E6 created with PGP 6 (or earlier) where the user ID is not UTF-8 encoded? KMail applies some heuristics to guess the correct encoding if UTF-8 doesn't seem to work, but even if KMail guesses wrong and is not able to decode the user ID properly it's still possible to use such a key for encryption. Moreover, user IDs are not unique while key IDs (usually) are. So if you want to be sure that the correct key is used you cannot use the user ID. > For example, it certainly works fine from the shell: > > 0 d...@pip:~$ echo test | \ > > > gpg --encrypt --trust-model always -r 'Ingo Klöcker' | \ > > gpg --list-packets > > > :pubkey enc packet: version 3, algo 16, keyid 30CFDDC732319538 > > data: [2047 bits] > data: [2048 bits] > > :encrypted data packet: > > length: 64 > mdc_method: 2 > gpg: encrypted with 2048-bit ELG-E key, ID 32319538, created > 2000-10-16 "Ingo Klöcker " > gpg: decryption failed: secret key not available > 2 d...@pip:~$ Good to see that it works nowadays for UTF-8 encoded user IDs on systems using a UTF-8 locale. > > Is enigmail really still using the user ID? > > I haven't dug into it deeply, but what i observed from my tests was > that if i switched the order of keys in my gpg keyring, enigmail > selected a different key for a recipient who had two keys with > matching User IDs. > > So i suspect that Enigmail is indeed passing the e-mail address at > least (if not the name) to gpg to select a reasonable key for > encryption. Yeah, not very clever if you ask me. But, of course, I'm biased. :-) Regards, Ingo 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: choosing an encryption target from a User ID
On Friday 25 September 2009, Daniel Kahn Gillmor wrote: > On 09/24/2009 04:56 PM, Ingo Klöcker wrote: > > Does it also work with keys like 0xCB0D4CAF or 0xAB1BC4E6 created > > with PGP 6 (or earlier) where the user ID is not UTF-8 encoded? > > hm; 0xCB0D4CAF looks to me like it expired 5 years ago; and > 0xAB1BC4E6 doesn't appear to be available on the public keyservers at > all. I guess that's just my luck picking exactly those two keys in my keyring that have either expired or are not publically available. :-) > Do you have any examples that are both public and still valid? 0xF661F608 (This is _not_ one of my keys. Funny enough this Ingo Klöcker went to the same school and the same university as I did.) 0x104B0FAF, 0x5706A4B4, 0xD96484AC, 0x7C52AC99, 0xAFA03822, 0x91190EF9 (this last one is definitely still in use) > RFC 2440 (over a decade ago) mandates UTF-8 for user IDs: > > http://tools.ietf.org/html/rfc2440#section-5.11 I'm fully aware of this. > > Moreover, user IDs are not unique while key IDs (usually) are. So > > if you want to be sure that the correct key is used you cannot use > > the user ID. > > 8-xdigit key IDs are fairly easy to replicate with today's hardware, > so relying on their uniqueness is not a good idea from a security > perspective. Full 40-xdigit fingerprints are probably effectively > unique for the time being, though. True. Actually, I lied about KMail using key IDs. Since about 6.5 years KMail uses gpgme and leaves all of those hairy details (like telling gpg what keys to use) to this library. > You're not the first person to suggest that supplying the key ID (or > fingerprint) directly is the best approach, but doing this just moves > a serious problem from GnuPG onto the shoulders of the user (or their > MUA or other tools). > > The problem that gets shifted in this case is: what key should you > use to encrypt data to a specific person? This is a potentially > complicated problem, and the right answer changes in the face of > changed/updated/revoked certifications, expirations, altered trust > relationships, etc. Asking the user (or their MUA) to hard-code a > single key ID means that you're asking them to ignore all these > possible changes when they happen. I don't see why harmless changes (see David's example) shouldn't be ignored. If the user hard-coded the key Alice1, then what's wrong with using this key as long as it's valid. Obviously, any changes making a hard-coded key invalid need to be escalated and such a key must not be used anymore by the MUA. > Asking every MUA to implement their own mapping from User IDs to key > IDs seems like a recipe for either weird divergence (should kmail > select a different key than enigmail for f...@example.org?) If for some email address multiple matching valid keys are found by KMail (or rather gpgme) then KMail asks the user which key(s) to use (and then remembers the user's choice). This transparency gives me a better feeling than some automagic behind-my-back key selection based on user ID/email address. > or plain > insecure mappings (e.g. an MUA developer who doesn't understand the > problem of certificate validation as well as the GnuPG developers). Full ACK. That's why MUA developers should use gpgme or an appropriate binding. > Since most of these tools rely on gpg as a backend, implementing a > more-reasonable choice in gpg seems like a good idea. Regards, Ingo 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: choosing an encryption target from a User ID
On Friday 25 September 2009, Daniel Kahn Gillmor wrote: > On 09/25/2009 11:06 AM, David Shaw wrote: > > What troubles me about this sort of behavior is that it is > > genuinely good and helpful in some cases and baffling and > > off-putting in others. For example, someone has two different Alice > > keys in their keyring. Both keys have a single UID, which is signed > > by Baker. One of the Alices (call her Alice1) is also signed by > > Charlie. The other Alice (Alice2) is signed by Dan. Alice2 is a > > newer key than Alice1. > > just to be clear: these are two keys with User IDs corresponding to > the same e-mail address, right? And that person knows Baker, and > Baker has verified them with the keyholder, so presumably they're > held by the same person. > > > At the moment, the keyring contains Alice1, Alice2, and Baker. We > > have full trust in Charlie and Dan, but they are not currently > > present in the keyring. > > How does the keyring holder indicate full trust in charlie and dan > without them being present in the keyring? Have they done some sort > of weird gpg --import-trustdb operation without pulling in the key > itself? Is this something people normally do? > > If the user is assigning trust to charlie and dan explicitly during > the key imports you describe, does that make the change in key > selection behavior less confusing? > > > I'm not against that behavior - it's reasonable and makes sense... > > to someone who really understands the web of trust and OpenPGP. > > Your implication here is that it doesn't make sense to someone who > doesn't understand the WoT and OpenPGP. i think you're correct, > sadly. But i think that the current behavior also doesn't make sense > to those same people; if you haven't thought about how to choose a > key based on the user ID, the whole process doesn't make sense. In > that (admittedly confused) state, it's even more important that the > tools make healthy choices. > > What's more, there are (unusual) use cases for the current behavior > that result in confusion and dangerously bad security. For example, > Charlie imported Alice's key a few years ago, and he imported Bob's > key more recently. Charlie has certified both Alice and Bob's keys, > so from his perspective they both have full calculated validity. > Charlie granted Alice marginal ownertrust, because he think she's > pretty good at making reasonable certifications. > > Charlie conscientiously runs a "gpg --refresh" every so often, and > one day Alice adds some new User IDs to her key (one of which matches > "Bob"'s User ID). Every message Charlie now sends to Bob is going to > be encrypted to this bad User ID. Bob won't be able to read them. > Even worse: if Alice has the ability to tamper with the mail stream > between Charlie and Bob, she can intercept the messages, decrypt > them, and re-encrypt them to Bob. > > Even if Charlie hadn't granted Alice marginal ownertrust, after he > updated her key, every time he tried to encrypt data to Bob, he'd get > a big warning about using a key with a poorly-bound User ID. This example is a good example why "hard-coding" what key to use for a which contact/recipient (e.g. in the address book of the MUA) isn't such a bad idea. Once Bob's key has been stored in my address book Alice won't be able to trick me into using her key instead of Bob's. Regards, Ingo 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: Decryption Fails on UserName but not on EmailAddress ???
On Saturday 26 September 2009, nschroth wrote: > David, > > On the target (recipient) machine: > --list-keys shows my Primary Key, My desktop Key and a co-worker's > desktop key > --list-secret-keys shows only my Primary Ke > --list-keys PrimaryKeyUserName it only lists my primary key. > > This has happen when a file was encrypted from EITHER my desktop or > mycoworker's desktop. You have to check the source (sender) machine. The wrong key is used during encryption. Regards, Ingo > David Shaw wrote: > > On Sep 25, 2009, at 7:19 PM, nschroth wrote: > >> I have been reading previous posts on this topic but have not > >> found my answer. > >> When I ENcrypt on BoxA using -r UserName, decryption on BoxB > >> errors with : > >> "decryption failed: secret key not available". > >> However, doing the same test using the email address associated > >> with the > >> recipient, Decryption WORKS. > > > > It sounds like you have two keys. When you use "-r username" > > you're matching one of them. When you use "-r > > emailaddr...@example.com" you're matching the other one. > > > > Check your keyring to be sure: do a "gpg --list-keys username" to > > see all keys that match that name. > > > > David > > > > > > ___ > > Gnupg-users mailing list > > Gnupg-users@gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users 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: choosing an encryption target from a User ID
On Monday 28 September 2009, Daniel Kahn Gillmor wrote: > On 09/25/2009 02:40 PM, Ingo Klöcker wrote: > > 0xF661F608 (This is _not_ one of my keys. Funny enough this Ingo > > Klöcker went to the same school and the same university as I did.) > > > > 0x104B0FAF, 0x5706A4B4, 0xD96484AC, 0x7C52AC99, 0xAFA03822, > > 0x91190EF9 (this last one is definitely still in use) > > ok, thanks, those are not expired, though i only see non-unicode in > three of them: 104B0FAF and F661F608, and 91190EF9. > > Those keyholders should probably create a new User ID that *is* > UTF-8, with the same e-mail address as the non-UTF-8 one, and > encourage the people who have certified the old User ID to re-certify > the new one. Once enough certifications are through on the new, valid > one, they can revoke the old one and move forward with a fully > OpenPGP-compliant key. Yes, I suppose this would be a sensible solution. > > I don't see why harmless changes (see David's example) shouldn't be > > ignored. If the user hard-coded the key Alice1, then what's wrong > > with using this key as long as it's valid. Obviously, any changes > > making a hard-coded key invalid need to be escalated and such a key > > must not be used anymore by the MUA. > > If the user hard-coded a specific key (by fingerprint) to the Alice > User ID, then of course GPG should respect that preference (and it > should emit warnings if the key ever becomes invalid), but i don't > think that users should be asked to make permanent choices like this, > since they might become invalidated by future circumstances; how will > they know that another (maybe better) choice is available, or should > be made? If Alice does not tell them, then they might not know this. But I'm not sure whether this is a common problem or more an academic problem. Let's say Alice loses her first key and cannot revoke it because she didn't create a revocation certificate. She creates a new key, but Bob continues to use the old key. Unless Bob automatically imports unknown keys, he will notice that Alice now uses a different key because he cannot verify her signature anymore. And if Bob uses the old key to send an encrypted message to Alice, Alice will surely tell him what happened. So I don't really see the problem with a hardcoded choice. > > If for some email address multiple matching valid keys are found by > > KMail (or rather gpgme) then KMail asks the user which key(s) to > > use (and then remembers the user's choice). This transparency gives > > me a better feeling than some automagic behind-my-back key > > selection based on user ID/email address. > > I hear what you're saying, but i think there are two problems with > it: > > 0) for many users, they are being asked to make a choice that they > don't understand; there are few things more frustrating than this. > If the tool *can* make a good choice based on the knowledge available > to it, it shouldn't need to pester the user, who may or may not have > as much understanding of the problem space. I agree, but I also disagree. I agree that it's preferable to save the user from having to make a choice. But then again I disagree about the "not have as much understanding of the problem space". People who do not understand to a certain degree how the WoT works would be better off using a centralized PKI. IMO this is a major weakness of the WoT. > 1) users are being asked to make an effectively permanent decision, > even though relevant circumstances may change in the future. > Presumably, this binding will produce warnings (with the option to > change the binding) if the bound key suddenly actually drops into > unknown calculated validity (for example, if you decide to revoke > ownertrust on a relevant intermediary; has this been tested?) But > there might be other changes that make this selection suboptimal > without causing it to throw warnings. See above. I wonder how much of a real problem this is. How many people have multiple valid keys bound to the same email addresses? What is the use case for having multiple valid keys bound to the same addresses? In the past, when I worked at the university, I used a private/home key and a work key. At home I could read anything. At work I could only read messages encrypted with my work key. So anything I was supposed to read at work needed to be encrypted with my work key. To make things more complicated my home key did have my work address as one user ID. So hardcoding my work address to my work key was basically mandatory. Regards, Ingo 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: choosing an encryption target from a User ID
On Wednesday 30 September 2009, Daniel Kahn Gillmor wrote: > Thanks for the discussion, Ingo! This is really useful to me, and i > appreciate the thought you've obviously put in here. Thank you, the same to you! You really make me thinking. > On 09/29/2009 04:32 PM, Ingo Klöcker wrote: > > She creates a new key, but Bob > > continues to use the old key. Unless Bob automatically imports > > unknown keys, he will notice that Alice now uses a different key > > because he cannot verify her signature anymore. And if Bob uses the > > old key to send an encrypted message to Alice, Alice will surely > > tell him what happened. > > will she? will Alice know how to resolve the problem? If she sends > Bob her new key, and Bob imports it, that would be great. They've > already had to do some work manually. Let's say that Bob even takes > the time to properly certify Alice's new key. You're now asking Bob > to take an *additional* step of "re-binding" the new Key ID to the > User ID -- why would he need to do that, when he's already certified > the key? True, but this could be solved by improving the used tools. People using KMail and OpenPGP will probably use KGpg for key management. So it would probably make sense to make KGpg aware of the "key-bindings" (which are stored in the KDE-wide address book btw, so this isn't strictly KMail-specific) and ask Bob after he certified Alice key. Just an idea. > > I agree, but I also disagree. I agree that it's preferable to save > > the user from having to make a choice. But then again I disagree > > about the "not have as much understanding of the problem space". > > People who do not understand to a certain degree how the WoT works > > would be better off using a centralized PKI. IMO this is a major > > weakness of the WoT. > > if you're doing explicit, hard-coded keyID-to-UserID bindings, you're > not using the WoT. You're using your bindings, perhaps with a > smidgen of the WoT to make sure that the key isn't totally invalid or > revoked. > > The way i'd like to see the WoT actually used is to get people to > think about two things which are well within the range of normal > human activity: > > a) who can i identify? I have no problem doing this. > b) who can i rely on to identify others? This is what is giving me major headaches. Maybe I'm too pessimistic or paranoid, but I trust almost nobody. I prefer to go to keysigning parties and check the ids myself. You are correct, that this is not what the WoT is about. > and then let reasonable, well-thought-out mechanisms draw the links > for the people automatically, without them having to think about it. > > If the tools don't do the Right Thing by default, then we start to > ask users to think about a bunch of extra arcane ideas beyond a and b > (ideas that folks on this list have actually thought about in-depth). > Those are tough to understand, and non-experts are justifiably > confused by them. > > This is why we need the tools to draw the right patterns by default, > not an argument to use hard-coded bindings or some centralized PKI > that asks the user to make none of these decisions at all. I see the value in tools doing the Right Thing by default, so I agree that gpg should probably be improved in this respect. Maybe I'm really doing something wrong. Maybe you are right in that I should stick to what gpg thinks is best and only use hard-coded bindings if it's really necessary. Hmm. I need to think about this. > > See above. I wonder how much of a real problem this is. How many > > people have multiple valid keys bound to the same email addresses? > > What is the use case for having multiple valid keys bound to the > > same addresses? > > I agree that it's not currently a common situation. here are the few > legitimate situations with multiple keys that i know of: > > * several people are going through key transitions right now, for > the same reasons that the defaults are changing in gpg. These people > often have two keys for a period of time. Yes. That's a good use case. > * Some people also have old keys that they have accidentally lost > access to. once that happens, it's too late. Yeah. That's basically a variation of the above use case. > But: > > Malicious people can upload keys with arbitrary User IDs to public > keyservers; if a user fetches one of those from a search (perhaps to > check the validity of any attached signatures), it's still in their > keyring, possible before the valid key of the corresponding user. > > If we say "it's not a common situation, so
Re: Decryption Fails on UserName but not on EmailAddress ???
On Tuesday 29 September 2009, nschroth wrote: > Interesting. The key is not listed twice, but... > > --list-keys PrimaryUserName shows ALL THREE keys while > --list-keys PrimaryEmailAddress shows only the primary host key. > > Could it be that the name I used for the primary key was CompanyName > and the email addresses for all the people had that as their domain > (ex: b...@companyname.com) ??? Makes sense. gpg --list-keys foo will list all keys where one of the user IDs contains the three letters "foo" (substring match). Please read the section "HOW TO SPECIFY A USER ID" in the manual page of gpg (man gpg) for the different possibilities to specify what key(s) to use for some operation with gpg. Regards, Ingo 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
