From ryan at digicana.com Mon Jul 1 00:23:20 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Sun, 30 Jun 2019 22:23:20 +0000 Subject: Your Thoughts In-Reply-To: <87d0iuonab.fsf@ra.horus-it.com> References: <87d0iuonab.fsf@ra.horus-it.com> Message-ID: <-Yr6HFqptjWfO3cPpx8sz6H6nC2UDuSlbV4J41vPrxCQHj4N1hUTi5FI3RXqrf0iw3TmFgUq1Pu5oo0A3IAVGH-fsjHJI_vUfSve-OoLjRI=@digicana.com> It?s not so much that nothing better has come along, it?s that no single one of those things does all the things PGP sets out to do. For secure communications there are much better options than PGP - some of them in very heavy use by actual normal, non tech people. For symmetric encryption of files there much better options out there. For signing files there are other options (though perhaps not better). Does anyone know what PGP?s peak adoption rate was? I always loved it in concept but very very rarely saw people actually trying to use it in the wild, outside of the types of people who read this list. -Ryan McGinnis https://bigstormpicture.com PGP: 486ED7AD Sent with ProtonMail ??????? Original Message ??????? On Sunday, June 30, 2019 3:01 PM, Ralph Seichter wrote: > * david at gbenet.com: > > > Your Thoughts :) > > I think the article is five years old, has not aged well (e.g. MUA > integration has improved), and that nothing better than PGP has come > along in the meantime. > > Next. ;-) > > -Ralph > > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Jul 1 00:57:11 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 18:57:11 -0400 Subject: Your Thoughts In-Reply-To: <-Yr6HFqptjWfO3cPpx8sz6H6nC2UDuSlbV4J41vPrxCQHj4N1hUTi5FI3RXqrf0iw3TmFgUq1Pu5oo0A3IAVGH-fsjHJI_vUfSve-OoLjRI=@digicana.com> References: <87d0iuonab.fsf@ra.horus-it.com> <-Yr6HFqptjWfO3cPpx8sz6H6nC2UDuSlbV4J41vPrxCQHj4N1hUTi5FI3RXqrf0iw3TmFgUq1Pu5oo0A3IAVGH-fsjHJI_vUfSve-OoLjRI=@digicana.com> Message-ID: <24495751-6827-2bb2-df05-4dba6f42f673@sixdemonbag.org> > Does anyone know what PGP?s peak adoption rate was? We're living in it. OpenPGP is used on a scale the protocol designers never dreamed, mostly for verifying operating system packages. Peak _email_ adoption rate? It's never been any kind of serious player in that space. I've seen it used productively in nonpermissive environments where other tools simply could not suffice. I do not recommend it as a casual tool: but when nothing else will do, well... nothing else will do. From guilhem at fripost.org Mon Jul 1 01:23:28 2019 From: guilhem at fripost.org (Guilhem Moulin) Date: Mon, 1 Jul 2019 01:23:28 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: <20190630222311.puzaxll25pcmo2lq@x220.qyliss.net> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <20190630185603.GA17531@fripost.org> <20190630222311.puzaxll25pcmo2lq@x220.qyliss.net> Message-ID: <20190630232328.GA25033@fripost.org> On Sun, 30 Jun 2019 at 22:23:11 +0000, Alyssa Ross wrote: >> Third-party signatures from locally unknown certificates are arguably >> not so useful, so how about using ?--keyserver-options import-clean?? >> (Or even making it the default behavior?) Of course it's not perfect as >> it still clutters network traffic and gpg(1) needs to clean up the mess >> client-side (which is slow and CPU expensive), but at least it mitigates >> the DoS attack: it doesn't prevent keyring updates, and limits the bloat >> on disk. > > Alas, this doesn't fully mitigate the issue, because it's not exactly > difficult to get a key into somebody's keyring, especially with the > existence of the auto-key-retrieve option. Ah yeah, good point. At least this vastly limits the scope of the attack: instead of affecting every keyring upon refresh/import, the attacker needs to somewhat target which keyring they want to poison. -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon Jul 1 01:36:41 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 19:36:41 -0400 Subject: Your Thoughts In-Reply-To: <87d0iuonab.fsf@ra.horus-it.com> References: <87d0iuonab.fsf@ra.horus-it.com> Message-ID: <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> > I think the article is five years old, has not aged well (e.g. MUA > integration has improved), and that nothing better than PGP has come > along in the meantime. I think Matthew Green is a very sharp fellow and his criticisms are thoroughly on-point. My biggest complaint about that article is that he doesn't draw a clean distinction among the OpenPGP specification, how software packages like GnuPG choose to implement the specification, and the supporting ecosystem that is neither OpenPGP nor implementation. The OpenPGP spec says surprisingly little about what the format of a key should be, for instance. If you look at GnuPG's key export format, it was chosen in the late '90s to be interoperable with PGP Security's PGP 5.0 offering (which was, at the time, pretty much cutting-edge). Well -- nowadays GnuPG is the big mover in that space. There's a strong argument to be made that GnuPG should be more of an innovator. There's no reason anymore to retain the old and inefficient PGP 5 format. We can change it and still be compliant with the spec: maybe we should. I think we should. And hey, if we fix the key exchange format, that's one massive section of his objections gone. That set of objections isn't to OpenPGP, it's purely about how we implement it. Another major complaint of his is the keyserver network, which we've known for years was inadequate. It was also the only game in town and there was neither the money nor the manpower to do a better job. Now we've got Autocrypt, WKD, and Hagrid: of these Autocrypt is probably the most mature and the easiest for email users. We've got three at least arguably better ways of distributing certificates: if we can actually persuade people to start using them, we can fix this and wipe another set of complaints off his list. His set of objections here is not to either OpenPGP or an implementation of it, but rather the support ecosystem. (Note to anyone who thinks I'm saying "it's kinda good that this Great Unpleasantness is happening because it's making people migrate": no. Absolutely not. The people behind this deserve to be shunned by our community and exiled from our mailing lists. They are not our friends.) About the only actual protocol-level complaints Professor Green has are: 1. OpenPGP has no forward secrecy. (Correct! I'd love to see the OpenPGP Working Group tackle this. I'm not sure it can be done for offline asynchronous communications, but it would be good to at least investigate the possibilities.) 2. OpenPGP has no AE/AEAD mode. (Incorrect! The MDC is a form of authenticated encryption. It predates modern AE/AEAD and looks kind of baroque to modern eyes, but it's AE. The fact some mail clients *ignore* the AE is a different [and very serious!] matter. Further, the latest RFC4880bis spec -- which was written after Professor Green's blogpost -- explicitly incorporates modern AE/AEAD.) My complaint about Professor Green's blogpost is that he treats PGP as a single monolithic block, instead of as different plants in a garden that all grow interdependently. The OpenPGP protocol is solid. But we can, and I think we need to, do a serious modernization pass on how we choose to *implement* that protocol. If I were to set priorities for GnuPG? 1. Set a flag day. Past a certain date, old-and-busted certificates and data formats will simply not be supported. They won't be written, they won't be read, they won't be processed, GnuPG will simply say "nope, that might be legit old-school RFC4880 traffic but I'm not going to play that game." 2. Overhaul the key format. 3. Do away with user IDs. Only use key IDs. If a user wants to associate a key with an email address, let them: but user IDs originally existed *mostly* to support the email use case, and with the advent of Autocrypt that's not such an issue any more. (Note that a lot of thorny problems suddenly just *go away* if you stop using userIDs.) 4. Require a limited subset of the RFC4880bis standard to be used. Keep support for adding ciphers to the spec -- algorithm agility is a wonderful thing -- but by default only use one specific ECC algorithm in one specific key length, with AES256 as a symmetric cipher, and SHA512 for a hash. GnuPG's ability to support arbitrary preferences and algorithms is neat technically but I have literally *never* seen it be necessary in field usage, and I have seen people accidentally degrade their security literally *hundreds* of times. (If your cipher preferences are 3DES AES128 AES256, for instance? Say hello to 3DES: you will literally never use AES256.) 5. If we're going to continue to have a keyserver network the only way forward is to burn it down and build something newer and better. There are no other realistic options. 6. Develop a well-defined output format. Werner & co. like to say the output of --with-colons is well-defined. It's not. Unless there's something like a DTD or a BNF specification and the output can be formally verified against the specification, what you have is ad hoc. The processing bugs the Efail paper exploited were overwhelmingly caused by MUA authors misunderstanding or misinterpreting the output GnuPG was giving it. ... Would this be painful? Sure. But it doesn't involve throwing out the OpenPGP spec, just overhauling how we implement it and the supporting software ecosystem. That would be *hard*, don't get me wrong, and I am *in no way* saying this would be easy. But worth it? I dunno. Maybe. Yeah. Let's throw it out there, let's talk about it. But that's just me. :) From andrewg at andrewg.com Mon Jul 1 01:53:41 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 1 Jul 2019 00:53:41 +0100 Subject: Your Thoughts In-Reply-To: <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> Message-ID: <242B955E-F877-4255-A289-8E080B7A255A@andrewg.com> > On 1 Jul 2019, at 00:36, Robert J. Hansen wrote: > > Would this be painful? Sure. But it doesn't involve throwing out > the OpenPGP spec, just overhauling how we implement it and the > supporting software ecosystem. That would be *hard*, don't get me > wrong, and I am *in no way* saying this would be easy. Is it worth drawing up a work program for the ecosystem, some sort of priority list of what needs fixed, how urgent each is, and what dependencies there are between different components? For example, say we want to make it possible to work without any IDs. How many things need changed? How urgent is it compared to, say, getting Hagrid up to spec as an sks replacement? Where should we concentrate our efforts? This list will be long. A From rjh at sixdemonbag.org Mon Jul 1 03:52:45 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 21:52:45 -0400 Subject: Your Thoughts In-Reply-To: <242B955E-F877-4255-A289-8E080B7A255A@andrewg.com> References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> <242B955E-F877-4255-A289-8E080B7A255A@andrewg.com> Message-ID: <6fc3bd29-3202-99df-b249-493d8dc83e88@sixdemonbag.org> > This list will be long. Yes. And frankly, it's a bigger subject than just GnuPG: to be effective we'd need to get buy-in from OpenPGP.js and Sequoia, for starters. Optimistically, we'd be looking at two years of work, maybe more. One of the things I'm beginning to consider, though, is that it might be a good idea to make the Implementation-Future group invitation-only. Over the last few years I have *really* lost faith in the idea of open and unmoderated groups. The gist I posted where I outlined the poisoned-certificates attack took all of three messages before someone started accusing me of being a bigot on account of my belief that child pornography is a moral evil... https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f#gistcomment-2957390 From mirimir at riseup.net Mon Jul 1 04:08:19 2019 From: mirimir at riseup.net (Mirimir) Date: Sun, 30 Jun 2019 19:08:19 -0700 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: <5b4f779f-8669-2785-a92c-c75b48357f8d@riseup.net> On 06/30/2019 07:33 AM, Robert J. Hansen wrote: >> Your third point is actually why I suggested this. Maybe I'm just >> twisted, but what if some dickhead goes after certs that would break >> stuff for millions of people? One might, for example, block Linux kernel >> maintenance and development. Maybe just before using some 0-day. > > For whatever it's worth, as soon as I heard word there were poisoned > certificates in the strong set I spoke to a friend who's well-connected > in the kernel community and made sure to pass on the warning and the > mitigation. > > I am not worried about the kernel hackers being hit. They're > technically savvy, close-knit, and largely self-sufficient technologically. OK, that's great news. And I get from the HN thread that repository keys are updated via signed packages, with no calls to SKS keyservers. So I'm no longer freaking about that level of damage. > I'm very worried about people who lack technical skills (for many > people, just editing a config file is beyond them), who are in loose > contact with the GnuPG/keyserver community (people who might check in > once a year to see if there's any major updates), who are dependent on > others for their communications ("I don't know how this works, my IT > department sets it up for me"). > > Those people are -very- vulnerable to this. They're going to get hit hard. Yes, people like me. Whose Enigmail was setup to query SKS keyservers. So somehow they must be alerted. >> It would stop when certs can no longer be poisoned. > > Please show me how we can prevent certs from being poisoned. This is a > phenomenally hard problem. You are handwaving away a huge amount of > difficulty. > > What you are saying here is, "it would never end." Well, given what you've said about the chances that SKS keyservers will get fixed, it would likely never end for them. From what I've read, I gather that spam signatures to them can't be blocked. But using keyservers like hkps://keys.openpgp.org, certs couldn't be poisoned, right? Right now, I gather, keys can't even be signed after uploading. So basically, it would end when we switch to them, or to another secure alternative. And yes, hkps://keys.openpgp.org would fall over and die if too many users started using it. So cert poisoning will be an issue until there's a secure alternative. >> I don't see that as "doing the bad guys? work for them". I see it as >> preventing bad guys escalating from hurting a few people to doing >> serious damage. That's not "punishing the victim". > > "Look, this one guy who just got mugged? Clearly the street gang > doesn't like him. So if we just, you know, don't help him, then the > gang won't also go after us. We're not 'punishing the victim'. We're > just saying, the needs of the many outweigh the needs of the few. I > mean, it's too bad, what's happening to him. And it's too bad the gang > is making us turn our backs and walk away. > > I bet that once we're a block away we're not going to be able to hear > him screaming. > > Come on, let's walk faster." I apologize. I know that this has been horrible for you. And I get that it's not at all your fault. Nonetheless, your key on the SKS keyservers is hosed. It could happen to anyone. And given the design, it can't be fixed. However, it's not like your key and its authentic signatures are lost. You have it on your machines, it's at https://keybase.io/rjh, and you could put the key on hkps://keys.openpgp.org or another keyserver. So it's not you that's getting thrown under the bus. It's the SKS keyserver network that's getting thrown under the bus. And if someone needed signatures only available from the SKS keyservers, there must be some way to recover them. One could import the key safely, edit the signatures, and then put it on some secure keyserver. From mirimir at riseup.net Mon Jul 1 04:18:57 2019 From: mirimir at riseup.net (Mirimir) Date: Sun, 30 Jun 2019 19:18:57 -0700 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> Message-ID: <13aba65a-6ac8-7e33-70c6-363e6c7e7c79@riseup.net> On 06/30/2019 08:33 AM, Peter Lebbing wrote: >> "Look, this one guy who just got mugged? [...] > > I had to read it twice to distill what I think Mirimir meant, but I > think they meant that if you blacklist/blackhole all affected > certificates, you remove the incentive for the attackers to poison more > certificates since the poison can't spread to the people fetching keys. > Thus stopping the attackers. Thanks. That's almost right. But I'm not focusing on incentives. I'm focusing only on impacts. Because as I understand it, you can't stop people from poisoning certificates on the SKS keyservers. > I concluded that Mirimir perhaps forgot about that this creates a second > attack model, where you can block keys from being on the keyserver. This > seems like a new problem that means this stopgap measure is probably not > the one we want, since it still provides the incentive for attackers to > poison keys. > > Peter. I didn't forget about that. I just don't think that it matters. Unless I've misunderstood the situation, the SKS keyservers are dead meat. And have been dead meat for a decade. So the focus has gotta be on a secure and capable replacement. And meanwhile, on mitigating damage done through the SKS keyservers. From mirimir at riseup.net Mon Jul 1 04:26:06 2019 From: mirimir at riseup.net (Mirimir) Date: Sun, 30 Jun 2019 19:26:06 -0700 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <3c41fbc2-4862-289d-d0ed-8ff3484ea98b@andrewg.com> Message-ID: <255a2471-565a-7dd1-6d22-133c6b046914@riseup.net> On 06/30/2019 08:55 AM, Andrew Gallagher wrote: > >> On 30 Jun 2019, at 15:07, Erich Eckner via Gnupg-users wrote: >> >> maybe I don't get the original idea - but I thought, it was to block *uploads/updates* which would poisson a certificate - not to blackhole them after they got poissoned? No, I did mean blackholing poisoned certs. > Hm, that?s not how I read it, although I could be wrong. It is possible to prevent submission of bad keys, but this just leads to new problems: > > 1. We would have to ensure that all keyservers block the same uploads. One permissive keyserver is a backdoor into the entire system. We can?t block bad keys at reconciliation time for the same reasons that have been hashed to death already. > > 2. Although it may be possible to block an individual upload of tens of thousands of key packets, it will not in general be possible to prevent an attacker from incrementally increasing the number of packets attached to a key over time. If we impose a reasonable limit on the cumulative number of packets attached to a key, that key may never become undownloadable, but it will at some point become unmodifiable - so we have just transformed one DOS vector into a different one. > > A It does seem that it's impossible to keep certs on the current SKS network from being poisoned. I only see two alternatives: 1) fixing SKS, and 2) replacing SKS. And meanwhile, preventing poisoned certs on SKS from doing further damage. From mirimir at riseup.net Mon Jul 1 04:44:45 2019 From: mirimir at riseup.net (Mirimir) Date: Sun, 30 Jun 2019 19:44:45 -0700 Subject: SKS Keyserver Network Under Attack In-Reply-To: <875zon0ya3.fsf@llwynog.ekleog.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <3c41fbc2-4862-289d-d0ed-8ff3484ea98b@andrewg.com> <875zon0ya3.fsf@llwynog.ekleog.org> Message-ID: <0012a4bf-c79b-c180-851d-50682a55413d@riseup.net> On 06/30/2019 10:37 AM, Leo Gaspard via Gnupg-users wrote: >> 1. We would have to ensure that all keyservers block the same >> uploads. One permissive keyserver is a backdoor into the entire >> system. We can?t block bad keys at reconciliation time for the same >> reasons that have been hashed to death already. > > One way to do that, though it would mean officially sunsetting SKS, > might be to: > > 1. Publish an update to SKS that: > - Blocks all uploads of any packet that is not a revocation signature > packet (maybe also having to check the revocation is actually > correctly signed, to avoid flooding of revocation packets to become > the new flaw) I wasn't suggesting that. As long as only a few keys are being poisoned, it's arguably not necessary, and too disruptive. But if this becomes a game in the chans, that might become necessary. > - Embeds a hardcoded list of already-disrupted keys for which packets > should be filtered-out when serving them That's what I meant. Plus some mechanism for testing keys, so poisoned ones are blocked, as soon as possible. It'd also be useful for SKS to report "this key has been poisoned", and suggest alternative sources, rather than just failing silently. > 2. Pressure keyserver operators into updating > > 3. Kick all not-up-to-date keyservers from the pool after some delay > deemed acceptable (shorter means less broken GnuPG, longer means less > keyservers kicked out) > Note: I do not know how the pool is handled. Maybe this would mean > that the new update to SKS would need to stop synchronizing with > earlier versions, and that the hkps pool should be turned off until > enough keyservers are updated to handle the load? Makes sense. > Do you think such a plan might be reasonably done, to at least keep the > most basic functionality of not breaking existing installations and > allow them to keep revocations flowing? The biggest issue I can see is > it requires a quite big amount of development work. But less work than actually fixing SKS, right? > Hope that helps, > Leo > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From rjh at sixdemonbag.org Mon Jul 1 04:48:01 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Jun 2019 22:48:01 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: <5b4f779f-8669-2785-a92c-c75b48357f8d@riseup.net> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <5b4f779f-8669-2785-a92c-c75b48357f8d@riseup.net> Message-ID: <5b624954-b040-2757-be4f-9bdd8faae8d7@sixdemonbag.org> > OK, that's great news. And I get from the HN thread that repository keys > are updated via signed packages, with no calls to SKS keyservers. So I'm > no longer freaking about that level of damage. Eh. Yes. No. Hard to say. The problem is that many of these distros allow third parties to run their own repositories under more permissive rules, and some of these third parties are extremely popular. Plus, often sysadmins will roll their own RPMs of packages: in such cases you quickly lose the ability to say definitively what will or will not happen. If the major distros update their distro signing certificates through signed packages, great: that's good. But don't go thinking that means you're out of the woods. Whenever anyone gives you concrete yes-or-no, this will-or-won't happen answers about a complicated ecosystem that has a ton of hidden bits that can't be seen, that person most likely has misunderstood the problem. From hello at ezaquarii.com Mon Jul 1 06:59:00 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Mon, 01 Jul 2019 04:59:00 +0000 Subject: SKS Keyserver Network Under Attack In-Reply-To: <3f88910b-fcfd-e8b9-62e0-077a5f35f584@andrewnesbit.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <3f88910b-fcfd-e8b9-62e0-077a5f35f584@andrewnesbit.org> Message-ID: <8B6695B5-873A-469F-8385-C15881FF64CA@ezaquarii.com> > I must have missed the memo > describing the exact nature of the problem. https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Mon Jul 1 10:37:01 2019 From: markr at signal100.com (Mark Rousell) Date: Mon, 1 Jul 2019 09:37:01 +0100 Subject: SKS Keyserver Network Under Attack In-Reply-To: <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> Message-ID: <5D19C62D.5080109@signal100.com> On 30/06/2019 13:44, Robert J. Hansen wrote: > This has all the hallmarks of a child playing with matches and > clapping with glee as the house catches fire. I think not. You yourself say that the SKS system has had known problems for well over a decade and yet nothing has been done about it. In other words, inertia has overruled both prudence and strategic avoidance of predictable problems[1]. Well, someone has now brought widespread attention to the issue. By poisoning the certificate of (at least) two very high-profile members of this community, they have brought absolutely unavoidable attention to the fact that something needs to be done *now*. As things stand, it's still not too late for something to be done to protect the vast majority of users and use cases. Good can come of this attack on you and DKG. Yes, as you say in your Gist, the attackers could have come to you and worked together. But I can also understand why they didn't: This approach has made waves, and sometimes waves are necessary to wake up a community that really knows it should be taking action but hasn't done so. Both you and DKG are clearly furious that you were targetted (and rightly so!) but if 'lesser' members of the community had been attacked in this way it's entirely possible that either no one would have noticed or that it would not have had the radical shake up effect that this is now having. I'm not condoning an attack like this. In the UK (where I am located) it is likely to be illegal, and it is probably illegal in other jurisdictions. But I just don't see a "child [...] clapping with glee". Instead it seems to me that the net result is that long overdue action is now taking place. Thank you for all your input into OpenPGP. Yes, it's made you a target. But, despite the seemingly personal nature of this, it does seem that good can come of it. (And for the avoidance of doubt: I do not know who was behind this and it was not me.) Footnote:- 1: You referred to this inertia as "powerful technical and social factors" which is true but they still represent a bug, not a feature. These factors are in effect societal excuses, not legitimate reasons for lack of action. As I write this, I fully appreciate the fact that very few people receive remuneration for writing code or maintaining key servers (or much of anything else connected with OpenPGP). But again, perhaps this is also a bug of sorts. Perhaps there does need to be a way for critical non-hierarchical Internet infrastructure like this to be financed. Isn't Eric S. Raymond working on something like this right now? -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at gbenet.com Mon Jul 1 11:53:47 2019 From: david at gbenet.com (David) Date: Mon, 1 Jul 2019 10:53:47 +0100 Subject: Your Thoughts In-Reply-To: <87d0iuonab.fsf@ra.horus-it.com> References: <87d0iuonab.fsf@ra.horus-it.com> Message-ID: On 30/06/2019 21:01, Ralph Seichter wrote: > * david at gbenet.com: > >> Your Thoughts :) > > I think the article is five years old, has not aged well (e.g. MUA > integration has improved), and that nothing better than PGP has come > along in the meantime. > > Next. ;-) > > -Ralph > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > I have used gnupg for years and converted just a handful to encrypt their emails - and it's beyond my comprehension why it is that normal people do not encrypt their emails by default. Over the years GUIs have come along and gpg4win - perhaps people are not that concerned about GCHQ and the NSA reading all their emails - they read everything else from all thier devices. We know FaceBook Google etc.. hand over all data to the NSA and GCHQ and their are rumours that SSL has been cracked - am sure it has as my website and database were hacked and my host provider had 3 mail servers hacked in a matter of 3 days - much to their shock. I think for Windows users gpg4win attempts to provide a GUI that makes installation easy - but only geeks use it :) I try to promote user encryption on my website (it's down at this time) but very very few people take their daily lives seriously. David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Jul 1 11:54:26 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 1 Jul 2019 05:54:26 -0400 Subject: SKS Keyserver Network Under Attack In-Reply-To: <5D19C62D.5080109@signal100.com> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> <5D19C62D.5080109@signal100.com> Message-ID: <8fa2ef83-6f65-b1c4-6347-134c331a4b0c@sixdemonbag.org> > I think not. Thankfully we live in free societies where dissent is allowed: on good days, even tolerated and encouraged. You're wrong, of course, but please understand I encourage you to be wrong. :) Also, if it isn't clear: although I emphatically disagree with you, this is not a personal dispute. I plan on turning your idea into a pinata, but on a personal level as far as I'm concerned there's nothing but peace between us. > You yourself say that the SKS system has had known problems for well > over a decade and yet nothing has been done about it. No. No. No. I have not said that. In the last ten years the sks-devel at nongnu.org community has explored pretty thoroughly the problem space and concluded it cannot be solved at the SKS level, given the community's level of manpower and funding. That's not "nothing". That's a very important result and it is literally the most the sks-devel community can be asked or expected to do, given their critical shortages of money and manpower. In a very real sense, WKD, Autocrypt, Hagrid, dkg's work in abuse-resistant keyservers, and so forth, all sprang from the sks-devel community's recognition of the problem and the inability of SKS to effectively fix it. If SKS were in better shape it's likely none of those projects would have ever started. There is a line of thinking which I find to be morally appalling, and you describe it quite clearly in your footnote: > 1: You referred to this inertia as "powerful technical and social > factors" which is true but they still represent a bug, not a > feature. These factors are in effect societal excuses, not legitimate > reasons for lack of action. If the sks-devel community has repeatedly made it clear over the course of a decade that "we lack both the manpower and the financial resources to fix this problem", never receives manpower or financial resources, and then ten years later this happens... our reward is to be victim-blamed? "If you were really serious you would've done something by now"? It's like telling a doctor in the developing world who has for ten years been screaming that she needs polio vaccine, after a polio epidemic starts in her neighborhood, "the poverty is in effect a societal excuse, not a legitimate reason for lack of action"? It takes stuff to do stuff, and it's really rude to blame the victims for problems they inherited but did not create. > Well, someone has now brought widespread attention to the issue. By > poisoning the certificate of (at least) two very high-profile > members Three now, since apparently Kristian has been hit. > of this community, they have brought absolutely unavoidable attention > to the fact that something needs to be done *now*. At a tremendous price. A price that I, and many others, think is morally appalling. These people are not our friends and have done us no favors. > Good can come of this attack on you and DKG. I seem to recall people saying the same after 9/11: that yes it was a horrific thing, but that "good can come of this tragedy". I seem to recall people saying the same after my best friend's suicide: that yes it was a horrific thing, but that "good can come of this tragedy". It is the nature of goodness that, like hope, it springs eternal and in the most unlikely of places. But it is also barbarous to claim the good that may come out of a horror should be counted to the horror's credit. From peter at digitalbrains.com Mon Jul 1 12:44:38 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 1 Jul 2019 12:44:38 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: <8fa2ef83-6f65-b1c4-6347-134c331a4b0c@sixdemonbag.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> <5D19C62D.5080109@signal100.com> <8fa2ef83-6f65-b1c4-6347-134c331a4b0c@sixdemonbag.org> Message-ID: <7dd4dbbd-bd22-5509-6ec1-5cc653c2bc79@digitalbrains.com> On 01/07/2019 11:54, Robert J. Hansen wrote: > [...] I think this mail sums up the most important points about this whole ordeal very well. I completely, wholeheartedly agree. I encourage everyone to re-read it and internalise it. The only point not touched upon in this specific mail, I think, is why people who say that the damage that has been done is not of consequence, are wrong. It seems to me that rjh's and dkg's keys will be in many public keyrings and in many (key) signature chains, and thus have the potential to cause major problems for many people all around the world when they refresh their keys. I'd say the consequences of poisoning precisely these well-connected keys are pretty major. People who depend upon OpenPGP will find their software is hung and timing out, even when they're not trying to do anything with these specific public keys: often it's enough the poison is on the keyring, as far as I can tell. Lacking the knowledge to fix this, they will no longer be able to check signatures, and probably be unable to read encrypted messages altogether. For me, that'd be a nuisance. For some people, it may have very large real-life consequences. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From hi at alyssa.is Mon Jul 1 00:23:11 2019 From: hi at alyssa.is (Alyssa Ross) Date: Sun, 30 Jun 2019 22:23:11 +0000 Subject: SKS Keyserver Network Under Attack In-Reply-To: <20190630185603.GA17531@fripost.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <20190630185603.GA17531@fripost.org> Message-ID: <20190630222311.puzaxll25pcmo2lq@x220.qyliss.net> > Third-party signatures from locally unknown certificates are arguably > not so useful, so how about using ?--keyserver-options import-clean?? > (Or even making it the default behavior?) Of course it's not perfect as > it still clutters network traffic and gpg(1) needs to clean up the mess > client-side (which is slow and CPU expensive), but at least it mitigates > the DoS attack: it doesn't prevent keyring updates, and limits the bloat > on disk. Alas, this doesn't fully mitigate the issue, because it's not exactly difficult to get a key into somebody's keyring, especially with the existence of the auto-key-retrieve option. All I would have to do would be to sign the key of somebody in the strong set lots of times with the same key, and then send you an email signed by me, and an email with a body signed by the key I was attacking (I could find some sort of statement signed by that key online somewhere). Alternatively, I could construct a Git repository that would load the keys into your keychain in the correct order when you examined the commit signatures if I could find a commit signed by my victim somewhere. I'm sure it's easy enough to get a public key imported even without auto-key-retrieve, too. I imagine there are MUAs that would import a key attached to a message, maybe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From markr at signal100.com Mon Jul 1 12:57:53 2019 From: markr at signal100.com (Mark Rousell) Date: Mon, 1 Jul 2019 11:57:53 +0100 Subject: SKS Keyserver Network Under Attack In-Reply-To: <8fa2ef83-6f65-b1c4-6347-134c331a4b0c@sixdemonbag.org> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <45f2bc73-b2b2-80af-9649-2f21ae19d6bf@sixdemonbag.org> <5D19C62D.5080109@signal100.com> <8fa2ef83-6f65-b1c4-6347-134c331a4b0c@sixdemonbag.org> Message-ID: <5D19E731.1020401@signal100.com> On 01/07/2019 10:54, Robert J. Hansen wrote: >> I think not. > Thankfully we live in free societies where dissent is allowed: on good > days, even tolerated and encouraged. You're wrong, of course, but > please understand I encourage you to be wrong. :) > > Also, if it isn't clear: although I emphatically disagree with you, this > is not a personal dispute. I plan on turning your idea into a pinata, > but on a personal level as far as I'm concerned there's nothing but > peace between us. I can see that you are (rightly and understandably) very, very angry that this has been done and that you have been personally targetted but it nevertheless seems to me that it is not a childish act. Its very carefully targetted nature strongly suggests to me that is was done to produce specific results (which should actually be beneficial for the community as a whole). This does not mean that I condone the act. I do not! It was a bad thing to do in this form. > >> You yourself say that the SKS system has had known problems for well >> over a decade and yet nothing has been done about it. > No. No. No. I have not said that. In the last ten years the > sks-devel at nongnu.org community has explored pretty thoroughly the > problem space and concluded it cannot be solved at the SKS level, given > the community's level of manpower and funding. And yet, despite this, SKS is still in use and not currently fully replaceable, as I understand it. Is that not a problem of inertia? It certainly seems like it to me. No natter what the issue of lack of manpower or lack of funding, if these have not been overcome in 10+ years despite there being widely recognised problems then that's inertia. (No, this is not "victim-blaming". Read on for why not). However, all is not so dark as it might seem. You go to say... > In a very real sense, WKD, Autocrypt, Hagrid, dkg's work in > abuse-resistant keyservers, and so forth, all sprang from the sks-devel > community's recognition of the problem and the inability of SKS to > effectively fix it. If SKS were in better shape it's likely none of > those projects would have ever started. But this is good. It means that, in large part, inertia has in fact been overcome from new directions. People have contributed to improving things through innovation and new approaches. It just needs to go that little bit further, it seems. > There is a line of thinking which I find to be morally appalling, and > you describe it quite clearly in your footnote: > >> 1: You referred to this inertia as "powerful technical and social >> factors" which is true but they still represent a bug, not a >> feature. These factors are in effect societal excuses, not legitimate >> reasons for lack of action. > If the sks-devel community has repeatedly made it clear over the course > of a decade that "we lack both the manpower and the financial resources > to fix this problem", never receives manpower or financial resources, > and then ten years later this happens... our reward is to be > victim-blamed? "If you were really serious you would've done something > by now"? Don't be silly. I was merely pointing out how change is sometimes needed to overcome roadblocks. In corporate circles they (annoyingly enough) call it "thinking out of the box". Furthermore, I am not "victim-blaming" as you claim. Lack of manpower and funding is not what I regard as victimhood. Lack of manpower and/or finding is just normal life for many, many projects or human endeavours and is a natural and normal issue that needs to be overcome somehow for any project or endeavour of almost any type to initially succeed and then to be maintained. In my own case, I am involved in a project that I would dearly like to do better and it is in fact held back by lack of both manpower and funding. However, when people tell me that I need to overcome these issues, no matter how difficult they are to overcome, I do not claim victimhood or say that my critic is "victim-blaming" me. Instead I agree and ask my critic for possible sources of manpower or funding, or for other ways to address the issues that the project is intended to solve. And you will note in the footnote I did in fact mention an initiative that Eric S. Raymond is working on that might, at least in part, address issues of funding. So I have not made the mistake of criticising without at least offering some possible solution to the obvious problem. > >> of this community, they have brought absolutely unavoidable attention >> to the fact that something needs to be done *now*. > At a tremendous price. A price that I, and many others, think is > morally appalling. These people are not our friends and have done us no > favors. Time will tell. Do you think that something substantive will now be done that could not be done before because of previous lack of manpower or funding? Sometimes, the obvious and undeniable existence and public highlighting of an egregious flaw prompts the new availability of manpower and/or funding that was not available before because the flaw was too easy to ignore. It does look to me as if this is what might now happen. You (and others) should not have been the victims to make this happen, of course. That was unfair, wrong, and criminal. > >> Good can come of this attack on you and DKG. > I seem to recall people saying the same after 9/11: that yes it was a > horrific thing, but that "good can come of this tragedy". I think that this is something of an extreme comparison, and extreme comparisons always stretch reason. Nevertheless, I'll go along with it for now: In truth, some good did come of 911. But, yes, the world would certainly have been better off if 911 had never happened. However, the issue at hand here is a little different. There has been no widespread attack. It's been targetted. I say again that the attack being targetted does not excuse it but it does mean that the dynamics of the situation are very different. In this case, unlike 911, a very specific and very longstanding (you did say that it has been very longstanding) flaw has been publicly and undeniably highlighted. This could provide, and most certainly *should* provide, the catalyst for something new to be done; a new incentive, new motivation, new urgency. > But it is also barbarous to claim the good > that may come out of a horror should be counted to the horror's credit. I did not "credit" the horror. In fact I said that it was probably criminal! It was a bad thing to do to you! And yet, no matter how bad it was, it does seem that the attacker's motivation is blindingly obvious and that good things definitely can and *should* come of this shock to the system. The inertia to which I referred was and is real. And, let's face it, it's not as bad as either 911 or a suicide. This is bad, but it's not a disaster. And a disaster *can* still be avoided in this context. At risk of sounding like a politician, this is a wakeup call. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg at leo.gaspard.ninja Mon Jul 1 14:08:24 2019 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Mon, 01 Jul 2019 14:08:24 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: <0012a4bf-c79b-c180-851d-50682a55413d@riseup.net> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <3c41fbc2-4862-289d-d0ed-8ff3484ea98b@andrewg.com> <875zon0ya3.fsf@llwynog.ekleog.org> <0012a4bf-c79b-c180-851d-50682a55413d@riseup.net> Message-ID: <87sgrqyn2f.fsf@llwynog.ekleog.org> Mirimir via Gnupg-users writes: >> - Embeds a hardcoded list of already-disrupted keys for which packets >> should be filtered-out when serving them > > That's what I meant. Plus some mechanism for testing keys, so poisoned > ones are blocked, as soon as possible. > > It'd also be useful for SKS to report "this key has been poisoned", and > suggest alternative sources, rather than just failing silently. I think we can't rely on humans actually reading the output, even if GnuPG was able to display the output on eg. `--refresh-keys` in a way understandable by a human. Also, the aim of my suggestion was to actually *not* block the keys. This second point of part 1 is there to just filter some hardcoded list of packets, thus making key updates still propagate. The first point was there to prevent additional keys from being poisoned, and the second to limit the damage caused by already-existing keys -- the first one is unfortunately quite necessary, as sks-keyservers can't reasonably be coordinating changes on the ~220 keyservers every time a new key gets poisoned (or even twice, for that matter, one flag day is already bad enough) >> Do you think such a plan might be reasonably done, to at least keep the >> most basic functionality of not breaking existing installations and >> allow them to keep revocations flowing? The biggest issue I can see is >> it requires a quite big amount of development work. > > But less work than actually fixing SKS, right? Well, nowadays ?fixing SKS? means ?making hagrid able to synchronize its cryptographic-only content and propagate third-party signatures under some circumstances?, as far as I understand. From bernhard at intevation.de Mon Jul 1 12:18:29 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 1 Jul 2019 12:18:29 +0200 Subject: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts) In-Reply-To: <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> Message-ID: <201907011218.37327.bernhard@intevation.de> Am Montag 01 Juli 2019 01:36:41 schrieb Robert J. Hansen: > Now we've got Autocrypt, WKD, and Hagrid: of these Autocrypt is probably the > most mature and the easiest for email users. The problem with autocrypt are the cases where its security measures are tested. There is not good way to interact with the users in those cases. I know this is not parts of its design goals, but it works against a better user experience. The progrem with hagrid (from what I've heard) is that it is again an attempt of a validating keyserver, which means it has to centralize the trust function or there is no point in the validation. This makes WKD most mature and easiest for users in my eyes. (I was involved in its design.). Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From andrewg at andrewg.com Mon Jul 1 14:36:43 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 1 Jul 2019 13:36:43 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <87o92fngtq.fsf@fifthhorseman.net> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> Message-ID: On 2019/06/30 18:06, Daniel Kahn Gillmor wrote: > On Sun 2019-06-30 00:33:22 +0100, Andrew Gallagher wrote: >> Indeed, c) was exactly the killer use case I had in mind. > > so, how do we get there? We start from hagrid or something like it, and carefully add the ability to sync only the absolute minimum of data required to allow revocations to propagate. This probably means primary keys, their self-sigs and revocation sigs. (*Maybe* subkeys also, but it's probably unnecessary since distributing new key material is less urgent than revoking existing material.) We could repurpose the existing SKS recon protocol, but introduce breaking changes: a) the protocol is versioned so that implementations can gracefully degrade, and b) only whitelisted packet types are synced. >> On the other hand, b) is also quite useful in the short to medium >> term, until all mail providers decide to support WKD etc. > > WKD is mighty nice, but it is not necessary. For example, if you don't > care about first-contact, Autocrypt is a totally reasonable key > discovery mechanism. Sure, but WKD and Autocrypt still don't collectively cover all the edge cases, so some residual need for a keyserver-like system remains. >> And considering that some companies still don?t fully support PGP/MIME >> after nearly twenty years of being the preferred standard (I?m looking >> at you, Apple), ?short to medium? effectively means ?indefinitely?. > > If you know something specific about Apple failing PGP/MIME in some > capacity i hope you'll be more explicit about it, because i don't know > what you're talking about. iOS's native Mail app cannot be replaced, and all third-party mail apps must use its API which is less than fully-featured. Constructing a PGP/MIME message requires access to the MIME headers that the Mail app does not expose. All PGP apps under iOS must either cut and paste inline PGP or encapsulate messages as attachments that Mail treats as black boxes. PGP on iOS is therefore klunky as hell, and it's not going to improve unless Apple makes a conscious decision to support it. > Anyone who claimed > keyservers were authoritative in the past was either confused or > misleading you. I am under no illusion that the keyservers are authoritative, don't worry. A comparison with DNS may be useful. DNS is a distributed cached database, but there is a distinction between primary, secondary, recursive etc. Recursive resolvers make the system resilient, but the primary is consulted regularly and the cache constantly invalidated. (In DNS of course, the master is also considered authoritative, but this does not automatically follow in a cryptographically validating system) The keyservers make no distinction between primary and secondary - all keyservers are equal, the provenance of data is thrown away, and the cache can therefore never be invalidated. But provenance matters, and if synchronising keyservers can't be primaries, something else should be. That can be WKD, DANE, or just a plain URL on a server that I control. Keyservers would then be mainly limited to caching information that was obtained from some master keystore (with the exception of material strictly required for revocations). OpenPGP already has the "keyserver" field which is rarely used. It is supposedly a hint to clients to tell them to prefer a particular keyserver, but it could also be used as a hint to the keyservers themselves, to tell them where the master copy of any public key can be sourced. > If you want to propose changes to > https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore > i'd be happy to incorporate them too. I'd suggest adding a "caching keystore", either after or as a subsection of "updates-only keystore", with the following properties: ``` A caching keystore extends the concept of an updates-only keystore, by supplying user IDs and third-party certifications on the condition that they were recently available at an original location specified by the key's owner. This mitigates key-flooding attacks by preventing arbitrary submissions, and allows for the coordinated deletion of old or problematic material by removing it from the original location. * A caching keystore MUST accept submissions of primary keys as well as cryptographically-valid self-certification and revocation sigs (including third-party revocations) over those primary keys. * It MAY synchronise the above key packets from other keystores. It MUST NOT synchronise, or accept external submission of, any other packets. * It SHOULD attempt to fetch and temporarily cache user IDs and incoming third-party certifications over each primary key from the URL contained in that primary key's "keyserver" field, if defined. * If more than one "keyserver" definition is found for a given primary key, then the most recent cryptographically-valid packet MUST take precedence. * It MUST cryptographically verify all fetched material. * It MUST discard any unexpected fetched packets, even if they are cryptographically valid. In particular, it must discard any outgoing third-party certifications *from* the fetched key, in case they flood some other key. * It MAY impose further restrictions on cached packets (e.g. it may choose not to cache image IDs). * It SHOULD delete cached packets after a reasonable period of time once they can no longer be retrieved from the "keyserver" URL. ``` -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mgorny at gentoo.org Mon Jul 1 15:13:29 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Mon, 01 Jul 2019 15:13:29 +0200 Subject: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts) In-Reply-To: <201907011218.37327.bernhard@intevation.de> References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> <201907011218.37327.bernhard@intevation.de> Message-ID: On Mon, 2019-07-01 at 12:18 +0200, Bernhard Reiter wrote: > Am Montag 01 Juli 2019 01:36:41 schrieb Robert J. Hansen: > > Now we've got Autocrypt, WKD, and Hagrid: of these Autocrypt is probably the > > most mature and the easiest for email users. > > The problem with autocrypt are the cases where its security measures are > tested. There is not good way to interact with the users in those cases. > I know this is not parts of its design goals, but it works against a better > user experience. > > The progrem with hagrid (from what I've heard) is that it is again an attempt > of a validating keyserver, which means it has to centralize the trust > function or there is no point in the validation. > > This makes WKD most mature and easiest for users in my eyes. (I was involved > in its design.). > I agree. This is precisely why we've decided it for syncing distribution keys in Gentoo. However, the main problem with WKD right now is that AFAIK GnuPG doesn't support refreshing existing keys via WKD -- we had to employ a large hack to do it. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From rjh at sixdemonbag.org Mon Jul 1 15:26:38 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 1 Jul 2019 09:26:38 -0400 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> Message-ID: > We start from hagrid or something like it, and carefully add the ability > to sync only the absolute minimum of data required to allow revocations > to propagate. This probably means primary keys, their self-sigs and > revocation sigs. A thought that would unfortunately require an adjustment to the OpenPGP spec itself: why do we put certification signatures on the target's certificate, anyway? If Alice 0xDEADBEEF certifies Bob 0xDECAFBAD, 0xDECAFBAD bears a certification from 0xDEADBEEF. Why not reverse it? Why not, when looking at a certificate 0xDEADBEEF that says "Hi, I'm Alice!", do we not see "And I certify that 0xDECAFBAD is really Bob"? In some respects it would permit us to preserve an append-only signature model. Only the certificate owner would be allowed to append a cert signature to their cert. The current debacle is completely the result of allowing *anyone* to append a cert signature to *anyone else's* cert. I am certain there's some subtle problem here I'm not seeing. But it's worth a thought. > * It MUST cryptographically verify all fetched material. Note that this amounts to "SKS must die". SKS does no cryptographic verification of material. From andrewg at andrewg.com Mon Jul 1 15:29:41 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 1 Jul 2019 14:29:41 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> Message-ID: > On 1 Jul 2019, at 13:36, Andrew Gallagher wrote: > > We start from hagrid or something like it, and carefully add the ability > to sync only the absolute minimum of data required to allow revocations > to propagate. This probably means primary keys, their self-sigs and > revocation sigs. Or alternatively, we start with either hockeypuck or SKS (yes, I know) and carefully cripple them. Thinking about this a bit more, and with the DNS comparison in mind, it may be best if caching keyservers and validating keyservers were two entirely different things, to make sure we don?t accidentally open ourselves to a cache poisoning attack. A From andrewg at andrewg.com Mon Jul 1 15:55:10 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 1 Jul 2019 14:55:10 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> Message-ID: <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> On 2019/07/01 14:26, Robert J. Hansen wrote: > A thought that would unfortunately require an adjustment to the OpenPGP > spec itself: why do we put certification signatures on the target's > certificate, anyway? I think it's mostly to do with key size. This works fine either way when it's among peers, but in large organisations you'll tend to get one key that certifies a large number of others, while the median number of certifications made by any of the other keys is zero. Better to distribute lots of keys each with one signature, than lots of keys with no signatures and one key with all the signatures. Also, given that there tend to be a small number of super-certifiers, it is easier to trace back the possible verification paths given a list of certifiers on a newly-encountered key. The question is rarely "what is the list of the keys that I can verify?", and almost always "how can I verify this particular key?". X509 uses this model also, and for the same reason. > The current debacle is completely the result of allowing *anyone* to > append a cert signature to *anyone else's* cert. Yes, which is why we've informally had "let the owner choose whether to publish her incoming certifications" as best practice for a long time. Cross-signing would enforce this, but the client-side tooling is lacking. >> * It MUST cryptographically verify all fetched material. > > Note that this amounts to "SKS must die". SKS does no cryptographic > verification of material. SKS as we know it must die, but I think that has been obvious for a while. Its reconciliation algorithm can live on, however. The crypto verification doesn't need to be performed in the synchroniser. It might be best if it didn't so that we don't run into potential issues re some systems being able to verify, a new algorithm and some not. Better to let the synchroniser just do its job, and move all the verification and caching stuff to a higher level. It need not be in the same binary. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Mon Jul 1 16:13:45 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 1 Jul 2019 16:13:45 +0200 Subject: Your Thoughts In-Reply-To: References: Message-ID: David wrote: > Your Thoughts :) > > https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ > I agree with Professor Green. Maybe he and his students can program a POC something more simple, preferably in Golang and while using the NaCl* library. I think also (sorry to say this Werner!) the problem is that GnuPG is Linux cli based and not like MacPGP from Mr. Zimmermann, back in the 90's was GUI based with much lesser commands and easier to learn. There was back then no Enigmail or other MUA plug-ins and you could simply copy and paste your messages. A real "modern" GnuPG should be IMHO the same as PGP was GUI based back then. The GUI could be also cross-platform QT based, for example. I also don't understand why GnuPG needs so many components, like pinentry, dirmngr and gpg-agent plus GnuPG itself, while MacPGP from Mr Zimmermann was only one program. *And regarding key formats, standards, RFC's etc. my new NaCl (pronounced salt) pub key which I use now with friends for email communication looks like this :-) : 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 As you can see no infos about me, like email, name etc. and the communications are authenticated and no need for signing messages and no WoT or key servers! :-) Should also fit nicely on a business card. Regards Stefan From konstantin at linuxfoundation.org Mon Jul 1 16:27:20 2019 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Mon, 1 Jul 2019 10:27:20 -0400 Subject: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts) In-Reply-To: References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> <201907011218.37327.bernhard@intevation.de> Message-ID: <20190701142720.GA7789@chatter.i7.local> On Mon, Jul 01, 2019 at 03:13:29PM +0200, Micha? G?rny via Gnupg-users wrote: >> The problem with autocrypt are the cases where its security measures >> are >> tested. There is not good way to interact with the users in those cases. >> I know this is not parts of its design goals, but it works against a better >> user experience. >> >> The progrem with hagrid (from what I've heard) is that it is again an attempt >> of a validating keyserver, which means it has to centralize the trust >> function or there is no point in the validation. >> >> This makes WKD most mature and easiest for users in my eyes. (I was involved >> in its design.). >> > >I agree. This is precisely why we've decided it for syncing >distribution keys in Gentoo. However, the main problem with WKD right >now is that AFAIK GnuPG doesn't support refreshing existing keys via WKD >-- we had to employ a large hack to do it. This can't be stressed enough. The main purpose of a managed keyring for communities like kernel.org and others is to advise all members of things like: - subkey changes - UID additions/revocations - expiration date extensions WKD doesn't currently facilitate any of these. -K From david at gbenet.com Mon Jul 1 16:29:03 2019 From: david at gbenet.com (David) Date: Mon, 1 Jul 2019 15:29:03 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> Message-ID: <37d26001-89e0-6387-a306-105e0bddeb6f@gbenet.com> On 01/07/2019 14:55, Andrew Gallagher wrote: > On 2019/07/01 14:26, Robert J. Hansen wrote: >> A thought that would unfortunately require an adjustment to the OpenPGP >> spec itself: why do we put certification signatures on the target's >> certificate, anyway? > > I think it's mostly to do with key size. This works fine either way when > it's among peers, but in large organisations you'll tend to get one key > that certifies a large number of others, while the median number of > certifications made by any of the other keys is zero. Better to > distribute lots of keys each with one signature, than lots of keys with > no signatures and one key with all the signatures. > > Also, given that there tend to be a small number of super-certifiers, it > is easier to trace back the possible verification paths given a list of > certifiers on a newly-encountered key. The question is rarely "what is > the list of the keys that I can verify?", and almost always "how can I > verify this particular key?". X509 uses this model also, and for the > same reason. > >> The current debacle is completely the result of allowing *anyone* to >> append a cert signature to *anyone else's* cert. > > Yes, which is why we've informally had "let the owner choose whether to > publish her incoming certifications" as best practice for a long time. > Cross-signing would enforce this, but the client-side tooling is lacking. > >>> * It MUST cryptographically verify all fetched material. >> >> Note that this amounts to "SKS must die". SKS does no cryptographic >> verification of material. > > SKS as we know it must die, but I think that has been obvious for a > while. Its reconciliation algorithm can live on, however. The crypto > verification doesn't need to be performed in the synchroniser. It might > be best if it didn't so that we don't run into potential issues re some > systems being able to verify, a new algorithm and some not. Better to > let the synchroniser just do its job, and move all the verification and > caching stuff to a higher level. It need not be in the same binary. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > My take on all this is that I have had to disable Enigmail because it's screwed - I was not able to send mail and all the settings in enigmail were lots of ???????????? so I have been infected :( David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! https://gbenet.com From andrewg at andrewg.com Mon Jul 1 16:38:22 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 1 Jul 2019 15:38:22 +0100 Subject: Your Thoughts In-Reply-To: References: Message-ID: <2ba37ba8-3a2d-05f8-a38a-0fe4adafc679@andrewg.com> On 2019/07/01 15:13, Stefan Claas via Gnupg-users wrote: > I agree with Professor Green. Maybe he and his students can > program a POC something more simple, preferably in Golang and > while using the NaCl* library. Golang? Not Rust? :-P I do find it odd how many projects make such a big deal of what language they're written in. It shouldn't matter what language you use so long as it works (and is memory safe). > There was back then no Enigmail or other > MUA plug-ins and you could simply copy and paste your messages. Who wants to copy and paste messages? That's soooo 1995. > A real "modern" GnuPG should be IMHO the same as PGP was GUI based > back then. The GUI could be also cross-platform QT based, for > example. You can't script a GUI, but you can GUI a CLI - and there is no shortage of decent GUI interfaces for GnuPG. > I also don't understand why GnuPG needs so many components, like > pinentry, dirmngr and gpg-agent plus GnuPG itself, while MacPGP > from Mr Zimmermann was only one program. Most of those are separate because of security concerns. Monolithic systems may look simpler from the outside, but they're often a bucket of bolts on the inside. Role separation is your friend. > *And regarding key formats, standards, RFC's etc. my new NaCl > (pronounced salt) pub key which I use now with friends for email > communication looks like this :-) : Yes, it is possible to make very short public keys by stripping all non-mathematical information and using ECC (SSH's ECC keys are similarly terse). I'm skeptical of the long-term safety of ECC though (the NSA appears to agree[1]) so while it may be worth using for session keys I'm not going to trust it with my long-term identity. And the non-mathematical information has its uses if you're maintaining any sort of PKI. [1] https://blog.cryptographyengineering.com/2015/10/22/a-riddle-wrapped-in-curve/ -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mgorny at gentoo.org Mon Jul 1 16:47:58 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Mon, 01 Jul 2019 16:47:58 +0200 Subject: Your Thoughts In-Reply-To: <2ba37ba8-3a2d-05f8-a38a-0fe4adafc679@andrewg.com> References: <2ba37ba8-3a2d-05f8-a38a-0fe4adafc679@andrewg.com> Message-ID: <71050b4ea17fa7f9abd8a7214aee607e02cd4408.camel@gentoo.org> On Mon, 2019-07-01 at 15:38 +0100, Andrew Gallagher wrote: > On 2019/07/01 15:13, Stefan Claas via Gnupg-users wrote: > > I agree with Professor Green. Maybe he and his students can > > program a POC something more simple, preferably in Golang and > > while using the NaCl* library. > > Golang? Not Rust? :-P > > I do find it odd how many projects make such a big deal of what language > they're written in. It shouldn't matter what language you use so long as > it works (and is memory safe). I do find it odd how many projects choose exotic languages and then become defunct because few years later nobody wants to touch them. Presuming you're still able to build them. It's ironic people still don't see that even though SKS has just proven an example of that. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From andrewg at andrewg.com Mon Jul 1 17:11:31 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 1 Jul 2019 16:11:31 +0100 Subject: Your Thoughts In-Reply-To: <71050b4ea17fa7f9abd8a7214aee607e02cd4408.camel@gentoo.org> References: <2ba37ba8-3a2d-05f8-a38a-0fe4adafc679@andrewg.com> <71050b4ea17fa7f9abd8a7214aee607e02cd4408.camel@gentoo.org> Message-ID: On 2019/07/01 15:47, Micha? G?rny wrote: > I do find it odd how many projects choose exotic languages and then > become defunct because few years later nobody wants to touch them. > Presuming you're still able to build them. It's ironic people still > don't see that even though SKS has just proven an example of that. I think we're criticising the same thing. Yes, I'm calling Golang (and Rust) "exotic". :-) Interestingly, Rust was first implemented in OCaml... (!) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Mon Jul 1 17:15:02 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 1 Jul 2019 17:15:02 +0200 Subject: Your Thoughts In-Reply-To: <71050b4ea17fa7f9abd8a7214aee607e02cd4408.camel@gentoo.org> References: <2ba37ba8-3a2d-05f8-a38a-0fe4adafc679@andrewg.com> <71050b4ea17fa7f9abd8a7214aee607e02cd4408.camel@gentoo.org> Message-ID: Micha? G?rny via Gnupg-users wrote: > On Mon, 2019-07-01 at 15:38 +0100, Andrew Gallagher wrote: > > On 2019/07/01 15:13, Stefan Claas via Gnupg-users wrote: > > > I agree with Professor Green. Maybe he and his students can > > > program a POC something more simple, preferably in Golang and > > > while using the NaCl* library. > > > > Golang? Not Rust? :-P > > > > I do find it odd how many projects make such a big deal of what language > > they're written in. It shouldn't matter what language you use so long as > > it works (and is memory safe). > > I do find it odd how many projects choose exotic languages and then > become defunct because few years later nobody wants to touch them. > Presuming you're still able to build them. It's ironic people still > don't see that even though SKS has just proven an example of that. > As of my understanding Golang programmers are the highest paid programmers. Sorry I no longer have the link to quote that! BTW. Golang is from Google and if you check github project there always plenty of Golang solutions available. And the IMHO super cool thing of Golang is that if you cross-compile on a Windows box it runs on Mac, Linux, Arm etc. and vice versa, very cool! Regards Stefan From sac at 300baud.de Mon Jul 1 17:26:29 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 1 Jul 2019 17:26:29 +0200 Subject: Your Thoughts In-Reply-To: <2ba37ba8-3a2d-05f8-a38a-0fe4adafc679@andrewg.com> References: <2ba37ba8-3a2d-05f8-a38a-0fe4adafc679@andrewg.com> Message-ID: Andrew Gallagher wrote: > On 2019/07/01 15:13, Stefan Claas via Gnupg-users wrote: > > I agree with Professor Green. Maybe he and his students can > > program a POC something more simple, preferably in Golang and > > while using the NaCl* library. > > Golang? Not Rust? :-P He he, I have tried to compile sequoia-pgp under Windows 10 and failed miserably, do to the "excellent" compile instructions for Windows. I played with Rust in the past, under macOS, and never had problems. What I would like to do is to create a binary of sequoia-pgp under Windows 10 and then use the binary under Windows 7, offline. With Golang it would be no big deal, because that is super easy, but as understood the openpgp libs for Golang are not so good as the Rust ones. > Who wants to copy and paste messages? That's soooo 1995. Me for example :-) Why? I use encryption tools *offline* on my Notebook and then copy/paste the encrypted messages into CoolTerm to transfer them then via my USB to USB Nullmodem cable to my online computer. :-) > > A real "modern" GnuPG should be IMHO the same as PGP was GUI based > > back then. The GUI could be also cross-platform QT based, for > > example. > > You can't script a GUI, but you can GUI a CLI - and there is no shortage > of decent GUI interfaces for GnuPG. I am aware of that, but I do have (Golang) tools which work as cli tools and they can be used with an extra written GUI program, if someone likes to do so. Very handy! Regards Stefan From andrewg at andrewg.com Mon Jul 1 17:44:41 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 1 Jul 2019 16:44:41 +0100 Subject: Your Thoughts In-Reply-To: <2ba37ba8-3a2d-05f8-a38a-0fe4adafc679@andrewg.com> References: <2ba37ba8-3a2d-05f8-a38a-0fe4adafc679@andrewg.com> Message-ID: On 2019/07/01 16:26, Stefan Claas via Gnupg-users wrote: > I use encryption tools *offline* > on my Notebook and then copy/paste the encrypted messages > into CoolTerm to transfer them then via my USB to USB Nullmodem > cable to my online computer. :-) That seems excessively baroque. What's your threat model? Is it really so dire that Tails isn't sufficiently sandboxed for you? >> You can't script a GUI, but you can GUI a CLI - and there is no shortage >> of decent GUI interfaces for GnuPG. > > I am aware of that, but I do have (Golang) tools which work as cli > tools and they can be used with an extra written GUI program, if > someone likes to do so. Very handy! I agree that's the way user interfaces should be, but now I'm unclear what your complaint about GnuPG is, given that it's a CLI tool optionally wrapped in a GUI interface. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From brian at minton.name Mon Jul 1 16:17:25 2019 From: brian at minton.name (Brian Minton) Date: Mon, 1 Jul 2019 10:17:25 -0400 Subject: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts) In-Reply-To: References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> <201907011218.37327.bernhard@intevation.de> Message-ID: I'm kind of a corner case, but I can't use wkd because I don't control my top level domain for my email. I also can't use DANE for the same reason. I can and do use DNS CERT records because it allows a second-level domain. I suppose this has been discussed to death, but wouldn't it make sense to only allow external signatures on a key if they are cross-signed? That should prohibit third parties from adding junk to keys, but it doesn't prevent someone from making a key with your email address in it. I like the keybase.io approach of having publicly verifiable signatures to match a key to an id, but it only works for public ids such as github or facebook, rather than email. In the case of verifying signatures (for e.g. software distribution), just the id is needed, and no email is required. But in the case of encrypting to a stranger (for instance to send to a well-known reporter or something), the only way to trust the key is if they publicly sign something and put it on a publicly reachable website. It seems that in several well-known cases, such as Snowden, he just basically got lucky that the key in the keyserver network containing the Guardian's email address was in fact them and not an impostor. In the case of say a mailing list, tofu works pretty well, but still doesn't solve the problem of a cold communication with someone you've never before seen a signed message from. From brian at minton.name Mon Jul 1 16:22:10 2019 From: brian at minton.name (Brian Minton) Date: Mon, 1 Jul 2019 10:22:10 -0400 Subject: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts) In-Reply-To: References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> <201907011218.37327.bernhard@intevation.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Oops, forgot to sign it. I'm kind of a corner case, but I can't use wkd because I don't control my top level domain for my email. I also can't use DANE for the same reason. I can and do use DNS CERT records because it allows a second-level domain. I suppose this has been discussed to death, but wouldn't it make sense to only allow external signatures on a key if they are cross-signed? That should prohibit third parties from adding junk to keys, but it doesn't prevent someone from making a key with your email address in it. I like the keybase.io approach of having publicly verifiable signatures to match a key to an id, but it only works for public ids such as github or facebook, rather than email. In the case of verifying signatures (for e.g. software distribution), just the id is needed, and no email is required. But in the case of encrypting to a stranger (for instance to send to a well-known reporter or something), the only way to trust the key is if they publicly sign something and put it on a publicly reachable website. It seems that in several well-known cases, such as Snowden, he just basically got lucky that the key in the keyserver network containing the Guardian's email address was in fact them and not an impostor. In the case of say a mailing list, tofu works pretty well, but still doesn't solve the problem of a cold communication with someone you've never before seen a signed message from. -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTu0BWAE9wubW4AHqQ3uVB6z/IBbgUCXRoW/QAKCRA3uVB6z/IB bka7AP9DdmupTNZ0S7vC3BNxvIaVSkPgMvee5Kjk6SGWbgs6egD/Z08z2UVYzEoC pSOA5HJmNDIQrOMZz2vUXL/ZA+OekwSIdQQBEQgAHRYhBPnEu3YOeD8N7BCmimuO s6Blz7qpBQJdGhb+AAoJEGuOs6Blz7qp5n0A/A1cGVLBAI5XWAI2zvgoLpeIU7vU lxucPzOQKSGWSJKpAP0X2LdUFg3kayoJvZZ2QntoZT7F2blAYXTUXTjvi75Wrw== =xsw2 -----END PGP SIGNATURE----- From sac at 300baud.de Mon Jul 1 18:10:18 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 1 Jul 2019 18:10:18 +0200 Subject: Your Thoughts In-Reply-To: References: <2ba37ba8-3a2d-05f8-a38a-0fe4adafc679@andrewg.com> Message-ID: Andrew Gallagher wrote: > On 2019/07/01 16:26, Stefan Claas via Gnupg-users wrote: > > I use encryption tools *offline* > > on my Notebook and then copy/paste the encrypted messages > > into CoolTerm to transfer them then via my USB to USB Nullmodem > > cable to my online computer. :-) > > That seems excessively baroque. What's your threat model? Is it really > so dire that Tails isn't sufficiently sandboxed for you? My thread model is actually low, but my Linux Notebook was recently hacked and I don't trust my Windows 10 PC. I also had a couple of days ago a "nice" thing happen, that when sending a messsage in German from my VPS it arrived with other text content in Cyrillic at Gmail, in real time, so to speak. Cool, eh? Regardless if Tails or Linux etc. I no longer do encryption / decription with online computers. Seriously I think when using crypto tools in cli mode then users should also try to do that offline and "celebrate" a bit the encryption / decription procedure, unless of course they have a business running with plenty of messages per day. > > >> You can't script a GUI, but you can GUI a CLI - and there is no shortage > >> of decent GUI interfaces for GnuPG. > > > > I am aware of that, but I do have (Golang) tools which work as cli > > tools and they can be used with an extra written GUI program, if > > someone likes to do so. Very handy! > > I agree that's the way user interfaces should be, but now I'm unclear > what your complaint about GnuPG is, given that it's a CLI tool > optionally wrapped in a GUI interface. Sorry, there was no complaining intended from my side. Regards Stefan From wk at gnupg.org Mon Jul 1 18:26:20 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Jul 2019 18:26:20 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> (Andrew Gallagher's message of "Mon, 1 Jul 2019 14:55:10 +0100") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> Message-ID: <8736jpk9g3.fsf@wheatstone.g10code.de> On Mon, 1 Jul 2019 14:55, andrewg at andrewg.com said: > Yes, which is why we've informally had "let the owner choose whether to > publish her incoming certifications" as best practice for a long time. Actually gpg has always set the /Key Server Preferences/ to First octet: 0x80 = No-modify the key holder requests that this key only be modified or updated by the key holder or an administrator of the key server. assuming that at some point in the near future we would come up with a scheme to actually allow to implement such a verification. The problem here is that PGP-5 and thus OpenPGP continued to use the PGP-2 model and didn't defined key-signature as, for example, embedded signatures or something similar. We had no other chance here because the WoT was heavily used for real and for ranking games. Given that all public keyservers (there used to be others) didn't verified any signatures it was not possible to implement an upload scheme which guaranteed that key-signatures had been confirmed by the key holder. It has already been mentioned that this would have gone against the design of the keyserver network to be a perpetual storage system. I recall that we discussed all these issues at the keyserver admins conference in Utrecht back in 2000 and planned to do something about it. However, PGP Inc. was soon sold and interest in doing something with the decentralized keyservers network diminished. The new SKS thing then made keyservers working for OpenPGP (the original HKP was severely limited in accepting OpenPGP keys) but we all knew that if we ever get really successful with OpenPGP the keyserver would not be able to solve the key distribution task. In fact we are here too similar to X.509 and their CRL and OCSP problems. > Cross-signing would enforce this, but the client-side tooling is lacking. Cross-signing is not an easy solution because it can create a catch-22: You can only import a key which has been cross-signed but for cross-signing it needs to be imported. An approval of a key signature by a self-signature would be the right way - but a straightforward scheme would break the existing WoT and, worse for some, the ranking. The other and more important question is whether the WoT and thus classical key signatures solve a real world problem for the _masses_. I doubt that and I can live without public (exportable) key-signatures. Local key signatures are still a good idea as an annotation of imported keys. Salam-Shalom, Werner p.s. As stop-gap solution the next gpg release sports a --keyserver-options self-sigs-only to allow importing of spammed keys. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Jul 1 18:33:41 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Jul 2019 18:33:41 +0200 Subject: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts) In-Reply-To: (=?utf-8?Q?=22Micha=C5=82_G=C3=B3rny?= via Gnupg-users"'s message of "Mon, 01 Jul 2019 15:13:29 +0200") References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> <201907011218.37327.bernhard@intevation.de> Message-ID: <87y31hiuje.fsf@wheatstone.g10code.de> On Mon, 1 Jul 2019 15:13, gnupg-users at gnupg.org said: > distribution keys in Gentoo. However, the main problem with WKD right > now is that AFAIK GnuPG doesn't support refreshing existing keys via WKD Actually gpg updates expired keys via WKD. However, to not break things and not to go out and do a query on the mail domain, this is only done if the key has originally been fetched via WKD. That turned out to be a too conservative approach and thus I consider to change this so that gpg always tries to update an expired key via the WKD. Regarding a manual refresh there is indeed only a clumsy set of options and commands but if we can agree to stop using --search-keys with keyservers, this command can be used as a forceful update via WKD. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Jul 1 18:41:41 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Jul 2019 18:41:41 +0200 Subject: distributing pubkeys: autocrypt, hagrid, WKD In-Reply-To: <20190701142720.GA7789@chatter.i7.local> (Konstantin Ryabitsev's message of "Mon, 1 Jul 2019 10:27:20 -0400") References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> <201907011218.37327.bernhard@intevation.de> <20190701142720.GA7789@chatter.i7.local> Message-ID: <87tvc5iu62.fsf_-_@wheatstone.g10code.de> On Mon, 1 Jul 2019 10:27, konstantin at linuxfoundation.org said: > - subkey changes An expired key triggers a reload of the key via WKD or DANE. Modulo the problems I mentioned in the former mail. For new subkeys we have a problem unless we do a regular refresh similar to what should be done for revocations. > - UID additions/revocations A new UID will automatically be fetched, so this is not a problem. For revocations the same as above is true. > - expiration date extensions What do you mean by this? gpg --quick-set-expire and how this relates to the Web Key Directory? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Mon Jul 1 18:45:14 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 1 Jul 2019 17:45:14 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <8736jpk9g3.fsf@wheatstone.g10code.de> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> Message-ID: On 2019/07/01 17:26, Werner Koch wrote: > p.s. > As stop-gap solution the next gpg release sports a > --keyserver-options self-sigs-only to allow importing of spammed keys. I think this deserves more than a P.S. ;-) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From karel-v_g at tutanota.com Mon Jul 1 18:32:56 2019 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Mon, 1 Jul 2019 18:32:56 +0200 (CEST) Subject: Some thoughts on the future of OpenPGP and GnuPG Message-ID: Hello! Just right now I have read about a security vulnerability in the PGP keyservers, that can likely not be fixed according to Heise Online. That makes me writing about something I have been thinking of for quiet some time now: I am working in an environment that deals with highly sensitive personal data and my first PGP-key dates back to as far as the mid 1990s. Meanwhile I have changed it a few times, going from PGP 2.3 to the DH/DSS-Keys propagated by PGP 5 and then back to RSA-Keys with GnuPG. When looking at my In- and Outbox over the whole time I can safely say that I received and send only about 25 (!) mails in all the years and that many of my contacts simply have no PGP or don't use it any longer. It is easier and more reliable to send sensitive data by fax or mail for them. Many attempts to make mail encryption easier have failed and the standards we have for it are aging. S/MIME was never repaired after the so called efail-attack and OpenPGP relies on a SHA1-based modification detection code to protect from it as far as I know. Many other aspects are also far from moderns standards. Beyond this the complicated (and now dysfunctional as stated above) keydistribution caused many people to either send mails unencrypted, use regular mail or fax or use encrypting messengers nowadays. The renewal of the OpenPGP-standard has stopped or stalled last year and the additions to GnuPG were also rather small in the past years (aside from ECC). So my question as a user with a need for strong mail encryption is, whether it is not a time to start over with an all new encryption standard replacing OpenPGP and S/MIME completely. Something like the much praised Wireguard is doing right now in the VPN-world. Implementing just one (or two if needed) standardized modern method for each of the following basic components: s2k-function, hash algorithm, authenticating symmetric crypto-algorithm, one ECC-based and one conventional asymmetric crypto-algorithm. And somethin to ease the key distribution. OPENPGPKEY and WKD might be suitable for that. Thats it. No backwards compatibility. All new lean and easy. In my experience there are so few people actually using OpenPGP and these are crypto experienced so they should eysily adopt the modern proposal. If really needed the old standards could be supported for some time in a seperate "classic" component, but without the ability to create new keys. To propagate the distribution of this hypothetical new format it might be useful to get some of the major mailproviders, business software companies and mail software vendors might be useful, another problem of OpenPGP was and is that aditional software components are needed. Once again: I know that won't be easy or perhaps it can't be done at all. I really appreciate the work and commitment of Werner and all the others here and I am donatig each year to support them. But their work is simply not working in the real world. Sorry to say so, but that's my eperience and view? as a user -or let's better say wannabe user as there is no one to write encrypted mails to... ;) Thanks for reading and discussing! Karel From juergen at bruckner.tk Mon Jul 1 23:08:02 2019 From: juergen at bruckner.tk (Juergen Bruckner) Date: Mon, 1 Jul 2019 23:08:02 +0200 Subject: Your Thoughts In-Reply-To: <-Yr6HFqptjWfO3cPpx8sz6H6nC2UDuSlbV4J41vPrxCQHj4N1hUTi5FI3RXqrf0iw3TmFgUq1Pu5oo0A3IAVGH-fsjHJI_vUfSve-OoLjRI=@digicana.com> References: <87d0iuonab.fsf@ra.horus-it.com> <-Yr6HFqptjWfO3cPpx8sz6H6nC2UDuSlbV4J41vPrxCQHj4N1hUTi5FI3RXqrf0iw3TmFgUq1Pu5oo0A3IAVGH-fsjHJI_vUfSve-OoLjRI=@digicana.com> Message-ID: Hello to all, Am 01.07.19 um 00:23 schrieb Ryan McGinnis via Gnupg-users: > Does anyone know what PGP?s peak adoption rate was? I always loved it in concept but very very rarely saw people actually trying to use it in the wild, outside of the types of people who read this list. Well that not pretty "in the wild" but its pretty new: The Austrian Parliament and some parts of the Austria Government have released a website [1] where the PGP-Keys of Members of the Parliament and other people in the government are collected on one place. regards Juergen [1] https://gvkeys.at/ -- Juergen M. Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From sac at 300baud.de Mon Jul 1 23:36:59 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 1 Jul 2019 23:36:59 +0200 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: References: Message-ID: karel-v_g--- via Gnupg-users wrote: > Hello! [snip] Hi Karel, I think *flame on* Werner does not need to change anything, because he is in the lucky position do get financed by the big boys, so I see no need for him to start doing something new like many others (with no financial support) do. Plus he has the big openpgp community behind him, which supports him too. (I have nothing against Werner, he can make millions!) I also used PGP since the mid 90's and later used PGP and finally GnuPG. Nowadays I use the super cool box* (plus base91 as armor) with friends and for .pdf documents I use eIDAS conform signatures, so that I am compatible in the EU. I also experimented with encrypted Fax documents, but the armor GnuPG uses produces to many erros with OCR FOSS software. I had better luck with codegroup armor and Googles OCR, when uploading encrypted documents. If you like to use other solutions besides GnuPG I would google for it, like something like this etc. and check github too: https://ianix.com/pub/curve25519-deployment.html *https://github.com/rovaughn/box Regards Stefan From ryan at digicana.com Mon Jul 1 23:55:38 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Mon, 01 Jul 2019 21:55:38 +0000 Subject: Your Thoughts Message-ID: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> Null modem transfer of your messages? Yikes. To me that?s the issue with PGP in general as it relates to secure communications - the nerds and the criminals and the spies know how to work it, but your average end user doesn?t need their step one to be ?go to a Goodwill in a city you don?t live in wearing a disguise and buy a laptop with cash?, they need PGP to almost be automatic. Think of how easy it is to bootstrap Signal and how hard you?d have to try to accidentally send something cleartext over that application. Linking your key to a new device is as easy as scanning QR code. Perfect forward secrecy, rich media, voice and video synchronous communications upgrades, you name it. And my grandma could probably set it up without help. I guarantee most big data scooping intelligence services are a lot more worried about OpenWhisper protocol than PGP because *people actually use it*. Just being caught with WhatApp in China can get you sent to a camp, depending on your ethnicity. -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail ??????? Original Message ??????? On Monday, July 1, 2019 10:26 AM, Stefan Claas via Gnupg-users wrote: > Andrew Gallagher wrote: > > > On 2019/07/01 15:13, Stefan Claas via Gnupg-users wrote: > > > > > I agree with Professor Green. Maybe he and his students can > > > program a POC something more simple, preferably in Golang and > > > while using the NaCl* library. > > > > Golang? Not Rust? :-P > > He he, I have tried to compile sequoia-pgp under Windows 10 > and failed miserably, do to the "excellent" compile instructions > for Windows. I played with Rust in the past, under macOS, and > never had problems. > > What I would like to do is to create a binary of sequoia-pgp under > Windows 10 and then use the binary under Windows 7, offline. > > With Golang it would be no big deal, because that is super easy, > but as understood the openpgp libs for Golang are not so good > as the Rust ones. > > > Who wants to copy and paste messages? That's soooo 1995. > > Me for example :-) Why? I use encryption toolsoffline > on my Notebook and then copy/paste the encrypted messages > into CoolTerm to transfer them then via my USB to USB Nullmodem > cable to my online computer. :-) > > > > A real "modern" GnuPG should be IMHO the same as PGP was GUI based > > > back then. The GUI could be also cross-platform QT based, for > > > example. > > > > You can't script a GUI, but you can GUI a CLI - and there is no shortage > > of decent GUI interfaces for GnuPG. > > I am aware of that, but I do have (Golang) tools which work as cli > tools and they can be used with an extra written GUI program, if > someone likes to do so. Very handy! > > Regards > Stefan > > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users communications -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Tue Jul 2 00:09:47 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 2 Jul 2019 00:09:47 +0200 Subject: Your Thoughts In-Reply-To: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> References: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> Message-ID: Ryan McGinnis via Gnupg-users wrote: > > Null modem transfer of your messages? Yikes. To me that?s the issue with > PGP in general as it relates to secure communications - the nerds and the > criminals and the spies know how to work it, but your average end user > doesn?t need their step one to be ?go to a Goodwill in a city you don?t live > in wearing a disguise and buy a laptop with cash?, they need PGP to almost be > automatic. Think of how easy it is to bootstrap Signal and how hard you?d > have to try to accidentally send something cleartext over that application. > Linking your key to a new device is as easy as scanning QR code. Perfect > forward secrecy, rich media, voice and video synchronous communications > upgrades, you name it. And my grandma could probably set it up without > help. I guarantee most big data scooping intelligence services are a lot > more worried about OpenWhisper protocol than PGP because *people actually use > it*. Just being caught with WhatApp in China can get you sent to a camp, > depending on your ethnicity. Not to be off-topic, but you gave me the keyword "China" ... I just recently found this and was wondering what purpose it serves? Are people in China also allowed to use GnuPG? pgp.ustc.edu.cn/ Regards Stefan From hi at alyssa.is Tue Jul 2 00:43:18 2019 From: hi at alyssa.is (Alyssa Ross) Date: Mon, 1 Jul 2019 22:43:18 +0000 Subject: SKS Keyserver Network Under Attack In-Reply-To: <5b4f779f-8669-2785-a92c-c75b48357f8d@riseup.net> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <5b4f779f-8669-2785-a92c-c75b48357f8d@riseup.net> Message-ID: <20190701224317.x3mffnm63klnxcyg@x220.qyliss.net> > And yes, hkps://keys.openpgp.org would fall over and die if too many > users started using it. So cert poisoning will be an issue until there's > a secure alternative. Just as a point of interest, I've talked to the people running keys.openpgp.org about their capacity in #hagrid, when we were exploring whether to change the default keyserver in Nixpkgs' GnuPG[1] (which we ended up doing). The impression I got was that they're very optimistic about their ability to handle traffic to their server -- they were happy to have a distro make the switch, and will be changing the defaults in Enigmail and OpenKeychain very soon, as I understand it. It is a real shame that a decentralized Hagrid isn't really possible, though, at least to my understanding. It's quite the limitation for GnuPG. [1]: https://github.com/NixOS/nixpkgs/pull/63952 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From hi at alyssa.is Tue Jul 2 00:58:32 2019 From: hi at alyssa.is (Alyssa Ross) Date: Mon, 1 Jul 2019 22:58:32 +0000 Subject: Your Thoughts In-Reply-To: References: Message-ID: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> > I think also (sorry to say this Werner!) the problem is that > GnuPG is Linux cli based and not like MacPGP from Mr. Zimmermann, > back in the 90's was GUI based with much lesser commands and > easier to learn. There was back then no Enigmail or other > MUA plug-ins and you could simply copy and paste your messages. GnuPG is cross-platform and in no way tied to Linux, but I think you have a point about the CLI-focused design of it. The problem isn't that it's CLI-based per se, but that this design has made it far too easy for it to accumulate features without much consideration for how the whole thing works together. For example, why isn't ask-cert-level a default? I'm guessing it's just because at some point it didn't exist, and the developers didn't want to make a backwards incompatible change. But it means that, out of the box, signatures on other keys are next to useless, because it's not possible to specify how carefully you've checked a key. This leads to people only signing keys that they've very carefully checked, and makes it so that marginal signatures see almost no use, which I think has likely been a major contributor to the failure of the web of trust. A large part of what makes alternative encryption software like Signal successful is its simplicity. I don't have to worry about the 3000 different setting combinations available to me, because there's design work been put into it to set me up for success out of the box. I've spent hours of my life learning about how to use GnuPG, and have ended up with a way of using it that seems completely different to anybody else's, but I still don't think I'm doing it right. It's not possible to figure out how to use it as intended, because there's no intended way to use it. There's no high level design for how people are supposed to use the software. And without that, it's never going to be possible to use GnuPG properly no matter how much time one is willing to invest. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mirimir at riseup.net Tue Jul 2 04:44:04 2019 From: mirimir at riseup.net (Mirimir) Date: Mon, 1 Jul 2019 19:44:04 -0700 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <37d26001-89e0-6387-a306-105e0bddeb6f@gbenet.com> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <37d26001-89e0-6387-a306-105e0bddeb6f@gbenet.com> Message-ID: <4c4a0cab-5fae-5351-6b88-6f363032f290@riseup.net> On 07/01/2019 07:29 AM, David wrote: > My take on all this is that I have had to disable Enigmail because it's > screwed - I was not able to send mail and all the settings in enigmail > were lots of ???????????? so I have been infected :( > > David Damn. But all is likely not lost. If you can open Enigmail Preferences, go to the Keyserver tab, and specify only keys.openpgp.org as the keyserver. That way, if you manage to fix gpg, Enigmail won't break it again. Also see "100% CPU usage endles loop of gpg --list-keys" for background. About hardening and fixing gpg, see at Mitigations and Repairs. Also see . You'll very likely need to use gpg in terminal. I suspect that GPA may be just as wedged as Enigmail. Maybe someone could post a step-by-step guide for fixing gpg. For people who don't commonly use it in terminal. I suppose that I could import one of the poisoned keys in a fresh VM, and explore how to fix it. But I'm sure that someone reading this could just dash it out. From rjh at sixdemonbag.org Tue Jul 2 05:47:56 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 1 Jul 2019 23:47:56 -0400 Subject: Your Thoughts In-Reply-To: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> References: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> Message-ID: <30ca199b-1087-4439-2dc8-b46401179380@sixdemonbag.org> > GnuPG is cross-platform and in no way tied to Linux, but I think you > have a point about the CLI-focused design of it. The problem isn't that > it's CLI-based per se, but that this design has made it far too easy for > it to accumulate features without much consideration for how the whole > thing works together. Eh. Yes, no. I agree with the claim that GnuPG's "we-do-it-all" approach is overall a net negative for security: but there's a strong argument to be made that if GnuPG didn't do it all, it wouldn't get done at all. Remember that for about fifteen years GnuPG received basically nil for funding. For a long while each Christmas I'd run a fundraiser match for GnuPG, where I'd match dollar-for-dollar every dollar donated to GnuPG for development. My donation capped at $500. For several of those years, I was one of the largest individual contributors to GnuPG. During that long period when GnuPG was short of funds and developers, it could have focused on just one part of the crypto puzzle. "This will verify operating system packages with OpenPGP" or "this will verify emails with OpenPGP", to use one simple distinction. But doing that would've left the other, just as important, need unaddressed: so the developers did their best to make one package be useful to as many OpenPGP users as possible. This approach created some problems. Some of the Efail bugs were created when GnuPG generates output data even though the file fails integrity checks. This is not behavior you want in an email crypto engine: if the email fails, you want to just bomb out and create no data. But this *is* behavior you want in a bulk crypto engine, where there is no reasonable way to store petabytes of encrypted data in RAM to check for consistency before writing to disk. From wk at gnupg.org Tue Jul 2 08:59:13 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jul 2019 08:59:13 +0200 Subject: Your Thoughts In-Reply-To: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> (Alyssa Ross's message of "Mon, 1 Jul 2019 22:58:32 +0000") References: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> Message-ID: <87v9wkhqgu.fsf@wheatstone.g10code.de> On Mon, 1 Jul 2019 22:58, hi at alyssa.is said: > For example, why isn't ask-cert-level a default? I'm guessing it's just > because at some point it didn't exist, and the developers didn't want to Because we have good defaults and options to chnage them in the config. We do not want to expose all options to standard users and annoy them with useless questions. Some lobbied for such an interactive option anyway and thus we added it 1.3.6: * New --ask-cert-level/--no-ask-cert-level option to turn on and off the prompt for signature level when signing a key. Defaults to off. The interactive prompts are designed in a way that new prompts can be added without breaking anything. We have introduced new prompts a lot without much fear about compatibility problems. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Jul 2 09:04:13 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jul 2019 09:04:13 +0200 Subject: Your Thoughts In-Reply-To: <30ca199b-1087-4439-2dc8-b46401179380@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 1 Jul 2019 23:47:56 -0400") References: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> <30ca199b-1087-4439-2dc8-b46401179380@sixdemonbag.org> Message-ID: <87r278hq8i.fsf@wheatstone.g10code.de> On Mon, 1 Jul 2019 23:47, rjh at sixdemonbag.org said: > for development. My donation capped at $500. For several of those > years, I was one of the largest individual contributors to GnuPG. Right, your donation encouraged me to keep on working on this set of tool which is used at many more places than people expect. Thank you and also all the other folks who continue to help financing us. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bernhard at intevation.de Tue Jul 2 09:18:30 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 2 Jul 2019 09:18:30 +0200 Subject: WKD refreshing (was: distributing pubkeys: autocrypt, hagrid, WKD) In-Reply-To: <87y31hiuje.fsf@wheatstone.g10code.de> References: <87y31hiuje.fsf@wheatstone.g10code.de> Message-ID: <201907020918.35183.bernhard@intevation.de> Am Montag 01 Juli 2019 18:33:41 schrieb Werner Koch via Gnupg-users: > I consider to change this so that gpg always tries to update > an expired key via the WKD. To add to this: The idea for WKD was to be able to improve the algorithm when a new search is done. It is just obvious that the extreme cases to always retrieve a pubkey when using it and to never again retrieve a pubkey are not suitable. There is a lot in between, which could also depend on the client and users idea of their security compromises. So it is a normal situation with WKD that the client algorithm when to refresh will be adapted like Werner is mentioning above. Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From tlikonen at iki.fi Tue Jul 2 09:23:18 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Tue, 02 Jul 2019 10:23:18 +0300 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <8736jpk9g3.fsf@wheatstone.g10code.de> (Werner Koch via Gnupg-users's message of "Mon, 01 Jul 2019 18:26:20 +0200") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> Message-ID: <877e90ew7t.fsf_-_@iki.fi> Werner Koch [2019-07-01 18:26:20+02:00] wrote: > As stop-gap solution the next gpg release sports a --keyserver-options > self-sigs-only to allow importing of spammed keys. Why not make "import-clean" and "import-minimal" strip key signatures before importing a key? That would make "import-minimal" behave like this new "self-sigs-only" and there would be no need for yet another option. Who needs both "import-minimal" and "self-sigs-only"? My opinion: make "keyserver-options import-clean" the default and make it internally never import any unknown signatures. -- /// Teemu Likonen // // PGP: 4E1055DC84E9DFF613D78557719D69D324539450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From bernhard at intevation.de Tue Jul 2 09:39:39 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 2 Jul 2019 09:39:39 +0200 Subject: GnuPG funding (was: Your Thoughts) In-Reply-To: <30ca199b-1087-4439-2dc8-b46401179380@sixdemonbag.org> References: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> <30ca199b-1087-4439-2dc8-b46401179380@sixdemonbag.org> Message-ID: <201907020939.43627.bernhard@intevation.de> Am Dienstag 02 Juli 2019 05:47:56 schrieb Robert J. Hansen: > Remember that for about fifteen years GnuPG received basically nil for > funding. In the last 20 years there has been significant cross-funding through contracts that the companies g10 code, KDAB, some other companies and Intevation (which I co-own) have been received from German government tenders leading to contracts. g10 code used the part of the profit from these contracts to invest it in GnuPG, so did other companeis. The German Federal Agency of IT-Security (BSI) has been a major source of funding for GnuPG development by doing so, before it there was the German Ministry of Economics and some other organisation over the years. (This has all been published, for example see the "Contracts" section of https://wiki.gnupg.org/Gpg4win ) This funding (from my perspective) was not sufficient to meet the challenges posed by maintaining and build a crypto engine and applications around it. Each donation and volunteer payments was very helpful. (We've reported a couple of times how we did spend that money, e.g. for Gpg4win donations. Thanks again!) Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Jul 2 09:46:15 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 2 Jul 2019 09:46:15 +0200 Subject: A usable crypto experience with GnuPG (Re: Your Thoughts) In-Reply-To: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> References: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> Message-ID: <201907020946.15755.bernhard@intevation.de> Am Dienstag 02 Juli 2019 00:58:32 schrieb Alyssa Ross: > A large part of what makes alternative encryption software like Signal > successful is its simplicity. Though at some points it is too simple to use (from my point of view). My main point of critic are the central server architecture, the lack of a stable business interest, mandory need of a mobil phone number and the only use of the Google services to notifications. > I don't have to worry about the 3000 > different setting combinations available to me, because there's design > work been put into it to set me up for success out of the box. With WKD and the related "automatic encryption" concept, there is an outline since 2 years how a much better crypto experience can be done with GnuPG as a crypto engine. Modern clients like GpgOL already implement a large part of this, you type in an email address and even if this is the first time, you get an encrypted email. One main challenge is to get mail service prodiders and mail clients to implement the modern concepts. For details see: https://wiki.gnupg.org/WKD https://wiki.gnupg.org/AutomatedEncryption (some elder view of the design process https://wiki.gnupg.org/EasyGpg2016/VisionAndStories) Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From wiktor at metacode.biz Tue Jul 2 10:01:25 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 2 Jul 2019 10:01:25 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: <20190701224317.x3mffnm63klnxcyg@x220.qyliss.net> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <5b4f779f-8669-2785-a92c-c75b48357f8d@riseup.net> <20190701224317.x3mffnm63klnxcyg@x220.qyliss.net> Message-ID: Hi Alyssa, On 02.07.2019 00:43, Alyssa Ross wrote: > The impression I got was that they're very optimistic about their > ability to handle traffic to their server -- they were happy to have a > distro make the switch, and will be changing the defaults in Enigmail > and OpenKeychain very soon, as I understand it. I did work on one scheme that uses OpenPGP and I did some extensive tests even before keys.openpgp.org was announced and in terms of reliability it's day vs night compared to SKS. Hagrid, as far as understand it, serves keys from static files so it by design has good performance. SKS on the other hand requires caches in front of the server and, in my tests, it was frequent that an old version persisted in the cache long after I updated a key. No such issues on keys.openpgp.org, gpg --send-key and the new updated key is immediately available with no time outs or delays. > It is a real shame that a decentralized Hagrid isn't really possible, > though, at least to my understanding. It's quite the limitation for > GnuPG. Decentralized non-identity information hagrid could still be possible. It's just a question over which protocol to synchronize this kind of data. Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Jul 2 10:06:31 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 2 Jul 2019 10:06:31 +0200 Subject: Your Thoughts In-Reply-To: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> References: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> Message-ID: <542a47cc-6a2b-67d0-e310-feed6a37cb66@digitalbrains.com> On 01/07/2019 23:55, Ryan McGinnis via Gnupg-users wrote: > Null modem transfer of your messages? Yikes. To me that?s the issue > with PGP in general as it relates to secure communications None of any of the alternatives to OpenPGP you mention solve the issue that a secure offline system sets out to solve. They are orthogonal issues. Alternatives to OpenPGP have the same need or lack of need of a secure offline system as OpenPGP itself. The only difference I can think of would be in the number of messages disclosed or the range of signatures that could be faked by a compromise, not the base premise of disclosure and impersonation. You might well reasonably object to the UX of OpenPGP. Just not on the ground that there are people who think about offline secure systems, that makes no sense to me. The two are unrelated. The only relation I can think of is that people who think about deploying offline secure systems probably aren't quickly scared off by an overly complicated system ;-). Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wiktor at metacode.biz Tue Jul 2 10:16:45 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 2 Jul 2019 10:16:45 +0200 Subject: Your Thoughts In-Reply-To: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> References: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> Message-ID: <4e01cd0e-3d9e-4ab9-479a-db5cb3f25700@metacode.biz> On 02.07.2019 00:58, Alyssa Ross wrote: > For example, why isn't ask-cert-level a default? For an alternative view on ask-cert-level see also: https://debian-administration.org/users/dkg/weblog/98 I do agree that no two people use gpg in the same way. Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Jul 2 10:51:29 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 2 Jul 2019 10:51:29 +0200 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: References: Message-ID: <1a09ea63-31a7-a927-42c0-cbf21eecdab0@digitalbrains.com> On 01/07/2019 23:36, Stefan Claas via Gnupg-users wrote: > I think *flame on* Werner does not need to change anything, > because he is in the lucky position do get financed by > the big boys, so I see no need for him to start doing something > new like many others (with no financial support) do. Oh, for the love of... https://www.propublica.org/article/the-worlds-email-encryption-software-relies-on-one-guy-who-is-going-broke Seriously, ... . I'm going to exercise some restraint here and not write anything else, because I can't find words to do it politely. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wiktor at metacode.biz Tue Jul 2 11:11:37 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 2 Jul 2019 11:11:37 +0200 Subject: Your Thoughts In-Reply-To: References: <87d0iuonab.fsf@ra.horus-it.com> <-Yr6HFqptjWfO3cPpx8sz6H6nC2UDuSlbV4J41vPrxCQHj4N1hUTi5FI3RXqrf0iw3TmFgUq1Pu5oo0A3IAVGH-fsjHJI_vUfSve-OoLjRI=@digicana.com> Message-ID: On 01.07.2019 23:08, Juergen Bruckner via Gnupg-users wrote: > Well that not pretty "in the wild" but its pretty new: > The Austrian Parliament and some parts of the Austria Government have > released a website [1] where the PGP-Keys of Members of the Parliament > and other people in the government are collected on one place. > > [1] https://gvkeys.at/ That's interesting. All keys have the same comment in User ID field (random key): $ gpg -k D81FE9F91ED6AA9F pub rsa4096 2018-03-26 [SCEA] [expires: 2023-03-25] B5601EA2ABE3CDD51765B6F9D81FE9F91ED6AA9F uid [marginal] Nikolaus Berlakovich (Offizieller Schl?ssel der REPUBLIK ?STERREICH https://gvkeys.at) And they all are just one primary key (no subkeys) with all capabilities. Email addresses use the same domain "parlament.gv.at" so it would be a perfect place to deploy WKD for these keys :) Kind regards, Wiktor -- https://metacode.biz/@wiktor From andrewg at andrewg.com Tue Jul 2 11:44:12 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 2 Jul 2019 10:44:12 +0100 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: References: Message-ID: <9fbe3384-6910-6d5d-054d-0d1353adb5a6@andrewg.com> On 2019/07/01 17:32, karel-v_g--- via Gnupg-users wrote: > So my question as a user with a need for strong mail encryption is, > whether it is not a time to start over with an all new encryption > standard replacing OpenPGP and S/MIME completely. The main problem with OpenPGP isn't that its guts are old and slightly klunky. Many other things that the internet relies on are old and slightly klunky, but they still do the job. Where it does fall down often is in ease of use, both for end users and developers. And this is where most mature software projects end up putting most of their time, because "fit for use" is an order of magnitude more difficult than "fit for purpose". [1] The problem is that a) there's no revenue model for email security, so the big companies are reluctant to work on it for profit, and b) it's not sexy, so the talented youngsters aren't willing to work on it for fun. That will be true of any replacement, which is why despite people suggesting a modern replacement for over a decade, nobody has actually made one. And while starting from scratch may look tempting because it gets rid of all the technical debt, it also gets rid of all the technical assets. Yes, there are sexy new things like Signal, but they got to where they are by doing one (relatively straightforward) thing and doing it well. OpenPGP is a generalist tool, which explains both why it has ended up quietly embedded in so many other things, and why it is so difficult to upgrade or replace. > To propagate the distribution of this > hypothetical new format it might be useful to get some of the major > mailproviders, business software companies and mail software vendors > might be useful And this is the crux of the problem. If the big mail providers took email security seriously, we would never have got here in the first place. But the nature of email is that nobody owns it, therefore it is nobody's job to fix it. And the people who care have real jobs and mortgages. [1] https://www.quora.com/What-is-the-service-utility-and-warranty-in-ITIL-v3 -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From siemons at cleanfuels.nl Tue Jul 2 11:21:24 2019 From: siemons at cleanfuels.nl (Roland) Date: Tue, 2 Jul 2019 11:21:24 +0200 Subject: Local solutions: SKS Keyserver Network Under Attack [edited] In-Reply-To: References: Message-ID: Dear Forum, GNUPG Users Digest is nearly flooding my mailbox with exchanges about the WoT and keyserver issues. A simple user (me) needs to know how one could make adaptations in the settings of GPA or Kleopatra. I would expect instructions here: https://kde.org/applications/utilities/org.kde.kleopatra www.gnupg.org/related_software/gpa/ or perhaps here: www.gpg4win.org/index.html www.enigmail.net/index.php/en/ *There are not.* Hansen's and DKG's blog are only partly helpful. For example my Linux system seems to *not* have a? ~/.gnupg/dirmngr.conf file at all (one of those files recommended for editing). I.e. Nautilus cannot find it. So, I did adapt gpg.conf by outcommenting (#) any line starting with keyserver, but was not able to adapt the dirmngr.conf. Upon inspection, thereafter, my GPA and Kleopatra were NOT correctly configured. Trying to figure out how GPA and Kleopatra could be adapted, I found, for GPA: Menu > Edit > Backend preferences > Network > Configuration for Keyservers > Use custom value > adapt to hkps://keys.openpgp.org For Kleopatra: Menu > Settings > Configure Kleopatra > Directory Services > Open PGP Keyserver > adapt to hkps://keys.openpgp.org (I would have included an inline screenshot, but this list is allergic to html) Apparently these GUI manipulations generated the ~/.gnupg/dirmngr.conf file! (Only hereafter they existed). And that file indeed showed the new keyserver. GPG4Win and Enigmail need further research. (This is a suggestion. I cannot do it). And further, I would have expected a program update that sets the defaults to the ones suggested by Hansen and DKG. Or is the matter still under consideration, or is it not that important? (I personally cannot judge it). The only hint that I can give: The WoT nor keyservers are not very important in my case. I use GnuPG inside a small group of people who (for identity verification) can talk to each other, at least by telephone. I do not use Enigmail (since limited to few mail clients and not accepted by sufficient of my recipients), but just send encrypted messages as attachments. Best regards Roland From siemons at cleanfuels.nl Tue Jul 2 10:28:51 2019 From: siemons at cleanfuels.nl (Roland) Date: Tue, 2 Jul 2019 10:28:51 +0200 Subject: Local solutions: SKS Keyserver Network Under Attack In-Reply-To: References: Message-ID: Dear Forum, GNUPG Users Digest is nearly flooding my mailbox with exchanges about the WoT and keyserver issues. A simple user (me) needs to know how one could make adaptations in the settings of GPA or Kleopatra. I would expect instructions here: https://kde.org/applications/utilities/org.kde.kleopatra www.gnupg.org/related_software/gpa/ or perhaps here: www.gpg4win.org/index.html www.enigmail.net/index.php/en/ *There are not.* Hansen's and DKG's blog are only partly helpful. For example my Linux system seems to *not* have a? ~/.gnupg/dirmngr.conf file at all (one of those files recommended for editing). I.e. Nautilus cannot find it. So, I did adapt gpg.conf by outcommenting (#) any line starting with keyserver, but was not able to adapt the dirmngr.conf. Upon inspection, thereafter, my GPA and Kleopatra were NOT correctly configured. Trying to figure out how GPA and Kleopatra could be adapted, I found, for GPA: Menu > Edit > Backend preferences > Network > Configuration for Keyservers > Use custom value > adapt to hkps://keys.openpgp.org For Kleopatra: Menu > Settings > Configure Kleopatra > Directory Services > Open PGP Keyserver > adapt to hkps://keys.openpgp.org (I would have included an inline screenshot, but this list is allergic to html) GPG4Win and Enigmail need further research. (This is a suggestion. I cannot do it). And further, I would have expected a program update that sets the defaults to the ones suggested by Hansen and DKG. Or is the matter still under consideration, or is it not that important? (I personally cannot judge it). The only hint that I can give: The WoT nor keyservers are not very important in my case. I use GnuPG inside a small group of people who (for identity verification) can talk to each other, at least by telephone. I do not use Enigmail (since limited to few mail clients and not accepted by sufficient of my recipients), but just send encrypted messages as attachments. Best regards Roland On 02/07/2019 05:48, gnupg-users-request at gnupg.org wrote: > Send Gnupg-users mailing list submissions to > gnupg-users at gnupg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnupg.org/mailman/listinfo/gnupg-users > or, via email, send a message with subject or body 'help' to > gnupg-users-request at gnupg.org > > You can reach the person managing the list at > gnupg-users-owner at gnupg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gnupg-users digest..." > > > Today's Topics: > > 1. Re: Your Thoughts (Stefan Claas) > 2. Re: SKS Keyserver Network Under Attack (Alyssa Ross) > 3. Re: Your Thoughts (Alyssa Ross) > 4. Re: New keyserver at keys.openpgp.org - what's your take? > (Mirimir) > 5. Re: Your Thoughts (Robert J. Hansen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Jul 2019 00:09:47 +0200 > From: Stefan Claas > To: gnupg-users at gnupg.org > Subject: Re: Your Thoughts > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Ryan McGinnis via Gnupg-users wrote: > >> Null modem transfer of your messages? Yikes. To me that?s the issue with >> PGP in general as it relates to secure communications - the nerds and the >> criminals and the spies know how to work it, but your average end user >> doesn?t need their step one to be ?go to a Goodwill in a city you don?t live >> in wearing a disguise and buy a laptop with cash?, they need PGP to almost be >> automatic. Think of how easy it is to bootstrap Signal and how hard you?d >> have to try to accidentally send something cleartext over that application. >> Linking your key to a new device is as easy as scanning QR code. Perfect >> forward secrecy, rich media, voice and video synchronous communications >> upgrades, you name it. And my grandma could probably set it up without >> help. I guarantee most big data scooping intelligence services are a lot >> more worried about OpenWhisper protocol than PGP because *people actually use >> it*. Just being caught with WhatApp in China can get you sent to a camp, >> depending on your ethnicity. > Not to be off-topic, but you gave me the keyword "China" ... > > I just recently found this and was wondering what purpose it > serves? Are people in China also allowed to use GnuPG? > > pgp.ustc.edu.cn/ > > Regards > Stefan > > > > ------------------------------ > > Message: 2 > Date: Mon, 1 Jul 2019 22:43:18 +0000 > From: Alyssa Ross > To: Mirimir > Cc: gnupg-users at gnupg.org > Subject: Re: SKS Keyserver Network Under Attack > Message-ID: <20190701224317.x3mffnm63klnxcyg at x220.qyliss.net> > Content-Type: text/plain; charset="us-ascii" > >> And yes, hkps://keys.openpgp.org would fall over and die if too many >> users started using it. So cert poisoning will be an issue until there's >> a secure alternative. > Just as a point of interest, I've talked to the people running > keys.openpgp.org about their capacity in #hagrid, when we were exploring > whether to change the default keyserver in Nixpkgs' GnuPG[1] (which we > ended up doing). > > The impression I got was that they're very optimistic about their > ability to handle traffic to their server -- they were happy to have a > distro make the switch, and will be changing the defaults in Enigmail > and OpenKeychain very soon, as I understand it. > > It is a real shame that a decentralized Hagrid isn't really possible, > though, at least to my understanding. It's quite the limitation for > GnuPG. > > [1]: https://github.com/NixOS/nixpkgs/pull/63952 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 833 bytes > Desc: not available > URL: > > ------------------------------ > > Message: 3 > Date: Mon, 1 Jul 2019 22:58:32 +0000 > From: Alyssa Ross > To: Stefan Claas > Cc: gnupg-users at gnupg.org > Subject: Re: Your Thoughts > Message-ID: <20190701225832.6oldo4pexgjuy6yy at x220.qyliss.net> > Content-Type: text/plain; charset="us-ascii" > >> I think also (sorry to say this Werner!) the problem is that >> GnuPG is Linux cli based and not like MacPGP from Mr. Zimmermann, >> back in the 90's was GUI based with much lesser commands and >> easier to learn. There was back then no Enigmail or other >> MUA plug-ins and you could simply copy and paste your messages. > GnuPG is cross-platform and in no way tied to Linux, but I think you > have a point about the CLI-focused design of it. The problem isn't that > it's CLI-based per se, but that this design has made it far too easy for > it to accumulate features without much consideration for how the whole > thing works together. > > For example, why isn't ask-cert-level a default? I'm guessing it's just > because at some point it didn't exist, and the developers didn't want to > make a backwards incompatible change. But it means that, out of the box, > signatures on other keys are next to useless, because it's not possible > to specify how carefully you've checked a key. This leads to people only > signing keys that they've very carefully checked, and makes it so that > marginal signatures see almost no use, which I think has likely been a > major contributor to the failure of the web of trust. > > A large part of what makes alternative encryption software like Signal > successful is its simplicity. I don't have to worry about the 3000 > different setting combinations available to me, because there's design > work been put into it to set me up for success out of the box. I've > spent hours of my life learning about how to use GnuPG, and have ended > up with a way of using it that seems completely different to anybody > else's, but I still don't think I'm doing it right. It's not possible to > figure out how to use it as intended, because there's no intended way to > use it. There's no high level design for how people are supposed to use > the software. And without that, it's never going to be possible to use > GnuPG properly no matter how much time one is willing to invest. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 833 bytes > Desc: not available > URL: > > ------------------------------ > > Message: 4 > Date: Mon, 1 Jul 2019 19:44:04 -0700 > From: Mirimir > To: gnupg-users at gnupg.org > Subject: Re: New keyserver at keys.openpgp.org - what's your take? > Message-ID: <4c4a0cab-5fae-5351-6b88-6f363032f290 at riseup.net> > Content-Type: text/plain; charset=utf-8 > > On 07/01/2019 07:29 AM, David wrote: > > > >> My take on all this is that I have had to disable Enigmail because it's >> screwed - I was not able to send mail and all the settings in enigmail >> were lots of ???????????? so I have been infected :( >> >> David > Damn. But all is likely not lost. > > If you can open Enigmail Preferences, go to the Keyserver tab, and > specify only keys.openpgp.org as the keyserver. That way, if you manage > to fix gpg, Enigmail won't break it again. Also see "100% CPU usage > endles loop of gpg --list-keys" for > background. > > About hardening and fixing gpg, see > at > Mitigations and Repairs. Also see > . > > You'll very likely need to use gpg in terminal. I suspect that GPA may > be just as wedged as Enigmail. > > Maybe someone could post a step-by-step guide for fixing gpg. For people > who don't commonly use it in terminal. I suppose that I could import one > of the poisoned keys in a fresh VM, and explore how to fix it. But I'm > sure that someone reading this could just dash it out. > > > > ------------------------------ > > Message: 5 > Date: Mon, 1 Jul 2019 23:47:56 -0400 > From: "Robert J. Hansen" > To: gnupg-users at gnupg.org > Subject: Re: Your Thoughts > Message-ID: <30ca199b-1087-4439-2dc8-b46401179380 at sixdemonbag.org> > Content-Type: text/plain; charset=windows-1252 > >> GnuPG is cross-platform and in no way tied to Linux, but I think you >> have a point about the CLI-focused design of it. The problem isn't that >> it's CLI-based per se, but that this design has made it far too easy for >> it to accumulate features without much consideration for how the whole >> thing works together. > Eh. Yes, no. I agree with the claim that GnuPG's "we-do-it-all" > approach is overall a net negative for security: but there's a strong > argument to be made that if GnuPG didn't do it all, it wouldn't get done > at all. > > Remember that for about fifteen years GnuPG received basically nil for > funding. For a long while each Christmas I'd run a fundraiser match for > GnuPG, where I'd match dollar-for-dollar every dollar donated to GnuPG > for development. My donation capped at $500. For several of those > years, I was one of the largest individual contributors to GnuPG. > > During that long period when GnuPG was short of funds and developers, it > could have focused on just one part of the crypto puzzle. "This will > verify operating system packages with OpenPGP" or "this will verify > emails with OpenPGP", to use one simple distinction. But doing that > would've left the other, just as important, need unaddressed: so the > developers did their best to make one package be useful to as many > OpenPGP users as possible. > > This approach created some problems. Some of the Efail bugs were > created when GnuPG generates output data even though the file fails > integrity checks. This is not behavior you want in an email crypto > engine: if the email fails, you want to just bomb out and create no > data. But this *is* behavior you want in a bulk crypto engine, where > there is no reasonable way to store petabytes of encrypted data in RAM > to check for consistency before writing to disk. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > ------------------------------ > > End of Gnupg-users Digest, Vol 190, Issue 11 > ******************************************** > > -- Mail to: c/o University of Twente PO Box 217 7500 AE Enschede The Netherlands Visiting address: Marconistraat 33A 7575 AR Oldenzaal The Netherlands T: +31 (0)53 4892909 M: +31 (0)64561 6734 Siemons at CleanFuels.nl www.cleanfuels.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From siemons at cleanfuels.nl Tue Jul 2 10:29:11 2019 From: siemons at cleanfuels.nl (Roland) Date: Tue, 2 Jul 2019 10:29:11 +0200 Subject: Local solutions: SKS Keyserver Network Under Attack In-Reply-To: References: Message-ID: <29653ea2-99b7-6aa3-741d-058731c8937c@cleanfuels.nl> Dear Forum, GNUPG Users Digest is nearly flooding my mailbox with exchanges about the WoT and keyserver issues. A simple user (me) needs to know how one could make adaptations in the settings of GPA or Kleopatra. I would expect instructions here: https://kde.org/applications/utilities/org.kde.kleopatra www.gnupg.org/related_software/gpa/ or perhaps here: www.gpg4win.org/index.html www.enigmail.net/index.php/en/ *There are not.* Hansen's and DKG's blog are only partly helpful. For example my Linux system seems to *not* have a? ~/.gnupg/dirmngr.conf file at all (one of those files recommended for editing). I.e. Nautilus cannot find it. So, I did adapt gpg.conf by outcommenting (#) any line starting with keyserver, but was not able to adapt the dirmngr.conf. Upon inspection, thereafter, my GPA and Kleopatra were NOT correctly configured. Trying to figure out how GPA and Kleopatra could be adapted, I found, for GPA: Menu > Edit > Backend preferences > Network > Configuration for Keyservers > Use custom value > adapt to hkps://keys.openpgp.org For Kleopatra: Menu > Settings > Configure Kleopatra > Directory Services > Open PGP Keyserver > adapt to hkps://keys.openpgp.org (I would have included an inline screenshot, but this list is allergic to html) GPG4Win and Enigmail need further research. (This is a suggestion. I cannot do it). And further, I would have expected a program update that sets the defaults to the ones suggested by Hansen and DKG. Or is the matter still under consideration, or is it not that important? (I personally cannot judge it). The only hint that I can give: The WoT nor keyservers are not very important in my case. I use GnuPG inside a small group of people who (for identity verification) can talk to each other, at least by telephone. I do not use Enigmail (since limited to few mail clients and not accepted by sufficient of my recipients), but just send encrypted messages as attachments. Best regards Roland On 02/07/2019 05:48, gnupg-users-request at gnupg.org wrote: > Send Gnupg-users mailing list submissions to > gnupg-users at gnupg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnupg.org/mailman/listinfo/gnupg-users > or, via email, send a message with subject or body 'help' to > gnupg-users-request at gnupg.org > > You can reach the person managing the list at > gnupg-users-owner at gnupg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gnupg-users digest..." > > > Today's Topics: > > 1. Re: Your Thoughts (Stefan Claas) > 2. Re: SKS Keyserver Network Under Attack (Alyssa Ross) > 3. Re: Your Thoughts (Alyssa Ross) > 4. Re: New keyserver at keys.openpgp.org - what's your take? > (Mirimir) > 5. Re: Your Thoughts (Robert J. Hansen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Jul 2019 00:09:47 +0200 > From: Stefan Claas > To: gnupg-users at gnupg.org > Subject: Re: Your Thoughts > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Ryan McGinnis via Gnupg-users wrote: > >> Null modem transfer of your messages? Yikes. To me that?s the issue with >> PGP in general as it relates to secure communications - the nerds and the >> criminals and the spies know how to work it, but your average end user >> doesn?t need their step one to be ?go to a Goodwill in a city you don?t live >> in wearing a disguise and buy a laptop with cash?, they need PGP to almost be >> automatic. Think of how easy it is to bootstrap Signal and how hard you?d >> have to try to accidentally send something cleartext over that application. >> Linking your key to a new device is as easy as scanning QR code. Perfect >> forward secrecy, rich media, voice and video synchronous communications >> upgrades, you name it. And my grandma could probably set it up without >> help. I guarantee most big data scooping intelligence services are a lot >> more worried about OpenWhisper protocol than PGP because *people actually use >> it*. Just being caught with WhatApp in China can get you sent to a camp, >> depending on your ethnicity. > Not to be off-topic, but you gave me the keyword "China" ... > > I just recently found this and was wondering what purpose it > serves? Are people in China also allowed to use GnuPG? > > pgp.ustc.edu.cn/ > > Regards > Stefan > > > > ------------------------------ > > Message: 2 > Date: Mon, 1 Jul 2019 22:43:18 +0000 > From: Alyssa Ross > To: Mirimir > Cc: gnupg-users at gnupg.org > Subject: Re: SKS Keyserver Network Under Attack > Message-ID: <20190701224317.x3mffnm63klnxcyg at x220.qyliss.net> > Content-Type: text/plain; charset="us-ascii" > >> And yes, hkps://keys.openpgp.org would fall over and die if too many >> users started using it. So cert poisoning will be an issue until there's >> a secure alternative. > Just as a point of interest, I've talked to the people running > keys.openpgp.org about their capacity in #hagrid, when we were exploring > whether to change the default keyserver in Nixpkgs' GnuPG[1] (which we > ended up doing). > > The impression I got was that they're very optimistic about their > ability to handle traffic to their server -- they were happy to have a > distro make the switch, and will be changing the defaults in Enigmail > and OpenKeychain very soon, as I understand it. > > It is a real shame that a decentralized Hagrid isn't really possible, > though, at least to my understanding. It's quite the limitation for > GnuPG. > > [1]: https://github.com/NixOS/nixpkgs/pull/63952 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 833 bytes > Desc: not available > URL: > > ------------------------------ > > Message: 3 > Date: Mon, 1 Jul 2019 22:58:32 +0000 > From: Alyssa Ross > To: Stefan Claas > Cc: gnupg-users at gnupg.org > Subject: Re: Your Thoughts > Message-ID: <20190701225832.6oldo4pexgjuy6yy at x220.qyliss.net> > Content-Type: text/plain; charset="us-ascii" > >> I think also (sorry to say this Werner!) the problem is that >> GnuPG is Linux cli based and not like MacPGP from Mr. Zimmermann, >> back in the 90's was GUI based with much lesser commands and >> easier to learn. There was back then no Enigmail or other >> MUA plug-ins and you could simply copy and paste your messages. > GnuPG is cross-platform and in no way tied to Linux, but I think you > have a point about the CLI-focused design of it. The problem isn't that > it's CLI-based per se, but that this design has made it far too easy for > it to accumulate features without much consideration for how the whole > thing works together. > > For example, why isn't ask-cert-level a default? I'm guessing it's just > because at some point it didn't exist, and the developers didn't want to > make a backwards incompatible change. But it means that, out of the box, > signatures on other keys are next to useless, because it's not possible > to specify how carefully you've checked a key. This leads to people only > signing keys that they've very carefully checked, and makes it so that > marginal signatures see almost no use, which I think has likely been a > major contributor to the failure of the web of trust. > > A large part of what makes alternative encryption software like Signal > successful is its simplicity. I don't have to worry about the 3000 > different setting combinations available to me, because there's design > work been put into it to set me up for success out of the box. I've > spent hours of my life learning about how to use GnuPG, and have ended > up with a way of using it that seems completely different to anybody > else's, but I still don't think I'm doing it right. It's not possible to > figure out how to use it as intended, because there's no intended way to > use it. There's no high level design for how people are supposed to use > the software. And without that, it's never going to be possible to use > GnuPG properly no matter how much time one is willing to invest. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 833 bytes > Desc: not available > URL: > > ------------------------------ > > Message: 4 > Date: Mon, 1 Jul 2019 19:44:04 -0700 > From: Mirimir > To: gnupg-users at gnupg.org > Subject: Re: New keyserver at keys.openpgp.org - what's your take? > Message-ID: <4c4a0cab-5fae-5351-6b88-6f363032f290 at riseup.net> > Content-Type: text/plain; charset=utf-8 > > On 07/01/2019 07:29 AM, David wrote: > > > >> My take on all this is that I have had to disable Enigmail because it's >> screwed - I was not able to send mail and all the settings in enigmail >> were lots of ???????????? so I have been infected :( >> >> David > Damn. But all is likely not lost. > > If you can open Enigmail Preferences, go to the Keyserver tab, and > specify only keys.openpgp.org as the keyserver. That way, if you manage > to fix gpg, Enigmail won't break it again. Also see "100% CPU usage > endles loop of gpg --list-keys" for > background. > > About hardening and fixing gpg, see > at > Mitigations and Repairs. Also see > . > > You'll very likely need to use gpg in terminal. I suspect that GPA may > be just as wedged as Enigmail. > > Maybe someone could post a step-by-step guide for fixing gpg. For people > who don't commonly use it in terminal. I suppose that I could import one > of the poisoned keys in a fresh VM, and explore how to fix it. But I'm > sure that someone reading this could just dash it out. > > > > ------------------------------ > > Message: 5 > Date: Mon, 1 Jul 2019 23:47:56 -0400 > From: "Robert J. Hansen" > To: gnupg-users at gnupg.org > Subject: Re: Your Thoughts > Message-ID: <30ca199b-1087-4439-2dc8-b46401179380 at sixdemonbag.org> > Content-Type: text/plain; charset=windows-1252 > >> GnuPG is cross-platform and in no way tied to Linux, but I think you >> have a point about the CLI-focused design of it. The problem isn't that >> it's CLI-based per se, but that this design has made it far too easy for >> it to accumulate features without much consideration for how the whole >> thing works together. > Eh. Yes, no. I agree with the claim that GnuPG's "we-do-it-all" > approach is overall a net negative for security: but there's a strong > argument to be made that if GnuPG didn't do it all, it wouldn't get done > at all. > > Remember that for about fifteen years GnuPG received basically nil for > funding. For a long while each Christmas I'd run a fundraiser match for > GnuPG, where I'd match dollar-for-dollar every dollar donated to GnuPG > for development. My donation capped at $500. For several of those > years, I was one of the largest individual contributors to GnuPG. > > During that long period when GnuPG was short of funds and developers, it > could have focused on just one part of the crypto puzzle. "This will > verify operating system packages with OpenPGP" or "this will verify > emails with OpenPGP", to use one simple distinction. But doing that > would've left the other, just as important, need unaddressed: so the > developers did their best to make one package be useful to as many > OpenPGP users as possible. > > This approach created some problems. Some of the Efail bugs were > created when GnuPG generates output data even though the file fails > integrity checks. This is not behavior you want in an email crypto > engine: if the email fails, you want to just bomb out and create no > data. But this *is* behavior you want in a bulk crypto engine, where > there is no reasonable way to store petabytes of encrypted data in RAM > to check for consistency before writing to disk. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > ------------------------------ > > End of Gnupg-users Digest, Vol 190, Issue 11 > ******************************************** > > From wiktor at metacode.biz Tue Jul 2 11:56:39 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 2 Jul 2019 11:56:39 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> Message-ID: <21c4c200-beb6-3a8a-bd3d-13730b206f05@metacode.biz> On 01.07.2019 14:36, Andrew Gallagher wrote: > OpenPGP already has the "keyserver" field which is rarely used. It is > supposedly a hint to clients to tell them to prefer a particular > keyserver, but it could also be used as a hint to the keyservers > themselves, to tell them where the master copy of any public key can be > sourced. This sounds like a really good idea. This way only one place would have to be updated by the user and keyservers would automatically refresh key data themselves. I did suggest something like that but using WKD for Hagrid: https://gitlab.com/hagrid-keyserver/hagrid/issues/55#note_181162712 but your suggestion Andrew is more generic (key can be put on any HTTP host anywhere). Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From david at gbenet.com Tue Jul 2 12:18:33 2019 From: david at gbenet.com (David) Date: Tue, 2 Jul 2019 11:18:33 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <4c4a0cab-5fae-5351-6b88-6f363032f290@riseup.net> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <37d26001-89e0-6387-a306-105e0bddeb6f@gbenet.com> <4c4a0cab-5fae-5351-6b88-6f363032f290@riseup.net> Message-ID: <1077c5d3-1071-8152-6e76-0d7cdf5afa0d@gbenet.com> On 02/07/2019 03:44, Mirimir via Gnupg-users wrote: > On 07/01/2019 07:29 AM, David wrote: > > > >> My take on all this is that I have had to disable Enigmail because it's >> screwed - I was not able to send mail and all the settings in enigmail >> were lots of ???????????? so I have been infected :( >> >> David > > Damn. But all is likely not lost. > > If you can open Enigmail Preferences, go to the Keyserver tab, and > specify only keys.openpgp.org as the keyserver. That way, if you manage > to fix gpg, Enigmail won't break it again. Also see "100% CPU usage > endles loop of gpg --list-keys" for > background. > > About hardening and fixing gpg, see > at > Mitigations and Repairs. Also see > . > > You'll very likely need to use gpg in terminal. I suspect that GPA may > be just as wedged as Enigmail. > > Maybe someone could post a step-by-step guide for fixing gpg. For people > who don't commonly use it in terminal. I suppose that I could import one > of the poisoned keys in a fresh VM, and explore how to fix it. But I'm > sure that someone reading this could just dash it out. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > My "fix" was simple - I already have a linux laptop - saved all my keys and my secret key on a usb stick. Whilst reading the thread - I changed all the key servers from sks - but then I got screwed as sks key servers refreshed my keys! WTF!!! Having installed everything to the new laptop I just copied the folder onto my or this working laptop and all is fine. But as key servers share data - (???) maybe the infected keys will circulate??? My public key has only one confirmed signing - it had two - but really I am not that tempted to download from any key server. Not all here attach their public key - and do not upload to a key server - and well no one will ever upload to a key server again!!!!!!! Ha! Every key server is at risk. It has been done once - and can be done again - there is some very sophisticated malware out there. This is a great shock and a wake up call to tighten security - on all key servers - and to have a standardised platform - that takes money and developers. I'm still in shock and very very wary!!! David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x5C6EE7FBAAD8C47D.asc Type: application/pgp-keys Size: 5036 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jul 2 12:24:42 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jul 2019 12:24:42 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <877e90ew7t.fsf_-_@iki.fi> (Teemu Likonen via Gnupg-users's message of "Tue, 02 Jul 2019 10:23:18 +0300") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> Message-ID: <87v9wkg2dx.fsf@wheatstone.g10code.de> On Tue, 2 Jul 2019 10:23, gnupg-users at gnupg.org said: > Why not make "import-clean" and "import-minimal" strip key signatures > before importing a key? That would make "import-minimal" behave like Because that contradicts what import-clean is supposed to do: After import, compact (remove all signatures except the self-signature) any user IDs from the new key that are not usable. Then, remove any signatures from the new key _that are not usable_. This includes signatures that were issued by keys that are not present on the keyring. To do this gpg needs to check whether the corresponding key exists and the verify the signature using that key. In contrast self-sigs-only removes all signature which are not self-signature right away by just comparing a 64 bit integer. > My opinion: make "keyserver-options import-clean" the default and make > it internally never import any unknown signatures. Sorry, this is a catch-22. We need the key to verify the signature. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Jul 2 12:33:50 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jul 2019 12:33:50 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: (Wiktor Kwapisiewicz via Gnupg-users's message of "Tue, 2 Jul 2019 10:01:25 +0200") References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <5b4f779f-8669-2785-a92c-c75b48357f8d@riseup.net> <20190701224317.x3mffnm63klnxcyg@x220.qyliss.net> Message-ID: <87r278g1yp.fsf@wheatstone.g10code.de> On Tue, 2 Jul 2019 10:01, gnupg-users at gnupg.org said: > No such issues on keys.openpgp.org, gpg --send-key and the new updated > key is immediately available with no time outs or delays. Unless you are on Windows where the server can't be accessed because it uses a pretty limited set of TLS cipher suites. Thus the majority of GnuPG encryption users are out of luck. On Windows we use the ntbtls library which has not yet support for the GCM mode and we hesitate to add this to 2.2 because GCM has not been approved for the use of GnuPG in restricted communication (VS-NfD). It is not a technical problem but a policy one which we first need to sort out. Even with the fear of padding oracles on CBC and old as well as a forthcoming attack, the restriction of the server to use only GCM based cipher modes is not helpful. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From look at my.amazin.horse Tue Jul 2 13:47:00 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Tue, 02 Jul 2019 13:47:00 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: <87r278g1yp.fsf@wheatstone.g10code.de> References: <87r278g1yp.fsf@wheatstone.g10code.de> <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <5b4f779f-8669-2785-a92c-c75b48357f8d@riseup.net> <20190701224317.x3mffnm63klnxcyg@x220.qyliss.net> Message-ID: <25Y8006VEF74F.3CBRHKC1F0SLW@my.amazin.horse> > Unless you are on Windows where the server can't be accessed because it > uses a pretty limited set of TLS cipher suites. Thus the majority of > GnuPG encryption users are out of luck. Huh, that's interesting. I was not aware of this issue, and wish you had reached out to me, or to support at keys.openpgp.org, or filed an issue on Hagrid. > Even with the fear of padding oracles on CBC and old as well as a forthcoming > attack, the restriction of the server to use only GCM based cipher modes is > not helpful. This BSI requirement was not known to me. While it would be preferable to stick with AEAD ciphersuites, I would of course add another ciphersuite if you say you consider this a worthwhile tradeoff. It would be good to sort out the policy issue at some point as well, but I understand that won't happen overnight. - V From rjh at sixdemonbag.org Tue Jul 2 13:55:28 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 2 Jul 2019 07:55:28 -0400 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: <1a09ea63-31a7-a927-42c0-cbf21eecdab0@digitalbrains.com> References: <1a09ea63-31a7-a927-42c0-cbf21eecdab0@digitalbrains.com> Message-ID: <74ff9f0a-ba9d-dc67-1324-3f636166d4f4@sixdemonbag.org> > Seriously, ... . I'm going to exercise some restraint here and not write > anything else, because I can't find words to do it politely. I could not agree more. Stefan, that was out of bounds, inaccurate, and easy to refute. If you'd just done a Google search before you hit 'Send' you would've discovered the truth. I think you owe Werner an apology. From mgorny at gentoo.org Tue Jul 2 14:06:53 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Tue, 02 Jul 2019 14:06:53 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> References: <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> Message-ID: On Tue, 2019-06-25 at 16:30 +0200, Vincent Breitmoser via Gnupg-users wrote: > > Hi @ll. > > Hi Dirk, > > thanks for your thoughts! > > > I don't think it's such a good idea to drop Signatures on keys. > > As mentioned in our FAQ, the reason we don't support those is that with the SKS > model, anyone can attach arbitrary data to others' keys. It's hard to overstate > how problematic that is. I can just add a megabyte or fifty of data to your key. > > There are solutions that still allow for some of the TPS-based use cases, but > until there is at least some agreement on how to proceed, we decided against > supporting them. > > Free distribution of arbitrary TPSes is quite simply not a viable model for any > keyserver. The discussion shouldn't be about liking or disliking them, it should > be about what alternatives could be. > > I see from your signing policy that you do a caff-style workflow. Have you > considered the option to have keys cross-sign third party signatures for > publication? It's a very slight switch in tooling if we assume a caff workflow, > but that way each key remains in control of the public version of itself. > I honestly neither like the idea of requiring the 'first party' to explicitly confirm all signatures, nor losing compatibility with existing software in order to implement that. The latter should be quite obvious so I'll focus on the former. In Gentoo we're using a CA-like model with a central service signing UIDs of all developers. It is *convenient* for it to be able to inject those signatures into keys of the developers, and distribute them along with them. If we required developers to explicitly import the signature, certify it and upload the key I'm pretty sure our coverage would go down because people simply won't care. The problem is that this bites not developers who don't care much but users who lose the ability to verify the key easily. As an alternative: since keys.openpgp.org makes keys without verified e- mail addresses practically useless, why not permit only those signatures that were made using a key that's on keys.o.o and has at least single verified e-mail address? If you combine that with accepting only one signature per certifying key (i.e. pruning old signatures), it should be 'good enough'. That is, as long as attackers won't decide to create and verify humongous number of e-mail addresses. This could work fine alongside 'first-party attested blah blah' model, or at least work as an interim solution until the latter is widely deployed. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From ryan at digicana.com Tue Jul 2 14:10:58 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Tue, 02 Jul 2019 12:10:58 +0000 Subject: Your Thoughts In-Reply-To: <542a47cc-6a2b-67d0-e310-feed6a37cb66@digitalbrains.com> References: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> <542a47cc-6a2b-67d0-e310-feed6a37cb66@digitalbrains.com> Message-ID: <_oYPRH1csOfSk33UMqTiJDZG8AKgjS7pc6J0g8Y5pdFGLAWCOFv-waMe6ZphU_e1BbzQQdhLyMdJ1ywyHC66g58skSc_tK8INfXaAM_ccEc=@digicana.com> Right, I probably wasn?t being very clear with what I meant. What I?m saying is that people who use PGP at the moment are rather tech savvy, lady over from the legacy of the fact that for most of PGP?s existence a user *had* to be tech savvy to even get PGP backed out of the metaphorical garage. Because of this, applications that use PGP all seem designed to make that crowd happy. But making that crowd happy necessarily excludes the much larger crowd that would never need, consider, or even understand aid-gapping. Signal went the other way. Build a verifiably secure communications platform so easy that literally anyone can figure it out. Make it hard to impossible to screw up. Most of the people who implemented secure whisper adopted this philosophy. No, it?s not federated, but in terms of real-world impact it actually has one because people actually use it to communicate. -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail ??????? Original Message ??????? On Tuesday, July 2, 2019 3:06 AM, Peter Lebbing wrote: > On 01/07/2019 23:55, Ryan McGinnis via Gnupg-users wrote: > > > Null modem transfer of your messages? Yikes. To me that?s the issue > > with PGP in general as it relates to secure communications > > None of any of the alternatives to OpenPGP you mention solve the issue > that a secure offline system sets out to solve. They are orthogonal > issues. > > Alternatives to OpenPGP have the same need or lack of need of a secure > offline system as OpenPGP itself. The only difference I can think of > would be in the number of messages disclosed or the range of signatures > that could be faked by a compromise, not the base premise of disclosure > and impersonation. > > You might well reasonably object to the UX of OpenPGP. Just not on the > ground that there are people who think about offline secure systems, > that makes no sense to me. The two are unrelated. The only relation I > can think of is that people who think about deploying offline secure > systems probably aren't quickly scared off by an overly complicated > system ;-). > > Cheers, > > Peter. > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at http://digitalbrains.com/2012/openpgp-key-peter -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From ryan at digicana.com Tue Jul 2 14:14:22 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Tue, 02 Jul 2019 12:14:22 +0000 Subject: Fw: Re: Your Thoughts In-Reply-To: <_oYPRH1csOfSk33UMqTiJDZG8AKgjS7pc6J0g8Y5pdFGLAWCOFv-waMe6ZphU_e1BbzQQdhLyMdJ1ywyHC66g58skSc_tK8INfXaAM_ccEc=@digicana.com> References: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> <542a47cc-6a2b-67d0-e310-feed6a37cb66@digitalbrains.com> <_oYPRH1csOfSk33UMqTiJDZG8AKgjS7pc6J0g8Y5pdFGLAWCOFv-waMe6ZphU_e1BbzQQdhLyMdJ1ywyHC66g58skSc_tK8INfXaAM_ccEc=@digicana.com> Message-ID: By the way, I just *love* my iPhone?s desire to help me with words it thinks I?ve misspelled. :) -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail ??????? Original Message ??????? On Tuesday, July 2, 2019 7:10 AM, Ryan McGinnis wrote: > Right, I probably wasn?t being very clear with what I meant. What I?m saying is that people who use PGP at the moment are rather tech savvy, lady over from the legacy of the fact that for most of PGP?s existence a user had to be tech savvy to even get PGP backed out of the metaphorical garage. Because of this, applications that use PGP all seem designed to make that crowd happy. But making that crowd happy necessarily excludes the much larger crowd that would never need, consider, or even understand aid-gapping. > > Signal went the other way. Build a verifiably secure communications platform so easy that literally anyone can figure it out. Make it hard to impossible to screw up. Most of the people who implemented secure whisper adopted this philosophy. No, it?s not federated, but in terms of real-world impact it actually has one because people actually use it to communicate. > > -Ryan McGinnis > https://bigstormpicture.com > PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD > Sent with ProtonMail > > ??????? Original Message ??????? > On Tuesday, July 2, 2019 3:06 AM, Peter Lebbing peter at digitalbrains.com wrote: > > > On 01/07/2019 23:55, Ryan McGinnis via Gnupg-users wrote: > > > > > Null modem transfer of your messages? Yikes. To me that?s the issue > > > with PGP in general as it relates to secure communications > > > > None of any of the alternatives to OpenPGP you mention solve the issue > > that a secure offline system sets out to solve. They are orthogonal > > issues. > > Alternatives to OpenPGP have the same need or lack of need of a secure > > offline system as OpenPGP itself. The only difference I can think of > > would be in the number of messages disclosed or the range of signatures > > that could be faked by a compromise, not the base premise of disclosure > > and impersonation. > > You might well reasonably object to the UX of OpenPGP. Just not on the > > ground that there are people who think about offline secure systems, > > that makes no sense to me. The two are unrelated. The only relation I > > can think of is that people who think about deploying offline secure > > systems probably aren't quickly scared off by an overly complicated > > system ;-). > > Cheers, > > Peter. > > > > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > > You can send me encrypted mail if you want some privacy. > > My key is available at http://digitalbrains.com/2012/openpgp-key-peter -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Jul 2 14:18:29 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 2 Jul 2019 08:18:29 -0400 Subject: Your Thoughts In-Reply-To: <_oYPRH1csOfSk33UMqTiJDZG8AKgjS7pc6J0g8Y5pdFGLAWCOFv-waMe6ZphU_e1BbzQQdhLyMdJ1ywyHC66g58skSc_tK8INfXaAM_ccEc=@digicana.com> References: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> <542a47cc-6a2b-67d0-e310-feed6a37cb66@digitalbrains.com> <_oYPRH1csOfSk33UMqTiJDZG8AKgjS7pc6J0g8Y5pdFGLAWCOFv-waMe6ZphU_e1BbzQQdhLyMdJ1ywyHC66g58skSc_tK8INfXaAM_ccEc=@digicana.com> Message-ID: <07bc864c-cc00-1196-e873-4a04e8452a00@sixdemonbag.org> > Signal went the other way. Build a verifiably secure communications platform so easy that literally anyone can figure it out. I think this is a misunderstanding of Signal. OpenPGP is, by its very nature, agnostic to ... well, just about everything. It was originally intended for email but spread to become just about everywhere. It's used for package verification mostly nowadays. That is the genuine 99% use case, and that's where our attention really should be focused on. Email is a niche, and even moreso nowadays as email _itself_ is becoming a niche. OpenPGP in email is a niche within a niche. Signal is, by its very nature, tightly tied to one specific communications platform -- that of the smartphone. It's not likely to break out of its home. It's true that Signal has had more impact than OpenPGP in email -- but I think that's an unfair statement to make, as you're cherrypicking the one niche where OpenPGP has had the *least* adoption. Anything looks like a failure if you only look at where it's failed. From mgorny at gentoo.org Tue Jul 2 14:32:26 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Tue, 02 Jul 2019 14:32:26 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> Message-ID: On Fri, 2019-06-14 at 10:12 +0200, Oscar Carlsson via Gnupg-users wrote: > I'm generally curious on your opinions on the latest new keyserver, this > time running a new software than the normal keyservers. > > They seem to have a different model which minimize the amount of > information available, to be compliant with GDPR and friends. Do you > think there are any downsides to this? > Others have already somewhat pointed this out but I believe it hasn't been emphasized enough: in my opinion, stripping third-party signatures entirely is a no-go. I'd go ever as far as to say this key server is harmful to OpenPGP users, and defeats the purpose of using OpenPGP. I agree that WoT is nowhere near perfect, and that it is confusing to a lot of simple users. However, it's the best solution for validating keys that we have right now. With keys.openpgp.org implicitly stripping third-party signatures on one hand, and explicitly requiring e-mail verification on the other, it effectively shifts the security model into trusting e-mail verification done by the server software. I'm not saying that people running the server encourage that in any way. I'm saying that it's going to happen to a larger degree than before because users will be making the wrong assumptions. In other words, if users see that the particular key will be associated with the e-mail address only once that address is verified, some of them will also assume that if the e-mail address is present, then it is reliably confirmed. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From ryan at digicana.com Tue Jul 2 14:53:47 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Tue, 02 Jul 2019 12:53:47 +0000 Subject: Your Thoughts In-Reply-To: <07bc864c-cc00-1196-e873-4a04e8452a00@sixdemonbag.org> References: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> <542a47cc-6a2b-67d0-e310-feed6a37cb66@digitalbrains.com> <_oYPRH1csOfSk33UMqTiJDZG8AKgjS7pc6J0g8Y5pdFGLAWCOFv-waMe6ZphU_e1BbzQQdhLyMdJ1ywyHC66g58skSc_tK8INfXaAM_ccEc=@digicana.com> <07bc864c-cc00-1196-e873-4a04e8452a00@sixdemonbag.org> Message-ID: <6FP-Y0uYOAdlyFNK1PJ0_CtSGjE8Zoj4yxkkg8f90K2C_bc3i3YAX9olz2ItIHKup4x5Uvo6dFhO8UJZ9-vj4nQqQDfZ6gtd9amy3DZRFoo=@digicana.com> That is true that I am probably being unfair - my focus on GPG for email is more a nostalgic sadness that secure (beyond TLS transport) email never really became ubiquitous. In the end the protocol of email itself couldn?t keep up with way people needed to communicate, so email is now a bit of a niche thing - used for business and as a repository for ?unimportant and lacking urgency, but still desired? types of communications. As a run of the mill IT fire putter outer it seems nuts that I run across institutions still using fax machines (just regular old unencrypted data turned to audio over POTS lines) because they are somehow still compliant with data protection laws, and they see encrypted email as less viable as it much more expensive to set up with much more overhead. But I also agree - it certainly does make sense to focus development on what the users primarily use it for. Sent from ProtonMail Mobile On Tue, Jul 2, 2019 at 07:18, Robert J. Hansen wrote: >> Signal went the other way. Build a verifiably secure communications platform so easy that literally anyone can figure it out. > > I think this is a misunderstanding of Signal. > > OpenPGP is, by its very nature, agnostic to ... well, just about > everything. It was originally intended for email but spread to become > just about everywhere. It's used for package verification mostly > nowadays. That is the genuine 99% use case, and that's where our > attention really should be focused on. Email is a niche, and even > moreso nowadays as email _itself_ is becoming a niche. OpenPGP in email > is a niche within a niche. > > Signal is, by its very nature, tightly tied to one specific > communications platform -- that of the smartphone. It's not likely to > break out of its home. > > It's true that Signal has had more impact than OpenPGP in email -- but I > think that's an unfair statement to make, as you're cherrypicking the > one niche where OpenPGP has had the *least* adoption. Anything looks > like a failure if you only look at where it's failed. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: publicKey - ryan at digicana.com - 5c738727ee58786a777c4f1db5aa3fa3486ed7ad.asc URL: From andrewg at andrewg.com Tue Jul 2 15:02:55 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 2 Jul 2019 14:02:55 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: References: <39af1623f803234588d1dbe5a49bdc511f9df3f1.camel@googlemail.com> <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <3NTU2ZDNFR80P.3CN4RPAJE8LVZ@my.amazin.horse> Message-ID: <7440e152-4b7d-6115-8473-862068c851a6@andrewg.com> On 02/07/2019 13:06, Micha? G?rny via Gnupg-users wrote: > In Gentoo we're using a CA-like model with a central service signing > UIDs of all developers. It is *convenient* for it to be able to inject > those signatures into keys of the developers, and distribute them along > with them. It is convenient, but if it is covenient for you to attach one signature to the keys of your developers and redistribute, then it is convenient for an arbitrary person to attach a million sigs and gum up the system. I think this is one case where convenience will have to be sacrificed no matter what solution we adopt. This could be a use case for the "preferred keyserver" extension. If you ran your own keyserver and your developers set it as their preferred keyserver, then they would be publicly stating "Allow Gentoo to attach signatures without my explicit permisson, but distrust everyone else". This would only have to be done once in advance, and it could be made part of your new developer onboarding process. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jul 2 15:28:24 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jul 2019 15:28:24 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: <25Y8006VEF74F.3CBRHKC1F0SLW@my.amazin.horse> (Vincent Breitmoser's message of "Tue, 02 Jul 2019 13:47:00 +0200") References: <87r278g1yp.fsf@wheatstone.g10code.de> <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <5b4f779f-8669-2785-a92c-c75b48357f8d@riseup.net> <20190701224317.x3mffnm63klnxcyg@x220.qyliss.net> <25Y8006VEF74F.3CBRHKC1F0SLW@my.amazin.horse> Message-ID: <87pnmsefbb.fsf@wheatstone.g10code.de> On Tue, 2 Jul 2019 13:47, look at my.amazin.horse said: > Huh, that's interesting. I was not aware of this issue, and wish you had reached > out to me, or to support at keys.openpgp.org, or filed an issue on Hagrid. I assumed that newly launched server software with the goal to take over all existing keyservers has been properly tested on the major desktop platform. We track the case as https://dev.gnupg.org/T4597 > This BSI requirement was not known to me. While it would be preferable > to stick It is not a requirement but it is what has been evaluated. Changing anything crypto related requires discussion on whether this will affect the approval. It won't be a problem for GnuPG 2.3 because a lot of things will change there anyway and a re-evaluation will be required. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Tue Jul 2 16:03:03 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 2 Jul 2019 16:03:03 +0200 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: <74ff9f0a-ba9d-dc67-1324-3f636166d4f4@sixdemonbag.org> References: <1a09ea63-31a7-a927-42c0-cbf21eecdab0@digitalbrains.com> <74ff9f0a-ba9d-dc67-1324-3f636166d4f4@sixdemonbag.org> Message-ID: Robert J. Hansen wrote: > > Seriously, ... . I'm going to exercise some restraint here and not write > > anything else, because I can't find words to do it politely. > > I could not agree more. > > Stefan, that was out of bounds, inaccurate, and easy to refute. If > you'd just done a Google search before you hit 'Send' you would've > discovered the truth. > > I think you owe Werner an apology. O.k. I should better have said "was* in or may still is in" the lucky position. With "big boys" I meaned the German Government, German BSI and Facebook. Before I do any further replies I kindly request that some kind soul here acts as Interpreter of the footage below, so that all you guys and gals understand better what I meaned. I assume that 99.9 % of GnuPG /gpg4win users have not seen this before. https://www.youtube.com/watch?v=ZfbvNyy6vBE P.S. to me it is still unknown why exactly Facebook is an anual donor. Regards Stefan From andrewg at andrewg.com Tue Jul 2 16:27:37 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 2 Jul 2019 15:27:37 +0100 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: <74ff9f0a-ba9d-dc67-1324-3f636166d4f4@sixdemonbag.org> References: <1a09ea63-31a7-a927-42c0-cbf21eecdab0@digitalbrains.com> <74ff9f0a-ba9d-dc67-1324-3f636166d4f4@sixdemonbag.org> Message-ID: On 02/07/2019 15:03, Stefan Claas via Gnupg-users wrote: > P.S. to me it is still unknown why exactly Facebook is an anual donor. Facebook are a *serious* user of OpenPGP. Every email they send me is encrypted to my PGP key. In this respect they are decades ahead of 99.9% of the other big IT companies. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From ryan at digicana.com Tue Jul 2 16:49:25 2019 From: ryan at digicana.com (ryan at digicana.com) Date: Tue, 02 Jul 2019 14:49:25 +0000 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: References: <1a09ea63-31a7-a927-42c0-cbf21eecdab0@digitalbrains.com> <74ff9f0a-ba9d-dc67-1324-3f636166d4f4@sixdemonbag.org> Message-ID: This is quite cool (I have mine set up the same way), but somewhat ironic considering, well... they're Facebook. I mean of all the big dog internet companies out there that you'd expect to give you extreme measures protect in-transit personal user data... Facebook?! -Ryan McGinnis https://bigstormpicture.com PGP fingerprint: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail -----Original Message----- From: Gnupg-users On Behalf Of Andrew Gallagher Sent: Tuesday, July 2, 2019 9:28 AM To: gnupg-users at gnupg.org Subject: Re: Some thoughts on the future of OpenPGP and GnuPG On 02/07/2019 15:03, Stefan Claas via Gnupg-users wrote: > P.S. to me it is still unknown why exactly Facebook is an anual donor. Facebook are a *serious* user of OpenPGP. Every email they send me is encrypted to my PGP key. In this respect they are decades ahead of 99.9% of the other big IT companies. -- Andrew Gallagher _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com.asc.pgp Type: application/pgp-key Size: 3073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 871 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jul 2 17:31:23 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jul 2019 17:31:23 +0200 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: (Stefan Claas via Gnupg-users's message of "Tue, 2 Jul 2019 16:03:03 +0200") References: <1a09ea63-31a7-a927-42c0-cbf21eecdab0@digitalbrains.com> <74ff9f0a-ba9d-dc67-1324-3f636166d4f4@sixdemonbag.org> Message-ID: <87imske9mc.fsf@wheatstone.g10code.de> On Tue, 2 Jul 2019 16:03, gnupg-users at gnupg.org said: > With "big boys" I meaned the German Government, German BSI and Facebook. I, or well my company g10 Code GmbH, has currently no contracts with the German government or the BSI. We had projects with the BSI but no funding whatsoever. These projects are the usual invitation for bid, a bid by us (together with Intevation GmbH), and with luck the bid was then accepted. The last such project ended about 2 years ago. Right now we are talking to companies and also institutions like the BSI with the goal to sell support contracts (under the gnupg.com label); that is a new effort Andre and me started this year. Facebook and Stripe both donate 50k USD per year to support GnuPG because they use it internally and with their customers and users. They are obviously interested to keep the software well maintained. We also have recurring donations from individuals which are really helpful and encouraging. Thanks. > I assume that 99.9 % of GnuPG /gpg4win users have not seen this before. This is an old (2014) video showing the answer to a parliamentarian question by MdB Christian Str?bele on why support for German crypto [GnuPG] is such low. The answer has some numbers on money spent via BSI and BMWI for these purposes. We tried to figure out how they get to these numbers and it seems they lumped together different efforts over a long period of time. Anyway, it might have helped that new invitations for bids were sent out by the BSI and Intevation and g10 Code where lucky enough to get acceptance for our bids on 3 projects (Gpg4all, EasyGpg and Gpg4vs-nfd). They worked quite well and for the first time we actually made some profit form these projects. See [1] for short article on g10 Code's profits in 2016 and [2] for the balance sheet of 2017. Unfortunately I have had not found the time to write about the year 2017, or even 2018, on how we are doing. This lack of time of mine is partly caused by the departure of 3 of our employers to move on to pEp and hack on their projects over there. Anyway, we are currently without financial problems and are more troubled to find good developers who have a professional working habit and, best, have some experience in our field. Shalom-Salam, Werner [1] https://gnupg.org/blog/20170904-financial-results-2016.html [2] https://gnupg.org/blog/data/g10code-bilanz-2017-pub.pdf -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Tue Jul 2 18:00:45 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 2 Jul 2019 18:00:45 +0200 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: <87imske9mc.fsf@wheatstone.g10code.de> References: <1a09ea63-31a7-a927-42c0-cbf21eecdab0@digitalbrains.com> <74ff9f0a-ba9d-dc67-1324-3f636166d4f4@sixdemonbag.org> <87imske9mc.fsf@wheatstone.g10code.de> Message-ID: Werner Koch via Gnupg-users wrote: [snip] > [1] https://gnupg.org/blog/20170904-financial-results-2016.html > [2] https://gnupg.org/blog/data/g10code-bilanz-2017-pub.pdf Thanks a lot for the detailed reply, much appreciated! Also *much* success in the future! Regards Stefan From dkg at fifthhorseman.net Tue Jul 2 17:00:26 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 02 Jul 2019 11:00:26 -0400 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <87v9wkg2dx.fsf@wheatstone.g10code.de> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> Message-ID: <871rz8o511.fsf@fifthhorseman.net> On Tue 2019-07-02 12:24:42 +0200, Werner Koch via Gnupg-users wrote: > On Tue, 2 Jul 2019 10:23, gnupg-users at gnupg.org said: > >> Why not make "import-clean" and "import-minimal" strip key signatures >> before importing a key? That would make "import-minimal" behave like > > Because that contradicts what import-clean is supposed to do: > > After import, compact (remove all signatures except the > self-signature) any user IDs from the new key that are not usable. > Then, remove any signatures from the new key _that are not usable_. > This includes signatures that were issued by keys that are not present > on the keyring. > > To do this gpg needs to check whether the corresponding key exists and > the verify the signature using that key. In contrast self-sigs-only > removes all signature which are not self-signature right away by just > comparing a 64 bit integer. It sounds like you are saying that the order of operations -- import-then-clean vs. clean-then-import is part of the API spec that GnuPG is committed to. However, as Teemu points out, the order of operations is clearly the cause of the problem here. If you're saying that "clean-then-import" is technically difficult to implemente, that is a different answer -- it would be good to understand why it is difficult, so that we can consider how to fix it. But "clean-then-import" is clearly a preferable approach to any of the workarounds described so far. >> My opinion: make "keyserver-options import-clean" the default and make >> it internally never import any unknown signatures. > > Sorry, this is a catch-22. We need the key to verify the signature. Surely GnuPG could validate each certification without first storing the certificate in the keyring. "clean" means that the certificates already stored in the keyring are used to validate incoming signatures. right? or am i misunderstanding something? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From angel at pgp.16bits.net Tue Jul 2 20:41:12 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Tue, 02 Jul 2019 20:41:12 +0200 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: References: Message-ID: <1562092872.1077.29.camel@16bits.net> On 2019-07-01 at 18:32 +0200, karel-v_g--- via Gnupg-users wrote: > Hello! > Just right now I have read about a security vulnerability in the PGP keyservers, Note: that's a problem with the keyservers and key distribution, not with PGP itself. (...) > So my question as a user with a need for strong mail encryption is, whether it is not a time to start over with an all new encryption standard replacing OpenPGP and S/MIME completely. Something like the much praised Wireguard is doing right now in the VPN-world. > Implementing just one (or two if needed) standardized modern method for each of the following basic components: s2k-function, hash algorithm, authenticating symmetric crypto-algorithm, one ECC-based and one conventional asymmetric crypto-algorithm. And somethin to ease the key distribution. OPENPGPKEY and WKD might be suitable for that. > Thats it. No backwards compatibility. All new lean and easy. That won't solve *email* encryption. In fact, you will again some old problems (that may not have been fixed completely even after all these years, though). A new shiny system could be made in a couple of days that worked in a different way and required you to use a separate program. Encrypted messages could be exchanged through email in the form of attachments that you need to extract, then open with a special program to decrypt. (In fact, many people _currently_ use OpenPGP in that stony age way) But none of those is really *email* encryption. You could maybe even make that new program able to connect to your existing email via IMAP (assuming it's supported!). But then, it needs to work in Microsoft Outlook. Or in Lotus. Or have it sent thorough a certain Exchange server which blocks the encrypted mails sent using this PGP plugin but not this other one. While the first one does a much better job for reading than the second one. And you end up with the bizarre case of having one plugin that works for reading and another for writing. Let's not get started with being able to read it on the company smartphone where only a single email client is allowed. Or the Webmail you were provided. Here we face the adoption problem. If everyone used OpenPGP, all email clients would be expected to support it. And those creating the email clients would dedicate resources so that their MUA works properly with encrypted messages, rather than leaving that to third parties that often need to loop through holes to support things. (Also, many mail providers actually benefit from having access to users' data, from virus/spam filters, to learning your preferences in order to eg. show you more suited ads. Combined with little customer interest of such feature, it's not that strange there hasn't been much interest on going the route for OpenPGP adoption) MUA support is the big problem IMHO. First of all for supporting seamless reading and writing of encrypted emails, and then having the right user interfaces. A new system could improve some minor things in the wire format and encryption options, but it's working pretty well there, and can be fixed relatively painlessly on rfc4880 successor. The big deal are email clients. And there you would have all the issues that existing implementations have. Plus those they have fixed. Unless you somehow get to have everyone moving to encrypted mails almost at once, so it creates such pressure. > In my experience there are so few people actually using OpenPGP and these > are crypto experienced so they should eysily adopt the modern proposal. That would be much more harder than you expect. But the big problem is the above one. And rewriting everything won't solve that. Regards From rjh at sixdemonbag.org Tue Jul 2 21:29:26 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 2 Jul 2019 15:29:26 -0400 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: References: <1a09ea63-31a7-a927-42c0-cbf21eecdab0@digitalbrains.com> <74ff9f0a-ba9d-dc67-1324-3f636166d4f4@sixdemonbag.org> Message-ID: <6e23b2d5-840a-dda8-fe0b-a2a6361b5eb0@sixdemonbag.org> > This is quite cool (I have mine set up the same way), but somewhat > ironic considering, well... they're Facebook. I mean of all the big > dog internet companies out there that you'd expect to give you > extreme measures protect in-transit personal user data... Facebook?! Oh yes, absolutely so. Facebook makes good money off your personal data. If they allow other people to obtain it, that's money they're losing. You can rely on Facebook to zealously protect their bottom line. From konstantin at linuxfoundation.org Tue Jul 2 21:40:32 2019 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Tue, 2 Jul 2019 15:40:32 -0400 Subject: distributing pubkeys: autocrypt, hagrid, WKD In-Reply-To: <87tvc5iu62.fsf_-_@wheatstone.g10code.de> References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> <201907011218.37327.bernhard@intevation.de> <20190701142720.GA7789@chatter.i7.local> <87tvc5iu62.fsf_-_@wheatstone.g10code.de> Message-ID: <20190702194032.GA15443@chatter.i7.local> On Mon, Jul 01, 2019 at 06:41:41PM +0200, Werner Koch via Gnupg-users wrote: >On Mon, 1 Jul 2019 10:27, konstantin at linuxfoundation.org said: > >> - subkey changes > >An expired key triggers a reload of the key via WKD or DANE. Modulo the >problems I mentioned in the former mail. For new subkeys we have a >problem unless we do a regular refresh similar to what should be done >for revocations. Most subkey changes that I am aware of are not due to people's old subkeys expiring, but because they add new ones for reasons like migrating between smartcard solutions or just being nerdy and picking a new ECC-based subkey. When this happens, a maintainer who tries to verify a signed pull request will have the operation fail, so they need to have a way to force-refresh the developer's key. I would say this is the #1 workflow scenario that I need to fix if we can't rely on the SKS network any more. -K From wiktor at metacode.biz Tue Jul 2 22:37:31 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 2 Jul 2019 22:37:31 +0200 Subject: distributing pubkeys: autocrypt, hagrid, WKD In-Reply-To: <20190702194032.GA15443@chatter.i7.local> References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> <201907011218.37327.bernhard@intevation.de> <20190701142720.GA7789@chatter.i7.local> <87tvc5iu62.fsf_-_@wheatstone.g10code.de> <20190702194032.GA15443@chatter.i7.local> Message-ID: <10f3af3e-8ea4-6ebb-d432-9ac65a679f2c@metacode.biz> Hi Konstantin, On 02.07.2019 21:40, Konstantin Ryabitsev wrote: > Most subkey changes that I am aware of are not due to people's old > subkeys expiring, but because they add new ones for reasons like > migrating between smartcard solutions or just being nerdy and picking a > new ECC-based subkey. > > When this happens, a maintainer who tries to verify a signed pull > request will have the operation fail, so they need to have a way to > force-refresh the developer's key. Do you mean something simpler than [0]: gpg --auto-key-locate clear,wkd,nodefault --locate-key torvalds at kernel.org ? Trying key lookup over WKD if the subkey is missing locally (but primary key is present) would be a good idea. I've seen some really weird errors in that case [1]. If the primary key used short expiration [2] the refresh would be automatic but not many people like to prolong expirations every couple of months. Kind regards, Wiktor [0]: https://dev.gnupg.org/T2917#115978 [1]: https://www.reddit.com/r/tails/comments/9rchgi/tails_3101_error_cant_check_signature_no_public/ [2]: https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/ -- https://metacode.biz/@wiktor From angel at pgp.16bits.net Wed Jul 3 02:45:40 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Wed, 03 Jul 2019 02:45:40 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <87v9wkg2dx.fsf@wheatstone.g10code.de> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> Message-ID: <1562114740.1077.40.camel@16bits.net> On 2019-07-02 at 12:24 +0200, Werner Koch via Gnupg-users wrote: > > My opinion: make "keyserver-options import-clean" the default and > make it internally never import any unknown signatures. > > Sorry, this is a catch-22. We need the key to verify the signature. I don't think so. You can have the signing key in the keyring, even if that one was imported with only its own self-sigs. Ultimately, I think the signatures should only be imported when they are cross-signed by the key owner. This would require a migration step were people signed the signatures they already have on their key, but would otherwise allow them to keep their 'precious signatures' they already have. Then there should probably be a new command that would have to be used to import the new signatures to your key that you are sent. It won't fix the problem of a malicious keys being made with thousands of fake signatures, but it pretty much solves the spamming problem by only putting the owner in charge of accepting the signatures that can go on his key. Cheers From gnupg at raf.org Wed Jul 3 04:35:30 2019 From: gnupg at raf.org (gnupg at raf.org) Date: Wed, 3 Jul 2019 12:35:30 +1000 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <1562114740.1077.40.camel@16bits.net> References: <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <1562114740.1077.40.camel@16bits.net> Message-ID: <20190703023529.kowkcti3evnj4zr3@raf.org> ?ngel wrote: > On 2019-07-02 at 12:24 +0200, Werner Koch via Gnupg-users wrote: > > > My opinion: make "keyserver-options import-clean" the default and > > make it internally never import any unknown signatures. > > > > Sorry, this is a catch-22. We need the key to verify the signature. > > I don't think so. You can have the signing key in the keyring, even if > that one was imported with only its own self-sigs. > > Ultimately, I think the signatures should only be imported when they are > cross-signed by the key owner. > > This would require a migration step were people signed the signatures > they already have on their key, but would otherwise allow them to keep > their 'precious signatures' they already have. > > Then there should probably be a new command that would have to be used > to import the new signatures to your key that you are sent. > > It won't fix the problem of a malicious keys being made with thousands > of fake signatures, but it pretty much solves the spamming problem by > only putting the owner in charge of accepting the signatures that can go > on his key. > > Cheers Apologies in advance if this is a stupid comment (I don't know about gpg's implementation or the precise reason why keys with many signatures is a problem but I have read RJH's article). It sounds like SKS servers can handle these poisoned keys but GPG can't. That suggests that maybe GPG's keyring handling code could be changed so that poisoned keys no longer constitute a DoS. For example, if the problem is overuse of resources such as memory, could the keyring handling code be rewritten to use fewer resources? e.g. treat the keyring like a database where not all of it can fit in memory at the same time. If that were possible, these other changes wouldn't be needed. But perhaps it already does that and it's not enough. On the other hand, if the problem is that GPG is validating all of those signatures when importing a key, perhaps there could be a limit to how many signatures GPG will verify. Does it really have to verify every single one? Limiting the number that will be verified (or the amount of time spent verifying them) might prevent this situation becoming a DoS while still giving confidence that the key being imported has been signed by at least some members of your WoT. Again, apologies if I'm completely misunderstanding the issue. Perhaps the problem isn't limited to importing. I'm just thinking that being able to cope with garbage is more robust than trying to come up with ways to avoid garbage especially when you know that garbage happens. cheers, raf From mirimir at riseup.net Wed Jul 3 05:20:19 2019 From: mirimir at riseup.net (Mirimir) Date: Tue, 2 Jul 2019 20:20:19 -0700 Subject: Your Thoughts In-Reply-To: <07bc864c-cc00-1196-e873-4a04e8452a00@sixdemonbag.org> References: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> <542a47cc-6a2b-67d0-e310-feed6a37cb66@digitalbrains.com> <_oYPRH1csOfSk33UMqTiJDZG8AKgjS7pc6J0g8Y5pdFGLAWCOFv-waMe6ZphU_e1BbzQQdhLyMdJ1ywyHC66g58skSc_tK8INfXaAM_ccEc=@digicana.com> <07bc864c-cc00-1196-e873-4a04e8452a00@sixdemonbag.org> Message-ID: <1b1ec5da-f227-cae9-cc80-846da84b8f05@riseup.net> On 07/02/2019 05:18 AM, Robert J. Hansen wrote: >> Signal went the other way. Build a verifiably secure communications platform so easy that literally anyone can figure it out. > > I think this is a misunderstanding of Signal. > Signal is, by its very nature, tightly tied to one specific > communications platform -- that of the smartphone. It's not likely to > break out of its home. And not only that, it's tied to one of the least privacy-friendly aspects of smartphones: the phone number.[0] | Requirements | | Signal uses your existing phone number. | | The number must be able to receive an SMS or phone call. Sure, it's not necessarily the number of the phone that you're using Signal on. But it's gotta be a number that you can use, and which others can't use. So what do you do, to avoid geolocation? You can't use one of those shared SMS services. So what, lease a SIM from some SIM farm in wherever, and hope that they're honest? There's also the issue of actually using Signal while preventing geolocation. You can't just use Tor, which itself is nontrivial on smartphones, because Signal needs UDP. So you're stuck with VPNs, where you must trust providers. It's frightening how popular Signal has become. Especially for people whose lives are threatened by geolocation. If I were paranoid, I'd say that it was a honeypot. But whatever. Something using Tor onion services is probably the best option. Unless Tor is also a honeypot. 0) https://support.signal.org/hc/en-us/articles/360007318691-Register-a-phone-number From lists at boyandin.info Wed Jul 3 05:28:33 2019 From: lists at boyandin.info (Konstantin Boyandin) Date: Wed, 03 Jul 2019 10:28:33 +0700 Subject: SKS and GnuPG related issues and possible workarounds Message-ID: Hello All, After having read the recent multitude of messages related to SKS keyservers related issue, I figured out that a. The entire SKS keyservers design and interaction has a fundamental design flaw named "unlimited resources assumption". I.e., it is assumed every server, every client has unlimited resources (to store signatures; to retrieve and process them - unlimited RAM/storage, unlimited network speed). b. It is only a matter of time when other certificates are under attack. When the ones used by, say, Linux distributions to sign packages are affected, that will cause another wave of chaos. So the only valid option is to stop using current (the one written in OCaml) keyserver implementation and return to stone-age practice of manually sending them. c. More or less valid approach would be to - when exchanging with keyserver, only load/transmit signatures for certificates in the user's keyring. To withstand traffic and other resources waste, client should pass known certificates footprints first, to only get from a keyserver the relevant signature - implement local black/white lists feature - to able to filter out the signatures while processing them d. The above, or any other approach is hard to implement in foreseeable future, even harder to make a de facto standard. Personally, I am mostly concerned with b. at the moment. And if approach "data came, data stay" remains in effect for keyservers, they will merrily be flooded with junk certificates/signatures. I can see no easy means to prevent that, without wasting resources of human users. Am I wrong - perhaps there are brighter alternatives? Thanks. Sincerely, Konstantin Boyandin From gnupg-users at spodhuis.org Wed Jul 3 06:46:49 2019 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Wed, 3 Jul 2019 00:46:49 -0400 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <21c4c200-beb6-3a8a-bd3d-13730b206f05@metacode.biz> References: <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <21c4c200-beb6-3a8a-bd3d-13730b206f05@metacode.biz> Message-ID: <20190703044649.GA23596@spodhuis.org> On 2019-07-02 at 11:56 +0200, Wiktor Kwapisiewicz via Gnupg-users wrote: > On 01.07.2019 14:36, Andrew Gallagher wrote: > > OpenPGP already has the "keyserver" field which is rarely used. It is > > supposedly a hint to clients to tell them to prefer a particular > > keyserver, but it could also be used as a hint to the keyservers > > themselves, to tell them where the master copy of any public key can be > > sourced. > > This sounds like a really good idea. > > This way only one place would have to be updated by the user and keyservers > would automatically refresh key data themselves. Beware: the HKP schema of paths is used with the keyserver in that field, in GnuPG at least. I can't find the logbooks I'd have kept "somewhere" of my experimenting at the time, but key 0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04 in the first self-sig I see from 2013, includes: hashed subpkt 24 len 33 (preferred keyserver: hkp://ha.pool.sks-keyservers.net/) and my recollection is that I had tried various alternatives, to point to a fixed URL where the key was guaranteed to live, but it insisted on the /pks/ layout, so I gave up and went with HKP, at least pointing folks towards what at the time was the more reliable option, the HA pool. Using http:/https: didn't help, HKP was still used. I got around it later by specifying a `finger:` URL. :) It's been 30-40 years since folks last revamped the conventions on top of finger. That one is safe. -Phil From mirimir at riseup.net Wed Jul 3 08:23:37 2019 From: mirimir at riseup.net (Mirimir) Date: Tue, 2 Jul 2019 23:23:37 -0700 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: References: Message-ID: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> On 07/02/2019 08:28 PM, Konstantin Boyandin via Gnupg-users wrote: > Hello All, > > After having read the recent multitude of messages related to SKS > keyservers related issue, I figured out that > > a. The entire SKS keyservers design and interaction has a fundamental > design flaw named "unlimited resources assumption". I.e., it is assumed > every server, every client has unlimited resources (to store signatures; > to retrieve and process them - unlimited RAM/storage, unlimited network > speed). Either that, or it's the assumption that people won't do bad things. That was apparently a common assumption, back in the day. > b. It is only a matter of time when other certificates are under attack. > When the ones used by, say, Linux distributions to sign packages are > affected, that will cause another wave of chaos. So the only valid > option is to stop using current (the one written in OCaml) keyserver > implementation and return to stone-age practice of manually sending them. Yes. I gather that people working on really key stuff have likely been very aware of this issue, perhaps for years, and are protected. But there are probably many who were/are unaware, and are vulnerable. I don't think that it's necessary to stop using SKS keyservers. And I suspect that doing so would be nontrivial. Given that requests to them are likely hard-coded, or buried in obscure options and preferences. Stuff that nobody has touched for years. I believe that the most practical approach is 1) efficiently finding toxic keys, and 2) reconfiguring keyservers not to serve them. I get that many find this distasteful, doing the attackers' work for them, etc, etc, etc. But it would limit damage, to the extent that toxic keys can be identified soon enough. And there are other ways to share good copies of those keys. Via Keybase, for example. Or as you say, manually. > c. More or less valid approach would be to > - when exchanging with keyserver, only load/transmit signatures for > certificates in the user's keyring. To withstand traffic and other > resources waste, client should pass known certificates footprints first, > to only get from a keyserver the relevant signature > - implement local black/white lists feature - to able to filter out the > signatures while processing them I doubt that solutions depending on client behavior could ever work. > d. The above, or any other approach is hard to implement in foreseeable > future, even harder to make a de facto standard. It doesn't need to be a new standard. People have been working or that for years, and there's been much progress. But apparently there's nothing yet that satisfies all use cases. > Personally, I am mostly concerned with b. at the moment. And if approach > "data came, data stay" remains in effect for keyservers, they will > merrily be flooded with junk certificates/signatures. I can see no easy > means to prevent that, without wasting resources of human users. Same here about b. But from what little I know about SKS keyservers, "data came, data stay" ain't gonna change. So they'll just need to handle the junk. But it's arguably good enough if they can not serve junk to client apps that can't handle it. > Am I wrong - perhaps there are brighter alternatives? > > Thanks. > > Sincerely, > Konstantin Boyandin > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From mgorny at gentoo.org Wed Jul 3 08:42:07 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Wed, 03 Jul 2019 06:42:07 +0000 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> Message-ID: <1521C5BC-A9FF-4074-AAED-C8AE207CF27A@gentoo.org> Dnia July 3, 2019 6:23:37 AM UTC, Mirimir via Gnupg-users napisa?(a): >On 07/02/2019 08:28 PM, Konstantin Boyandin via Gnupg-users wrote: >> Hello All, >> >> After having read the recent multitude of messages related to SKS >> keyservers related issue, I figured out that >> >> a. The entire SKS keyservers design and interaction has a fundamental >> design flaw named "unlimited resources assumption". I.e., it is >assumed >> every server, every client has unlimited resources (to store >signatures; >> to retrieve and process them - unlimited RAM/storage, unlimited >network >> speed). > >Either that, or it's the assumption that people won't do bad things. >That was apparently a common assumption, back in the day. > >> b. It is only a matter of time when other certificates are under >attack. >> When the ones used by, say, Linux distributions to sign packages are >> affected, that will cause another wave of chaos. So the only valid >> option is to stop using current (the one written in OCaml) keyserver >> implementation and return to stone-age practice of manually sending >them. > >Yes. I gather that people working on really key stuff have likely been >very aware of this issue, perhaps for years, and are protected. But >there are probably many who were/are unaware, and are vulnerable. > >I don't think that it's necessary to stop using SKS keyservers. And I >suspect that doing so would be nontrivial. Given that requests to them >are likely hard-coded, or buried in obscure options and preferences. >Stuff that nobody has touched for years. > >I believe that the most practical approach is 1) efficiently finding >toxic keys, and 2) reconfiguring keyservers not to serve them. I get >that many find this distasteful, doing the attackers' work for them, >etc, etc, etc. But it would limit damage, to the extent that toxic keys >can be identified soon enough. And there are other ways to share good >copies of those keys. Via Keybase, for example. Or as you say, >manually. I don't think this is going to work long term. Even if you manage to somehow synchronously control all servers in SKS rotation, there's no way to prevent attackers from poisoning them over and over again. Then, they may decide to start mass poisoning other keys just to prove this is not the right solution. > >> c. More or less valid approach would be to >> - when exchanging with keyserver, only load/transmit signatures for >> certificates in the user's keyring. To withstand traffic and other >> resources waste, client should pass known certificates footprints >first, >> to only get from a keyserver the relevant signature >> - implement local black/white lists feature - to able to filter out >the >> signatures while processing them > >I doubt that solutions depending on client behavior could ever work. > >> d. The above, or any other approach is hard to implement in >foreseeable >> future, even harder to make a de facto standard. > >It doesn't need to be a new standard. People have been working or that >for years, and there's been much progress. But apparently there's >nothing yet that satisfies all use cases. > >> Personally, I am mostly concerned with b. at the moment. And if >approach >> "data came, data stay" remains in effect for keyservers, they will >> merrily be flooded with junk certificates/signatures. I can see no >easy >> means to prevent that, without wasting resources of human users. > >Same here about b. But from what little I know about SKS keyservers, >"data came, data stay" ain't gonna change. So they'll just need to >handle the junk. But it's arguably good enough if they can not serve >junk to client apps that can't handle it. > >> Am I wrong - perhaps there are brighter alternatives? >> >> Thanks. >> >> Sincerely, >> Konstantin Boyandin >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > >_______________________________________________ >Gnupg-users mailing list >Gnupg-users at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-users (I'm replying from phone, sorry about lack of line wrapping and uncut quote) -- Best regards, Micha? G?rny From wk at gnupg.org Wed Jul 3 08:44:23 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2019 08:44:23 +0200 Subject: Some thoughts on the future of OpenPGP and GnuPG In-Reply-To: <1562092872.1077.29.camel@16bits.net> (=?utf-8?Q?=22=C3=81nge?= =?utf-8?Q?l=22's?= message of "Tue, 02 Jul 2019 20:41:12 +0200") References: <1562092872.1077.29.camel@16bits.net> Message-ID: <87pnmrsjlk.fsf@wheatstone.g10code.de> On Tue, 2 Jul 2019 20:41, angel at pgp.16bits.net said: > attachments that you need to extract, then open with a special program > to decrypt. > (In fact, many people _currently_ use OpenPGP in that stony age way) From my experience many people use ZIP or PDF encryption here and not OpenPGP. But anyway we do not have any real numbers on that and thus we can't tell for sure. Agreed, copy and pasting armored gpg messages is often a very useful thing in particular with chats and fora. > But then, it needs to work in Microsoft Outlook. Or in Lotus. We like to hear about problem you experience with Gpg4win and Outlook with and without Exchange. A few minor bugs are known but most users tells us that it works pretty well, be it OpenPGP or S/MIME. The user interface of GpgOL (The outlook plugin from Gpg4win) for encryption is even more advanced than Outlook's internal S/MIME encryption. > The big deal are email clients. And there you would have all the issues > that existing implementations have. Plus those they have fixed. Right, and most faults you have seen in recent years are due to bad integration of crypto in MUAs. It used to be better when we started to integrate encryption into MUAs about 20 years ago but meanwhile nifty UIs and featurism seems to be more important than solid integration. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 3 08:57:55 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2019 08:57:55 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <871rz8o511.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 02 Jul 2019 11:00:26 -0400") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <871rz8o511.fsf@fifthhorseman.net> Message-ID: <87lfxfsiz0.fsf@wheatstone.g10code.de> On Tue, 2 Jul 2019 11:00, dkg at fifthhorseman.net said: > It sounds like you are saying that the order of operations -- > import-then-clean vs. clean-then-import is part of the API spec that > GnuPG is committed to. No. What I say is that if we want to clean the keys from bogus signatures we need to get the key for each signature first. Obviously this requires that we do some checking on that key as a weel and this is why I say it is a catch-22. However, if you are only talking about self-signature, there is for sure no problem: We already have the key (it is a self-signature) and thus we can immediately check the signature. Anyway, that takes some time, it is a crypto operation - multiply that by 150000. OTOH, simply removing non-self-signatures does not costs any measurable time because it is just comparing two integers. > But "clean-then-import" is clearly a preferable approach to any of the > workarounds described so far. --import-options import-clean does exactly this. With the latest pacth we fallback to this option and --self-sigs-only if gpg detects that the keyblock is too larger afer some basic checks. > certificate in the keyring. "clean" means that the certificates already > stored in the keyring are used to validate incoming signatures. right? import-clean does this: After import, compact (remove all signatures except the self-signature) any user IDs from the new key that are not usable. Then, remove any signatures from the new key that are not usable. This includes *signatures that were issued by keys that are not* *present on the keyring*. This option is the same as running the --edit-key command "clean" after import. Defaults to no. This import-clean works on all signatures, not just self-signatures. This is what takes time - finding the key in the keyring (slower since 2.1 due to DB correctness improvements). In contrast import-minimal does this Import the smallest key possible. This removes all signatures except the most recent self-signature on each user ID. This option is the same as running the --edit-key command "minimize" after import. Defaults to no. But I am sure you know this. What Am I misreading? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 3 09:13:08 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2019 09:13:08 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <20190703023529.kowkcti3evnj4zr3@raf.org> (gnupg's message of "Wed, 3 Jul 2019 12:35:30 +1000") References: <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <1562114740.1077.40.camel@16bits.net> <20190703023529.kowkcti3evnj4zr3@raf.org> Message-ID: <87h883si9n.fsf@wheatstone.g10code.de> On Wed, 3 Jul 2019 12:35, gnupg-users at gnupg.org said: > problem but I have read RJH's article). It sounds like SKS servers can > handle these poisoned keys but GPG can't. That suggests that maybe GPG's I think here is a misunderstanding. Sure, processing 150k signatures takes quite some time and makes things very slow. This is why we call it a DoS. We can't do much about it. Compare it to X.509 CRLs - they have a very similar problem (cacert.org is a prominent but not the only example of CRLs making S/MIME processing very slow). The actual problem in gpg when using the keybox format is that only after processing the imported keys we hit a 5MiB limit for the keyblock in the database layer. Thus the import fails. Determining the size of the keyblock as it will be stored requires that we first remove some (standard) garbage from the keyblock - this takes some time. With the currently deployed code gpg will just reject any updates from a key if that limit was reached. That is not a good choice and the reason why I call it a bug. The fix to this bug is to fallback importing a stripped down version of the key. The current state is that we keep only self-signatures and then then import again with import-clean (which is then basically identical to import-minimal). > For example, if the problem is overuse of resources such as memory, could > the keyring handling code be rewritten to use fewer resources? e.g. treat Years ago we had the problem that people uploaded keys with large user ids and such. Thus we introduced limits to avoid spamming the keyring with such faked data. There is also an overall limit of 5 MiB for the entire keyblock which is sufficient for all real-world keyblocks - even for those with many key-signatures. > signatures when importing a key, perhaps there could be a limit to how many > signatures GPG will verify. Does it really have to verify every single one? It needs to validate all self-signature because they make up the integrity of the keyblock. For key-signature, sure we could introduce a limit, we actually do that with import-clean because that imports only those key-signature which we can verify and which are the latest from the same key (it is possible to sign a key several times to change meta data associated with the key-signature). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 3 09:21:20 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2019 09:21:20 +0200 Subject: distributing pubkeys: autocrypt, hagrid, WKD In-Reply-To: <20190702194032.GA15443@chatter.i7.local> (Konstantin Ryabitsev's message of "Tue, 2 Jul 2019 15:40:32 -0400") References: <87d0iuonab.fsf@ra.horus-it.com> <26325bf6-7a4f-784d-2904-9d8a0dda3aea@sixdemonbag.org> <201907011218.37327.bernhard@intevation.de> <20190701142720.GA7789@chatter.i7.local> <87tvc5iu62.fsf_-_@wheatstone.g10code.de> <20190702194032.GA15443@chatter.i7.local> Message-ID: <87d0irshvz.fsf@wheatstone.g10code.de> On Tue, 2 Jul 2019 15:40, konstantin at linuxfoundation.org said: > When this happens, a maintainer who tries to verify a signed pull > request will have the operation fail, so they need to have a way to > force-refresh the developer's key. I would say this is the #1 workflow Agreed. A signature carries only the fingerprint of the then unknown subkey without any information on the primary key. Thus an automated lookup is not possible. But wait, if --sender has been used or due to other reasons the Signer's UID is included in the keyring, we could do a lookup via tha user-id to see whether the signature has been made by a new subkey. The --auto-key-retrieve code already respective code but we need to chnage the order from where a key is fetched. And yes, an easier to remember command to forcefully update a key would be very useful. I have gpg --serach-key MAILADDRESS for that in mind. See https://dev/gnupg.org/T4599 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tlikonen at iki.fi Wed Jul 3 09:38:26 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Wed, 03 Jul 2019 10:38:26 +0300 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <87lfxfsiz0.fsf@wheatstone.g10code.de> (Werner Koch via Gnupg-users's message of "Wed, 03 Jul 2019 08:57:55 +0200") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <871rz8o511.fsf@fifthhorseman.net> <87lfxfsiz0.fsf@wheatstone.g10code.de> Message-ID: <87v9wjtvnx.fsf@iki.fi> Werner Koch via Gnupg-users [2019-07-03 08:57:55+02:00] wrote: > On Tue, 2 Jul 2019 11:00, dkg at fifthhorseman.net said: >> But "clean-then-import" is clearly a preferable approach to any of the >> workarounds described so far. > > --import-options import-clean does exactly this. Daniel basically said that "first clean then import [to local keyring]" and you confirmed that import-clean does exactly this. But then... > import-clean does this: > > After import, compact (remove all signatures except the > self-signature) ...here you and the manual say that "first import [to local keyring] then clean". So there are conflicting messages. Which of the two happens? I think everyone would prefer that import-clean would do all the checking and cleaning before importing certificates to the local keyring. The same thing with import-minimal. -- /// Teemu Likonen // // PGP: 4E1055DC84E9DFF613D78557719D69D324539450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From andrewg at andrewg.com Wed Jul 3 10:17:51 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 3 Jul 2019 09:17:51 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <20190703044649.GA23596@spodhuis.org> References: <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <21c4c200-beb6-3a8a-bd3d-13730b206f05@metacode.biz> <20190703044649.GA23596@spodhuis.org> Message-ID: On 03/07/2019 05:46, Phil Pennock via Gnupg-users wrote: > Beware: the HKP schema of paths is used with the keyserver in that > field, in GnuPG at least. OK, but what's the failure mode? If it's graceful, then we haven't lost much. So long as key updates fall back to a keyserver somewhere it should be transparent. This does of course need thorough testing, as not all clients will have the same failure modes. > Using http:/https: didn't help, HKP was still used. Yes, from my reading this is expected behaviour. It would be relatively straightforward to create a server-side alias for the HKP URL, depending on what else is deployed at that location. > I got around it later by specifying a `finger:` URL. :) > It's been 30-40 years since folks last revamped the conventions on top > of finger. That one is safe. I didn't even know it supported finger URLs - handy to know! Opening a finger port may be a step too far for the security-conscious though... -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Jul 3 11:06:13 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 3 Jul 2019 05:06:13 -0400 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: References: Message-ID: > a. The entire SKS keyservers design and interaction has a fundamental > design flaw named "unlimited resources assumption". I.e., it is assumed > every server, every client has unlimited resources (to store signatures; > to retrieve and process them - unlimited RAM/storage, unlimited network > speed). This is reasonably correct. You'll get well-intentioned pedants screaming at you that you've got things exactly wrong (as I have discovered in recent days), but ignore them. > b. It is only a matter of time when other certificates are under attack. As I understand it the current list of targeted keys is myself, dkg, Werner, Patrick, and Kristian. It is clear the attacker's goal is to wedge as many GnuPG installations as possible. > When the ones used by, say, Linux distributions to sign packages are > affected, that will cause another wave of chaos. Yes. A warning is in order: few distributions use the keyserver network to distribute signing certificates directly. However, given the behavior of --refresh-keys, one could always upload a poisoned signing certificate to the keyserver network, wait for sysadmins to do a --refresh-keys on the entire keyring, and blammo. > So the only valid > option is to stop using current (the one written in OCaml) keyserver > implementation and return to stone-age practice of manually sending them. Or switch to Autocrypt, WKD, or Hagrid. All three options are worth considering, although none of them are (or could be) drop-in replacements. > c. More or less valid approach would be to > - when exchanging with keyserver, only load/transmit signatures for > certificates in the user's keyring. To withstand traffic and other > resources waste, client should pass known certificates footprints first, > to only get from a keyserver the relevant signature > - implement local black/white lists feature - to able to filter out the > signatures while processing them This would only shift the problem, not cure it. Once you poison a certificate until it's a few gigabytes in size, you can easily kill the entire SKS network by forcing it to reconcile that certificate over and over. > Am I wrong - perhaps there are brighter alternatives? I am *cautiously* optimistic. As an emergency mitigation, I think distributions should consider issuing a system update that blackholes *.sks-keyservers.net, with a big warning to people about what's happening and why. Enigmail users are, at present, getting hit left and right due to (a) how many of them have an affected certificate in their keyrings and (b) Enigmail's habit of automatically refreshing keyrings. Patrick has already sent an emergency message to the Enigmail mailing list, and an emergency update will be released imminently shifting to keys.openpgp.net. Werner will no doubt be updating GpgOL as well. Those two account for literally 99% of all use cases. The vast majority of OpenPGP is to verify package signatures; for the small fraction that use it for email, Enigmail is the most dominant choice, with GpgOL a close second. The one small bit of silver lining to this stormcloud is we only need to figure out how to fix three separate things. The real damage is going to be to people's workflows. A whole lot of people are going to be impacted by these fixes and we can expect to need to help an awful lot of them. From look at my.amazin.horse Wed Jul 3 11:48:34 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Wed, 03 Jul 2019 11:48:34 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> Message-ID: <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> Friendly reminder: There are no developers working on SKS right now. Zero. No actual work has been done on SKS in years. - V From peter at digitalbrains.com Wed Jul 3 11:59:08 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 3 Jul 2019 11:59:08 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <87h883si9n.fsf@wheatstone.g10code.de> References: <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <1562114740.1077.40.camel@16bits.net> <20190703023529.kowkcti3evnj4zr3@raf.org> <87h883si9n.fsf@wheatstone.g10code.de> Message-ID: <4786ae84-c9d8-2256-e919-49d8cbeab876@digitalbrains.com> On 03/07/2019 09:13, Werner Koch via Gnupg-users wrote: > The current state is that we keep only self-signatures and then then > import again with import-clean (which is then basically identical to > import-minimal). What is the difference in the end result between --keyserver-options self-sigs-only and --import-options import-minimal? I think the former keeps all self sigs and the latter only the most recent valid self sig? Is it perhaps possible to incorporate the desired functionality of self-sigs-only into import-minimal, avoiding another extra option? Perhaps the extra granularity of self-sigs-only is not a useful feature for users, and poisoned keys should just be imported by import-minimal which could automatically imply the current functionality of self-sigs-only. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Jul 3 11:58:15 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2019 11:58:15 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: (Robert J. Hansen's message of "Wed, 3 Jul 2019 05:06:13 -0400") References: Message-ID: <87r277qw20.fsf@wheatstone.g10code.de> On Wed, 3 Jul 2019 05:06, rjh at sixdemonbag.org said: > As I understand it the current list of targeted keys is myself, dkg, > Werner, Patrick, and Kristian. It is clear the attacker's goal is to I am not yet affected except for these few thousand old xmas fun signatures. > Werner will no doubt be updating GpgOL as well. I am sorting out some other bugs and hope to get a release out next week. I tend to make --keyserver-options self-sigs-only the default to avoid importing possible crap from the keyservers. no-self-sigs-only should allow to revert for those who still want to receive updates from the anyway overloaded keyservers. A command to clean affected keys would also be useful but it might be better to get a new release out early than to implement a feature which needs quite some time taking testing. (https://dev/gnupg.org/T4591) What we can also do is to remove the default keyserver feature we introduced with 2.2. This means that anyone who wants to use a keyserver needs to pick one and not rely on defaults. The other thing I have in mind to actually add to 2.2 is to re-purpose --search-keys to update from WKD or DANE instead looking up at the keyservers. (T4599) > of OpenPGP is to verify package signatures; for the small fraction that > use it for email, Enigmail is the most dominant choice, with GpgOL a Frankly, I doubt that given the many users of Gpg4win compared to those of Linux desktops. But this is a different topic. > The real damage is going to be to people's workflows. A whole lot of > people are going to be impacted by these fixes and we can expect to need Actually not being able to fetch a key from the keyservers can improve security or at least avoid problems sending mails encrypted to the wrong key. (see my comment above on --search-keys). Shalom-Salam, Werner p.s. Why can't we have such problems at times when it is cold and rainy and you can anyway only sit at your desk ;-). -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mirimir at riseup.net Wed Jul 3 12:01:49 2019 From: mirimir at riseup.net (Mirimir) Date: Wed, 3 Jul 2019 03:01:49 -0700 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <1521C5BC-A9FF-4074-AAED-C8AE207CF27A@gentoo.org> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <1521C5BC-A9FF-4074-AAED-C8AE207CF27A@gentoo.org> Message-ID: <3c8d27d0-048b-5ce1-a5bc-7e433b7bdf63@riseup.net> On 07/02/2019 11:42 PM, Micha? G?rny wrote: > Dnia July 3, 2019 6:23:37 AM UTC, Mirimir via Gnupg-users napisa?(a): >> I don't think that it's necessary to stop using SKS keyservers. And I >> suspect that doing so would be nontrivial. Given that requests to them >> are likely hard-coded, or buried in obscure options and preferences. >> Stuff that nobody has touched for years. >> >> I believe that the most practical approach is 1) efficiently finding >> toxic keys, and 2) reconfiguring keyservers not to serve them. I get >> that many find this distasteful, doing the attackers' work for them, >> etc, etc, etc. But it would limit damage, to the extent that toxic keys >> can be identified soon enough. And there are other ways to share good >> copies of those keys. Via Keybase, for example. Or as you say, >> manually. > > I don't think this is going to work long term. Even if you manage to > somehow synchronously control all servers in SKS rotation, there's no > way to prevent attackers from poisoning them over and over again. I'm not suggesting any controls on a server-by-server basis. I'm suggesting that blacklisting of toxic keys be a software update. And as the Tor network does, keyservers would ignore peers running outdated versions. Also, if what I propose is workable, toxic keys won't matter. They'll just be wasted space on the keyservers. And indeed, "poisoning them over and over again" isn't at all an issue. Given that toxic keys, or the signatures that poison them, can't actually be removed. By design, to prevent censorship. > Then, they may decide to start mass poisoning other keys just to > prove this is not the right solution. If what I propose is workable, attackers can poison as many keys as they like. Until SKS keyservers go down, anyway. Until then, if the system catches them quickly enough, they won't do widespread damage. They'll inconvenience some people, of course, but that seems unavoidable. And as an extra benefit, this would nuke file systems that store data in signatures. From wiktor at metacode.biz Wed Jul 3 12:03:36 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 3 Jul 2019 12:03:36 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: References: Message-ID: <7acc35fa-0392-b657-cdfe-ddb0c7b0f5c4@metacode.biz> On 03.07.2019 11:06, Robert J. Hansen wrote: > Those two account for literally 99% of all use cases. The vast majority > of OpenPGP is to verify package signatures; for the small fraction that > use it for email, Enigmail is the most dominant choice, with GpgOL a > close second. Yes. It seems distros that I know of manually manage package signing keys so they wouldn't be vulnerable to this kind of attack: https://blog.liw.fi/posts/2019/07/02/debian_and_the_sks_signature_flooding_attack/ (although it would be a chore as previously they could just --refresh-keys). For something completely different: on gnupg-devel there was a discussion on using Web Key Directory first for fetching signing keys. So "gpg --auto-key-retrieve --verify HOWTO.txt.sig HOWTO.txt" would get the key from sixdemonbag.org instead of keyservers thus retrieving good, non-flooded key. The change is tracked at https://dev.gnupg.org/T4595 Kind regards, Wiktor -- https://metacode.biz/@wiktor From wk at gnupg.org Wed Jul 3 12:04:55 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2019 12:04:55 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <87v9wjtvnx.fsf@iki.fi> (Teemu Likonen's message of "Wed, 03 Jul 2019 10:38:26 +0300") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <871rz8o511.fsf@fifthhorseman.net> <87lfxfsiz0.fsf@wheatstone.g10code.de> <87v9wjtvnx.fsf@iki.fi> Message-ID: <87muhvqvqw.fsf@wheatstone.g10code.de> On Wed, 3 Jul 2019 10:38, tlikonen at iki.fi said: >> import-clean does this: >> >> After import, compact (remove all signatures except the >> self-signature) > > ...here you and the manual say that "first import [to local keyring] > then clean". > > So there are conflicting messages. Which of the two happens? Right, the man page is a ambigious in use of the term "import". It should say that "after the key has been received by gpg, is is compacted ..., and if no error is encountred written to the keyring". > I think everyone would prefer that import-clean would do all the > checking and cleaning before importing certificates to the local > keyring. The same thing with import-minimal. It does this. However for 150k signatures it even takes quite some time to check whether the key does not exist locally so that the signature won't be imported. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From peter at digitalbrains.com Wed Jul 3 12:29:39 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 3 Jul 2019 12:29:39 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <4786ae84-c9d8-2256-e919-49d8cbeab876@digitalbrains.com> References: <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <1562114740.1077.40.camel@16bits.net> <20190703023529.kowkcti3evnj4zr3@raf.org> <87h883si9n.fsf@wheatstone.g10code.de> <4786ae84-c9d8-2256-e919-49d8cbeab876@digitalbrains.com> Message-ID: <72e1d064-1480-922e-f5c2-eca16b3f22a0@digitalbrains.com> On 03/07/2019 11:59, Peter Lebbing wrote: > What is the difference in the end result between --keyserver-options > self-sigs-only and --import-options import-minimal? Ah, based on a new message I just read the penny dropped. self-sigs-only can be made a default because it only applies to keyservers. import-minimal cannot be made a default because it affects all other methods of importing. Hope that helps myself / Happy to help myself / HTHM, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Jul 3 12:58:39 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 3 Jul 2019 12:58:39 +0200 Subject: Local solutions: SKS Keyserver Network Under Attack In-Reply-To: References: Message-ID: Hello Roland, > Hansen's and DKG's blog are only partly helpful. For example my Linux > system seems to *not* have a ~/.gnupg/dirmngr.conf file at all (one > of those files recommended for editing). I.e. Nautilus cannot find it. The usual case on Linux systems is that if a configuration file would otherwise be empty or equal to the default (the two can be entirely different things in general!), the configuration file simply does not exist. So instead of modifying ~/.gnupg/dirmngr.conf, *create* one and put a single line in it saying keyserver hkps://keys.openpgp.org/ I encountered some strange behaviour here: I invoked $ gpgconf --reload dirmngr afterwards (otherwise dirmngr will not reconsider its now changed configuration), and it *did not work*. It was still using the default. It did work after I rebooted (I was not in the mood to fiddle more with it and did the most heavy-handed thing that would work). Also, Enigmail doesn't seem to use this configuration at all and instead it is configured at Enigmail -> Preferences -> Keyserver I did verify using systemd's journal that the gpgconf --reload command reached its intended goal: dirmngr said "re-reading config". It just didn't have an effect for some odd reason. For people thinking about this: no, I don't use Tor for keyservers, it's not related to dirmngr refusing to change keyservers when on Tor. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Jul 3 13:17:24 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2019 13:17:24 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <72e1d064-1480-922e-f5c2-eca16b3f22a0@digitalbrains.com> (Peter Lebbing's message of "Wed, 3 Jul 2019 12:29:39 +0200") References: <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <1562114740.1077.40.camel@16bits.net> <20190703023529.kowkcti3evnj4zr3@raf.org> <87h883si9n.fsf@wheatstone.g10code.de> <4786ae84-c9d8-2256-e919-49d8cbeab876@digitalbrains.com> <72e1d064-1480-922e-f5c2-eca16b3f22a0@digitalbrains.com> Message-ID: <875zojqse3.fsf@wheatstone.g10code.de> On Wed, 3 Jul 2019 12:29, peter at digitalbrains.com said: > Ah, based on a new message I just read the penny dropped. self-sigs-only > can be made a default because it only applies to keyservers. > import-minimal cannot be made a default because it affects all other Not quite. When importing from a keyserver you use --keyserver-options and thus this allows to have a different set of options than when importing using --import (and its corresponding --import-options option). --keyserver-options recognizes all import options in addition to keyserver specific options. The main advantage of self-sigs-only is that it is really fast. Importing dkg's keys from a file takes 0.2s. Importing without that option takes 50 seconds. The latter takes a long time until it runs into the size limit which then triggers the fallback to self-sigs-only. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tlikonen at iki.fi Wed Jul 3 13:26:11 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Wed, 03 Jul 2019 14:26:11 +0300 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <87muhvqvqw.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 03 Jul 2019 12:04:55 +0200") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <871rz8o511.fsf@fifthhorseman.net> <87lfxfsiz0.fsf@wheatstone.g10code.de> <87v9wjtvnx.fsf@iki.fi> <87muhvqvqw.fsf@wheatstone.g10code.de> Message-ID: <87k1cztl4c.fsf@iki.fi> Werner Koch [2019-07-03 12:04:55+02:00] wrote: > On Wed, 3 Jul 2019 10:38, tlikonen at iki.fi said: >> I think everyone would prefer that import-clean would do all the >> checking and cleaning before importing certificates to the local >> keyring. The same thing with import-minimal. > > It does this. However for 150k signatures it even takes quite some > time to check whether the key does not exist locally so that the > signature won't be imported. Good. So in principle it works well. Thanks you. I downloaded (--receive-key) a poisoned key into an empty keyring using two different keyserver-options. The duration was practically the same. import-clean: 1 min 28 s import-minimal: 1 min 25 s I would expect import-minimal be much faster or actually both quite fast as my test keyring was empty on both tries. Anyway, it works and those options seem to protect keyring from getting poisonous certificates. There is the DOS aspect of course as it takes quite long. The same --receive-key without any keyserver-options hits gpg's limits at 26 seconds: gpg: key [...]: 4 duplicate signatures removed gpg: key [...]: 54614 signatures not checked due to missing keys gpg: key [...]: 4 signatures reordered gpg: error writing keyring '[...]/pubring.kbx': Provided object is too large gpg: key [...]: public key "[User ID not found]" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: not imported: 1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From peter at digitalbrains.com Wed Jul 3 13:50:31 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 3 Jul 2019 13:50:31 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <875zojqse3.fsf@wheatstone.g10code.de> References: <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <1562114740.1077.40.camel@16bits.net> <20190703023529.kowkcti3evnj4zr3@raf.org> <87h883si9n.fsf@wheatstone.g10code.de> <4786ae84-c9d8-2256-e919-49d8cbeab876@digitalbrains.com> <72e1d064-1480-922e-f5c2-eca16b3f22a0@digitalbrains.com> <875zojqse3.fsf@wheatstone.g10code.de> Message-ID: Hello, On 03/07/2019 13:17, Werner Koch wrote: > --keyserver-options recognizes all import options in addition to > keyserver specific options. But then import-minimal could be modified so it includes the behaviour currently planned for self-sigs-only, and import-minimal could be made the default for --keyserver-options, eliminating the need for another option called self-sigs-only. I don't think there is a need for the extra granularity: 1) --keyserver-options self-sigs-only retains all self-sigs 2) --keyserver-options import-minimal retains only the most recent self-sig Is there a good use-case for the former? If the latter also filtered out non-self-sigs in a very early stage like planned for self-sigs-only, in addition to its current functionality in a later stage of import, it would prevent the poison. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From siemons at cleanfuels.nl Wed Jul 3 15:00:16 2019 From: siemons at cleanfuels.nl (Roland) Date: Wed, 3 Jul 2019 15:00:16 +0200 Subject: Local solutions: SKS Keyserver Network Under Attack In-Reply-To: References: Message-ID: Thanks, Peter, for this confirmation. You give further detail to what I had guessed in the course of playing with the settings of GPA and Kleopatra. I conclude that there are at least two possible actions for those who want to protect there systems: In the GUIs of GPA or Kleopatra to fiddle the settings as I suggested earlier in this thread. And for Enigmail: your suggestion or In the terminal, to edit ~/.gnupg/dirmngr.conf so as to say "keyserver hkps://keys.openpgp.org/" or, if that file does not exist to create it as per your suggestion. This could be useful for some mere common GnuPG users, like me. Greetz Roland Some side thoughts: 1/ Perhaps the fear of compromised communication (including distributed software, private messages) can be mitigated by practicing short feed back lines: confirmations. Like "did you get my communication, what did it say?" 2/ Perhaps one should not give too much trust to a WoT at all. After all, a crook can pretend to be a friend, and thus yield the entire WoT untrustworthy. Sometimes a friend becomes an enemy at a later stage. As a very ordinary mere user, I do not really understand the trust levels that GnuPG asks me to consider. How can a WoT that is not 100% understood by absolutely all users be reliable? 3/ With these thoughts, I hope NOT to embarrass the developers. Forget it, if you consider it useless for your troubles. (Thanks for GnuPG!) On 03/07/2019 12:58, Peter Lebbing wrote: > Hello Roland, > >> Hansen's and DKG's blog are only partly helpful. For example my Linux >> system seems to *not* have a ~/.gnupg/dirmngr.conf file at all (one >> of those files recommended for editing). I.e. Nautilus cannot find it. > The usual case on Linux systems is that if a configuration file would > otherwise be empty or equal to the default (the two can be entirely > different things in general!), the configuration file simply does not > exist. > > So instead of modifying ~/.gnupg/dirmngr.conf, *create* one and put a > single line in it saying > > keyserver hkps://keys.openpgp.org/ > > I encountered some strange behaviour here: I invoked > > $ gpgconf --reload dirmngr > > afterwards (otherwise dirmngr will not reconsider its now changed > configuration), and it *did not work*. It was still using the default. > It did work after I rebooted (I was not in the mood to fiddle more with > it and did the most heavy-handed thing that would work). > > Also, Enigmail doesn't seem to use this configuration at all and instead > it is configured at > > Enigmail -> Preferences -> Keyserver > > I did verify using systemd's journal that the gpgconf --reload command > reached its intended goal: dirmngr said "re-reading config". It just > didn't have an effect for some odd reason. For people thinking about > this: no, I don't use Tor for keyservers, it's not related to dirmngr > refusing to change keyservers when on Tor. > > HTH, > > Peter. > From mgorny at gentoo.org Wed Jul 3 15:02:21 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Wed, 03 Jul 2019 15:02:21 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <3c8d27d0-048b-5ce1-a5bc-7e433b7bdf63@riseup.net> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <1521C5BC-A9FF-4074-AAED-C8AE207CF27A@gentoo.org> <3c8d27d0-048b-5ce1-a5bc-7e433b7bdf63@riseup.net> Message-ID: <90d9a8db659b65ccb3b7e76f64791e744d568ebd.camel@gentoo.org> On Wed, 2019-07-03 at 03:01 -0700, Mirimir via Gnupg-users wrote: > On 07/02/2019 11:42 PM, Micha? G?rny wrote: > > Then, they may decide to start mass poisoning other keys just to > > prove this is not the right solution. > > If what I propose is workable, attackers can poison as many keys as they > like. Until SKS keyservers go down, anyway. Until then, if the system > catches them quickly enough, they won't do widespread damage. They'll > inconvenience some people, of course, but that seems unavoidable. And as > an extra benefit, this would nuke file systems that store data in > signatures. > I'm afraid you are underestimating those people. The way I see it, the number of poisoned OpenPGP keys will grow quick enough to remove all valid keys from SKS keyservers, and render them practically useless. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From wk at gnupg.org Wed Jul 3 15:10:00 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2019 15:10:00 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: (Peter Lebbing's message of "Wed, 3 Jul 2019 13:50:31 +0200") References: <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <1562114740.1077.40.camel@16bits.net> <20190703023529.kowkcti3evnj4zr3@raf.org> <87h883si9n.fsf@wheatstone.g10code.de> <4786ae84-c9d8-2256-e919-49d8cbeab876@digitalbrains.com> <72e1d064-1480-922e-f5c2-eca16b3f22a0@digitalbrains.com> <875zojqse3.fsf@wheatstone.g10code.de> Message-ID: <87ftnnp8lz.fsf@wheatstone.g10code.de> On Wed, 3 Jul 2019 13:50, peter at digitalbrains.com said: > Is there a good use-case for the former? If the latter also filtered out Yes, as I wrote: 0.2s compared to 50s. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 3 15:06:25 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2019 15:06:25 +0200 Subject: Local solutions: SKS Keyserver Network Under Attack In-Reply-To: (Peter Lebbing's message of "Wed, 3 Jul 2019 12:58:39 +0200") References: Message-ID: <87muhvp8ry.fsf@wheatstone.g10code.de> On Wed, 3 Jul 2019 12:58, peter at digitalbrains.com said: > reached its intended goal: dirmngr said "re-reading config". It just > didn't have an effect for some odd reason. For people thinking about Check that you do not have a keyserver entry in your gpg.conf or Enigmail is calling gpg with that options. The keyserver specified by gpg overrides whatever dirmngr has been configured to. debug ipc log-file /some/file in dirmngr.conf should shows what is going on. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Wed Jul 3 15:20:25 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 3 Jul 2019 14:20:25 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: References: <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <21c4c200-beb6-3a8a-bd3d-13730b206f05@metacode.biz> <20190703044649.GA23596@spodhuis.org> Message-ID: <0d3ce39d-5b9d-b0d7-0871-dc3e3d5f5de3@andrewg.com> On 03/07/2019 13:45, Kristian Fiskerstrand wrote: > There are various ways this can be used for other > attack vectors as well, so they are mostly just ignored. Any of those attack vectors applicable to keyservers attempting to refresh from it? -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Jul 3 15:33:46 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 3 Jul 2019 14:33:46 +0100 Subject: No subject In-Reply-To: References: Message-ID: <64af6e4d-98fb-665a-eb4d-b47f16ea5f68@andrewg.com> On 03/07/2019 14:00, Roland wrote: > 1/ Perhaps the fear of compromised communication (including > distributed software, private messages) can be mitigated by > practicing short feed back lines: confirmations. Like "did you get my > communication, what did it say?" If your communication pathway is untrustworthy, it is more effective to use multiple independent lines of communication than multiple messages over the same channel. This is still not foolproof, but it significantly increases the difficulties faced by an attacker. That said, if you've already leaked your secrets over the insecure channel it may be too late for you. > 2/ Perhaps one should not give too much trust to a WoT at all. After > all, a crook can pretend to be a friend, and thus yield the entire > WoT untrustworthy This is not quite true - if I am the recipient of a message, I must explicitly assign "signing trust" to all the links in the signature chain, in addition to assigning "identity verification" to the root of that chain. I can also assign "marginal trust" so that more than one verification pathway is required, to protect against duplicitous individuals. But you're right, these subtleties are why WoT never took off. :-) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Jul 3 15:42:21 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 3 Jul 2019 15:42:21 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <87ftnnp8lz.fsf@wheatstone.g10code.de> References: <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <1562114740.1077.40.camel@16bits.net> <20190703023529.kowkcti3evnj4zr3@raf.org> <87h883si9n.fsf@wheatstone.g10code.de> <4786ae84-c9d8-2256-e919-49d8cbeab876@digitalbrains.com> <72e1d064-1480-922e-f5c2-eca16b3f22a0@digitalbrains.com> <875zojqse3.fsf@wheatstone.g10code.de> <87ftnnp8lz.fsf@wheatstone.g10code.de> Message-ID: Hi, On 03/07/2019 15:10, Werner Koch wrote: > Yes, as I wrote: 0.2s compared to 50s. I fear we're miscommunicating, so let me try to rephrase it again. Sorry for my persistence, it's only because I think we're miscommunicating and it would be good if that could be fixed. If --keyserver-options import-minimal behaved like --keyserver-options self-sigs-only,import-minimal as I propose, why would it take longer than 0.2 s? If there is no good use case for using --keyserver-options self-sigs-only instead of --keyserver-options self-sigs-only,import-minimal or for using --keyserver-options import-minimal instead of --keyserver-options self-sigs-only,import-minimal then the self-sigs-only behaviour can be folded into import-minimal, avoiding creating yet another option in an already crowded option space. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Jul 3 15:55:11 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 3 Jul 2019 15:55:11 +0200 Subject: Local solutions: SKS Keyserver Network Under Attack In-Reply-To: References: Message-ID: <4084bcee-f7fb-427c-0d48-39a5c3bb7844@digitalbrains.com> Hello Roland, On 03/07/2019 15:00, Roland wrote: > And for Enigmail: your suggestion or In the terminal, to edit > ~/.gnupg/dirmngr.conf so as to say "keyserver > hkps://keys.openpgp.org/" or, if that file does not exist to create it > as per your suggestion. I don't think Enigmail respects dirmngr.conf, it just provides its own set of keyservers. At least, if I delete them all from the Preferences dialog of Enigmail, it prompts me to enter a keyserver, defaulting to the literal text "undefined". HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Wed Jul 3 16:00:53 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 3 Jul 2019 16:00:53 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> Message-ID: Vincent Breitmoser via Gnupg-users wrote: > > Friendly reminder: There are no developers working on SKS right now. Zero. No > actual work has been done on SKS in years. > > - V Correct. If I would be an SKS operator I would switch to your Hadgrid, to support the PGP / GnuPG community. If I had time and money I would hire a lawyer, would formulate a letter for SKS operators stating that I request the removal of my pub key data and would as EU citizen refer in this letter to our GDPR. Maybe, if time allows, I may check with EFF and their lawyers ... Regards Stefan From ryan at digicana.com Wed Jul 3 16:16:55 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Wed, 03 Jul 2019 14:16:55 +0000 Subject: Your Thoughts In-Reply-To: <1b1ec5da-f227-cae9-cc80-846da84b8f05@riseup.net> References: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> <542a47cc-6a2b-67d0-e310-feed6a37cb66@digitalbrains.com> <_oYPRH1csOfSk33UMqTiJDZG8AKgjS7pc6J0g8Y5pdFGLAWCOFv-waMe6ZphU_e1BbzQQdhLyMdJ1ywyHC66g58skSc_tK8INfXaAM_ccEc=@digicana.com> <07bc864c-cc00-1196-e873-4a04e8452a00@sixdemonbag.org> <1b1ec5da-f227-cae9-cc80-846da84b8f05@riseup.net> Message-ID: Not sure why the phone number thing bothers people -- having a phone at all in the first place means you are easily tracked. What Signal (and any encryption system, really) does is try to prevent in-transit interception and surveillance of the actual data content. It can't hide the metadata associated with a layer well above the application layer. Openwhisper can be picked up at the firewall level, but then so can Tor and VPN spinups, and all of these things are metadata that make you score more interesting to the mass-data-scoop algorithms. If you don't want to be easily geo-locationally tracked, don't use a device with a cellular modem, full stop. What Signal (or any other E2E encrypted messaging system) does is give people the ability to communicate with each other privately. People can still see that they are talking and are trying to hide what they are saying. Yeah, that makes those people targets in some countries, but it also greatly increases the cost in manpower and resources needed to peek into those communications. Now you're looking at burning 0days to install APTs and sending human resources to deal with individuals when this could previously be handled on a global level en masse with some fiber splitters and a big ol' datacenter. If enough people use it can have a disruptive effect on mass surveillance and state control. -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail ??????? Original Message ??????? On Tuesday, July 2, 2019 10:20 PM, Mirimir via Gnupg-users wrote: > On 07/02/2019 05:18 AM, Robert J. Hansen wrote: > > > > Signal went the other way. Build a verifiably secure communications platform so easy that literally anyone can figure it out. > > > > I think this is a misunderstanding of Signal. > > > > > Signal is, by its very nature, tightly tied to one specific > > communications platform -- that of the smartphone. It's not likely to > > break out of its home. > > And not only that, it's tied to one of the least privacy-friendly > aspects of smartphones: the phone number.[0] > > | Requirements > | > | Signal uses your existing phone number. > | > | The number must be able to receive an SMS or phone call. > > Sure, it's not necessarily the number of the phone that you're using > Signal on. But it's gotta be a number that you can use, and which others > can't use. So what do you do, to avoid geolocation? > > You can't use one of those shared SMS services. So what, lease a SIM > from some SIM farm in wherever, and hope that they're honest? > > There's also the issue of actually using Signal while preventing > geolocation. You can't just use Tor, which itself is nontrivial on > smartphones, because Signal needs UDP. So you're stuck with VPNs, where > you must trust providers. > > It's frightening how popular Signal has become. Especially for people > whose lives are threatened by geolocation. If I were paranoid, I'd say > that it was a honeypot. But whatever. Something using Tor onion services > is probably the best option. Unless Tor is also a honeypot. > > > > 0) > https://support.signal.org/hc/en-us/articles/360007318691-Register-a-phone-number > > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Jul 3 16:18:50 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 3 Jul 2019 15:18:50 +0100 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> Message-ID: <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> On 03/07/2019 15:00, Stefan Claas via Gnupg-users wrote: > If I had time and money I would hire a lawyer, would formulate a letter > for SKS operators stating that I request the removal of my pub key data > and would as EU citizen refer in this letter to our GDPR. > > Maybe, if time allows, I may check with EFF and their lawyers ... Would you mind waiting for the replacement system to be fully tested and migrated before setting fire to the old one? There's a scene in the classic comedy Father Ted, where a visitor to the parochial house starts complaining about the build quality of the bookshelves, and to prove his point he pulls them to pieces. "Look at that, it's falling apart!" [1] Just because something is broken does not mean you are obliged to kick it over to prove the point. [1] https://vimeo.com/108169770 -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Jul 3 14:45:16 2019 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 3 Jul 2019 14:45:16 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: References: <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <21c4c200-beb6-3a8a-bd3d-13730b206f05@metacode.biz> <20190703044649.GA23596@spodhuis.org> Message-ID: On 7/3/19 10:17 AM, Andrew Gallagher wrote: > On 03/07/2019 05:46, Phil Pennock via Gnupg-users wrote: >> Beware: the HKP schema of paths is used with the keyserver in that >> field, in GnuPG at least. > OK, but what's the failure mode? If it's graceful, then we haven't lost > much. So long as key updates fall back to a keyserver somewhere it > should be transparent. > > This does of course need thorough testing, as not all clients will have > the same failure modes. > at least one issue that has been pointed out historically about relying on specification of TPK URI for refresh is privacy issues related to callbacks and/or DoS. There are various ways this can be used for other attack vectors as well, so they are mostly just ignored. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Wed Jul 3 16:27:21 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 3 Jul 2019 16:27:21 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> Message-ID: Andrew Gallagher wrote: > On 03/07/2019 15:00, Stefan Claas via Gnupg-users wrote: > > If I had time and money I would hire a lawyer, would formulate a letter > > for SKS operators stating that I request the removal of my pub key data > > and would as EU citizen refer in this letter to our GDPR. > > > > Maybe, if time allows, I may check with EFF and their lawyers ... > > Would you mind waiting for the replacement system to be fully tested and > migrated before setting fire to the old one? Sure, of course. Meanwhile SKS operators may check out hockeypuck (written in Golang :-)), if that helps. Regards Stefan From andrewg at andrewg.com Wed Jul 3 16:31:23 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 3 Jul 2019 15:31:23 +0100 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> Message-ID: <4219a58a-b933-5f39-46fa-385b251dd2b4@andrewg.com> On 03/07/2019 15:27, Stefan Claas via Gnupg-users wrote: > Sure, of course. Meanwhile SKS operators may check out hockeypuck (written > in Golang :-)), if that helps. It's the protocol that's broken, not the software. Migrating from SKS to hockeypuck doesn't (in itself) fix the problems. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Wed Jul 3 16:41:55 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 3 Jul 2019 16:41:55 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <4219a58a-b933-5f39-46fa-385b251dd2b4@andrewg.com> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> <4219a58a-b933-5f39-46fa-385b251dd2b4@andrewg.com> Message-ID: Andrew Gallagher wrote: > On 03/07/2019 15:27, Stefan Claas via Gnupg-users wrote: > > Sure, of course. Meanwhile SKS operators may check out hockeypuck (written > > in Golang :-)), if that helps. > > It's the protocol that's broken, not the software. Migrating from SKS to > hockeypuck doesn't (in itself) fix the problems. O.k. but as understood it is in active development and I thought, even if it is the protocol, that it would be easier to fix issues in hockeypuck than in SKS, due to the fact that Golang is more modern and has a bigger programmers community. Regards Stefan From peter at digitalbrains.com Wed Jul 3 16:43:40 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 3 Jul 2019 16:43:40 +0200 Subject: dirmngr not picking up new config? In-Reply-To: <87muhvp8ry.fsf@wheatstone.g10code.de> References: <87muhvp8ry.fsf@wheatstone.g10code.de> Message-ID: On 03/07/2019 15:06, Werner Koch wrote: > Check that you do not have a keyserver entry in your gpg.conf or > Enigmail is calling gpg with that options. The keyserver specified by > gpg overrides whatever dirmngr has been configured to. > > debug ipc > log-file /some/file > > in dirmngr.conf should shows what is going on. There hasn't been a keyserver line in my gpg.conf in a long time; I checked this before I created dirmngr.conf. And I was testing on the command line, using --refresh-keys. My guess is: dirmngr reloads existing configuration files but fails to check for new ones. Here's a reproduction: --8<---------------cut here---------------start------------->8--- $ pwd /home/peter $ rm .gnupg/dirmngr.conf $ gpgconf --kill all $ gpg --refresh-keys ac46efe6de500b3e gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net gpg: key AC46EFE6DE500B3E: 2 signatures not checked due to missing keys gpg: key AC46EFE6DE500B3E: "Peter Lebbing " not changed gpg: Total number processed: 1 gpg: unchanged: 1 $ cat >.gnupg/dirmngr.conf <" not changed gpg: Total number processed: 1 gpg: unchanged: 1 $ stat dirmngr.log stat: cannot stat 'dirmngr.log': No such file or directory $ gpgconf --kill dirmngr $ gpg --refresh-keys ac46efe6de500b3e gpg: refreshing 1 key from hkps://keys.openpgp.org/ gpg: key AC46EFE6DE500B3E: "Peter Lebbing " not changed gpg: Total number processed: 1 gpg: unchanged: 1 $ cat dirmngr.log 2019-07-03 16:30:01 dirmngr[13185.0] permanently loaded certificates: 0 2019-07-03 16:30:01 dirmngr[13185.0] runtime cached certificates: 0 2019-07-03 16:30:01 dirmngr[13185.6] handler for fd 6 started 2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> # Home: /home/peter/.gnupg 2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> # Config: /home/peter/.gnupg/dirmngr.conf 2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> OK Dirmngr 2.1.18 at your service 2019-07-03 16:30:01 dirmngr[13185.6] connection from process 13184 (1000:1000) 2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 <- GETINFO version 2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> D 2.1.18 2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> OK 2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 <- KEYSERVER 2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> S KEYSERVER hkps://keys.openpgp.org/ 2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> OK 2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 <- KS_GET -- 0x8FA94E79AD6AB56EE38CE5CBAC46EFE6DE500B3E 2019-07-03 16:30:01 dirmngr[13185.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known] 2019-07-03 16:30:01 dirmngr[13185.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known] 2019-07-03 16:30:01 dirmngr[13185.6] number of system provided CAs: 152 2019-07-03 16:30:01 dirmngr[13185.6] DBG: chan_6 -> S SOURCE https://keys.openpgp.org:443 2019-07-03 16:30:02 dirmngr[13185.6] DBG: (16329 bytes sent via D lines not shown) 2019-07-03 16:30:02 dirmngr[13185.6] DBG: chan_6 -> OK 2019-07-03 16:30:02 dirmngr[13185.6] DBG: chan_6 <- BYE 2019-07-03 16:30:02 dirmngr[13185.6] DBG: chan_6 -> OK closing connection 2019-07-03 16:30:02 dirmngr[13185.6] handler for fd 6 terminated --8<---------------cut here---------------end--------------->8--- Here's the stuff my Debian stable reports about my GnuPG: --8<---------------cut here---------------start------------->8--- Package: gnupg Version: 2.1.18-8~deb9u4 -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable'), (610, 'testing'), (600, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 5.0.15 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnupg depends on: ii gnupg-agent 2.1.18-8~deb9u4 ii libassuan0 2.4.3-2 ii libbz2-1.0 1.0.6-8.1 ii libc6 2.24-11+deb9u4 ii libgcrypt20 1.7.6-2+deb9u3 ii libgpg-error0 1.26-2 ii libksba8 1.3.5-2 ii libreadline7 7.0-3 ii libsqlite3-0 3.16.2-5+deb9u1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages gnupg recommends: ii dirmngr 2.1.18-8~deb9u4 ii gnupg-l10n 2.1.18-8~deb9u4 Versions of packages gnupg suggests: pn parcimonie pn xloadimage -- no debconf information --8<---------------cut here---------------end--------------->8--- HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Jul 3 16:50:31 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 3 Jul 2019 15:50:31 +0100 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <4219a58a-b933-5f39-46fa-385b251dd2b4@andrewg.com> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> <4219a58a-b933-5f39-46fa-385b251dd2b4@andrewg.com> Message-ID: <4c2981d0-f2d5-92ca-ee07-e8b4a92fd644@andrewg.com> On 03/07/2019 15:41, Stefan Claas via Gnupg-users wrote: > O.k. but as understood it is in active development and I thought, > even if it is the protocol, that it would be easier to fix issues > in hockeypuck than in SKS, due to the fact that Golang is more > modern and has a bigger programmers community. Sure, but it doesn't help server operators until after those changes are made. And because hockeypuck is currently ineligible to be a member of any of the pools, operators migrating en masse to it will hasten the pools' death. If you don't have one of the poisoned keys in your keyring, there's nothing wrong with continuing to use the keyservers (for now), so we shouldn't kill a service that's working just fine for those people, not until we have a replacement. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Jul 3 16:55:04 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2019 16:55:04 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: (Peter Lebbing's message of "Wed, 3 Jul 2019 15:42:21 +0200") References: <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <1562114740.1077.40.camel@16bits.net> <20190703023529.kowkcti3evnj4zr3@raf.org> <87h883si9n.fsf@wheatstone.g10code.de> <4786ae84-c9d8-2256-e919-49d8cbeab876@digitalbrains.com> <72e1d064-1480-922e-f5c2-eca16b3f22a0@digitalbrains.com> <875zojqse3.fsf@wheatstone.g10code.de> <87ftnnp8lz.fsf@wheatstone.g10code.de> Message-ID: <878stfp3qv.fsf@wheatstone.g10code.de> On Wed, 3 Jul 2019 15:42, peter at digitalbrains.com said: > --keyserver-options self-sigs-only,import-minimal > > as I propose, why would it take longer than 0.2 s? Indeed, we could change the code for import-minimal so that it first does the same what self-sigs-only does. Then it should be very similar. The reason why I added self-sigs-only is to allow ignoring key-signatures completely. Regardless of any other cleaning options. Sometimes it is useful to not clean things so that one can see hcnages to preferences and such. And well, self-sigs-only is a less intrusive change than changing import-minimal. If it breaks something it can easily be reverted by the user - a change to the semantics of import-minimal can't be reverted by the user. "self-sigs-only" also better expresses what it does. If you have a better name, let us know. > then the self-sigs-only behaviour can be folded into import-minimal, > avoiding creating yet another option in an already crowded option space. Removing the keyserver support would even result in more cleanup of that space ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Wed Jul 3 16:59:18 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 3 Jul 2019 16:59:18 +0200 Subject: SKS and GnuPG related issues and possible workarounds References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> <4219a58a-b933-5f39-46fa-385b251dd2b4@andrewg.com> Message-ID: Stefan Claas via Gnupg-users wrote: > O.k. but as understood it is in active development and I thought, > even if it is the protocol, that it would be easier to fix issues > in hockeypuck than in SKS, due to the fact that Golang is more > modern and has a bigger programmers community. Now, you awake my interest. You said it is the protocol, so let's say when Werner and his hackers has fixed the issue in GnuPG and for a protocol you usually have to sides, to work with, could that not mean then when Werner does x,y,z code in GnuPG that hockeypuck must follow x,y,z code in order that the protocol works ... ?! Or do SKS key servers dictate how GnuPG's submission / receiving protocol must work? Regards Stefan From steffen at sdaoden.eu Wed Jul 3 17:08:32 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 03 Jul 2019 17:08:32 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <87lfxfsiz0.fsf@wheatstone.g10code.de> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <871rz8o511.fsf@fifthhorseman.net> <87lfxfsiz0.fsf@wheatstone.g10code.de> Message-ID: <20190703150832.mYZtU%steffen@sdaoden.eu> Werner Koch via Gnupg-users wrote in <87lfxfsiz0.fsf at wheatstone.g10code.de>: |On Tue, 2 Jul 2019 11:00, dkg at fifthhorseman.net said: ... |import-clean does this: ... |[.]In contrast import-minimal |does this ... I (still user of GPG1, it is only your newer key which this cannot do for me) had export-options no-export-attributes,export-clean #import-options import-clean,merge-only import-options import-minimal,merge-only keyserver hkps://hkps.pool.sks-keyservers.net keyserver-options check-cert ca-cert-file=/home/steffen/sec.arena/pgp.git/sks-keyservers.net in gpg.conf (also because the in-town TU Darmstadt key server is of a terrible sort), but changed to import-minimal now, as above. I note that after --refresh-keys all the signatures are still in the DB, and even a truly updated key just loaded more signatures. My question: is there any better way than a shell script over --list-keys --with-colon | grep ^pub | ...etc... to "minimize" keys in my keyring (with gpg1)? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From kristian.fiskerstrand at sumptuouscapital.com Wed Jul 3 17:13:19 2019 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 3 Jul 2019 17:13:19 +0200 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <0d3ce39d-5b9d-b0d7-0871-dc3e3d5f5de3@andrewg.com> References: <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <21c4c200-beb6-3a8a-bd3d-13730b206f05@metacode.biz> <20190703044649.GA23596@spodhuis.org> <0d3ce39d-5b9d-b0d7-0871-dc3e3d5f5de3@andrewg.com> Message-ID: <2e969b54-090f-c95f-eb36-280d1672f277@sumptuouscapital.com> On 7/3/19 3:20 PM, Andrew Gallagher wrote: > On 03/07/2019 13:45, Kristian Fiskerstrand wrote: >> There are various ways this can be used for other >> attack vectors as well, so they are mostly just ignored. > > Any of those attack vectors applicable to keyservers attempting to > refresh from it? > potential DoS vector? (probably not the most efficient one, but...) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Jul 3 17:15:59 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 3 Jul 2019 17:15:59 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> Message-ID: On 03/07/2019 16:00, Stefan Claas via Gnupg-users wrote: > If I had time and money I would hire a lawyer, would formulate a letter > for SKS operators stating that I request the removal of my pub key data > and would as EU citizen refer in this letter to our GDPR. Do you object to your data being available not only from the many public archives of this mailing list but also from the SKS keyserver network? If so: why? Don't you think many more people would use a web search to find out about your name and e-mail address than use a keyserver search? And why the hell does exist then?!?! Or is it not that you wish to invoke the GDPR for what it was meant for, but rather you want to force the SKS keyserver network to go down, forcing your world view upon the good people running the network? If so: why do you feel entitled to do that? I seem to remember you threatening, more than a year ago, to hose some specific person's public key, who was it again, with bogus third-party signatures. I get the notion you're not what you'd call a "team player". "Bully" seems to be a better description. I'm going to leave it at that, because I don't want the list to go down the road I so desperately want to go personally. I'll take some solace from having recently read some stronger qualifications in a public post. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Jul 3 17:17:31 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 3 Jul 2019 16:17:31 +0100 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <4219a58a-b933-5f39-46fa-385b251dd2b4@andrewg.com> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> <4219a58a-b933-5f39-46fa-385b251dd2b4@andrewg.com> Message-ID: <98598085-066d-95bf-c49b-1ff1fa2ffaea@andrewg.com> On 03/07/2019 15:59, Stefan Claas via Gnupg-users wrote: > Now, you awake my interest. You said it is the protocol, so let's > say when Werner and his hackers has fixed the issue in GnuPG and > for a protocol you usually have to sides, to work with, could that > not mean then when Werner does x,y,z code in GnuPG that hockeypuck > must follow x,y,z code in order that the protocol works ... ?! > > Or do SKS key servers dictate how GnuPG's submission / receiving > protocol must work? There are several interlocking issues here. Firstly, gnupg locks up when importing outsized keys. There are things that can be done at the import stage, and this is what you mention above, but all of them just move around the consequences of abuse. That's because of the second issue, which is that the keyservers are abusable. You can fix this by making keyservers verify the identity of the uploader (as hagrid and keybase do), but this then makes the SKS reconciliation protocol unviable - so it is SKS the protocol that has to be changed, not SKS the software. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Jul 3 17:20:37 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 3 Jul 2019 16:20:37 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <2e969b54-090f-c95f-eb36-280d1672f277@sumptuouscapital.com> References: <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <21c4c200-beb6-3a8a-bd3d-13730b206f05@metacode.biz> <20190703044649.GA23596@spodhuis.org> <0d3ce39d-5b9d-b0d7-0871-dc3e3d5f5de3@andrewg.com> <2e969b54-090f-c95f-eb36-280d1672f277@sumptuouscapital.com> Message-ID: On 03/07/2019 16:13, Kristian Fiskerstrand wrote: > potential DoS vector? (probably not the most efficient one, but...) As in DoS amplification? I create a load of keys with a victim's URL in the `keyserver` field and the pool does my dirty work? Interesting, but so long as the keyservers' spiders are well behaved, it should be no worse than being indexed by Google. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From tlikonen at iki.fi Wed Jul 3 17:22:08 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Wed, 03 Jul 2019 18:22:08 +0300 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <20190703150832.mYZtU%steffen@sdaoden.eu> (Steffen Nurpmeso's message of "Wed, 03 Jul 2019 17:08:32 +0200") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <871rz8o511.fsf@fifthhorseman.net> <87lfxfsiz0.fsf@wheatstone.g10code.de> <20190703150832.mYZtU%steffen@sdaoden.eu> Message-ID: <87zhlvta73.fsf@iki.fi> Steffen Nurpmeso [2019-07-03 17:08:32+02:00] wrote: > My question: is there any better way than a shell script over > --list-keys --with-colon | grep ^pub | ...etc... to "minimize" keys in > my keyring (with gpg1)? It seems that there is no better way than scripting it. My "--edit-key + clean" script is below. It can be changed to "minimize". #!/bin/sh gpg --batch --with-colons --list-keys | awk -F: ' $1 == "pub" {pub = 1} pub == 1 && $1 == "fpr" {printf "%s clean save\n", $10; pub = 0}' | \ xargs -n3 -- gpg --batch --no-auto-check-trustdb --edit-key -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From peter at digitalbrains.com Wed Jul 3 17:22:39 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 3 Jul 2019 17:22:39 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> <4219a58a-b933-5f39-46fa-385b251dd2b4@andrewg.com> Message-ID: On 03/07/2019 16:59, Stefan Claas via Gnupg-users wrote: > Or do SKS key servers dictate how GnuPG's submission / receiving > protocol must work? It's in the reconsiliation protocol and the very foundation of the assumptions of the synchronizing keyserver network. GnuPG doesn't come anywhere near this protocol, it's just a downstream casualty of the implications of the system. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From steffen at sdaoden.eu Wed Jul 3 17:30:25 2019 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 03 Jul 2019 17:30:25 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <87zhlvta73.fsf@iki.fi> References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <871rz8o511.fsf@fifthhorseman.net> <87lfxfsiz0.fsf@wheatstone.g10code.de> <20190703150832.mYZtU%steffen@sdaoden.eu> <87zhlvta73.fsf@iki.fi> Message-ID: <20190703153025.Lcq0_%steffen@sdaoden.eu> Teemu Likonen wrote in <87zhlvta73.fsf at iki.fi>: |Steffen Nurpmeso [2019-07-03 17:08:32+02:00] wrote: | |> My question: is there any better way than a shell script over |> --list-keys --with-colon | grep ^pub | ...etc... to "minimize" keys in |> my keyring (with gpg1)? | |It seems that there is no better way than scripting it. My "--edit-key + |clean" script is below. It can be changed to "minimize". | |#!/bin/sh |gpg --batch --with-colons --list-keys | awk -F: ' |$1 == "pub" {pub = 1} |pub == 1 && $1 == "fpr" {printf "%s clean save\n", $10; pub = 0}' | \ | xargs -n3 -- gpg --batch --no-auto-check-trustdb --edit-key --End of <87zhlvta73.fsf at iki.fi> Ah, thanks. Cool! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From sac at 300baud.de Wed Jul 3 17:33:35 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 3 Jul 2019 17:33:35 +0200 Subject: SKS and GnuPG related issues and possible workarounds Message-ID: Peter Lebbing wrote: > On 03/07/2019 16:00, Stefan Claas via Gnupg-users wrote: > > If I had time and money I would hire a lawyer, would formulate a letter > > for SKS operators stating that I request the removal of my pub key data > > and would as EU citizen refer in this letter to our GDPR. > > Do you object to your data being available not only from the many public > archives of this mailing list but also from the SKS keyserver network? > If so: why? Don't you think many more people would use a web search to > find out about your name and e-mail address than use a keyserver search? > And why the hell does exist then?!?! > > Or is it not that you wish to invoke the GDPR for what it was meant for, > but rather you want to force the SKS keyserver network to go down, > forcing your world view upon the good people running the network? If so: > why do you feel entitled to do that? > > I seem to remember you threatening, more than a year ago, to hose some > specific person's public key, who was it again, with bogus third-party > signatures. > > I get the notion you're not what you'd call a "team player". "Bully" > seems to be a better description. I'm going to leave it at that, because > I don't want the list to go down the road I so desperately want to go > personally. I'll take some solace from having recently read some > stronger qualifications in a public post. > > Peter. Mmmhhh...Peter, if I should do this it should serve as help guideline for users wishing to do the same. Why? O.k. here is the deal: Let's say teenagers or younger people, like you, made funny things with someone else's pub key and you get later older and regret that someone has uploaded your pub key to the Network, without your consent (of course...) then he / she should have the possibility to remove that data, for what ever reason a person might have. Or say you are in the strong set, and later you figure out that a person in the strong set is a criminal, you do not want any longer associated with his / her signature on your key. Then also don't forget that only GnuPG and one other tool has a WoT, which even dgk could in one reply to me never explain what it is good for. People may later change their careers and no longer, for what ever reason they might have, do not want to be associated with the WoT. I assume you only know crypto stuff as a GnuPG user and has never used other crypto tools, otherwise you would not speak like this. Regarding my keybase presence, I can immediately close down my account and my data and the data from my followers is removed, cool eh? Regards Stefan From sac at 300baud.de Wed Jul 3 18:20:58 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 3 Jul 2019 18:20:58 +0200 Subject: SKS and GnuPG related issues and possible workarounds Message-ID: Stefan Claas via Gnupg-users wrote: > Regarding my keybase presence, I can immediately close down my account > and my data and the data from my followers is removed, cool eh? One more thing... You uploaded your keys with friends signatures to an SKS server and you are activists in one area. Because nowadays everyone can run a key server and peer with others globally, you *may* get later also a bit in trouble, if such a peering key server is located in a country you visit for holidays, but this country may not be as democratic as the country you live in and it may even have a crypto usage ban. The tool I currently use with friends can't bring me in possible trouble that much, because it bears no data on my key from me and the key ring with the keys from my friends has only nickname entries (I can freely choose) for their keys. My X.509 cert bears also no data from my friends. Regards Stefan From peter at digitalbrains.com Wed Jul 3 18:28:14 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 3 Jul 2019 18:28:14 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: References: Message-ID: <91ee2d7d-e94e-d7c8-4fe0-093b9cef497e@digitalbrains.com> On 03/07/2019 17:33, Stefan Claas via Gnupg-users wrote: > Mmmhhh...Peter, if I should do this it should serve as help guideline > for users wishing to do the same. > > Why? Pfah. Stop rationalising. If this is your concern, create a website where your offer your services to people wishing to do this and advertise that website broadly. Then do it for the first person that truly wants to have their data removed. I asked why you felt entitled to force your opinion upon others. You say nothing about that. You just like to bully. That's your reason. > Regarding my keybase presence, I can immediately close down my account > and my data and the data from my followers is removed, cool eh? https://web.archive.org/web/20190423190205/https://keybase.io/stefan_claas Yes, really cool! And totally beside the point, because I brought up keybase to illustrate my point that you do not want to invoke the GDPR currently to remove your data. If you would currently want to remove your data, you would have already closed your keybase account. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Wed Jul 3 18:37:46 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 3 Jul 2019 18:37:46 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <91ee2d7d-e94e-d7c8-4fe0-093b9cef497e@digitalbrains.com> References: <91ee2d7d-e94e-d7c8-4fe0-093b9cef497e@digitalbrains.com> Message-ID: Peter Lebbing wrote: > On 03/07/2019 17:33, Stefan Claas via Gnupg-users wrote: > > Mmmhhh...Peter, if I should do this it should serve as help guideline > > for users wishing to do the same. > > > > Why? > > Pfah. Stop rationalising. If this is your concern, create a website > where your offer your services to people wishing to do this and > advertise that website broadly. Then do it for the first person that > truly wants to have their data removed. > > I asked why you felt entitled to force your opinion upon others. You say > nothing about that. > > You just like to bully. That's your reason. > > > Regarding my keybase presence, I can immediately close down my account > > and my data and the data from my followers is removed, cool eh? > > https://web.archive.org/web/20190423190205/https://keybase.io/stefan_claas > > Yes, really cool! And totally beside the point, because I brought up > keybase to illustrate my point that you do not want to invoke the GDPR > currently to remove your data. If you would currently want to remove > your data, you would have already closed your keybase account. > > Peter. > Why so upset? I think I am allowed here to post my opinion and I do no "force" people. If it's your impression I can live with it. EOD. Regards Stefan From wk at gnupg.org Wed Jul 3 18:35:11 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jul 2019 18:35:11 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <20190703150832.mYZtU%steffen@sdaoden.eu> (Steffen Nurpmeso's message of "Wed, 03 Jul 2019 17:08:32 +0200") References: <43578cd858ac1015cc5e33d183a78ce6@spindel.tax> <20190614105602.gtoujikznomkyx3l@CHS-TMB-078.qmcr.qmul.ac.uk> <417b87d122ae9b41da401b2828ef614a12fb5764.camel@gentoo.org> <5d03b0b1.1c69fb81.d8a7c.b5d3SMTPIN_ADDED_MISSING@mx.google.com> <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <871rz8o511.fsf@fifthhorseman.net> <87lfxfsiz0.fsf@wheatstone.g10code.de> <20190703150832.mYZtU%steffen@sdaoden.eu> Message-ID: <87y31fnkjk.fsf@wheatstone.g10code.de> On Wed, 3 Jul 2019 17:08, steffen at sdaoden.eu said: > I (still user of GPG1, it is only your newer key which this cannot Just don't use it unless you need to decrypt very old mails. In particular not with keyservers or cards. The next maintenance release will anyway remove all keyserver and card code. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From peter at digitalbrains.com Wed Jul 3 19:00:55 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 3 Jul 2019 19:00:55 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: References: <91ee2d7d-e94e-d7c8-4fe0-093b9cef497e@digitalbrains.com> Message-ID: <34444130-4b37-f646-0b4a-424d58f10489@digitalbrains.com> On 03/07/2019 18:37, Stefan Claas via Gnupg-users wrote: > Why so upset? > > I think I am allowed here to post my opinion and I do no "force" > people. You just said that if only you had the time and money, you would try to take down the SKS network using a legal procedure. A procedure meant to object to your data being available on the internet, while you clearly don't have a problem with your data being available. A year ago, you threatened to do precisely what has happened now: poison Rob's OpenPGP key. You might even be the one that has done it, we can't know. That's not posting an opinion here. And it /is/ threatening to force your way on other people. This all is so bloody transparent that I don't see what your point is yelling that the sky is green when clearly it's blue. And apparently, I didn't check although it did ring a few bells, you have in the past indicated you had wilfully fucked with other people's OpenPGP keys to prove your point that it was possible. That's vandalism in my book. > EOD. Neither of us gets to decide that for the other. BTW, you literally asked a question ("Why so upset?"). Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Wed Jul 3 19:24:05 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 3 Jul 2019 19:24:05 +0200 Subject: Your Thoughts In-Reply-To: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> References: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> Message-ID: Alyssa Ross wrote: Apologies for my late reply, I have overlooked your reply, sorry! > For example, why isn't ask-cert-level a default? I'm guessing it's just > because at some point it didn't exist, and the developers didn't want to > make a backwards incompatible change. But it means that, out of the box, > signatures on other keys are next to useless, because it's not possible > to specify how carefully you've checked a key. This leads to people only > signing keys that they've very carefully checked, and makes it so that > marginal signatures see almost no use, which I think has likely been a > major contributor to the failure of the web of trust. I would even say if --ask-cert-level would be a default it does not guarantee how carefully a user has done key management. If you look at WWW based key server interfaces you seldom see people who have a policy link attached to their signature. And even if they would have one, they differ from user to user, making to understand the WoT harder. I tried to formulate such a policy a while ago, to strengthen the classical (global) WoT a bit, but responses to my procedure were minimal. > A large part of what makes alternative encryption software like Signal > successful is its simplicity. I don't have to worry about the 3000 > different setting combinations available to me, because there's design > work been put into it to set me up for success out of the box. I've > spent hours of my life learning about how to use GnuPG, and have ended > up with a way of using it that seems completely different to anybody > else's, but I still don't think I'm doing it right. It's not possible to > figure out how to use it as intended, because there's no intended way to > use it. There's no high level design for how people are supposed to use > the software. And without that, it's never going to be possible to use > GnuPG properly no matter how much time one is willing to invest. Normally one needs only a few commands to use GnuPG successfully for encryption and signing messages or encrypting files. Sure, when looking at the GnuPG FAQ or the source code of GnuPG it is first to much what someone has to study before he / she can use the software. Regards Stefan From ryan at digicana.com Wed Jul 3 19:26:25 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Wed, 03 Jul 2019 17:26:25 +0000 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> Message-ID: To be fair, that bookshelf got pointed out like a decade ago. It?s just that resources to build a new one never materialized. While pointing out a problem by doing a targeted demonstration attack is about as aggressively black hat as it gets, it?s hard to not expect it. Even big white hat boys like Project Zero give 90 days to fix an issue before publishing (and once published, you can assume the exploit will be used in the wild.) Pining for a simpler time when people didn?t try to exploit other people and systems is silly because those times never existed - it?s just that there didn?t use to be such significant value attached to software systems so the only people who carried out attacks were nerds doing it for the lulz. (Well, the ROTFLs back then, I guess.) Sure, nobody could anticipate contemporary attacks a decade ago, but that seems more a cautionary tale against allowing non-serviceable abandonware to run critical systems. If any 15 year old script kiddie can easily bring your whole heavily relied-upon system down, then having someone pull back the curtain on the wizard seems like an understandable choice, even if it?s a bit of a jerk move. But yeah, that said ? don?t kick the bookshelf over. :) Just hope that in the meantime nobody figures out a way to profit or benefit somehow from doing so. -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail ??????? Original Message ??????? On Wednesday, July 3, 2019 9:18 AM, Andrew Gallagher wrote: > On 03/07/2019 15:00, Stefan Claas via Gnupg-users wrote: > > > If I had time and money I would hire a lawyer, would formulate a letter > > for SKS operators stating that I request the removal of my pub key data > > and would as EU citizen refer in this letter to our GDPR. > > Maybe, if time allows, I may check with EFF and their lawyers ... > > Would you mind waiting for the replacement system to be fully tested and > migrated before setting fire to the old one? > > There's a scene in the classic comedy Father Ted, where a visitor to the > parochial house starts complaining about the build quality of the > bookshelves, and to prove his point he pulls them to pieces. "Look at > that, it's falling apart!" [1] > > Just because something is broken does not mean you are obliged to kick > it over to prove the point. > > [1] https://vimeo.com/108169770 > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Andrew Gallagher > > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users To -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From hi at alyssa.is Wed Jul 3 20:30:45 2019 From: hi at alyssa.is (Alyssa Ross) Date: Wed, 3 Jul 2019 18:30:45 +0000 Subject: Your Thoughts In-Reply-To: <4e01cd0e-3d9e-4ab9-479a-db5cb3f25700@metacode.biz> References: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> <4e01cd0e-3d9e-4ab9-479a-db5cb3f25700@metacode.biz> Message-ID: <20190703183045.luortiatpzbunghr@x220.qyliss.net> > > For example, why isn't ask-cert-level a default? > > For an alternative view on ask-cert-level see also: > > https://debian-administration.org/users/dkg/weblog/98 Oh, interesting. Thank you for showing this to me. I had it in my head that a "weak" signature would count as a marginal in the web of trust, but I suppose I was wrong about that. In that case, I agree that ask-cert-level doesn't make sense as a default. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gnupg at leo.gaspard.ninja Wed Jul 3 21:14:00 2019 From: gnupg at leo.gaspard.ninja (Leo Gaspard) Date: Wed, 03 Jul 2019 21:14:00 +0200 Subject: Your Thoughts In-Reply-To: <20190703183045.luortiatpzbunghr@x220.qyliss.net> References: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> <4e01cd0e-3d9e-4ab9-479a-db5cb3f25700@metacode.biz> <20190703183045.luortiatpzbunghr@x220.qyliss.net> Message-ID: <87tvc39bif.fsf@llwynog.ekleog.org> Alyssa Ross writes: >> > For example, why isn't ask-cert-level a default? >> >> For an alternative view on ask-cert-level see also: >> >> https://debian-administration.org/users/dkg/weblog/98 > > Oh, interesting. Thank you for showing this to me. I had it in my head > that a "weak" signature would count as a marginal in the web of trust, > but I suppose I was wrong about that. > > In that case, I agree that ask-cert-level doesn't make sense as a > default. Well, that's also an ecosystem issue, and if I'm not mistaken this thread (or was it another one?) was going quite far in the ?let's fix the ecosystem and keep the standard? direction. ?weak? *could* be used for verification. For instance, if I were to write an OpenPGP client, I'd likely make it so that: * Trust (which is 0-255 in the standard) is a slider with marks like ?I trust not at all|a bit|a lot| completely? (with a proper sentence so that people understand, not like what I'm putting here) * Signature level (4 levels in the standard) is a similar slider * Both trust and signature level are mapped to a [0, 1] value, and multiplied to get the amount of confidence we have thanks to this particular signature that the key is correct * All such amounts of confidence get added, and the ?3-marginals or 1-full? rule becomes a simple number that needs to be passed with this addition (also configured as a slider with some ?normal user / ? / parano?d user? landmarks) (for trust signatures, in such a scheme they'd first be cut off to follow the OpenPGP certification, and then get multiplied by the length of the path, to account for decreasing trust along longer paths) This is compatible with RFC4880 (well, except it doesn't respect the ?SHOULD? that full trust is 120 and marginal 60, because it actually uses the whole range). So ask-cert-level might make sense as a default. Just not as GnuPG's default, as GnuPG doesn't have such a behavior (and no client that I know of currently do). But someday, maybe. From wiktor at metacode.biz Wed Jul 3 21:28:26 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 3 Jul 2019 21:28:26 +0200 Subject: Your Thoughts In-Reply-To: <20190703183045.luortiatpzbunghr@x220.qyliss.net> References: <20190701225832.6oldo4pexgjuy6yy@x220.qyliss.net> <4e01cd0e-3d9e-4ab9-479a-db5cb3f25700@metacode.biz> <20190703183045.luortiatpzbunghr@x220.qyliss.net> Message-ID: <22119f69-4d85-8e95-e496-7bd484c351e3@metacode.biz> On 03.07.2019 20:30, Alyssa Ross wrote: > Oh, interesting. Thank you for showing this to me. I had it in my head > that a "weak" signature would count as a marginal in the web of trust, > but I suppose I was wrong about that. > > In that case, I agree that ask-cert-level doesn't make sense as a > default. I spent far too much time reading various OpenPGP resources so if you don't mind two articles that I particularly like:) https://www.linux.com/learn/pgp-web-trust-core-concepts-behind-trusted-communication and https://www.linuxfoundation.org/blog/2014/02/pgp-web-of-trust-delegated-trust-and-keyservers/ The information density when I read them was definitely high for me but such articles are unfortunately very rare in this ecosystem. Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From gnupg at raf.org Thu Jul 4 03:42:09 2019 From: gnupg at raf.org (raf) Date: Thu, 4 Jul 2019 11:42:09 +1000 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <87h883si9n.fsf@wheatstone.g10code.de> References: <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <1562114740.1077.40.camel@16bits.net> <20190703023529.kowkcti3evnj4zr3@raf.org> <87h883si9n.fsf@wheatstone.g10code.de> Message-ID: <20190704014209.libj6bnkppvxrspd@raf.org> Werner Koch via Gnupg-users wrote: > On Wed, 3 Jul 2019 12:35, gnupg-users at gnupg.org said: > > > problem but I have read RJH's article). It sounds like SKS servers can > > handle these poisoned keys but GPG can't. That suggests that maybe GPG's > > I think here is a misunderstanding. Sure, processing 150k signatures > takes quite some time and makes things very slow. This is why we call > it a DoS. We can't do much about it. Compare it to X.509 CRLs - they > have a very similar problem (cacert.org is a prominent but not the only > example of CRLs making S/MIME processing very slow). > > The actual problem in gpg when using the keybox format is that only > after processing the imported keys we hit a 5MiB limit for the keyblock > in the database layer. Thus the import fails. Determining the size of > the keyblock as it will be stored requires that we first remove some > (standard) garbage from the keyblock - this takes some time. With the > currently deployed code gpg will just reject any updates from a key if > that limit was reached. That is not a good choice and the reason why I > call it a bug. The fix to this bug is to fallback importing a stripped > down version of the key. The current state is that we keep only > self-signatures and then then import again with import-clean (which is > then basically identical to import-minimal). > > > For example, if the problem is overuse of resources such as memory, could > > the keyring handling code be rewritten to use fewer resources? e.g. treat > > Years ago we had the problem that people uploaded keys with large user > ids and such. Thus we introduced limits to avoid spamming the keyring > with such faked data. There is also an overall limit of 5 MiB for the > entire keyblock which is sufficient for all real-world keyblocks - even > for those with many key-signatures. > > > signatures when importing a key, perhaps there could be a limit to how many > > signatures GPG will verify. Does it really have to verify every single one? > > It needs to validate all self-signature because they make up the > integrity of the keyblock. For key-signature, sure we could introduce a > limit, we actually do that with import-clean because that imports only > those key-signature which we can verify and which are the latest from the > same key (it is possible to sign a key several times to change meta data > associated with the key-signature). > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. Hi Werner, Thanks for the detailed explanation. And thanks for gpg. cheers, raf From angel at pgp.16bits.net Thu Jul 4 04:23:22 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Thu, 04 Jul 2019 04:23:22 +0200 Subject: SKS Keyserver Network Under Attack In-Reply-To: References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <5b4f779f-8669-2785-a92c-c75b48357f8d@riseup.net> <20190701224317.x3mffnm63klnxcyg@x220.qyliss.net> Message-ID: <1562207002.902.9.camel@16bits.net> On 2019-07-02 at 10:01 +0200, Wiktor Kwapisiewicz wrote: > > It is a real shame that a decentralized Hagrid isn't really > >possible, though, at least to my understanding. It's quite the > >limitation for GnuPG. > > Decentralized non-identity information hagrid could still be > possible. > It's just a question over which protocol to synchronize this kind of > data. A point I don't like about the design of hagrid is that verification is performed by the server itself. Thus, it seems that if there were a reconciliation protocol between them, either entering into one of them would lead to all of them blindly trusting it, or the owner would need to validate a challenge for each keyserver to which it gets replicated. My expectation would be that the verification added a (non-dropped) signature by the entity which performed the verification. The keyservers themselves would be configured with a set of introducing keys whose signatures they accepted for non-stripping. This way, multiple servers, managed by different individuals, could rely on a common verification entity (which may not run a keyserver itself). The current reconciliation protocol (ie. the one used by SKS) would probably work if all keyservers in a network trusted the same verification keys, as they would share the same view. (I admit my utter ignorance of the gossip protocol, though) It would be desirable that it worked even with separate ones, so eg. gentoo could use a single server that allowed its own CA and keys.openpgp.org, even if the later only trusted its own verifier. Unpublishing of uids would simply be triggered by the publication of the revocation signature. This is akin to other systems, like the old "PGP Global Directory Verification Key" signatures. I see on https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/ that a machine-readable vouch was not added since "we don?t think that the verification is strong enough to even warrant a positive certification". However, I do think that will be needed in order to have a successful keyserver network, and it would be helpful to separate both roles. They could be made at the persona cert level (1), to make gpg ignore them (by default), though, as a way to disincentive treating them as a CA. Kind regards From gnupg-users at spodhuis.org Thu Jul 4 04:29:01 2019 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Wed, 3 Jul 2019 22:29:01 -0400 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: References: <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <21c4c200-beb6-3a8a-bd3d-13730b206f05@metacode.biz> <20190703044649.GA23596@spodhuis.org> Message-ID: <20190704022901.GA20696@spodhuis.org> On 2019-07-03 at 09:17 +0100, Andrew Gallagher wrote: > I didn't even know it supported finger URLs - handy to know! Opening a > finger port may be a step too far for the security-conscious though... Depends upon the implementation. I'm biased here, I wrote my own in Go back in 2016: https://go.pennock.tech/fingerd/ See the AttackSurface.md doc therein too. That provides the finger service for @spodhuis.org ... using the FreeBSD port 1079 example configuration. A packet filter redirects port 79 to the correct port in the Jail which lacks outbound network connectivity except via NAT state for established connections. -Phil From mirimir at riseup.net Thu Jul 4 07:19:13 2019 From: mirimir at riseup.net (Mirimir) Date: Wed, 3 Jul 2019 22:19:13 -0700 Subject: Local solutions: SKS Keyserver Network Under Attack In-Reply-To: <4084bcee-f7fb-427c-0d48-39a5c3bb7844@digitalbrains.com> References: <4084bcee-f7fb-427c-0d48-39a5c3bb7844@digitalbrains.com> Message-ID: <0af7bb5e-98ad-361a-1e72-47b0745a126b@riseup.net> Moved by Roland's requests, I've broken Enigmail in a fresh VM. And I'd appreciate some advice about how to fix it. I installed Thunderbird and Enigmail in a Debian 9.5 x64 VM with Gnome. Using Enigmail Key Management, I tried to get rjh's 1DCBDC01B44427C7 from pool.sks-keyservers.net, but that just timed out. So I downloaded it via HTTPS. And it was ~60MB. I tried importing from the downloaded file, but that went nowhere. With 100% CPU. So I got it from https://keybase.io/rjh and imported from clipboard in Enigmail Key Management. That worked just fine. So then I tried refreshing keys in Enigmail, leaving pool.sks-keyservers.net as the default keyserver. And that failed, complaining about no dirmngr. Then I tried refreshing keys with gpg in terminal, and got the same error about no dirmngr. Then I deleted rjh's key, and got my own from Keybase, and imported it. But when I tried refreshing keys, I got the same error about no dirmngr. So gpg must still work, because I can import and delete keys via Enigmail. But something seems borked about dirmngr. I guess that I'll try purging and reinstalling. Or is there a better fix? And yes, I should have tested everything first with a clean key, before messing with rjh's key. Is it likely that I borked dirmngr during the intital attempt to get it from pool.sks-keyservers.net? From ryan at digicana.com Thu Jul 4 07:40:20 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Thu, 04 Jul 2019 05:40:20 +0000 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> References: <1bb517a6-5586-24e3-8f11-8538e72d2ff1@riseup.net> <2HWKPFEVMT5VZ.3AC2NY04PM0HF@my.amazin.horse> <39fa2a94-e48f-31b0-1881-4b6f8d8b56fe@andrewg.com> Message-ID: To be fair, that bookshelf got pointed out like a decade ago. It?s just that resources to build a new one never materialized. While pointing out a problem by doing a targeted demonstration attack is about as aggressively black hat as it gets, it?s hard to not expect it. Even big white hat boys like Project Zero give 90 days to fix an issue before publishing (and once published, you can assume the exploit will be used in the wild.) Pining for a simpler time when people didn?t try to exploit other people and systems is silly because those times never existed - it?s just that there didn?t use to be such significant value attached to software systems so the only people who carried out attacks were nerds doing it for the lulz. (Well, the ROTFLs back then, I guess.) Sure, nobody could anticipate contemporary attacks a decade ago, but that seems more a cautionary tale against allowing non-serviceable abandonware to run critical systems. If any 15 year old script kiddie can easily bring your whole global heavily relied-upon system down, then having someone pull back the curtain on the wizard seems like an understandable choice, even if it?s a bit of a jerk move. But yeah, that said ? don?t kick the bookshelf over. :) Just hope that in the meantime nobody figures out a way to profit or benefit somehow from doing so. -Ryan McGinnis [https://bigstormpicture.com](https://bigstormpicture.com/) PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail On Wed, Jul 3, 2019 at 09:18, Andrew Gallagher wrote: > On 03/07/2019 15:00, Stefan Claas via Gnupg-users wrote: >> If I had time and money I would hire a lawyer, would formulate a letter >> for SKS operators stating that I request the removal of my pub key data >> and would as EU citizen refer in this letter to our GDPR. >> >> Maybe, if time allows, I may check with EFF and their lawyers ... > > Would you mind waiting for the replacement system to be fully tested and > migrated before setting fire to the old one? > > There's a scene in the classic comedy Father Ted, where a visitor to the > parochial house starts complaining about the build quality of the > bookshelves, and to prove his point he pulls them to pieces. "Look at > that, it's falling apart!" [1] > > Just because something is broken does not mean you are obliged to kick > it over to prove the point. > > [1] https://vimeo.com/108169770 > > -- > Andrew Gallagher > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: publicKey - ryan at digicana.com - 5c738727ee58786a777c4f1db5aa3fa3486ed7ad.asc URL: From mirimir at riseup.net Thu Jul 4 07:55:43 2019 From: mirimir at riseup.net (Mirimir) Date: Wed, 3 Jul 2019 22:55:43 -0700 Subject: Your Thoughts In-Reply-To: References: <2FnvG3ACPyCfS4AqMpPsSOKCoypDXdywxX6V3v85lJfS7-7aff3TO9RH5-INCpdGLOudWdkuyP4pD0n4m_iJIdSDtYRsEvUsh9koHUjcLk0=@digicana.com> <542a47cc-6a2b-67d0-e310-feed6a37cb66@digitalbrains.com> <_oYPRH1csOfSk33UMqTiJDZG8AKgjS7pc6J0g8Y5pdFGLAWCOFv-waMe6ZphU_e1BbzQQdhLyMdJ1ywyHC66g58skSc_tK8INfXaAM_ccEc=@digicana.com> <07bc864c-cc00-1196-e873-4a04e8452a00@sixdemonbag.org> <1b1ec5da-f227-cae9-cc80-846da84b8f05@riseup.net> Message-ID: On 07/03/2019 07:16 AM, Ryan McGinnis via Gnupg-users wrote: > Not sure why the phone number thing bothers people -- having a > phone at all in the first place means you are easily tracked. Well, that's why I only use phones (and not smartphones) for routine meatspace stuff where I don't care about privacy. If the NSA wants to know about my dental appointments, fine. > What Signal (and any encryption system, really) does is try to > prevent in-transit interception and surveillance of the actual > data content. It can't hide the metadata associated with a layer > well above the application layer. You're missing the point. Signal not only doesn't hide network-level metadata, it embeds it in the content. As the bloody account ID. I mean, I'm sitting here at a computer. It has lots of firmware IDs, a MAC address, and a public ISP-assigned IP address. But none of that stuff, unless I am sadly mistaken, shows up in my online activity. In the headers of this message, for example. Because I use nested VPN chains, plus Tor when I really want some anonymity. So the equivalent here to Signal would be that my email address had to be associated with my ISP-assigned IP address. And for sure, that's how it was 20 years ago, when I used an email address from my ISP. I used PGP for content privacy, but there was zero anonymity. So how is that bullshit acceptable in 2019? > Openwhisper can be picked up at the firewall level, but then so > can Tor and VPN spinups, and all of these things are metadata > that make you score more interesting to the mass-data-scoop > algorithms. If you don't want to be easily geo-locationally > tracked, don't use a device with a cellular modem, full stop. Sure. But I can start with a popular VPN, and maybe 20% of people around me use VPNs for pirating, so that's not too unusual. What's unusual is what I route through that VPN. But even discovering that would take some work, and then they'd just see another VPN. The won't see Tor until they drill down 3-4 VPNs. It's not just cellular modems that enable geolocation. There's GPS. And there are databases with locations of WiFi APs. If it were possible to securely use VPNs and Tor on smartphones, geolocation wouldn't be any more of an issue than it is for me, sitting here at my computer. From mirimir at riseup.net Thu Jul 4 08:34:21 2019 From: mirimir at riseup.net (Mirimir) Date: Wed, 3 Jul 2019 23:34:21 -0700 Subject: Local solutions: SKS Keyserver Network Under Attack In-Reply-To: <0af7bb5e-98ad-361a-1e72-47b0745a126b@riseup.net> References: <4084bcee-f7fb-427c-0d48-39a5c3bb7844@digitalbrains.com> <0af7bb5e-98ad-361a-1e72-47b0745a126b@riseup.net> Message-ID: <2b718f80-7eb8-37d2-b83a-9f14bd3c4b10@riseup.net> On 07/03/2019 10:19 PM, Mirimir wrote: > Moved by Roland's requests, I've broken Enigmail in a fresh VM. And I'd > appreciate some advice about how to fix it. > > I installed Thunderbird and Enigmail in a Debian 9.5 x64 VM with Gnome. > Using Enigmail Key Management, I tried to get rjh's 1DCBDC01B44427C7 > from pool.sks-keyservers.net, but that just timed out. > > So I downloaded it via HTTPS. And it was ~60MB. I tried importing from > the downloaded file, but that went nowhere. With 100% CPU. > > So I got it from https://keybase.io/rjh and imported from clipboard in > Enigmail Key Management. That worked just fine. So then I tried > refreshing keys in Enigmail, leaving pool.sks-keyservers.net as the > default keyserver. And that failed, complaining about no dirmngr. Then I > tried refreshing keys with gpg in terminal, and got the same error about > no dirmngr. > > Then I deleted rjh's key, and got my own from Keybase, and imported it. > But when I tried refreshing keys, I got the same error about no dirmngr. > > So gpg must still work, because I can import and delete keys via > Enigmail. But something seems borked about dirmngr. I guess that I'll > try purging and reinstalling. Or is there a better fix? Damn. Somehow dirmngr didn't get installed with Thunderbird and Enigmail. How embarrassing. So now Enigmail does refresh my key. But after importing rjh's key, refreshing in Enigmail fails: | Downloading of keys failed | gpg: keyserver receive failed: No data I also tried in terminal: | user at debian:~$ gpg --refresh-keys | gpg: refreshing 2 keys from hkps://hkps.pool.sks-keyservers.net | gpg: key ...: 22 signatures not checked due to missing keys | gpg: key ...: "mirimir " not changed | gpg: Total number processed: 1 | gpg: unchanged: 1 Then I disabled rjh's key, and found that my key still refreshed quickly. Using hkps.pool.sks-keyservers.net. So that's good news, yes? Trying to refresh rjh's key failed, but it failed quickly, and the attempt apparently didn't break anything. > And yes, I should have tested everything first with a clean key, before > messing with rjh's key. Is it likely that I borked dirmngr during the > intital attempt to get it from pool.sks-keyservers.net? > From andrewg at andrewg.com Thu Jul 4 09:19:10 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 4 Jul 2019 08:19:10 +0100 Subject: SKS Keyserver Network Under Attack In-Reply-To: <1562207002.902.9.camel@16bits.net> References: <3c4424c0-3ba9-e3f9-169f-0738311e7ca7@sixdemonbag.org> <7c894582-c9c2-c112-c388-0cd0496ca9e6@sixdemonbag.org> <5b4f779f-8669-2785-a92c-c75b48357f8d@riseup.net> <20190701224317.x3mffnm63klnxcyg@x220.qyliss.net> <1562207002.902.9.camel@16bits.net> Message-ID: <2529A97B-744A-4E06-BB56-480CEB74075B@andrewg.com> > On 4 Jul 2019, at 03:23, ?ngel wrote: > > A point I don't like about the design of hagrid is that verification is > performed by the server itself. > Thus, it seems that if there were a reconciliation protocol between > them, either entering into one of them would lead to all of them blindly > trusting it, or the owner would need to validate a challenge for each > keyserver to which it gets replicated. Exactly. This is why I believe we need to separate the functions of ?master? keystores (such as hagrid, keybase, WKD) from ?caching? keystores such as SKS. The master (but not authoritative) keystores would provide IDs and third party sigs, at the cost of having to perform verification (email in the case of email IDs and domain in the case of server IDs). The caching keystores would synchronise, but only the primary keys. They would then spider the master keystores for the rest of the key info. There is no reason for the master keystores to publicly certify keys - their verification process is an antispam measure, not an attestation of identity. But we can?t do away with verifying entirely, because there is no other known way to prevent flooding. A From andrewg at andrewg.com Thu Jul 4 10:37:56 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 4 Jul 2019 09:37:56 +0100 Subject: New keyserver at keys.openpgp.org - what's your take? In-Reply-To: <20190704022901.GA20696@spodhuis.org> References: <87fto3oyhj.fsf@wheatstone.g10code.de> <817b568d-f39e-30fe-7d75-ed92cb67af5e@andrewg.com> <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <21c4c200-beb6-3a8a-bd3d-13730b206f05@metacode.biz> <20190703044649.GA23596@spodhuis.org> <20190704022901.GA20696@spodhuis.org> Message-ID: On 04/07/2019 03:29, Phil Pennock wrote: > Depends upon the implementation. I'm biased here, I wrote my own in > Go back in 2016: https://go.pennock.tech/fingerd/ Nice. I can't see corporate firewall admins buying it though. :-) -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Jul 4 15:35:11 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 4 Jul 2019 15:35:11 +0200 Subject: keyserver-options: self-sigs-only, import-clean, import-minimal In-Reply-To: <878stfp3qv.fsf@wheatstone.g10code.de> References: <87ef3my885.fsf@fifthhorseman.net> <1EB66780-9D33-49E6-9EB6-6D0D2F5FD4C2@andrewg.com> <87o92fngtq.fsf@fifthhorseman.net> <0642c71b-5365-5473-5c5b-1349f12fde1c@andrewg.com> <8736jpk9g3.fsf@wheatstone.g10code.de> <877e90ew7t.fsf_-_@iki.fi> <87v9wkg2dx.fsf@wheatstone.g10code.de> <1562114740.1077.40.camel@16bits.net> <20190703023529.kowkcti3evnj4zr3@raf.org> <87h883si9n.fsf@wheatstone.g10code.de> <4786ae84-c9d8-2256-e919-49d8cbeab876@digitalbrains.com> <72e1d064-1480-922e-f5c2-eca16b3f22a0@digitalbrains.com> <875zojqse3.fsf@wheatstone.g10code.de> <87ftnnp8lz.fsf@wheatstone.g10code.de> <878stfp3qv.fsf@wheatstone.g10code.de> Message-ID: <8ea753f6-2d80-b14d-0a45-df11d45c1773@digitalbrains.com> On 03/07/2019 16:55, Werner Koch wrote: > And well, self-sigs-only is a less intrusive change than changing > import-minimal. If it breaks something it can easily be reverted by the > user - a change to the semantics of import-minimal can't be reverted by > the user. Ah, yes, I had completely not considered that area of impact. > "self-sigs-only" also better expresses what it does. If you have a > better name, let us know. No, I think it's a good name. Thanks for making the rationale of the design clear! Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wiktor at metacode.biz Fri Jul 5 11:15:10 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 5 Jul 2019 11:15:10 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> On 03.07.2019 17:33, Stefan Claas via Gnupg-users wrote: > Regarding my keybase presence, I can immediately close down my account > and my data and the data from my followers is removed, cool eh? I did a small experiment and it seems that your data is permanently preserved in sigchains of all people that follow you. Even if you delete your account. For example this is my account's sigchain: https://keybase.io/_/api/1.0/sig/get.json?uid=ba0cc408d52c5965ac804448d36e1b19 I did create a dummy account and followed that. The account is deleted now: https://keybase.io/richard12384 But the data still remain in API of my sigchain (grep for the username). I did try to clarify this with Keybase people but did not get the reply (maybe you'd have more luck in this). Kind regards, Wiktor -- https://metacode.biz/@wiktor From peter at digitalbrains.com Fri Jul 5 11:26:58 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 5 Jul 2019 11:26:58 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> Message-ID: <4e6d2283-80cd-e7bf-7a25-ae3ac866dc19@digitalbrains.com> On 05/07/2019 11:15, Wiktor Kwapisiewicz via Gnupg-users wrote: > I did a small experiment and it seems that your data is permanently > preserved in sigchains of all people that follow you. Even if you > delete your account. Plus, the data is preserved in different places such as archive.org, which I showed already in my earlier post: https://web.archive.org/web/20190423190205/https://keybase.io/stefan_claas That's a snapshot from 2 months ago, which will not go anywhere. It kinda was my point posting that link ;-). Peter. PS: Before you blame archive.org: they respect robots exclusions and wishes from individual site owners. It was keybase.io which allowed it in the first place, although it may or may not have been a conscious decision on their part. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wiktor at metacode.biz Fri Jul 5 12:13:25 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 5 Jul 2019 12:13:25 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <4e6d2283-80cd-e7bf-7a25-ae3ac866dc19@digitalbrains.com> References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> <4e6d2283-80cd-e7bf-7a25-ae3ac866dc19@digitalbrains.com> Message-ID: <3ce714ff-63f7-bb3d-1178-7279563d604e@metacode.biz> On 05.07.2019 11:26, Peter Lebbing wrote: > PS: Before you blame archive.org: they respect robots exclusions and > wishes from individual site owners. It was keybase.io which allowed it > in the first place, although it may or may not have been a conscious > decision on their part. To be honest I'd consider this a separate matter. Because if the data is deleted from site X but archive.org snapshots it it's archive.org that now processes your data, not site X. Now, of course I do agree with your overall conclusion that the data is spread throughout the Internet anyway (through mailing lists, git logs etc.) but that doesn't mean that social sites shouldn't do their due diligence w.r.t. data deletion. As for robots.txt not all archiving sites respect it: https://www.archiveteam.org/index.php?title=Robots.txt Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Fri Jul 5 16:14:17 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 5 Jul 2019 16:14:17 +0200 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> Message-ID: Wiktor Kwapisiewicz wrote: > On 03.07.2019 17:33, Stefan Claas via Gnupg-users wrote: > > Regarding my keybase presence, I can immediately close down my account > > and my data and the data from my followers is removed, cool eh? > > I did a small experiment and it seems that your data is permanently > preserved in sigchains of all people that follow you. Even if you delete > your account. > > For example this is my account's sigchain: > > https://keybase.io/_/api/1.0/sig/get.json?uid=ba0cc408d52c5965ac804448d36e1b19 > > I did create a dummy account and followed that. > > The account is deleted now: > https://keybase.io/richard12384 > > But the data still remain in API of my sigchain (grep for the username). > > I did try to clarify this with Keybase people but did not get the reply > (maybe you'd have more luck in this). > > Kind regards, > Wiktor > Thanks for the info, much appreciated! I think also that people who delete their accounts can live with at least the fact that keybase searches in the interface no longer show up then their page, right? Regard?ng archive.org, I think if one request the deletion of data there they have to follow too, same as Google and any others. We people should be thankful that this is since GDPR took place now possible, at least for EU citizens. Regards Stefan From wk at gnupg.org Fri Jul 5 17:15:12 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Jul 2019 17:15:12 +0200 Subject: Release candidate for 2.2.17 Message-ID: <875zogms1r.fsf@wheatstone.g10code.de> Hi! Due to the SKS keyserver problems we are planning a new release for the next week. That release will have some changes related to keyserver. See below for details. In general we do not provide release candidates because experience showed that they are more or less ignored. However, this time I would like to you to give that version some testing. Get it from and in case of problems please report to gnupg-devel. Here are the changes: * gpg: Ignore all key-signatures received from keyservers. This change is required to mitigate a DoS due to keys flooded with faked key-signatures. The old behaviour can be achieved by adding keyserver-options no-self-sigs-only,no-import-clean to your gpg.conf. [#4607] * gpg: If an imported keyblocks is too large to be stored in the keybox (pubring.kbx) do not error out but fallback to an import using the options "self-sigs-only,import-clean". [#4591] * gpg: New command --locate-external-key which can be used to refresh keys from the Web Key Directory or via other methods configured with --auto-key-locate. * gpg: New import option "self-sigs-only". * gpg: In --auto-key-retrieve prefer WKD over keyservers. [#4595] * dirmngr: Support the "openpgpkey" subdomain feature from draft-koch-openpgp-webkey-service-07. [#4590]. * dirmngr: Add an exception for the "openpgpkey" subdomain to the CSRF protection. [#4603] * dirmngr: Fix endless loop due to http errors 503 and 504. [#4600] * dirmngr: Fix TLS bug during redirection of HKP requests. [#4566] * gpgconf: Fix a race condition when killing components. [#4577] Release-info: https://dev.gnupg.org/T4606 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From david at gbenet.com Fri Jul 5 20:24:15 2019 From: david at gbenet.com (David) Date: Fri, 5 Jul 2019 19:24:15 +0100 Subject: test Message-ID: Just testing my e-,ails are getting through :) But not signed :) no public key David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! https://gbenet.com From lists at boyandin.info Sat Jul 6 02:45:59 2019 From: lists at boyandin.info (Konstantin Boyandin) Date: 5 Jul 2019 20:45:59 -0400 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> Message-ID: <3e3ed575-d305-44c8-a3ef-0f4ada3aecba@mtasv.net> Hello, Thanks to everyone who expressed their opinions (I read the thread, even if I don't reply often). I didn't expect the discussion would become so red-hot, however. There's a Russian saying with closest English translation "two movings are as devastating as one fire". I assume that transition to the announced GnuPG pre-release, as well as gradual switching to the new keyserver(s) may reduce the number of movings. As for data staying forever in keyservers records - I assume no amount of GDPRs may force the Internet to completely forget a piece of information (while it still can be wiped from most public places). Whereas archive.org can remove any site/page from their history (they explain the procedure upon request), Archive Team and many others definitely won't, and there's no magic to remove the piece of information from everywhere. So it's just a fact, anyone can post anything that will stay for long. ATM, none of systems I use GnuPG in has been hit with the signature flood disaster. If I might miss that point - is it possible to get, somehow, the list of flooded keys IDs (if anyone keeps the stats)? Sincerely, Konstantin Boyandin On 05.07.2019 21:14, Stefan Claas via Gnupg-users writes: > Wiktor Kwapisiewicz wrote: > >> On 03.07.2019 17:33, Stefan Claas via Gnupg-users wrote: >>> Regarding my keybase presence, I can immediately close down my account >>> and my data and the data from my followers is removed, cool eh? >> >> I did a small experiment and it seems that your data is permanently >> preserved in sigchains of all people that follow you. Even if you delete >> your account. >> ... >> >> I did try to clarify this with Keybase people but did not get the reply >> (maybe you'd have more luck in this). > > Thanks for the info, much appreciated! > > I think also that people who delete their accounts can live with at > least the fact that keybase searches in the interface no longer > show up then their page, right? > > Regard?ng archive.org, I think if one request the deletion of data > there they have to follow too, same as Google and any others. > > We people should be thankful that this is since GDPR took place > now possible, at least for EU citizens. > > Regards > Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: not available URL: From tlikonen at iki.fi Sat Jul 6 07:33:37 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Sat, 06 Jul 2019 08:33:37 +0300 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <3e3ed575-d305-44c8-a3ef-0f4ada3aecba@mtasv.net> (Konstantin Boyandin via Gnupg-users's message of "5 Jul 2019 20:45:59 -0400") References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> <3e3ed575-d305-44c8-a3ef-0f4ada3aecba@mtasv.net> Message-ID: <87lfxb20cu.fsf@iki.fi> Konstantin Boyandin via Gnupg-users [2019-07-05T20:45:59-04:00] wrote: > ATM, none of systems I use GnuPG in has been hit with the signature > flood disaster. If I might miss that point - is it possible to get, > somehow, the list of flooded keys IDs (if anyone keeps the stats)? I don't maintain a list and such a list can be always outdated anyway. Better option is to set protective settings right now in gpg.conf file. keyserver-options import-clean # maybe also: import-options import-clean With option "import-clean" key import operations accept only key signatures from already known keys. With poisoned keys the import operation can take time but at least your local keyring is protected from importing them. The gpg(1) manual page for version 2.1.18 (Debian) is misleading, though. import-clean After import, compact (remove all signatures except the self-signature) any user IDs from the new key that are not usable. Then, remove any signatures from the new key that are not usable. This includes signatures that were issued by keys that are not present on the keyring. This option is the same as running the --edit- key command "clean" after import. Defaults to no. It says "After import" but according to Werner Koch[1] it actually strips unknown key signatures _before_ importing them to the local keyring. The manual also says that "This option is the same as running the --edit-key command 'clean' after import." This is also wrong or misleading because it may lead user thinking that in import oprations first all keys and key signatures are imported to local keyring and then they are cleaned. ----- 1. https://lists.gnupg.org/pipermail/gnupg-users/2019-July/062239.html -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 507 bytes Desc: not available URL: From ryan at digicana.com Sat Jul 6 13:50:48 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Sat, 06 Jul 2019 11:50:48 +0000 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <87lfxb20cu.fsf@iki.fi> References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> <3e3ed575-d305-44c8-a3ef-0f4ada3aecba@mtasv.net> <87lfxb20cu.fsf@iki.fi> Message-ID: Someone brought it to my attention that my key is now one of the affected keys; I think from this we can probably surmise that whoever(s) is doing this probably reads this list as this email address doesn?t see heavy circulation. -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail On Sat, Jul 6, 2019 at 00:33, Teemu Likonen via Gnupg-users wrote: > Konstantin Boyandin via Gnupg-users [2019-07-05T20:45:59-04:00] wrote: > >> ATM, none of systems I use GnuPG in has been hit with the signature >> flood disaster. If I might miss that point - is it possible to get, >> somehow, the list of flooded keys IDs (if anyone keeps the stats)? > > I don't maintain a list and such a list can be always outdated anyway. > Better option is to set protective settings right now in gpg.conf file. > > keyserver-options import-clean > # maybe also: > import-options import-clean > > With option "import-clean" key import operations accept only key > signatures from already known keys. With poisoned keys the import > operation can take time but at least your local keyring is protected > from importing them. > > The gpg(1) manual page for version 2.1.18 (Debian) is misleading, > though. > > import-clean > After import, compact (remove all signatures except the > self-signature) any user IDs from the new key that are > not usable. Then, remove any signatures from the new > key that are not usable. This includes signatures that > were issued by keys that are not present on the > keyring. This option is the same as running the --edit- > key command "clean" after import. Defaults to no. > > It says "After import" but according to Werner Koch[1] it actually > strips unknown key signatures _before_ importing them to the local > keyring. The manual also says that "This option is the same as running > the --edit-key command 'clean' after import." This is also wrong or > misleading because it may lead user thinking that in import oprations > first all keys and key signatures are imported to local keyring and then > they are cleaned. > > ----- > 1. https://lists.gnupg.org/pipermail/gnupg-users/2019-July/062239.html > > -- > /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 > // https://keys.openpgp.org/search?q=tlikonen at iki.fi > / https://keybase.io/tlikonen https://github.com/tlikonen > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: publicKey - ryan at digicana.com - 5c738727ee58786a777c4f1db5aa3fa3486ed7ad.asc URL: From listofactor at mail.ru Sat Jul 6 14:06:35 2019 From: listofactor at mail.ru (Listo Factor) Date: Sat, 6 Jul 2019 12:06:35 +0000 Subject: robots.txt and archiveteam.org... In-Reply-To: <3ce714ff-63f7-bb3d-1178-7279563d604e@metacode.biz> References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> <4e6d2283-80cd-e7bf-7a25-ae3ac866dc19@digitalbrains.com> <3ce714ff-63f7-bb3d-1178-7279563d604e@metacode.biz> Message-ID: On 7/5/19 10:13 AM, Wiktor Kwapisiewicz via Gnupg-users - gnupg-users at gnupg.org wrote: > > As for robots.txt not all archiving sites respect it: > https://www.archiveteam.org/index.php?title=Robots.txt > Thanks for posting the link. To quote from the text there: > What this situation does, in fact, is cause many more problems than it solves - catastrophic failures on a website are ensured total destruction with the addition of ROBOTS.TXT. Modifications, poor choices in URL transition, and all other sorts of management work can lead to a loss of historically important and relevant data. Unchecked, and left alone, the ROBOTS.TXT file ensures no mirroring or reference for items that may have general use and meaning beyond the website's context. This is both stupid and arrogant. It is precisely the owner of the website and data contain therein to decide what is and what isn't of "general use and meaning beyond the website's context", not of some aggregator/archiver's management. GDPR has indeed changed the nature of Internet forever, and it is for the better. If Google was put in its place (well, at least first steps have been made..) by the EU, surely it will be possible to force other, lesser operators of "archived information" to toe the line. Among other, to respect the straight and simple Robot Exclusion Protocol. It is not at all something difficult to do. From lists at boyandin.info Sat Jul 6 18:35:01 2019 From: lists at boyandin.info (Konstantin Boyandin) Date: Sat, 06 Jul 2019 23:35:01 +0700 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> <3e3ed575-d305-44c8-a3ef-0f4ada3aecba@mtasv.net> <87lfxb20cu.fsf@iki.fi> Message-ID: <30a464eaf9d352940dcb19ee79b65e0b@boyandin.info> Since the list archives can be read by anyone, it's obvious the possible wrongdoers are monitoring the list closely, and can take any and all suggestions into account, to adapt further goals. Sincerely, Konstantin Boyandin Ryan McGinnis via Gnupg-users wrote 2019-07-06 18:50: > Someone brought it to my attention that my key is now one of the > affected keys; I think from this we can probably surmise that > whoever(s) is doing this probably reads this list as this email > address doesn?t see heavy circulation. > > -Ryan McGinnis > > https://bigstormpicture.com > > PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD > > Sent with ProtonMail > > On Sat, Jul 6, 2019 at 00:33, Teemu Likonen via Gnupg-users > wrote: > >> Konstantin Boyandin via Gnupg-users [2019-07-05T20:45:59-04:00] >> wrote: >> >>> ATM, none of systems I use GnuPG in has been hit with the >> signature >>> flood disaster. If I might miss that point - is it possible to >> get, >>> somehow, the list of flooded keys IDs (if anyone keeps the stats)? >> >> I don't maintain a list and such a list can be always outdated >> anyway. >> Better option is to set protective settings right now in gpg.conf >> file. >> >> keyserver-options import-clean >> # maybe also: >> import-options import-clean >> >> With option "import-clean" key import operations accept only key >> signatures from already known keys. With poisoned keys the import >> operation can take time but at least your local keyring is protected >> from importing them. >> >> The gpg(1) manual page for version 2.1.18 (Debian) is misleading, >> though. >> >> import-clean >> After import, compact (remove all signatures except the >> self-signature) any user IDs from the new key that are >> not usable. Then, remove any signatures from the new >> key that are not usable. This includes signatures that >> were issued by keys that are not present on the >> keyring. This option is the same as running the --edit- >> key command "clean" after import. Defaults to no. >> >> It says "After import" but according to Werner Koch[1] it actually >> strips unknown key signatures _before_ importing them to the local >> keyring. The manual also says that "This option is the same as >> running >> the --edit-key command 'clean' after import." This is also wrong or >> misleading because it may lead user thinking that in import >> oprations >> first all keys and key signatures are imported to local keyring and >> then >> they are cleaned. >> >> ----- >> 1. >> https://lists.gnupg.org/pipermail/gnupg-users/2019-July/062239.html >> >> -- >> /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 >> // https://keys.openpgp.org/search?q=tlikonen at iki.fi >> / https://keybase.io/tlikonen https://github.com/tlikonen From david at gbenet.com Sun Jul 7 00:18:39 2019 From: david at gbenet.com (David) Date: Sat, 6 Jul 2019 23:18:39 +0100 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> <3e3ed575-d305-44c8-a3ef-0f4ada3aecba@mtasv.net> <87lfxb20cu.fsf@iki.fi> Message-ID: <67a43770-ffae-cc02-e57b-255494e14cdc@gbenet.com> On 06/07/2019 12:50, Ryan McGinnis via Gnupg-users wrote: > Someone brought it to my attention that my key is now one of the > affected keys; I think from this we can probably surmise that whoever(s) > is doing this probably reads this list as this email address doesn?t see > heavy circulation. If in deed that's the case - that person can download any public key insert malicious code and upload to any key server. I am not updating any keys and no sks key servers. Who's new to the mailing list? Now we have a web of distrust :( David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ryan at digicana.com Sun Jul 7 01:15:45 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Sat, 06 Jul 2019 23:15:45 +0000 Subject: SKS and GnuPG related issues and possible workarounds In-Reply-To: <67a43770-ffae-cc02-e57b-255494e14cdc@gbenet.com> References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> <3e3ed575-d305-44c8-a3ef-0f4ada3aecba@mtasv.net> <87lfxb20cu.fsf@iki.fi> <67a43770-ffae-cc02-e57b-255494e14cdc@gbenet.com> Message-ID: I believe this list is web accessible to non-subscribers, so being subscribed here or not subscribed here doesn?t mean much. Just that if you post here someone who is willing to do this attack (maybe not even the original someone - this is an attack literally anyone can do) is reading what you write. *waves at someone* At any rate, this just underscores what I suspect the original attacker was trying to make clear: stick a fork in SKS servers, they?re dead. -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail On Sat, Jul 6, 2019 at 17:18, David wrote: > On 06/07/2019 12:50, Ryan McGinnis via Gnupg-users wrote: >> Someone brought it to my attention that my key is now one of the >> affected keys; I think from this we can probably surmise that whoever(s) >> is doing this probably reads this list as this email address doesn?t see >> heavy circulation. > If in deed that's the case - that person can download any public key > insert malicious code and upload to any key server. I am not updating > any keys and no sks key servers. > > Who's new to the mailing list? Now we have a web of distrust :( > > David > > -- > People Should Not Be Afraid Of Their Government - Their Government > Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION > Becomes A DUTY! Join the Rebellion Today! https://gbenet.com > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: publicKey - ryan at digicana.com - 5c738727ee58786a777c4f1db5aa3fa3486ed7ad.asc URL: From lists at boyandin.info Sun Jul 7 02:22:02 2019 From: lists at boyandin.info (Konstantin Boyandin) Date: Sun, 07 Jul 2019 07:22:02 +0700 Subject: robots.txt and archiveteam.org... In-Reply-To: References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> <4e6d2283-80cd-e7bf-7a25-ae3ac866dc19@digitalbrains.com> <3ce714ff-63f7-bb3d-1178-7279563d604e@metacode.biz> Message-ID: <1eacecfab6bfd856db23a0a7ba34997b@boyandin.info> I believe this subject is way off the mailing list, but just my 5 cents. 1. GDPR, as any other bloated, convoluted, written in inhuman juridical language law, mostly benefits two kinds of people: lawyers and government-related officials. It incurs a lot of ado and expenses, gives vast grounds for power abuse and so on and so forth. As a side effect, it somewhat helps ordinary people to control the usage of their personal data. Since data lifespan on the Net is hardly controllable in whole, the abuse potential of GDPR is limitless. Cheer the politicians for this excellent masterpiece of legislation. As many such laws (the closest example of similarly inadequate law is Russian Federal Law #152, "On personal data") are introduced worldwide, they will strike a lethal blow to majority of small and medium businesses, and cripple the base of normal human communication. Let just watch the process and enjoy the show. 2. The "Robot Exclusion Protocol", as it's defined in its text, is advisory only. It is not mandatory for any kind of data transmission. Thus any claims or demands about following its statements are void. You may ask, not to demand. Any entity trying to transmit data over Net can't be reliably *and* efficiently identified as human being (or a bot). Thus, it's quite easy to imitate bot/human being, which makes the robots.txt a lame excuse for lack of efficient control over which data should be taken by which means. Simply stating, if you don't want your digital crap being available to anyone, don't make it publicly available. robots.txt usage was weird and strange in many cases. I remember several WordPress versions which silently changed, when installed, robots.txt to disable all page indexing. Also, you cannot magically demand to remove downloaded and stored locally data just by altering your robots.txt at will. That's pure nonsense. Although I do not like, in many cases, the wording Archive Teams uses, in this given case I think they are, generally, right. Sincerely, Konstantin Boyandin Listo Factor via Gnupg-users wrote 2019-07-06 19:06: > On 7/5/19 10:13 AM, Wiktor Kwapisiewicz via Gnupg-users - > gnupg-users at gnupg.org wrote: >> >> As for robots.txt not all archiving sites respect it: >> https://www.archiveteam.org/index.php?title=Robots.txt >> > Thanks for posting the link. To quote from the text there: > >> What this situation does, in fact, is cause many more problems than it >> solves - catastrophic failures on a website are ensured total >> destruction with the addition of ROBOTS.TXT. Modifications, poor >> choices in URL transition, and all other sorts of management work can >> lead to a loss of historically important and relevant data. Unchecked, >> and left alone, the ROBOTS.TXT file ensures no mirroring or reference >> for items that may have general use and meaning beyond the website's >> context. > This is both stupid and arrogant. It is precisely the owner of the > website and data contain therein to decide what is and what isn't of > "general use and meaning beyond the website's context", not of some > aggregator/archiver's management. > > GDPR has indeed changed the nature of Internet forever, and it is for > the better. If Google was put in its place (well, at least first steps > have been made..) by the EU, surely it will be possible to force other, > lesser operators of "archived information" to toe the line. Among > other, > to respect the straight and simple Robot Exclusion Protocol. It is not > at all something difficult to do. > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From mgorny at gentoo.org Sun Jul 7 07:43:55 2019 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Sun, 07 Jul 2019 07:43:55 +0200 Subject: robots.txt and archiveteam.org... In-Reply-To: <1eacecfab6bfd856db23a0a7ba34997b@boyandin.info> References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> <4e6d2283-80cd-e7bf-7a25-ae3ac866dc19@digitalbrains.com> <3ce714ff-63f7-bb3d-1178-7279563d604e@metacode.biz> <1eacecfab6bfd856db23a0a7ba34997b@boyandin.info> Message-ID: On Sun, 2019-07-07 at 07:22 +0700, Konstantin Boyandin via Gnupg-users wrote: > I believe this subject is way off the mailing list, but just my 5 cents. > > 1. GDPR, as any other bloated, convoluted, written in inhuman juridical > language law, mostly benefits two kinds of people: lawyers and > government-related officials. It incurs a lot of ado and expenses, gives > vast grounds for power abuse and so on and so forth. It also benefits third kind of people: new companies that specialize in GDPR busywork. > As a side effect, it somewhat helps ordinary people to control the usage > of their personal data. Since data lifespan on the Net is hardly > controllable in whole, the abuse potential of GDPR is limitless. Cheer > the politicians for this excellent masterpiece of legislation. 'Helps' is a big word. Any company sufficiently evil to abuse your personal data will continue to do so, and ignore any requests to the contrary. > As many such laws (the closest example of similarly inadequate law is > Russian Federal Law #152, "On personal data") are introduced worldwide, > they will strike a lethal blow to majority of small and medium > businesses, and cripple the base of normal human communication. > Exactly. Some companies just close, some live hoping their non- compliance won't be caught. And by 'non-compliance', I'm not talking about personal data abuse, just not meeting the nonsense. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From listofactor at mail.ru Sun Jul 7 14:31:32 2019 From: listofactor at mail.ru (Listo Factor) Date: Sun, 7 Jul 2019 12:31:32 +0000 Subject: robots.txt and archiveteam.org... In-Reply-To: References: <5d1ccde1.1c69fb81.cd047.396cSMTPIN_ADDED_MISSING@mx.google.com> <00749523-9a51-c8ca-4c20-de3f15a3c662@metacode.biz> <4e6d2283-80cd-e7bf-7a25-ae3ac866dc19@digitalbrains.com> <3ce714ff-63f7-bb3d-1178-7279563d604e@metacode.biz> <1eacecfab6bfd856db23a0a7ba34997b@boyandin.info> Message-ID: <7eb67c88-f018-9d7b-fd06-b61bf1fd0396@mail.ru> >> 1. GDPR, as any other bloated, convoluted, written in inhuman juridical >> language law, mostly benefits two kinds of people: lawyers and >> government-related officials. It incurs a lot of ado and expenses, gives >> vast grounds for power abuse and so on and so forth. > > It also benefits third kind of people: new companies that specialize > in GDPR busywork. > >> As a side effect, it somewhat helps ordinary people to control the usage >> of their personal data. Since data lifespan on the Net is hardly >> controllable in whole, the abuse potential of GDPR is limitless. Cheer >> the politicians for this excellent masterpiece of legislation. > > 'Helps' is a big word. Any company sufficiently evil to abuse your > personal data will continue to do so, and ignore any requests to > the contrary. As any law or regulation, it has undeniable and numerous detrimental side effects, which I fully acknowledge. But it establishes an important principle, completely new to the Internet (and thus often very irritating to those that are forced to change their MO): *An individual has the right* to demand that his personally identifiable information be removed from some specific public information source, *even if*, at some previous time, in his ignorance or naivete, he himself made that information publicly available. The GDPR as a solution is neither perfect nor without warts, but our agreement or disagreement with this principle - in my humble observation - determines how harsh we judge its warts. lf From dbuergin at gluet.ch Sat Jul 6 18:57:24 2019 From: dbuergin at gluet.ch (David =?utf-8?Q?B=C3=BCrgin?=) Date: Sat, 6 Jul 2019 18:57:24 +0200 Subject: Testing WKD setup? Message-ID: <20190706165724.GA18183@azadi> Hello list, I have implemented WKD for my domain, but now I don?t know an easy way of testing it ? is there a service or similar where I can check if this email address is properly WKD-enabled? Thank you. -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wolfgang.traylor at posteo.de Sun Jul 7 20:48:12 2019 From: wolfgang.traylor at posteo.de (Wolfgang Traylor) Date: Sun, 7 Jul 2019 20:48:12 +0200 Subject: Testing WKD setup? In-Reply-To: <20190706165724.GA18183@azadi> References: <20190706165724.GA18183@azadi> Message-ID: <20190707184810.zhzyn7wilnhs64hg@gruenfink> > is there a service or similar where I can check if this email address is properly WKD-enabled? https://metacode.biz/openpgp/web-key-directory -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tlikonen at iki.fi Sun Jul 7 20:59:32 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Sun, 07 Jul 2019 21:59:32 +0300 Subject: Testing WKD setup? In-Reply-To: <20190706165724.GA18183@azadi> ("David =?iso-8859-1?Q?B=FCrgi?= =?iso-8859-1?Q?n?= via Gnupg-users"'s message of "Sat, 6 Jul 2019 18:57:24 +0200") References: <20190706165724.GA18183@azadi> Message-ID: <87h87xy8kr.fsf@iki.fi> David B?rgin via Gnupg-users [2019-07-06T18:57:24+02] wrote: > I have implemented WKD for my domain, but now I don?t know an easy way > of testing it ? is there a service or similar where I can check if > this email address is properly WKD-enabled? Can't answer to those questions but I got your key via WKD and with the kye verified your email. So, this test was success. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From dbuergin at gluet.ch Sun Jul 7 21:14:13 2019 From: dbuergin at gluet.ch (David =?utf-8?Q?B=C3=BCrgin?=) Date: Sun, 7 Jul 2019 21:14:13 +0200 Subject: Testing WKD setup? In-Reply-To: <87h87xy8kr.fsf@iki.fi> References: <20190706165724.GA18183@azadi> <87h87xy8kr.fsf@iki.fi> Message-ID: <20190707191413.GA23290@azadi> On Sun, Jul 07, 2019 at 09:59:32PM +0300, Teemu Likonen wrote: > Can't answer to those questions but I got your key via WKD and with the > kye verified your email. So, this test was success. Well, in that case thank you for checking, Teemu! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From johannes at zarl-zierl.at Sun Jul 7 22:37:00 2019 From: johannes at zarl-zierl.at (Johannes Zarl-Zierl) Date: Sun, 07 Jul 2019 22:37:00 +0200 Subject: Testing WKD setup? In-Reply-To: <20190707184810.zhzyn7wilnhs64hg@gruenfink> References: <20190706165724.GA18183@azadi> <20190707184810.zhzyn7wilnhs64hg@gruenfink> Message-ID: <2144594.dpbWWjdrQj@mani> On Sonntag, 7. Juli 2019 20:48:12 CEST Wolfgang Traylor via Gnupg-users wrote: > > is there a service or similar where I can check if this email address is > > properly WKD-enabled? > https://metacode.biz/openpgp/web-key-directory Thank you! This is so much easier to comprehend than the official documentation... Cheers, Johannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From hi at alyssa.is Mon Jul 8 20:07:55 2019 From: hi at alyssa.is (Alyssa Ross) Date: Mon, 8 Jul 2019 18:07:55 +0000 Subject: Testing WKD setup? In-Reply-To: <20190706165724.GA18183@azadi> References: <20190706165724.GA18183@azadi> Message-ID: <20190708180754.2qzgrbdey7gcvxvb@x220.qyliss.net> > I have implemented WKD for my domain, but now I don?t know an easy way > of testing it ? is there a service or similar where I can check if this > email address is properly WKD-enabled? When I was setting up WKD recently, I tested it like this: gpg --homedir "$(mktemp -d)" --locate-keys hi at alyssa.is -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gnupg-users at spodhuis.org Mon Jul 8 22:17:05 2019 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Mon, 8 Jul 2019 16:17:05 -0400 Subject: Testing WKD setup? In-Reply-To: <20190707184810.zhzyn7wilnhs64hg@gruenfink> References: <20190706165724.GA18183@azadi> <20190707184810.zhzyn7wilnhs64hg@gruenfink> Message-ID: <20190708201704.GA22438@spodhuis.org> On 2019-07-07 at 20:48 +0200, Wolfgang Traylor via Gnupg-users wrote: > > is there a service or similar where I can check if this email address is properly WKD-enabled? > > https://metacode.biz/openpgp/web-key-directory It's nice, but it also checks stuff which isn't per the spec, so gives false negatives. It only supports the 'direct' method, where the key has to be hosted on `example.org` instead of `openpgpkey.example.org`. Just a limitation to be aware of. -Phil From diafygi at gmail.com Tue Jul 9 01:45:36 2019 From: diafygi at gmail.com (Daniel Roesler) Date: Mon, 8 Jul 2019 18:45:36 -0500 Subject: Third-Party Confirmation signature? Message-ID: Howdy, Is there a way to create a "Third-Party Confirmation signature"[1] using the gnupg command line interface? [1]: https://tools.ietf.org/html/rfc4880#section-5.2.1 (see "0x50: Third-Party Confirmation signature.") Thanks, Daniel From wk at gnupg.org Tue Jul 9 12:12:03 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jul 2019 12:12:03 +0200 Subject: Testing WKD setup? In-Reply-To: <20190708201704.GA22438@spodhuis.org> (Phil Pennock via Gnupg-users's message of "Mon, 8 Jul 2019 16:17:05 -0400") References: <20190706165724.GA18183@azadi> <20190707184810.zhzyn7wilnhs64hg@gruenfink> <20190708201704.GA22438@spodhuis.org> Message-ID: <875zobjz4c.fsf@wheatstone.g10code.de> On Mon, 8 Jul 2019 16:17, gnupg-users at gnupg.org said: > false negatives. It only supports the 'direct' method, where the key > has to be hosted on `example.org` instead of `openpgpkey.example.org`. BTW, the openpgpkey subdomain method was accidently not available in 2.2. This will be fixed with the release of 2.2.17 Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Jul 9 12:19:06 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jul 2019 12:19:06 +0200 Subject: Third-Party Confirmation signature? In-Reply-To: (Daniel Roesler via Gnupg-users's message of "Mon, 8 Jul 2019 18:45:36 -0500") References: Message-ID: <871ryzjysl.fsf@wheatstone.g10code.de> On Mon, 8 Jul 2019 18:45, gnupg-users at gnupg.org said: > Is there a way to create a "Third-Party Confirmation signature"[1] > using the gnupg command line interface? No. You need to add code for this which also requires that you have a way to specify another signature packet. Are you considering to use 0x50 self-signatures to approve key signatures? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bernhard at intevation.de Tue Jul 9 15:02:26 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Jul 2019 15:02:26 +0200 Subject: WKD documentation (Re: Testing WKD setup?) In-Reply-To: <2144594.dpbWWjdrQj@mani> References: <20190706165724.GA18183@azadi> <20190707184810.zhzyn7wilnhs64hg@gruenfink> <2144594.dpbWWjdrQj@mani> Message-ID: <201907091502.30789.bernhard@intevation.de> Hi, Am Sonntag 07 Juli 2019 22:37:00 schrieb Johannes Zarl-Zierl: > On Sonntag, 7. Juli 2019 20:48:12 CEST Wolfgang Traylor via Gnupg-users wrote: > > > is there a service or similar where I can check if this email address > > > is properly WKD-enabled? > > > > https://metacode.biz/openpgp/web-key-directory > > Thank you! This is so much easier to comprehend than the official > documentation... please make suggestions (or help with improving) https://wiki.gnupg.org/WKD Note that on Wiktor's page a few details are missing: * policy file is needed * directory listing strongly recommend to be off * minimum version of gpg that has --with-wkd (some versions don't). BTW, last week we've updated https://wiki.gnupg.org/WKDHosting with a how to use gpg-wks-client on Gnu and Windows systems to create a flat file structure. Best Regards, Bernhard ps.: Thanks Wiktor for explaning WKD, I thought you'd be interested in the feedback. :) -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From wiktor at metacode.biz Tue Jul 9 15:50:01 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 9 Jul 2019 15:50:01 +0200 Subject: WKD documentation (Re: Testing WKD setup?) In-Reply-To: <201907091502.30789.bernhard@intevation.de> References: <20190706165724.GA18183@azadi> <20190707184810.zhzyn7wilnhs64hg@gruenfink> <2144594.dpbWWjdrQj@mani> <201907091502.30789.bernhard@intevation.de> Message-ID: <42b146f4-bebf-cd09-e731-8a5197df81b0@metacode.biz> Hi Bernhard, On 09.07.2019 15:02, Bernhard Reiter wrote: > Note that on Wiktor's page a few details are missing: > * policy file is needed > * directory listing strongly recommend to be off > * minimum version of gpg that has --with-wkd (some versions don't). Policy file is checked during WKD check (and I saw the original poster did set it up). Checking directory listing would be an interesting thing to add! (Although this would be only heuristic). --with-wkd gpg version is definitely good thing to add, thanks for the idea! > BTW, last week we've updated > https://wiki.gnupg.org/WKDHosting > with a how to use gpg-wks-client on Gnu and Windows systems > to create a flat file structure. What I like in WKD most is that it's a super-simple standard. Once upon a time I mailed random PGP-using people asking if they'd consider setting it up and the feedback has been overwhelmingly positive. The only thing I needed was basically the local-part hash and actually that's what I built the checker for, to generate the URL in an easy way, even without GPG. --with-wkd mentioned by Alyssa is what I used previously and it was good but ultimately I've become too lazy to use even that :) As Phil mentioned the checker has not been updated to latest specs and gives warnings for issues that I think should be part of the spec (I mentioned them on the OpenPGP mailing list but did not receive any feedback from the I-D author). > Best Regards, > Bernhard > ps.: Thanks Wiktor for explaning WKD > No problem! I actually also implemented WKD in a couple of projects in three different languages (OpenKeychain, OpenPGP.js, initial support in Mailpile, I did have a patch for mutt but they didn't like the idea :)), so the I-D looks solid! > I thought you'd be interested in the > feedback. :) Yep, thanks for the CC, I'm not subscribed to the ML at all times! See you later! Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Tue Jul 9 16:47:15 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Jul 2019 16:47:15 +0200 Subject: WKD documentation (Re: Testing WKD setup?) In-Reply-To: <42b146f4-bebf-cd09-e731-8a5197df81b0@metacode.biz> References: <20190706165724.GA18183@azadi> <201907091502.30789.bernhard@intevation.de> <42b146f4-bebf-cd09-e731-8a5197df81b0@metacode.biz> Message-ID: <201907091647.15556.bernhard@intevation.de> Hi Wiktor, [https://metacode.biz/openpgp/web-key-directory] Am Dienstag 09 Juli 2019 15:50:01 schrieb Wiktor Kwapisiewicz via Gnupg-users: > On 09.07.2019 15:02, Bernhard Reiter wrote: > > Note that on Wiktor's page a few details are missing: > > * policy file is needed > > * directory listing strongly recommend to be off > > * minimum version of gpg that has --with-wkd (some versions don't). > > Policy file is checked during WKD check (and I saw the original poster > did set it up). My suggestion is to mention this in the "Setting up" section, because otherwise people will only learn it when using the checker. > Checking directory listing would be an interesting thing > to add! (Although this would be only heuristic). Yes, this is just a recommendation (though a strong one). :) Some people may decide to publish the whole directory. > Once upon > a time I mailed random PGP-using people asking if they'd consider > setting it up and the feedback has been overwhelmingly positive. Cool, if you receive answer, please help us to keep the list of supporting organisations growing at https://wiki.gnupg.org/WKD (We'd have to move it to a subpage soon.) > No problem! I actually also implemented WKD in a couple of projects in > three different languages (OpenKeychain, OpenPGP.js, initial support in > Mailpile, Cool! Anything more you can share? > I did have a patch for mutt but they didn't like the idea :)) Do you have a link to your upstream submission? Maybe others users can help to state their interest? Did you also give it to https://neomutt.org/? Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From diafygi at gmail.com Tue Jul 9 17:10:15 2019 From: diafygi at gmail.com (Daniel Roesler) Date: Tue, 9 Jul 2019 10:10:15 -0500 Subject: Third-Party Confirmation signature? In-Reply-To: <871ryzjysl.fsf@wheatstone.g10code.de> References: <871ryzjysl.fsf@wheatstone.g10code.de> Message-ID: Hmmm, ok. Yes, I am considering ways of letting a user "whitelist" signatures on their public key, and using the Signature Target subpacket[1] seemed like a way to do that. However, if gpg doesn't support a way of adding that subpacket, then creating easy-to-copy-and-paste commands for users to use to approve signatures becomes difficult. What about using the Notation Data subpacket[2] to provide a pointer to a target signature that is "approved"? I noticed in the edit-key interface there is an option for setting notations[3]. Could a user use gpg's edit-key to create a signature on their key that has a notation specifying the whitelist of approved third party signature key-ids? [1]: https://tools.ietf.org/html/rfc4880#section-5.2.3.25 [2]: https://tools.ietf.org/html/rfc4880#section-5.2.3.16 [3]: https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Key-Management.html#index-keyedit_003anotation Thanks for the reply, Daniel On Tue, Jul 9, 2019 at 5:20 AM Werner Koch wrote: > > On Mon, 8 Jul 2019 18:45, gnupg-users at gnupg.org said: > > > Is there a way to create a "Third-Party Confirmation signature"[1] > > using the gnupg command line interface? > > No. You need to add code for this which also requires that you have a > way to specify another signature packet. > > Are you considering to use 0x50 self-signatures to approve key > signatures? > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jul 9 17:15:58 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jul 2019 17:15:58 +0200 Subject: [Announce] GnuPG 2.2.17 released to mitigate attacks on keyservers Message-ID: <87ftnfi6hd.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.17. This is maintenance release to mitigate the effects of the denial-of-service attacks on the keyserver network. See below for a list changes. About GnuPG =========== The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.17 ==================================== * gpg: Ignore all key-signatures received from keyservers. This change is required to mitigate a DoS due to keys flooded with faked key-signatures. The old behaviour can be achieved by adding keyserver-options no-self-sigs-only,no-import-clean to your gpg.conf. [#4607] * gpg: If an imported keyblocks is too large to be stored in the keybox (pubring.kbx) do not error out but fallback to an import using the options "self-sigs-only,import-clean". [#4591] * gpg: New command --locate-external-key which can be used to refresh keys from the Web Key Directory or via other methods configured with --auto-key-locate. * gpg: New import option "self-sigs-only". * gpg: In --auto-key-retrieve prefer WKD over keyservers. [#4595] * dirmngr: Support the "openpgpkey" subdomain feature from draft-koch-openpgp-webkey-service-07. [#4590]. * dirmngr: Add an exception for the "openpgpkey" subdomain to the CSRF protection. [#4603] * dirmngr: Fix endless loop due to http errors 503 and 504. [#4600] * dirmngr: Fix TLS bug during redirection of HKP requests. [#4566] * gpgconf: Fix a race condition when killing components. [#4577] Release-info: https://dev.gnupg.org/T4606 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.17 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.17.tar.bz2 (6560k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.17.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.17_20190709.exe (4185k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.17_20190709.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new version of Gpg4win incluing this version of GnuPG will be released in a few days. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.17.tar.bz2 you would use this command: gpg --verify gnupg-2.2.17.tar.bz2.sig gnupg-2.2.17.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.17.tar.bz2, you run the command like this: sha1sum gnupg-2.2.17.tar.bz2 and check that the output matches the next line: 12c1cee8871c03f0315fc8f27876364b75c95b12 gnupg-2.2.17.tar.bz2 533deef5939fcd6506be650731dea4a9d18f9df8 gnupg-w32-2.2.17_20190709.tar.xz 82abfbc79d1a99b27f25ba92fe878cad07a31532 gnupg-w32-2.2.17_20190709.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Japanese, Norwegian, Polish, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T4509 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs two full-time developers and one contractor. They all work exclusively on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wiktor at metacode.biz Tue Jul 9 20:51:41 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 9 Jul 2019 20:51:41 +0200 Subject: WKD documentation (Re: Testing WKD setup?) In-Reply-To: <201907091647.15556.bernhard@intevation.de> References: <20190706165724.GA18183@azadi> <201907091502.30789.bernhard@intevation.de> <42b146f4-bebf-cd09-e731-8a5197df81b0@metacode.biz> <201907091647.15556.bernhard@intevation.de> Message-ID: Hi Bernhard, On 09.07.2019 16:47, Bernhard Reiter wrote: >> Once upon >> a time I mailed random PGP-using people asking if they'd consider >> setting it up and the feedback has been overwhelmingly positive. > > Cool, if you receive answer, please help us to keep the list of supporting > organisations growing at https://wiki.gnupg.org/WKD > (We'd have to move it to a subpage soon.) You can also add Debian there and occrp.org (although the latter doesn't have policy file :(). I think Linux distributions are particularly good target for WKD - they can manage their developer's keys. They use HTTPS and usually developers have e-mail aliases at the distro domain. Additionally now with GnuPG 2.2.17 they can easily make first signature verification faster by utilizing Signer's UID packet (--sender option). (As a side note, I did contact two distros with that in mind and one of them, I'll share this openly: Gentoo - did handle it in a very professional matter enabling WKD for developers in days and keeping me - an outsider - in the loop for the whole time. I'm still impressed by their execution!) >> No problem! I actually also implemented WKD in a couple of projects in >> three different languages (OpenKeychain, OpenPGP.js, initial support in >> Mailpile, > > Cool! Anything more you can share? I'll think about it, this was just the most pleasant experiences I had in contributing (in no particular order!). I've got a small to-do list for project that I still want to contribute WKD support but sadly I'm out of time currently :-/ >> I did have a patch for mutt but they didn't like the idea :)) > > Do you have a link to your upstream submission? Maybe others users can help to > state their interest? Sure, take a look at the thread starting here: http://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20180702/000157.html (The patch is not there but it's basically setting external locate mechanism in gpgme so, except one bugfix that I also found, it would be a one-liner). From what I can see Werner also planned to add that but I don't know how it ended up: http://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20181119/000246.html > Did you also give it to https://neomutt.org/? Neomutt deferred to Mutt's mailing list, see: https://github.com/neomutt/neomutt/issues/1282#issuecomment-411401300 On the bright side I've seen other TUI mail clients planning to add WKD support e.g. Aerc (homepage: https://aerc-mail.org/), author's opinion on WKD: https://news.ycombinator.com/item?id=20091100 Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jul 9 21:06:47 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jul 2019 21:06:47 +0200 Subject: Third-Party Confirmation signature? In-Reply-To: (Daniel Roesler via Gnupg-users's message of "Tue, 9 Jul 2019 10:10:15 -0500") References: <871ryzjysl.fsf@wheatstone.g10code.de> Message-ID: <871ryzhvso.fsf@wheatstone.g10code.de> On Tue, 9 Jul 2019 10:10, gnupg-users at gnupg.org said: > However, if gpg doesn't support a way of adding that subpacket, then > creating easy-to-copy-and-paste commands for users to use to approve > signatures becomes difficult. The problem I see is that the keyservers need to check the validity of the 0x50 signature first. Only this will allow them to distribute only key-signatures which have veen approved buy the key owner. If that has been achieved we can quickly add the required feature to gpg. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Jul 9 21:17:18 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jul 2019 21:17:18 +0200 Subject: WKD documentation (Re: Testing WKD setup?) In-Reply-To: <42b146f4-bebf-cd09-e731-8a5197df81b0@metacode.biz> (Wiktor Kwapisiewicz via Gnupg-users's message of "Tue, 9 Jul 2019 15:50:01 +0200") References: <20190706165724.GA18183@azadi> <20190707184810.zhzyn7wilnhs64hg@gruenfink> <2144594.dpbWWjdrQj@mani> <201907091502.30789.bernhard@intevation.de> <42b146f4-bebf-cd09-e731-8a5197df81b0@metacode.biz> Message-ID: <87wogrggqp.fsf@wheatstone.g10code.de> On Tue, 9 Jul 2019 15:50, gnupg-users at gnupg.org said: > setting it up and the feedback has been overwhelmingly positive. The > only thing I needed was basically the local-part hash and actually > that's what I built the checker for, to generate the URL in an easy I think things are even easier now. I have not checked whether this has made it into the wiki. From gpg-wks-client(1): Since 2.2.12 we have: The command --install-key manually installs a key into a local directory (see option -C) reflecting the structure of a WKD. The arguments are a file with the keyblock and the user-id to install. If the first argument resembles a fingerprint the key is taken from the current keyring; to force the use of a file, prefix the first argument with "./". If no arguments are given the parameters are read from stdin; the expected format are lines with the fingerprint and the mailbox separated by a space. The command --remove-key removes a key from that directory, its only argument is a user-id. The idea is that you can prepare a WKD on your local machine and upload it by whatever you commonly use to for web pages. And it works on Windows. Since we 2.2.15 we also have: The command --print-wkd-hash prints the WKD user-id identifiers and the corresponding mail-boxes from the user-ids given on the command line or via stdin (one user-id per line). The command --print-wkd-url prints the URLs used to fetch the key for the given user-ids from WKD. The meanwhile preferred format with sub-domains is used here. It is a bit unfortunate that under Unix we install that tool in /usr/libexec or /usr/lib/. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From diafygi at gmail.com Tue Jul 9 22:55:21 2019 From: diafygi at gmail.com (Daniel Roesler) Date: Tue, 9 Jul 2019 15:55:21 -0500 Subject: Third-Party Confirmation signature? In-Reply-To: <871ryzhvso.fsf@wheatstone.g10code.de> References: <871ryzjysl.fsf@wheatstone.g10code.de> <871ryzhvso.fsf@wheatstone.g10code.de> Message-ID: On Tue, Jul 9, 2019 at 2:10 PM Werner Koch wrote: > The problem I see is that the keyservers need to check the validity of > the 0x50 signature first. Only this will allow them to distribute only > key-signatures which have veen approved buy the key owner. Correct, a keyserver would need to validate signatures before including them in the public API. However, when gossiping with peers, they could still included the hashes of non-verified signatures so they stay in sync with each other. > If that has been achieved we can quickly add the required feature to > gpg. While adding the ability for 0x50 signatures would be nice, I would still like to explore ways of users self-limiting signatures within the existing gpg command line, since most users will be just using whatever version is in their operating system repo or whatever version they downloaded at the time of installation. So it seems like Notation Data subpackets may be the way to go instead of 0x50 Third-Party Confirmation signatures, since notations can be added in the existing gpg edit-key interface. I'll begin playing around with this interface to see what kind of user experience is possible. Thanks for the prompt responses! Daniel From angel at pgp.16bits.net Wed Jul 10 09:50:22 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Wed, 10 Jul 2019 09:50:22 +0200 Subject: Third-Party Confirmation signature? In-Reply-To: References: <871ryzjysl.fsf@wheatstone.g10code.de> <871ryzhvso.fsf@wheatstone.g10code.de> Message-ID: <1562745022.942.12.camel@16bits.net> On 2019-07-09 at 15:55 -0500, Daniel Roesler via Gnupg-users wrote: > While adding the ability for 0x50 signatures would be nice, I would > still like to explore ways of users self-limiting signatures within > the existing gpg command line, since most users will be just using > whatever version is in their operating system repo or whatever version > they downloaded at the time of installation. We are currently in a catch-22 situation, where neither clients nor keyservers support such confirmation signatures. However, clients will eventually update, while we will be stuck forever supporting whatever format is devised. I think it's more important to define the right packets, based on packet semantics and also for performing on-the-fly validation. The users will need an updated software for making a confirmation signature anyway (even if it's just an extra shell script over gpg1), I see little hassle in requiring gpg >= 2.2.18 instead. Specially taking into account that receiving new (legitimate) sigs is an uncommon event. It wouldn't be that bad if someone had to use a LiveCD in order to incorporate a new signature, just as you may need to use a certification key which you usually keep offline. (It would be good if this prompted them to update their day-to-day client, though) Please go for the best solution in the longterm, not just the one which is easiest to support with ancient clients for the sake of it. Kind regards PS: This is not an endorsement of one type over the other, I haven't evaluated the merits of either option (yet). From bernhard at intevation.de Wed Jul 10 10:22:00 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 10:22:00 +0200 Subject: WKD: more organisations using it (Re: WKD documentation) In-Reply-To: References: <20190706165724.GA18183@azadi> <201907091647.15556.bernhard@intevation.de> Message-ID: <201907101022.06762.bernhard@intevation.de> Hi Wiktor, Am Dienstag 09 Juli 2019 20:51:41 schrieb Wiktor Kwapisiewicz via Gnupg-users: > > please help us to keep the list of > > supporting organisations growing at https://wiki.gnupg.org/WKD > You can also add Debian there and occrp.org (although the latter doesn't > have policy file :(). do you have something that can be publically referred to, or a contact person I could ask that they are fine being listed in the wiki? > I've got a small to-do list for project that I still want to contribute WKD > support but sadly I'm out of time currently :-/ Thanks for all that you have done so far. (Many people are in the same situation, we can only do so much and not more.) Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From patrick at enigmail.net Wed Jul 10 10:23:50 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 10 Jul 2019 10:23:50 +0200 Subject: How to delete flooded key Message-ID: <633d11a9-1fab-389e-2ba6-44976975fd0b@enigmail.net> First users ask for support on getting rid of the keys flooded with signatures. Is it sufficient to run "gpg --delete-keys 0x...", and wait for quite a while, or does it require other measures? Thanks, Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wiktor at metacode.biz Wed Jul 10 10:33:01 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 10 Jul 2019 10:33:01 +0200 Subject: WKD: more organisations using it (Re: WKD documentation) In-Reply-To: <201907101022.06762.bernhard@intevation.de> References: <20190706165724.GA18183@azadi> <201907091647.15556.bernhard@intevation.de> <201907101022.06762.bernhard@intevation.de> Message-ID: On 10.07.2019 10:22, Bernhard Reiter wrote: >> You can also add Debian there and occrp.org (although the latter doesn't >> have policy file :(). > do you have something that can be publically referred to, or a contact person > I could ask that they are fine being listed in the wiki? > If you see the staff page: https://www.occrp.org/staff there is this person listed: https://mastodon.social/@rysiek I'd contact them. For the record I don't know anyone there personally, I just checked one e-mail and saw they have WKD enabled (I do sometimes test random sites, hehe). Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Wed Jul 10 10:38:20 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 10:38:20 +0200 Subject: WKD: mutt integration status (was: WKD documentation) In-Reply-To: References: <20190706165724.GA18183@azadi> <201907091647.15556.bernhard@intevation.de> Message-ID: <201907101038.25127.bernhard@intevation.de> Hi Wiktor, = integrate WKD requests into mutt Am Dienstag 09 Juli 2019 20:51:41 schrieb Wiktor Kwapisiewicz via Gnupg-users: > Sure, take a look at the thread starting here: > http://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20180702/000157.html > > (The patch is not there but it's basically setting external locate > mechanism in gpgme so, except one bugfix that I also found, it would be > a one-liner). Maybe this is actually worth trying to propose again, one argument that is missing is the lost security by emails that are send unencrypted because users cannot figure out how to get the pubkey of their recipients. > From what I can see Werner also planned to add that but I don't know > how it ended up: > > http://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20181119/000246.html Werner submitted code to cleanup the code calling gpgme, which got integrated http://mutt.org/relnotes/1.12/ | = Internal Improvements | * Werner Koch contributed some cleanup and improvements to the GPGME code. | (Thanks, Werner!) > > Did you also give it to https://neomutt.org/? > > Neomutt deferred to Mutt's mailing list, see: > https://github.com/neomutt/neomutt/issues/1282#issuecomment-411401300 Added a comment there, because it is a security concern to not add an easy way to access a pubkey automatically. = Other terminal based email client: Aerc > On the bright side I've seen other TUI mail clients planning to add WKD > support e.g. Aerc (homepage: https://aerc-mail.org/), author's opinion > on WKD: https://news.ycombinator.com/item?id=20091100 Cool! Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From wiktor at metacode.biz Wed Jul 10 10:53:17 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 10 Jul 2019 10:53:17 +0200 Subject: WKD: mutt integration status (was: WKD documentation) In-Reply-To: <201907101038.25127.bernhard@intevation.de> References: <20190706165724.GA18183@azadi> <201907091647.15556.bernhard@intevation.de> <201907101038.25127.bernhard@intevation.de> Message-ID: <0f6a2112-1e07-c8c5-2ee8-1ad85e5f2ae7@metacode.biz> Hi Bernhard, On 10.07.2019 10:38, Bernhard Reiter wrote: > Am Dienstag 09 Juli 2019 20:51:41 schrieb Wiktor Kwapisiewicz via Gnupg-users: >> Sure, take a look at the thread starting here: >> http://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20180702/000157.html >> >> (The patch is not there but it's basically setting external locate >> mechanism in gpgme so, except one bugfix that I also found, it would be >> a one-liner). > Maybe this is actually worth trying to propose again, one argument that is > missing is the lost security by emails that are send unencrypted because > users cannot figure out how to get the pubkey of their recipients. > Sure, why not. Especially that now WKD is prevalent in e-mail clients that care about privacy (Mailpile, Enigmail...). There is additional argument in favor of WKD nowadays - WKD delivers non-flooded keys as it's the key owner that controls what's added to their key. If you convince Mutt community that WKD is a good idea I can prepare the patch for you. As far as I remember it's very minimal and I'd be happy to work on it. Unless there is no chance that WKD will be merged. Then I don't want to waste my time :) Nb. in the process of getting to know mutt-GnuPG integration I've seen more places that would need attention. For example the code is riddled with PKA integration code and from what I can see PKA is considered obsolete: https://lists.gnupg.org/pipermail/gnupg-users/2018-October/061034.html Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Jul 10 12:24:30 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Jul 2019 12:24:30 +0200 Subject: How to delete flooded key In-Reply-To: <633d11a9-1fab-389e-2ba6-44976975fd0b@enigmail.net> (Patrick Brunschwig's message of "Wed, 10 Jul 2019 10:23:50 +0200") References: <633d11a9-1fab-389e-2ba6-44976975fd0b@enigmail.net> Message-ID: <87muhmfaqp.fsf@wheatstone.g10code.de> On Wed, 10 Jul 2019 10:23, patrick at enigmail.net said: > Is it sufficient to run "gpg --delete-keys 0x...", and wait for quite a > while, or does it require other measures? --edit-key and then use "clean" to remove them. And well, install 2.2.17 to avoid future trouble. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 10 12:27:15 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Jul 2019 12:27:15 +0200 Subject: WKD: mutt integration status In-Reply-To: <0f6a2112-1e07-c8c5-2ee8-1ad85e5f2ae7@metacode.biz> (Wiktor Kwapisiewicz via Gnupg-users's message of "Wed, 10 Jul 2019 10:53:17 +0200") References: <20190706165724.GA18183@azadi> <201907091647.15556.bernhard@intevation.de> <201907101038.25127.bernhard@intevation.de> <0f6a2112-1e07-c8c5-2ee8-1ad85e5f2ae7@metacode.biz> Message-ID: <87imsafam4.fsf@wheatstone.g10code.de> On Wed, 10 Jul 2019 10:53, gnupg-users at gnupg.org said: > If you convince Mutt community that WKD is a good idea I can prepare > the patch for you. As far as I remember it's very minimal and I'd be Actually I started to work on Mutt (not NeoMutt, though) but had to give up due to time constraints. > more places that would need attention. For example the code is riddled > with PKA integration code and from what I can see PKA is considered That could should not harm but can of course be removed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tlikonen at iki.fi Wed Jul 10 12:49:10 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Wed, 10 Jul 2019 13:49:10 +0300 Subject: How to delete flooded key In-Reply-To: <633d11a9-1fab-389e-2ba6-44976975fd0b@enigmail.net> (Patrick Brunschwig's message of "Wed, 10 Jul 2019 10:23:50 +0200") References: <633d11a9-1fab-389e-2ba6-44976975fd0b@enigmail.net> Message-ID: <87h87ukvvd.fsf@iki.fi> Patrick Brunschwig [2019-07-10T10:23:50+02] wrote: > First users ask for support on getting rid of the keys flooded with > signatures. There is no need to get rid of the itself key, just the key signatures which are the "flood". The commands are --edit-key and then "clean" or "minimize". It is a good idea to also set that operation to guard the gate: keyserver-options import-clean That and other protective settings are enabled by default in GnuPG 2.2.17. "[Announce] GnuPG 2.2.17 released to mitigate attacks on keyservers" https://lists.gnupg.org/pipermail/gnupg-users/2019-July/062323.html -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From andrewg at andrewg.com Wed Jul 10 12:59:05 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 10 Jul 2019 11:59:05 +0100 Subject: WKD: mutt integration status In-Reply-To: <87imsafam4.fsf@wheatstone.g10code.de> References: <20190706165724.GA18183@azadi> <201907091647.15556.bernhard@intevation.de> <201907101038.25127.bernhard@intevation.de> <0f6a2112-1e07-c8c5-2ee8-1ad85e5f2ae7@metacode.biz> <87imsafam4.fsf@wheatstone.g10code.de> Message-ID: On 10/07/2019 11:27, Werner Koch via Gnupg-users wrote: > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Well now, this email was interesting. I can view it normally on my iphone, but in thunderbird+enigmail it comes up as an empty message. It could be that this is one of the Efail mitigations gone rogue, but there is another possibility. Most email clients use MIME boundaries such as: "===============8971366068707958548==" but Werner's email client uses a hot word dictionary, seemingly to mess with the NSA's bulk monitoring. For example, in this particular mail it uses: "=constitution_insurgency_Al_Qa'ida_Panama_Chicago_Posse_MI5_Stego_IDF" In this instance, I wonder if the apostrophe hasn't screwed something up - are apostrophes valid in the MIME boundary charset? -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Wed Jul 10 13:33:09 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 13:33:09 +0200 Subject: WKD: more organisations using it (Re: WKD documentation) In-Reply-To: References: <20190706165724.GA18183@azadi> <201907101022.06762.bernhard@intevation.de> Message-ID: <201907101333.10238.bernhard@intevation.de> Am Mittwoch 10 Juli 2019 10:33:01 schrieb Wiktor Kwapisiewicz via Gnupg-users: > On 10.07.2019 10:22, Bernhard Reiter wrote: > >> You can also add Debian there and occrp.org (although the latter doesn't > >> have policy file :(). > > > > do you have something that can be publically referred to, or a contact > > person I could ask that they are fine being listed in the wiki? > > If you see the staff page: [..] occrp.org is now listed on the wiki as an organisation that supports WKD. They may even provide a small statement about WKD in the future. :) Thanks Wiktor! Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jul 10 13:35:38 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 10 Jul 2019 13:35:38 +0200 Subject: WKD: mutt integration status (was: WKD documentation) In-Reply-To: <0f6a2112-1e07-c8c5-2ee8-1ad85e5f2ae7@metacode.biz> References: <20190706165724.GA18183@azadi> <201907101038.25127.bernhard@intevation.de> <0f6a2112-1e07-c8c5-2ee8-1ad85e5f2ae7@metacode.biz> Message-ID: <201907101335.38887.bernhard@intevation.de> Am Mittwoch 10 Juli 2019 10:53:17 schrieb Wiktor Kwapisiewicz via Gnupg-users: > If you convince Mutt community that WKD is a good idea I can prepare the > patch for you. As I'm not on the mutt development channels, I'd prefer if someone else would do this. Bernhard ps.: Still I'm an very occasional mutt user. -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From johannes at zarl-zierl.at Tue Jul 9 23:33:19 2019 From: johannes at zarl-zierl.at (Johannes Zarl-Zierl) Date: Tue, 09 Jul 2019 23:33:19 +0200 Subject: WKD documentation (Re: Testing WKD setup?) In-Reply-To: <201907091502.30789.bernhard@intevation.de> References: <20190706165724.GA18183@azadi> <2144594.dpbWWjdrQj@mani> <201907091502.30789.bernhard@intevation.de> Message-ID: <1568078.R1anZlQGBM@mani> Hi, On Dienstag, 9. Juli 2019 15:02:26 CEST Bernhard Reiter wrote: > please make suggestions (or help with improving) > https://wiki.gnupg.org/WKD I think the problem with that page is that it is handed out as a starting point to users asking "how can I enable WKD for my key?". To give credit, the page does give a decent explanation of the concepts of WKD: What is a Web Key Directory? How does it work? These two sections are a good start. What does it mean for users? Here I got sidelined a little: Basically, everything's nice for users and we don't need to do anything, I guess? I think the example video shows that you can just write an email and the mail client encrypted it to the recipient. Having subtitles (or a narrator) would probably make the intent of the video clearer. For me as a user, it would also be nice to know if WKD "just happens" automatically, or if I need to enable it, or give it precedence over my configured default keyserver... How to set it up? This section is "lots" of text with the important info hidden behind a link. I say "lots" even though it's hardly a paragraph, because it's roughly a whole line with boilerplate text and the link is a single word. Just putting "See: WKDHosting" without the paragraph would be better. Maybe a bullet-list could do the job: - Simple deployment (just a webserver): WKDHosting - Deployment with automated updates (recommended for organizations): WKS Web Key Directory (WKD) / Web Key Service (WKS) what is the difference? This is literally a list of differences - why not make it a list? Technical Details Implementations (Nothing wrong with those two sections). > Note that on Wiktor's page a few details are missing: > * policy file is needed > * directory listing strongly recommend to be off > * minimum version of gpg that has --with-wkd (some versions don't). Wiktor's page gave me enough of a starting point so that I could figure out the missing details. Actually, just entering my email into the form and then working to fix every complaint until it works wasn't too bad a user experience ;-) > BTW, last week we've updated > https://wiki.gnupg.org/WKDHosting > with a how to use gpg-wks-client on Gnu and Windows systems > to create a flat file structure. That's definitely an improvement - previously, I only took passing note of the page, noting that there has to be an easier way than "download some code from mercurial somewhere, install python prerequisites, create specially crafted keyring, and then it's just a one-liner to create the WKD. Now that I have done it once, I think the setup without /usr/lib/gnupg/gpg- wks-client isn't that complicated either: Basic steps: 1. Create directory structure: mkdir -p .well-known/openpgp/hu 2. Create policy file: touch .well-known/openpgp/policy (explaining valid policies and why one would want one) 3. Identify your key hash: gpg --list-secret-keys --with-wkd $KEYID -> Make sure to omit the domain part starting with "@" 4. Export your key to the right place: gpg --export-options export-clean --export $KEYID > .well-known/openpgp/hu/ $WKD_HASH (I'm not sure about the export-clean - it just seemed like a reasonable default.) Webserver configuration: 1. Turn off directory listing for .well-known/openpgp unless you really want this 2. Enable those header things that are mentioned in the wkd checker (explain the rationale behind this) Testing: a. using Wiktors web wkd-checker, which also checks best-practice b. Manually, using gpg: gpg --homedir "$(mktemp -d)" --locate-keys $KEYID I hope this helps a little, Johannes P.S.: Now that I've read up on the other mails it seems that it is also possible to host the WKD on a subdomain - I guess this could also need some documentation (describe the lookup-procedure on the WKD page under "How it works"; describe the differences in setup on WKDHosting) From wiktor at metacode.biz Wed Jul 10 14:03:34 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 10 Jul 2019 14:03:34 +0200 Subject: WKD: mutt integration status (was: WKD documentation) In-Reply-To: <201907101335.38887.bernhard@intevation.de> References: <20190706165724.GA18183@azadi> <201907101038.25127.bernhard@intevation.de> <0f6a2112-1e07-c8c5-2ee8-1ad85e5f2ae7@metacode.biz> <201907101335.38887.bernhard@intevation.de> Message-ID: <374474b1-e9b4-0b7d-1a73-d6dcc952558e@metacode.biz> On 10.07.2019 13:35, Bernhard Reiter wrote: > Am Mittwoch 10 Juli 2019 10:53:17 schrieb Wiktor Kwapisiewicz via Gnupg-users: >> If you convince Mutt community that WKD is a good idea I can prepare the >> patch for you. > > As I'm not on the mutt development channels, > I'd prefer if someone else would do this. > > Bernhard > ps.: Still I'm an very occasional mutt user. I never used mutt before working on that change too ;) Two patches are here (recreated from memory): https://github.com/wiktor-k/mutt/commits/master They do work as I've tested them in mutt using PGP: encrypt (y/e; the key was correctly fetched inside mutt). If someone wants to take it over and propose it again on mutt-dev I don't mind (I don't care about credits so let's say it's released as public domain ;)). There may be some error handling necessary. I've omitted it because if setting keylist_mode fails it's not catastrophic. Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Jul 10 19:34:41 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Jul 2019 19:34:41 +0200 Subject: WKD documentation (Re: Testing WKD setup?) In-Reply-To: <1568078.R1anZlQGBM@mani> (Johannes Zarl-Zierl's message of "Tue, 09 Jul 2019 23:33:19 +0200") References: <20190706165724.GA18183@azadi> <2144594.dpbWWjdrQj@mani> <201907091502.30789.bernhard@intevation.de> <1568078.R1anZlQGBM@mani> Message-ID: <874l3tg5e6.fsf@wheatstone.g10code.de> On Tue, 9 Jul 2019 23:33, johannes at zarl-zierl.at said: > Now that I have done it once, I think the setup without /usr/lib/gnupg/gpg- > wks-client isn't that complicated either: Please use gpg-wks-tool instead; it is much easier and less error prone. > b. Manually, using gpg: gpg --homedir "$(mktemp -d)" --locate-keys $KEYID With 2.2.17 use gpg --locate-external-key -v foo at example.org Granted it imports the key but after all that is what you want. That new command does not check the local keyring so it can be used to refresh from a WKD (or whatever has been configured in your AKL) You may use gpg-wks-client --with-colons --supported DOMAINS to get the status of the Web Key Service for the requested domains. See the man page for details. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 10 19:39:06 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Jul 2019 19:39:06 +0200 Subject: WKD: mutt integration status In-Reply-To: (Andrew Gallagher's message of "Wed, 10 Jul 2019 11:59:05 +0100") References: <20190706165724.GA18183@azadi> <201907091647.15556.bernhard@intevation.de> <201907101038.25127.bernhard@intevation.de> <0f6a2112-1e07-c8c5-2ee8-1ad85e5f2ae7@metacode.biz> <87imsafam4.fsf@wheatstone.g10code.de> Message-ID: <87zhlleqmd.fsf@wheatstone.g10code.de> On Wed, 10 Jul 2019 11:59, andrewg at andrewg.com said: > In this instance, I wonder if the apostrophe hasn't screwed something up > - are apostrophes valid in the MIME boundary charset? I use that for ages and believe this is all valid. But new Emacs versions sometimes chnage the spooky list and thus it is possible that the latest list proves me wrong. --8<---------------cut here---------------start------------->8--- (defun spook-make-boundary (&optional count) (save-excursion (set-buffer (generate-new-buffer " *spook tmp*")) (setq buffer-disable-undo t) (spook) (subst-char-in-region (point-min) (point-max) ?\n ?= t) (subst-char-in-region (point-min) (point-max) ? ?_ t) (subst-char-in-region (point-min) (point-max) ?[ ?. t) (subst-char-in-region (point-min) (point-max) ?] ?. t) (subst-char-in-region (point-min) (point-max) ?$ ?. t) (prog1 (buffer-substring (point-min) (min 70 (point-max))) (kill-buffer (current-buffer))))) (setq mml-boundary-function 'spook-make-boundary) (add-hook 'gnus-group-mode-hook 'gnus-topic-mode) --8<---------------cut here---------------end--------------->8--- Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From johannes at zarl-zierl.at Wed Jul 10 21:47:54 2019 From: johannes at zarl-zierl.at (Johannes Zarl-Zierl) Date: Wed, 10 Jul 2019 21:47:54 +0200 Subject: WKD documentation (Re: Testing WKD setup?) In-Reply-To: <874l3tg5e6.fsf@wheatstone.g10code.de> References: <20190706165724.GA18183@azadi> <1568078.R1anZlQGBM@mani> <874l3tg5e6.fsf@wheatstone.g10code.de> Message-ID: <2621495.KbpXRkanVB@mani> Am Mittwoch, 10. Juli 2019, 19:34:41 CEST schrieb Werner Koch: > On Tue, 9 Jul 2019 23:33, johannes at zarl-zierl.at said: > > Now that I have done it once, I think the setup without > > /usr/lib/gnupg/gpg- > > > wks-client isn't that complicated either: > Please use gpg-wks-tool instead; it is much easier and less error prone. ...except it isn't installed by default. Will this be part of gpg-wks-client? But in the future when it is installed by default, I 100% agree with you. Btw, and because we are on the topic of documentation: there is no mention of gpg-wks-tool anywhere in the WKD or WKDHosting pages. Anyways: whether you promote gpg-wks-client or gpg-wks-tool (which, hopefully, won't be installed to libexec), it would still be beneficial to describe the actual file system layout. > > b. Manually, using gpg: gpg --homedir "$(mktemp -d)" --locate-keys $KEYID > > With 2.2.17 use > > gpg --locate-external-key -v foo at example.org > > Granted it imports the key but after all that is what you want. That > new command does not check the local keyring so it can be used to > refresh from a WKD (or whatever has been configured in your AKL) That seems nice - I will take note for the time this enters Debian... Cheers, Johannes From hoermi at gmail.com Thu Jul 11 01:33:43 2019 From: hoermi at gmail.com (Matthias Herrmann) Date: Thu, 11 Jul 2019 01:33:43 +0200 Subject: wrong gpg-agent version running? Message-ID: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> Hello I've recently upgraded to Debian buster, and then upgraded gpg by downloading and installing the new version 2.2.17. Now, I get this warning: > gpg: WARNING: server 'gpg-agent' is older than us (2.2.12 < 2.2.17) $ gpg --version gpg (GnuPG) 2.2.17 libgcrypt 1.8.4 $ which gpg-agent /usr/local/bin/gpg-agent $ /usr/local/bin/gpg-agent --version gpg-agent (GnuPG) 2.2.17 libgcrypt 1.8.4 $ gpgconf --list-dirs sysconfdir:/usr/local/etc/gnupg bindir:/usr/local/bin libexecdir:/usr/local/libexec libdir:/usr/local/lib/gnupg datadir:/usr/local/share/gnupg localedir:/usr/local/share/locale socketdir:/run/user/1000/gnupg $ whereis gpg-agent gpg-agent: /usr/bin/gpg-agent /usr/local/bin/gpg-agent /usr/share/man/man1/gpg-agent.1.gz and: $ /usr/bin/gpg-agent --version gpg-agent (GnuPG) 2.2.12 libgcrypt 1.8.4 $ echo $PATH /usr/local/bin /usr/bin /bin /usr/local/games /usr/games I've even tried to add agent-program /usr/local/bin/gpg-agent to gpg.conf I don't know why the "wrong" agent gets started, can you please help me? -Hermi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From tlikonen at iki.fi Thu Jul 11 15:41:04 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 11 Jul 2019 16:41:04 +0300 Subject: wrong gpg-agent version running? In-Reply-To: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> (Matthias Herrmann via Gnupg-users's message of "Thu, 11 Jul 2019 01:33:43 +0200") References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> Message-ID: <87a7dky9hr.fsf@iki.fi> Matthias Herrmann [2019-07-11T01:33:43+02] wrote: > I've recently upgraded to Debian buster, and then upgraded gpg by > downloading and installing the new version 2.2.17. > Now, I get this warning: > >> gpg: WARNING: server 'gpg-agent' is older than us (2.2.12 < 2.2.17) > I don't know why the "wrong" agent gets started, can you please help > me? I believe it's because there is gpg-agent.socket unit which activates gpg-agent.service which has the path /usr/bin/gpg-agent. To override that create a unit "drop-in" file: # Filename: # ~/.config/systemd/user/gpg-agent.service.d/my.conf # or # /etc/systemd/user/gpg-agent.service.d/my.conf [Service] ExecStart=/usr/local/bin/gpg-agent --supervised ExecReload=/usr/local/bin/gpgconf --reload gpg-agent Test if it's found with "systemctl --user cat gpg-agent.service". Maybe also "killall gpg-agent" if you have something left from your previous settings. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From chrisbcoutinho at gmail.com Thu Jul 11 14:32:00 2019 From: chrisbcoutinho at gmail.com (Chris Coutinho) Date: Thu, 11 Jul 2019 14:32:00 +0200 Subject: wrong gpg-agent version running? In-Reply-To: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> Message-ID: Hi, I've run into this issue when my package manager updates gnupg without killing running gpg-agent daemons. I think you have a previous (old version) gpg-agent daemon still running. You can see if that's the case by looking at the output of 'ps x'. I would recommend killing that daemon by using 'gpgconf --kill gpg-agent'. Your next invocation of a gpg command will launch a fresh daemon using the correct version. Chris On Thu, 11 Jul 2019 at 11:50, Matthias Herrmann via Gnupg-users < gnupg-users at gnupg.org> wrote: > Hello > > I've recently upgraded to Debian buster, and then upgraded gpg by > downloading and installing the new version 2.2.17. > Now, I get this warning: > > > gpg: WARNING: server 'gpg-agent' is older than us (2.2.12 < 2.2.17) > > $ gpg --version > gpg (GnuPG) 2.2.17 > libgcrypt 1.8.4 > > $ which gpg-agent > /usr/local/bin/gpg-agent > > $ /usr/local/bin/gpg-agent --version > gpg-agent (GnuPG) 2.2.17 > libgcrypt 1.8.4 > > $ gpgconf --list-dirs > sysconfdir:/usr/local/etc/gnupg > bindir:/usr/local/bin > libexecdir:/usr/local/libexec > libdir:/usr/local/lib/gnupg > datadir:/usr/local/share/gnupg > localedir:/usr/local/share/locale > socketdir:/run/user/1000/gnupg > > $ whereis gpg-agent > gpg-agent: /usr/bin/gpg-agent /usr/local/bin/gpg-agent > /usr/share/man/man1/gpg-agent.1.gz > > and: > $ /usr/bin/gpg-agent --version > gpg-agent (GnuPG) 2.2.12 > libgcrypt 1.8.4 > > $ echo $PATH > /usr/local/bin /usr/bin /bin /usr/local/games /usr/games > > I've even tried to add agent-program /usr/local/bin/gpg-agent to gpg.conf > > I don't know why the "wrong" agent gets started, can you please help me? > > -Hermi > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hoermi at gmail.com Thu Jul 11 16:16:29 2019 From: hoermi at gmail.com (Matthias Herrmann) Date: Thu, 11 Jul 2019 16:16:29 +0200 Subject: wrong gpg-agent version running? In-Reply-To: <87a7dky9hr.fsf@iki.fi> References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> <87a7dky9hr.fsf@iki.fi> Message-ID: <3c953c2b-6f4d-3e23-dcf6-f4faa8382829@gmail.com> On 11/07/2019 15:41, Teemu Likonen wrote: > I believe it's because there is gpg-agent.socket unit which activates > gpg-agent.service which has the path /usr/bin/gpg-agent. To override > that create a unit "drop-in" file: Thank you, that was it. I edited /usr/lib/systemd/user/gpg-agent.service directly and changed the ExecStart and ExecReload paths. -Hermi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From tlikonen at iki.fi Thu Jul 11 16:36:03 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 11 Jul 2019 17:36:03 +0300 Subject: wrong gpg-agent version running? In-Reply-To: <3c953c2b-6f4d-3e23-dcf6-f4faa8382829@gmail.com> (Matthias Herrmann's message of "Thu, 11 Jul 2019 16:16:29 +0200") References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> <87a7dky9hr.fsf@iki.fi> <3c953c2b-6f4d-3e23-dcf6-f4faa8382829@gmail.com> Message-ID: <875zo8y6y4.fsf@iki.fi> Matthias Herrmann [2019-07-11T16:16:29+02] wrote: > I edited /usr/lib/systemd/user/gpg-agent.service directly and changed > the ExecStart and ExecReload paths. It is not a good idea to edit that file directly; it's not a configuration file. In systemd you should make your own changes in /etc/systemd/. I quote systemd.unit man page: Example 2. Overriding vendor settings There are two methods of overriding vendor settings in unit files: copying the unit file from /lib/systemd/system to /etc/systemd/system and modifying the chosen settings. Alternatively, one can create a directory named unit.d/ within /etc/systemd/system and place a drop-in file name.conf there that only changes the specific settings one is interested in. Note that multiple such drop-in files are read if present, processed in lexicographic order of their filename. The advantage of the first method is that one easily overrides the complete unit, the vendor unit is not parsed at all anymore. It has the disadvantage that improvements to the unit file by the vendor are not automatically incorporated on updates. The advantage of the second method is that one only overrides the settings one specifically wants, where updates to the unit by the vendor automatically apply. This has the disadvantage that some future updates by the vendor might be incompatible with the local changes. So in your case the first method (as descibed in the above quote) is to copy file /usr/lib/systemd/user/gpg-agent.service to /etc/systemd/user/gpg-agent.service and then edit the latter. The former is not used anymore because the /etc version overrides it completely. The second method is to override only parts of it by creating a "drop-in" /etc/systemd/user/gpg-agent.service.d/my.conf and define just the [Service] section and the settings one want's to override: [Service] ExecStart= ExecStart=/usr/local/bin/gpg-agent --supervised ExecReload= ExecReload=/usr/local/bin/gpgconf --reload gpg-agent The empty ExecStart= and ExecReload= reset all possible previous settings. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mkesper at schokokeks.org Thu Jul 11 16:45:06 2019 From: mkesper at schokokeks.org (Michael Kesper) Date: Thu, 11 Jul 2019 16:45:06 +0200 Subject: wrong gpg-agent version running? In-Reply-To: <87a7dky9hr.fsf@iki.fi> References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> <87a7dky9hr.fsf@iki.fi> Message-ID: <6d776359-2048-0d2f-ce5b-4675f4c33557@schokokeks.org> Hi all, On 11.07.19 15:41, Teemu Likonen via Gnupg-users wrote: > Matthias Herrmann [2019-07-11T01:33:43+02] wrote: > >> I've recently upgraded to Debian buster, and then upgraded gpg by >> downloading and installing the new version 2.2.17. >> Now, I get this warning: >> >>> gpg: WARNING: server 'gpg-agent' is older than us (2.2.12 < 2.2.17) > >> I don't know why the "wrong" agent gets started, can you please help >> me? > > I believe it's because there is gpg-agent.socket unit which activates > gpg-agent.service which has the path /usr/bin/gpg-agent. To override > that create a unit "drop-in" file: > > # Filename: > # ~/.config/systemd/user/gpg-agent.service.d/my.conf > # or > # /etc/systemd/user/gpg-agent.service.d/my.conf > > [Service] > ExecStart=/usr/local/bin/gpg-agent --supervised > ExecReload=/usr/local/bin/gpgconf --reload gpg-agent Did anyone open a bug with Debian (best with proposing a fix)? Bye Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From hoermi at gmail.com Thu Jul 11 16:49:29 2019 From: hoermi at gmail.com (Matthias Herrmann) Date: Thu, 11 Jul 2019 16:49:29 +0200 Subject: wrong gpg-agent version running? In-Reply-To: <875zo8y6y4.fsf@iki.fi> References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> <87a7dky9hr.fsf@iki.fi> <3c953c2b-6f4d-3e23-dcf6-f4faa8382829@gmail.com> <875zo8y6y4.fsf@iki.fi> Message-ID: On 11/07/2019 16:36, Teemu Likonen wrote: > Matthias Herrmann [2019-07-11T16:16:29+02] wrote: > >> I edited /usr/lib/systemd/user/gpg-agent.service directly and changed >> the ExecStart and ExecReload paths. > > It is not a good idea to edit that file directly; it's not a > configuration file. In systemd you should make your own changes in > /etc/systemd/. I quote systemd.unit man page: This worked! Perfect! :) I created the .d directory and only overwrote ExecStart and ExecReload as you suggested. Thank you for the short lesson in systemd, I didn't know about this mechanism. -Hermi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From hoermi at gmail.com Thu Jul 11 16:51:01 2019 From: hoermi at gmail.com (Matthias Herrmann) Date: Thu, 11 Jul 2019 16:51:01 +0200 Subject: wrong gpg-agent version running? In-Reply-To: <6d776359-2048-0d2f-ce5b-4675f4c33557@schokokeks.org> References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> <87a7dky9hr.fsf@iki.fi> <6d776359-2048-0d2f-ce5b-4675f4c33557@schokokeks.org> Message-ID: <37883f3c-34f0-27b8-c30c-98de0a6d0d94@gmail.com> Hi On 11/07/2019 16:45, Michael Kesper wrote: > Did anyone open a bug with Debian (best with proposing a fix)? Hello This is not a bug in debian, they ship with 2.2.12 [1]. I manually installed 2.2.17 from source. -Hermi [1] https://packages.debian.org/buster/gnupg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From tlikonen at iki.fi Thu Jul 11 17:11:53 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 11 Jul 2019 18:11:53 +0300 Subject: wrong gpg-agent version running? In-Reply-To: <6d776359-2048-0d2f-ce5b-4675f4c33557@schokokeks.org> (Michael Kesper's message of "Thu, 11 Jul 2019 16:45:06 +0200") References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> <87a7dky9hr.fsf@iki.fi> <6d776359-2048-0d2f-ce5b-4675f4c33557@schokokeks.org> Message-ID: <871rywy5ae.fsf@iki.fi> Michael Kesper [2019-07-11T16:45:06+02] wrote: > Did anyone open a bug with Debian (best with proposing a fix)? What bug? We have not seen a bug in this message thread. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mkesper at schokokeks.org Thu Jul 11 17:15:19 2019 From: mkesper at schokokeks.org (Michael Kesper) Date: Thu, 11 Jul 2019 17:15:19 +0200 Subject: wrong gpg-agent version running? In-Reply-To: <871rywy5ae.fsf@iki.fi> References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> <87a7dky9hr.fsf@iki.fi> <6d776359-2048-0d2f-ce5b-4675f4c33557@schokokeks.org> <871rywy5ae.fsf@iki.fi> Message-ID: Hi Teemu, On 11.07.19 17:11, Teemu Likonen wrote: > Michael Kesper [2019-07-11T16:45:06+02] wrote: > >> Did anyone open a bug with Debian (best with proposing a fix)? > > What bug? We have not seen a bug in this message thread. I'd consider it a bug if updating a package does not trigger reloading all necessary services. Bye Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From tlikonen at iki.fi Thu Jul 11 17:34:50 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 11 Jul 2019 18:34:50 +0300 Subject: wrong gpg-agent version running? In-Reply-To: (Michael Kesper's message of "Thu, 11 Jul 2019 17:15:19 +0200") References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> <87a7dky9hr.fsf@iki.fi> <6d776359-2048-0d2f-ce5b-4675f4c33557@schokokeks.org> <871rywy5ae.fsf@iki.fi> Message-ID: <87wogowpnp.fsf@iki.fi> Michael Kesper [2019-07-11T17:15:19+02] wrote: > I'd consider it a bug if updating a package does not trigger reloading > all necessary services. We have not been discussing about Debian package upgrade. This message thread is about additional local installation (/usr/local) which is outside of Debian's package system. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From tlikonen at iki.fi Thu Jul 11 20:40:22 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 11 Jul 2019 21:40:22 +0300 Subject: wrong gpg-agent version running? In-Reply-To: (Matthias Herrmann via Gnupg-users's message of "Thu, 11 Jul 2019 16:49:29 +0200") References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> <87a7dky9hr.fsf@iki.fi> <3c953c2b-6f4d-3e23-dcf6-f4faa8382829@gmail.com> <875zo8y6y4.fsf@iki.fi> Message-ID: <87muhkpg89.fsf@iki.fi> Matthias Herrmann via Gnupg-users [2019-07-11T16:49:29+02] wrote: > I created the .d directory and only overwrote ExecStart and ExecReload > as you suggested. Just remembered that there is also dirmngr.service for which you probably want to the same thing as for gpg-agent.service. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From hoermi at gmail.com Fri Jul 12 00:12:47 2019 From: hoermi at gmail.com (Matthias Herrmann) Date: Fri, 12 Jul 2019 00:12:47 +0200 Subject: wrong gpg-agent version running? In-Reply-To: <87muhkpg89.fsf@iki.fi> References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> <87a7dky9hr.fsf@iki.fi> <3c953c2b-6f4d-3e23-dcf6-f4faa8382829@gmail.com> <875zo8y6y4.fsf@iki.fi> <87muhkpg89.fsf@iki.fi> Message-ID: On 11/07/2019 20:40, Teemu Likonen wrote: > Just remembered that there is also dirmngr.service for which you > probably want to the same thing as for gpg-agent.service. I didn't think of that, thanks for the hint. -Hermi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Jul 12 10:30:30 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Jul 2019 10:30:30 +0200 Subject: WKD documentation (Re: Testing WKD setup?) In-Reply-To: <2621495.KbpXRkanVB@mani> (Johannes Zarl-Zierl's message of "Wed, 10 Jul 2019 21:47:54 +0200") References: <20190706165724.GA18183@azadi> <1568078.R1anZlQGBM@mani> <874l3tg5e6.fsf@wheatstone.g10code.de> <2621495.KbpXRkanVB@mani> Message-ID: <87o91zd595.fsf@wheatstone.g10code.de> On Wed, 10 Jul 2019 21:47, johannes at zarl-zierl.at said: > ...except it isn't installed by default. Will this be part of gpg-wks-client? Ooops. I meant gpg-wks-client. There is no gpg-wks-tool. > won't be installed to libexec), it would still be beneficial to describe the > actual file system layout. You mean, where it gets installed? When running ./configure without any options gpg-wks-tool whill be installed under /usr/local/libexec as per GNU standards. Debian and other distors don't have this directory and install it under /usr/lib. You can of course use $(gpgconf --list-dirs libexecdir)/gpg-wks-client Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wiktor at metacode.biz Fri Jul 12 15:10:43 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 12 Jul 2019 15:10:43 +0200 Subject: Arch Linux impacted by new defaults in 2.2.17 Message-ID: Hello, I just saw the following bug reported in Arch Linux repos: https://bugs.archlinux.org/task/63147 with the title "[gnupg] 2.2.17 release is broken by design and breaks pacman". It appears Arch's packages use Web of Trust for introducing new developers by adding 3 signatures out of 5 (or 6) marginally trusted Master Signing Keys: https://www.archlinux.org/master-keys/ and thus they depend on these signatures to be there. Quoting the bug report: > By default, pacman itself will try to look up keys which it does not know about yet, and download them with the master key signatures in order to validate signed packages/repositories. Would deploying WKD on archlinux.org and making signatures with --sender preserve third-party-signatures that they depend on? Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From johannes at zarl-zierl.at Fri Jul 12 15:11:28 2019 From: johannes at zarl-zierl.at (Johannes Zarl-Zierl) Date: Fri, 12 Jul 2019 15:11:28 +0200 Subject: WKD documentation (Re: Testing WKD setup?) In-Reply-To: <87o91zd595.fsf@wheatstone.g10code.de> References: <20190706165724.GA18183@azadi> <2621495.KbpXRkanVB@mani> <87o91zd595.fsf@wheatstone.g10code.de> Message-ID: <2762282.D8JtcrF1iO@johannes-slimbook> Am Freitag, 12. Juli 2019, 10:30:30 CEST schrieb Werner Koch via Gnupg-users: > On Wed, 10 Jul 2019 21:47, johannes at zarl-zierl.at said: > > ...except it isn't installed by default. Will this be part of > > gpg-wks-client? > Ooops. I meant gpg-wks-client. There is no gpg-wks-tool. Thanks for the clarification. > > won't be installed to libexec), it would still be beneficial to describe > > the actual file system layout. > > You mean, where it gets installed? When running ./configure without any > options gpg-wks-tool whill be installed under /usr/local/libexec as per > GNU standards. Debian and other distors don't have this directory and > install it under /usr/lib. You can of course use Sorry, I should have separated this better from the previous sentence. What I meant are two things: 1. If a user is ever to execute gpg-wks-client directly or through a script, libexec should not be used: [1] Right now I have the bizarre situation on Debian unstable that gpg-wks-server is in /usr/bin even though it is meant to be executed by a service and not by a user, but gpg-wks-client is located in /usr/lib/gnupg (Debian has no libexec, I think). [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html 2. It would still be beneficial to describe the actual file system layout of the WKD. This can either be done implicitly in the step-by-step guide ("After the call to gpg-wks-client, 'find .well-known/openpgp' should list a directory structure similar to this one: ..."). Or it can be documented separately on the WKD page, also explaining different options (e.g. is there a different WKD layout when WKD is deployed on a sub-domain, what are possible values for the policy file) with links to the canonical reference documentation. Cheers, Johannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From konstantin at linuxfoundation.org Fri Jul 12 21:21:01 2019 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Fri, 12 Jul 2019 15:21:01 -0400 Subject: Avoiding hardcoded paths when static-compiling Message-ID: <20190712192101.GA547@chatter.i7.local> Hi, all: I provide an RPM package called gnupg22-static for those who need to run newer versions of GnuPG on CentOS-7 environments (it's stuck on gnupg-2.0 there). For compilation, I use the convenient STATIC=1 mechanism, but there's still the problem that all paths end up being hardcoded to the RPM buildroot environment. The full build command is: make -f build-aux/speedo.mk STATIC=1 CUSTOM_SWDB=1 INSTALL_PREFIX=. this-native In the RPM context, the INSTALL_PREFIX ends up being inside a buildroot location, like so: /builddir/build/BUILD/gnupg-2.2.17/ However, the final installation of this will be in /opt/gnupg22, which means that if a binary needs to call another binary, it will try to execute /builddir/build/BUILD/gnupg-2.2.17/bin/foo (and fail). I can't set INSTALL_PREFIX=/opt/gnupg22, because that will make the RPM build fail (it cannot write outside of /builddir), so I need a way to tell the binaries during build time that their final install path will be different than the path used during build. I am able to use gpg and gpgv this way by setting agent-program and dirmngr-program config values, but trying to make this work with gpg-wks-server fails. Any pointers on how I can make this work without hardcoding bogus build-time paths? -K From patrick at enigmail.net Sat Jul 13 10:23:20 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 13 Jul 2019 10:23:20 +0200 Subject: Avoiding hardcoded paths when static-compiling In-Reply-To: <20190712192101.GA547__20800.9664713003$1562959380$gmane$org@chatter.i7.local> References: <20190712192101.GA547__20800.9664713003$1562959380$gmane$org@chatter.i7.local> Message-ID: <341e4d25-c126-596a-ef94-99b470124d05@enigmail.net> On 12.07.2019 21:21, Konstantin Ryabitsev wrote: > Hi, all: > > I provide an RPM package called gnupg22-static for those who need to run > newer versions of GnuPG on CentOS-7 environments (it's stuck on > gnupg-2.0 there). For compilation, I use the convenient STATIC=1 > mechanism, but there's still the problem that all paths end up being > hardcoded to the RPM buildroot environment. > > The full build command is: > make -f build-aux/speedo.mk STATIC=1 CUSTOM_SWDB=1 INSTALL_PREFIX=.? > this-native > In the RPM context, the INSTALL_PREFIX ends up being inside a buildroot > location, like so: > > /builddir/build/BUILD/gnupg-2.2.17/ > > However, the final installation of this will be in /opt/gnupg22, which > means that if a binary needs to call another binary, it will try to > execute /builddir/build/BUILD/gnupg-2.2.17/bin/foo (and fail). > > I can't set INSTALL_PREFIX=/opt/gnupg22, because that will make the RPM > build fail (it cannot write outside of /builddir), so I need a way to > tell the binaries during build time that their final install path will > be different than the path used during build. > I am able to use gpg and gpgv this way by setting agent-program and > dirmngr-program config values, but trying to make this work with > gpg-wks-server fails. > > Any pointers on how I can make this work without hardcoding bogus > build-time paths? I have the same situation for building gpgOSX. The solution is this: ./configure \ --with-pinentry-pgm=${TARGET_DIR}/bin/pinentry \ --with-agent-pgm=${TARGET_DIR}/bin/gpg-agent \ --with-scdaemon-pgm=${TARGET_DIR}/libexec/scdaemon \ --with-dirmngr-pgm=${TARGET_DIR}/bin/dirmngr \ --with-dirmngr-ldap-pgm=${TARGET_DIR}/libexec/dirmngr_ldap \ --with-protect-tool-pgm=${TARGET_DIR}/libexec/gpg-protect-tool \ etc. -Patrick From ml at mareichelt.com Sat Jul 13 13:36:35 2019 From: ml at mareichelt.com (Markus Reichelt) Date: Sat, 13 Jul 2019 13:36:35 +0200 Subject: Arch Linux impacted by new defaults in 2.2.17 In-Reply-To: References: Message-ID: <20190713113635.GA2291@pc21.mareichelt.com> It's all about where they look for new/updated keys. There's folks out there who use a WKD setup, as you mentioned, then there's some who use a standalone (isolated, non-peering) SKS keyserver, etc. I do not think reverting the patch that causes issues for them is a smart move in the long run. [...] Welcome to the mess of PKI. -- left blank, right bald From sac at 300baud.de Sat Jul 13 18:43:23 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 13 Jul 2019 16:43:23 -0000 Subject: test In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David wrote: > Just testing my e-,ails are getting through :) > > But not signed :) no public key > > David And a little reply, to see if my signature verifies properly. Step 1. Creating the reply in Notepad++ (offline). Step 2. Signing the message (offline). Step 3. Adding Headers (offline). Step 4. Transfer with CoolTerm to online computer. Step 5. Sending the message with openssl. Stefan -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTJPiUt+ztNt+rrhGrY1GSzXhKrdwUCXSn/qwAKCRDY1GSzXhKr dzwHAP4pjtOH72H4ZF/WXegsao/oVf7kAVKgl1zWAy2Ypg7PTgD8CtwPDxHoHxKq FMf+JEVzkjuigzAhyRvE/1vbnkf5GwA= =3gZ2 -----END PGP SIGNATURE----- From sac at 300baud.de Sat Jul 13 18:53:30 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 13 Jul 2019 16:53:30 -0000 Subject: test In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David wrote: > Just testing my e-,ails are getting through :) > > But not signed :) no public key > > David And a little reply, to see if my signature verifies properly. Step 1. Creating the reply in Notepad++ (offline). Step 2. Signing the message (offline). Step 3. Adding Headers (offline). Step 4. Transfer with CoolTerm to online computer. Step 5. Sending the message with openssl. Regards Stefan -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTJPiUt+ztNt+rrhGrY1GSzXhKrdwUCXSn/qwAKCRDY1GSzXhKr dzwHAP4pjtOH72H4ZF/WXegsao/oVf7kAVKgl1zWAy2Ypg7PTgD8CtwPDxHoHxKq FMf+JEVzkjuigzAhyRvE/1vbnkf5GwA= =3gZ2 -----END PGP SIGNATURE----- From sac at 300baud.de Sat Jul 13 18:56:51 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 13 Jul 2019 18:56:51 +0200 Subject: test References: Message-ID: Stefan Claas via Gnupg-users wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > David wrote: > > > Just testing my e-,ails are getting through :) > > > > But not signed :) no public key > > > > David > > And a little reply, to see if my signature verifies properly. > > Step 1. Creating the reply in Notepad++ (offline). > Step 2. Signing the message (offline). > Step 3. Adding Headers (offline). > Step 4. Transfer with CoolTerm to online computer. > Step 5. Sending the message with openssl. > > Stefan > -----BEGIN PGP SIGNATURE----- > > iHUEARYIAB0WIQTJPiUt+ztNt+rrhGrY1GSzXhKrdwUCXSn/qwAKCRDY1GSzXhKr > dzwHAP4pjtOH72H4ZF/WXegsao/oVf7kAVKgl1zWAy2Ypg7PTgD8CtwPDxHoHxKq > FMf+JEVzkjuigzAhyRvE/1vbnkf5GwA= > =3gZ2 > -----END PGP SIGNATURE----- Forgot the -quiet command in openssl, hence the error. Hope the second try is correct. Regards Stefan From david at gbenet.com Sun Jul 14 00:27:57 2019 From: david at gbenet.com (David) Date: Sat, 13 Jul 2019 23:27:57 +0100 Subject: test In-Reply-To: References: Message-ID: On 13/07/2019 17:45, Stefan Claas via Gnupg-users wrote: > David wrote: > >> Just testing my e-,ails are getting through :) > >> But not signed :) no public key > >> David > > And a little reply, to see if my signature verifies properly. > > Step 1. Creating the reply in Notepad++ (offline). > Step 2. Signing the message (offline). > Step 3. Adding Headers (offline). > Step 4. Transfer with CoolTerm to online computer. > Step 5. Sending the message with openssl. > > Stefan > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Hello Stefan - I copied and pasted your key into a file - then imported it - but I could not find your public key in my list - you have a very small public key :) David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From david at gbenet.com Sun Jul 14 01:29:36 2019 From: david at gbenet.com (David) Date: Sun, 14 Jul 2019 00:29:36 +0100 Subject: test In-Reply-To: References: Message-ID: <0053a342-93c5-b068-2fac-6da9474ffb08@gbenet.com> On 13/07/2019 17:56, Stefan Claas via Gnupg-users wrote: > Stefan Claas via Gnupg-users wrote: > > David wrote: > >>>> Just testing my e-,ails are getting through :) >>>> >>>> But not signed :) no public key >>>> >>>> David > > And a little reply, to see if my signature verifies properly. > > Step 1. Creating the reply in Notepad++ (offline). > Step 2. Signing the message (offline). > Step 3. Adding Headers (offline). > Step 4. Transfer with CoolTerm to online computer. > Step 5. Sending the message with openssl. > > Stefan > > Forgot the -quiet command in openssl, hence the error. > > Hope the second try is correct. > > Regards > Stefan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Hello Stefan, I mean to say - no keys were found :) David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Sun Jul 14 06:55:53 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 14 Jul 2019 06:55:53 +0200 Subject: test In-Reply-To: <0053a342-93c5-b068-2fac-6da9474ffb08@gbenet.com> References: <0053a342-93c5-b068-2fac-6da9474ffb08@gbenet.com> Message-ID: <20190714065553.00002678.sac@300baud.de> David wrote: > Hello Stefan, > > I mean to say - no keys were found :) Maybe you have to adjust you settings. My key is available via WKD or Hagrid. (P.S. I forgot to insert a Message-ID, so now threading is not correct.) Regards Stefn From tlikonen at iki.fi Sun Jul 14 08:21:12 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Sun, 14 Jul 2019 09:21:12 +0300 Subject: WKD auto-key-retrieve method In-Reply-To: <20190714065553.00002678.sac@300baud.de> (Stefan Claas via Gnupg-users's message of "Sun, 14 Jul 2019 06:55:53 +0200") References: <0053a342-93c5-b068-2fac-6da9474ffb08@gbenet.com> <20190714065553.00002678.sac@300baud.de> Message-ID: <87blxxb0h3.fsf_-_@iki.fi> Stefan Claas via Gnupg-users [2019-07-14T06:55:53+02] wrote: > My key is available via WKD or Hagrid. I think you should add "--sender email at address" option so that your signatures have information for WKD auto-key-retrieve method (and also for TOFU statistics). It is probably mail user agent's job to add "--sender" but maybe it is also fine to have that in gpg.conf file. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 507 bytes Desc: not available URL: From david at gbenet.com Sun Jul 14 12:37:36 2019 From: david at gbenet.com (David) Date: Sun, 14 Jul 2019 11:37:36 +0100 Subject: test In-Reply-To: <20190714065553.00002678.sac@300baud.de> References: <0053a342-93c5-b068-2fac-6da9474ffb08@gbenet.com> <20190714065553.00002678.sac@300baud.de> Message-ID: <47542645-1b59-5056-6ad4-aa950901d76b@gbenet.com> On 14/07/2019 05:55, Stefan Claas via Gnupg-users wrote: > David wrote: > >> Hello Stefan, >> >> I mean to say - no keys were found :) > > Maybe you have to adjust you settings. > > My key is available via WKD or Hagrid. > > (P.S. I forgot to insert a Message-ID, > so now threading is not correct.) > > Regards > Stefn > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > I have imported your key, David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x5C6EE7FBAAD8C47D.asc Type: application/pgp-keys Size: 4676 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Sun Jul 14 12:46:03 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 14 Jul 2019 10:46:03 -0000 Subject: WKD auto-key-retrieve method References: <0053a342-93c5-b068-2fac-6da9474ffb08@gbenet.com> <20190714065553.00002678.sac@300baud.de> <87blxxb0h3.fsf_-_@iki.fi> Message-ID: <7a7fdd1a-a622-11e9-9561-002318529d5b@iria.300baud.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Teemu Likonen wrote: > Stefan Claas via Gnupg-users [2019-07-14T06:55:53+02] wrote: > > > My key is available via WKD or Hagrid. > > I think you should add "--sender email at address" option so that your > signatures have information for WKD auto-key-retrieve method (and also > for TOFU statistics). > > It is probably mail user agent's job to add "--sender" but maybe it is > also fine to have that in gpg.conf file. > Thanks for the info, did not know this. Now a quick test with this option. Regards Stefan -----BEGIN PGP SIGNATURE----- iIUEARYIAC0WIQTJPiUt+ztNt+rrhGrY1GSzXhKrdwUCXSsDfw8cc2FjQDMwMGJh dWQuZGUACgkQ2NRks14Sq3fyvQD+JDUC7PvQt8/Fzsed1GakHZ7Bi6WYWV6lfvxS jtTpJGcBALnorJ57E/Ap8fZmsvtXh6bTgYv7jEOZ2NBAiv+q06UA =fGRC -----END PGP SIGNATURE----- From sac at 300baud.de Sun Jul 14 13:03:10 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 14 Jul 2019 13:03:10 +0200 Subject: test In-Reply-To: <47542645-1b59-5056-6ad4-aa950901d76b@gbenet.com> References: <0053a342-93c5-b068-2fac-6da9474ffb08@gbenet.com> <20190714065553.00002678.sac@300baud.de> <47542645-1b59-5056-6ad4-aa950901d76b@gbenet.com> Message-ID: <20190714130310.000013a8.sac@300baud.de> David wrote: > I have imported your key, :-) Regards Stefan From tlikonen at iki.fi Sun Jul 14 13:47:40 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Sun, 14 Jul 2019 14:47:40 +0300 Subject: WKD auto-key-retrieve method In-Reply-To: <7a7fdd1a-a622-11e9-9561-002318529d5b@iria.300baud.de> (Stefan Claas via Gnupg-users's message of "Sun, 14 Jul 2019 14:17:55 +0300 (EEST)") References: <0053a342-93c5-b068-2fac-6da9474ffb08@gbenet.com> <20190714065553.00002678.sac@300baud.de> <87blxxb0h3.fsf_-_@iki.fi> <7a7fdd1a-a622-11e9-9561-002318529d5b@iria.300baud.de> Message-ID: <877e8kbzxf.fsf@iki.fi> Stefan Claas via Gnupg-users [2019-07-14T14:17:55+03] wrote: > Teemu Likonen wrote: >> I think you should add "--sender email at address" option so that your >> signatures have information for WKD auto-key-retrieve method (and >> also for TOFU statistics). > Thanks for the info, did not know this. Now WKD lookup worked automatically when my mail client tried to verify your signature. It seems that you added --sender somewhere. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 507 bytes Desc: not available URL: From sac at 300baud.de Sun Jul 14 14:08:26 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 14 Jul 2019 14:08:26 +0200 Subject: WKD auto-key-retrieve method In-Reply-To: <877e8kbzxf.fsf@iki.fi> References: <0053a342-93c5-b068-2fac-6da9474ffb08@gbenet.com> <20190714065553.00002678.sac@300baud.de> <87blxxb0h3.fsf_-_@iki.fi> <7a7fdd1a-a622-11e9-9561-002318529d5b@iria.300baud.de> <877e8kbzxf.fsf@iki.fi> Message-ID: <20190714140826.00005a3e.sac@300baud.de> Teemu Likonen wrote: > Stefan Claas via Gnupg-users [2019-07-14T14:17:55+03] wrote: > > > Teemu Likonen wrote: > >> I think you should add "--sender email at address" option so that your > >> signatures have information for WKD auto-key-retrieve method (and > >> also for TOFU statistics). > > > Thanks for the info, did not know this. > > Now WKD lookup worked automatically when my mail client tried to verify > your signature. It seems that you added --sender somewhere. > Thanks for confirming! I added the --sender parameter in CLI mode when I signed the message (offline) with GnuPG. Regards Stefan From dbuergin at gluet.ch Mon Jul 15 18:03:23 2019 From: dbuergin at gluet.ch (David =?utf-8?Q?B=C3=BCrgin?=) Date: Mon, 15 Jul 2019 18:03:23 +0200 Subject: WKD: Publishing a key for multiple user IDs Message-ID: <20190715160323.GA8423@azadi> Under ?security considerations? the current WKD draft says: > The mail provider MUST make sure to publish a key in a way that only the > mail address belonging to the requested user is part of the User ID > packets included in the returned key. Other User ID packets and their > associated binding signatures NUST be removed before publication. So if I have two email addresses/user IDs me at my.org and me2 at my.org associated with the same key, I cannot just export the key and publish it, right? I have to somehow publish two different ?stripped? public keys. Is there documentation somewhere how to produce the keys for both these user IDs with GnuPG? (I don?t think the Python generate scripts do this properly, or do they?) Cheers, -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wk at gnupg.org Tue Jul 16 12:16:02 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Jul 2019 12:16:02 +0200 Subject: WKD: Publishing a key for multiple user IDs In-Reply-To: <20190715160323.GA8423@azadi> ("David =?utf-8?Q?B=C3=BCrgin?= via Gnupg-users"'s message of "Mon, 15 Jul 2019 18:03:23 +0200") References: <20190715160323.GA8423@azadi> Message-ID: <87d0ia5lp9.fsf@wheatstone.g10code.de> On Mon, 15 Jul 2019 18:03, gnupg-users at gnupg.org said: > So if I have two email addresses/user IDs me at my.org and me2 at my.org > associated with the same key, I cannot just export the key and publish > it, right? I have to somehow publish two different ?stripped? public Sight. GnuPG handles this for you if your frontend uses gpg-wks-cleint for this. You can use this tool also to create a local copy of server data structure and then sysc it up. > Is there documentation somewhere how to produce the keys for both these > user IDs with GnuPG? (I don?t think the Python generate scripts do this I don't known about Python scripts. Kmail, GpgOL, and Enigmail do the publishing for you. You can also do it manuallay, see the Wiki. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wiktor at metacode.biz Tue Jul 16 12:34:30 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 16 Jul 2019 12:34:30 +0200 Subject: WKD: Publishing a key for multiple user IDs In-Reply-To: <87d0ia5lp9.fsf@wheatstone.g10code.de> References: <20190715160323.GA8423@azadi> <87d0ia5lp9.fsf@wheatstone.g10code.de> Message-ID: <06fe07ae-a583-7582-5c00-094712b251db@metacode.biz> On 16.07.2019 12:16, Werner Koch via Gnupg-users wrote: >> So if I have two email addresses/user IDs me at my.org and me2 at my.org >> associated with the same key, I cannot just export the key and publish >> it, right? I have to somehow publish two different ?stripped? public > > Sight. GnuPG handles this for you if your frontend uses gpg-wks-cleint > for this. You can use this tool also to create a local copy of server > data structure and then sysc it up. If you've got only gpg installed you can use export filters to prepare a stripped key: $ gpg --export-options export-clean --export-filter keep-uid=mbox=$EMAIL --export $EMAIL Hope this helps. Kind regards, Wiktor -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From dbuergin at gluet.ch Tue Jul 16 08:41:11 2019 From: dbuergin at gluet.ch (=?UTF-8?Q?David_B=c3=bcrgin?=) Date: Tue, 16 Jul 2019 08:41:11 +0200 Subject: WKD: Publishing a key for multiple user IDs In-Reply-To: <20190716062325.3thypxqnscvmj3fv@lyta> References: <20190715160323.GA8423@azadi> <20190716062325.3thypxqnscvmj3fv@lyta> Message-ID: <2bea1306-f943-afd0-5a98-796088f490db@gluet.ch> On 16/07/2019 08:23, Wolfgang Traylor wrote: > Try the gpg-wks-client command. It should try to automatically strip the user IDs. Werner Koch explained that in an old post: > https://lists.gnupg.org/pipermail/gnupg-users/2019-February/061610.html > > Since my primary secret key is offline and I access it with the live system Tails, the gpg-wks-client does not work for me. > Instead I used the following commands in the Linux command line on Tails: > > Export secret & public keys (including the primary key) into "primary_key.asc". > > ``` > # Work in a temporary directory, with a blank keyring. > mkdir /tmp/gnupg_posteo > gpg --homedir "/tmp/gnupg_posteo" --import primary_key.asc > gpg --homedir "/tmp/gnupg_posteo" --edit-key > > # Create new user ID with empty name and only the posteo address. > # To add a comment like "WKD" or such is allowed. > gpg> adduid > > # Delete all other user IDs. > gpg> uid 1 > gpg> uid 2 > gpg> deluid > > # Save changes. > gpg> save > > # Export the public key without any third-party signatures. > gpg --homedir "/tmp/gnupg_posteo" --export-options="export-minimal" --armor --export > key_for_posteo.asc > ``` This is very helpful, thank you Wolfgang! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From dbuergin at gluet.ch Tue Jul 16 13:14:18 2019 From: dbuergin at gluet.ch (David =?utf-8?Q?B=C3=BCrgin?=) Date: Tue, 16 Jul 2019 13:14:18 +0200 Subject: WKD: Publishing a key for multiple user IDs In-Reply-To: <87d0ia5lp9.fsf@wheatstone.g10code.de> References: <20190715160323.GA8423@azadi> <87d0ia5lp9.fsf@wheatstone.g10code.de> Message-ID: <20190716111418.GA5377@azadi> Thanks everybody. > > Is there documentation somewhere how to produce the keys for both these > > user IDs with GnuPG? (I don?t think the Python generate scripts do this > > I don't known about Python scripts. Kmail, GpgOL, and Enigmail do the > publishing for you. You can also do it manuallay, see the Wiki. Exactly ? I was referring to the Python scripts in the wiki: https://wiki.gnupg.org/WKDHosting -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gnupgpacker at on.yourweb.de Tue Jul 16 17:18:07 2019 From: gnupgpacker at on.yourweb.de (gnupgpacker) Date: Tue, 16 Jul 2019 17:18:07 +0200 Subject: WKD auto-key-retrieve method Message-ID: <000a01d53be9$abc4ae30$034e0a90$@on.yourweb.de> > -----Original Message----- > I think you should add "--sender email at address" option so that your > signatures have information for WKD auto-key-retrieve method (and also > for TOFU statistics). > > It is probably mail user agent's job to add "--sender" but maybe it is > also fine to have that in gpg.conf file. Hello, how to put "--sender email at address" to gpg.conf file if using several different email addresses from sender? Is it possible to put "--sender" option to public key itself? Thanks + regards, Chris From kelvin_1987 at live.com Tue Jul 16 16:16:20 2019 From: kelvin_1987 at live.com (Kelvin Sutjipto) Date: Tue, 16 Jul 2019 14:16:20 +0000 Subject: Cannot Verify Signature Message-ID: Hi Users, I've received the recent GnuPG 2.2.17 release along with the attached signature. _*Issue:*_**Signature cannot be verified despite having downloaded the public key that created the signature (0x80615870F5BAD690333686D0F2AD85AC1E42B367) - see screenshot attached. Would anyone have an idea as to why this is the case (other than the possibility that the signed message could've been tampered with)? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXSSvrwAKCRD/gK6dHew1 jVNwAQCy6FrgqR99YIjCEeNbO9BFh8GBRny2MY7T6hNxuZ5EIwEA9H/LOO43+kIo kmrpMT0mYTWqE9j6o5j2kbuDCUkLIg8= =KPXQ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 573809 bytes Desc: not available URL: -------------- next part -------------- From: Kelvin Sutjipto Sent: Monday, July 15, 2019 9:32 PM To: Werner Koch Subject: Re: [Announce] GnuPG 2.2.17 released to mitigate attacks on keyservers Attachments: 1e42b367.asc; Screenshot.png Categories: GpgOL: Level 4 trust in 'kelvin_1987 at live.com' Hi Werner, The provided key still resulted in an unverified email message (please see screenshot). Any ideas why I can't verify your signature with the key you provided? Thanks, Kelvin On 7/15/2019 12:23 PM, Werner Koch wrote: > On Sat, 13 Jul 2019 09:16, kelvin_1987 at live.com said: > >> Would you mind sending me your public key? I'm trying to download your key: >> >> 0xD7FFC063B40A2294B966DB47FF80AE9D1DEC358D > See attachment. > > > Shalom-Salam, > > Werner > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ryan at digicana.com Wed Jul 17 05:28:03 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Wed, 17 Jul 2019 03:28:03 +0000 Subject: Essay on PGP as it is used today Message-ID: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> More than a bit critical, but a good read all the same. ?Found on HN.? https://latacora.micro.blog/2019/07/16/the-pgp-problem.html HN comment thread here: ?https://news.ycombinator.com/item?id=20455780 -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Jul 17 06:05:01 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 17 Jul 2019 00:05:01 -0400 Subject: Essay on PGP as it is used today In-Reply-To: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> Message-ID: > More than a bit critical, but a good read all the same. ?Found on HN. Although I largely share in the criticisms, I think the author made a couple of serious mistakes. First, RFC4880bis06 (the latest version) does a pretty good job of bringing the crypto angle to a more modern level. There's a massive installed base of clients that aren't aware of bis06, and if you have to interoperate with them you're kind of screwed: but there's also absolutely nothing prohibiting you from saying "I'm going to only implement a subset of bis06, the good modern subset, and if you need older stuff then I'm just not going to comply." Sequoia is more or less taking this route -- more power to them. Second, the author makes a couple of mistakes about the default ciphers. GnuPG has defaulted to AES for many years now: CAST5 is supported for legacy reasons (and I'd like to see it dropped entirely: see above, etc.). Third, a couple of times the author conflates what the OpenPGP spec requires with what it permits, and with how GnuPG implements it. Cleaner delineation would've made the criticisms better, I think. But all in all? It's a good criticism. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Jul 17 08:52:35 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 17 Jul 2019 07:52:35 +0100 Subject: Essay on PGP as it is used today In-Reply-To: References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> Message-ID: On 17 Jul 2019, at 05:05, Robert J. Hansen wrote: > But all in all? It's a good criticism. Indeed. Backwards compatibility with the 1990s is an albatross. Anyone still using obsolete ciphers is screwed anyway, so why encourage it? Some nitpicking: * Modern PGP does encrypt subjects (although not other metadata). * Magic wormhole is an excellent toy, but it?s written in python, so literally the *first person* I tested it with got his dependency stack shredded. I think he?s forgiven me but he hasn?t used it since. The line about rewriting wormhole in a decent language may look throwaway but it?s not. * Similarly, the alternative archiving software suggested is still a work in progress. It?s all very well criticising PGP for being a clumsy jack of all trades, but ?modern crypto? has had twenty years to replace it and still hasn?t fully succeeded. This isn?t just on PGP. * And finally: ?don?t encrypt email?? Yes, well. Email is not going away. Just like passwords, its death has been long anticipated, yet never arrives. So what do we do in the meantime? But yes. A From wk at gnupg.org Wed Jul 17 12:33:52 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jul 2019 12:33:52 +0200 Subject: WKD auto-key-retrieve method In-Reply-To: <000a01d53be9$abc4ae30$034e0a90$@on.yourweb.de> (gnupgpacker's message of "Tue, 16 Jul 2019 17:18:07 +0200") References: <000a01d53be9$abc4ae30$034e0a90$@on.yourweb.de> Message-ID: <87muhd3q7j.fsf@wheatstone.g10code.de> On Tue, 16 Jul 2019 17:18, gnupgpacker at on.yourweb.de said: > how to put "--sender email at address" to gpg.conf file if using several > different email addresses from sender? You can't it is the task of the MUA (cf. gpgme_set_sender). > Is it possible to put "--sender" option to public key itself? No. But the same effect can be achieved by specifying the sender via a mail address. Anywa, I would stuggest to use --sender or better gpgme_set_sender. The latter is a 3 liner for most MUAs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mkesper at schokokeks.org Wed Jul 17 15:31:54 2019 From: mkesper at schokokeks.org (Michael Kesper) Date: Wed, 17 Jul 2019 15:31:54 +0200 Subject: wrong gpg-agent version running? In-Reply-To: <87wogowpnp.fsf@iki.fi> References: <4b0999ae-d690-d0b1-d512-b49d3c45a0a0@gmail.com> <87a7dky9hr.fsf@iki.fi> <6d776359-2048-0d2f-ce5b-4675f4c33557@schokokeks.org> <871rywy5ae.fsf@iki.fi> <87wogowpnp.fsf@iki.fi> Message-ID: <0b97340e-bb68-f052-5985-0430e4dcbf61@schokokeks.org> Hi Teemu, On 11.07.19 17:34, Teemu Likonen wrote: > Michael Kesper [2019-07-11T17:15:19+02] wrote: > >> I'd consider it a bug if updating a package does not trigger reloading >> all necessary services. > > We have not been discussing about Debian package upgrade. This message > thread is about additional local installation (/usr/local) which is > outside of Debian's package system. Oh, obviously! Sorry, did not see that. Bye Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Wed Jul 17 20:46:47 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 17 Jul 2019 20:46:47 +0200 Subject: Essay on PGP as it is used today In-Reply-To: References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> Message-ID: <20190717204647.00006dfe.sac@300baud.de> Andrew Gallagher wrote: > * And finally: ?don?t encrypt email?? Yes, well. Email is not going away. > Just like passwords, its death has been long anticipated, yet never arrives. > So what do we do in the meantime? I think the biggest problems is how can PGP or GnuPG users tell other users, not familar with email encyrption yet, what else to use ... PGP / GnuPG users are pretty biased IMHO when it comes to email encryption and probably don't accept other and more modern solutions, which they could recommend. All those recent or older articles speak about non-email solutions. I for myself solved that problem with friends and now look for an additional solution to create offline S/MIME compatible messages, which then can easily been read by various MUAS. If someone has an idea I am all ears. I don't care about Efail, because I have not heard in practice that Mallory attacked already lot's of S/MIME users. Regards Stefan From ryan at digicana.com Wed Jul 17 21:24:15 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Wed, 17 Jul 2019 19:24:15 +0000 Subject: Essay on PGP as it is used today In-Reply-To: References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> Message-ID: > - And finally: ?don?t encrypt email?? Yes, well. Email is not going away. Just like passwords, its death has been long anticipated, yet never arrives. So what do we do in the meantime? I think what the author is saying is stop trying to ever think of email as a secure form of communications, no matter what you layer on top of it, full stop. Which given how email encrpytion options have performed over the past couple decades, makes sense to me. You might say that PGP over email is better than nothing over email, but is it? If you expect a non-secure channel and don't disclose secure information, that's one thing -- but if you expect a secure channel and send private information and through user error or clunky software implementation you end up sending cleartext, you're worse off than if you'd just assumed a non-secure channel. Email has a habit of having this happen. It's actually quite easy to mess up and send cleartext. IF there were no other options, then maybe it'd be worth rolling the dice. But there are quite a few extremely capable free solutions out there that will establish a secure channel of communications with relative ease. Frankly, the only way you'll ever get secure comms over email is if the big boys (Microsoft, the Goog, and to a lesser extent Yahoo and grandpa^H^H^H^H^H^H^H AOL decice to shake hands and come up with a standard and force it down all other provider's throat. Either that or roll their own secure (though not E2E since it relies on TLS) modes like Outlook 365 and Google/GSuite do and give users an option to send messages that force TLS by making the recepient go to a https email viewing page if you access the message from any outside provider. -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail ??????? Original Message ??????? On Wednesday, July 17, 2019 1:52 AM, Andrew Gallagher wrote: > On 17 Jul 2019, at 05:05, Robert J. Hansen rjh at sixdemonbag.org wrote: > > > But all in all? It's a good criticism. > > Indeed. Backwards compatibility with the 1990s is an albatross. Anyone still using obsolete ciphers is screwed anyway, so why encourage it? > > Some nitpicking: > > - Modern PGP does encrypt subjects (although not other metadata). > - Magic wormhole is an excellent toy, but it?s written in python, so literally the first person I tested it with got his dependency stack shredded. I think he?s forgiven me but he hasn?t used it since. The line about rewriting wormhole in a decent language may look throwaway but it?s not. > - Similarly, the alternative archiving software suggested is still a work in progress. It?s all very well criticising PGP for being a clumsy jack of all trades, but ?modern crypto? has had twenty years to replace it and still hasn?t fully succeeded. This isn?t just on PGP. > - And finally: ?don?t encrypt email?? Yes, well. Email is not going away. Just like passwords, its death has been long anticipated, yet never arrives. So what do we do in the meantime? > > But yes. > > A > > > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From ilf at zeromail.org Wed Jul 17 23:41:35 2019 From: ilf at zeromail.org (ilf) Date: Wed, 17 Jul 2019 23:41:35 +0200 Subject: I deleted 80 % of my keyring, but my keybox file isn't shrinking Message-ID: <20190717214135.GH1091@zeromail.org> Over the years, my keyring grew and got rather big. So I did some cleaning and deleted some revoked and otherwise useless certificates. (If you wonder how, see this script - feedback welcome: https://github.com/ilf/gpg-maintenance/blob/master/gpg-delete-revoked-keys.sh) This got my keyring down from 4.600 to 1.000 keys: > % kbxutil --stats ~/.gnupg.bak/pubring.kbx | grep -e "Total" -e "openpgp" > Total number of blobs: 4656 > openpgp: 4617 > % kbxutil --stats ~/.gnupg/pubring.kbx | grep -e "Total" -e "openpgp" > Total number of blobs: 1041 > openpgp: 1002 But the keybox file didn't get any smaller: > % du -h ~/.gnupg/pubring.kbx ~/.gnupg.bak/pubring.kbx > 99M ~/.gnupg/pubring.kbx > 99M ~/.gnupg.bak/pubring.kbx Why is this? I really don't understand keybox well enough to answer this myself. Thanks! PS: This could probably be updated: > Well, OpenPGP keys are not implemented, gpg still used the keyring > file pubring.gpg. https://www.gnupg.org/documentation/manuals/gnupg/kbxutil.html -- ilf If you upload your address book to "the cloud", I don't want to be in it. From gnupg at raf.org Thu Jul 18 04:13:33 2019 From: gnupg at raf.org (raf) Date: Thu, 18 Jul 2019 12:13:33 +1000 Subject: Essay on PGP as it is used today In-Reply-To: <20190717204647.00006dfe.sac@300baud.de> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190717204647.00006dfe.sac@300baud.de> Message-ID: <20190718021333.bj6iankdv4covvzv@raf.org> Stefan Claas via Gnupg-users wrote: > Andrew Gallagher wrote: > > > * And finally: ?don?t encrypt email?? Yes, well. Email is not going away. > > Just like passwords, its death has been long anticipated, yet never arrives. > > So what do we do in the meantime? > > I think the biggest problems is how can PGP or GnuPG users tell other users, > not familar with email encyrption yet, what else to use ... At work, when a client insists on email, and I (or the law) insist on encryption, I provide them with instructions for installing 7-zip and send them an AES-256 encrypted zip or 7z file as an attachment. It's the simplest thing I could think of that I thought most people could cope with. From ryan at digicana.com Thu Jul 18 04:47:33 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Thu, 18 Jul 2019 02:47:33 +0000 Subject: Essay on PGP as it is used today In-Reply-To: <20190718021333.bj6iankdv4covvzv@raf.org> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190717204647.00006dfe.sac@300baud.de> <20190718021333.bj6iankdv4covvzv@raf.org> Message-ID: Is that to send them a message or an attachment? You might look into Firefox Send -- not sure if this satisfies the legal requirements, but it is very robust end to end encryption. https://send.firefox.com/ -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail ??????? Original Message ??????? On Wednesday, July 17, 2019 9:13 PM, raf via Gnupg-users wrote: > Stefan Claas via Gnupg-users wrote: > > > Andrew Gallagher wrote: > > > > > - And finally: ?don?t encrypt email?? Yes, well. Email is not going away. > > > Just like passwords, its death has been long anticipated, yet never arrives. > > > So what do we do in the meantime? > > > > > > > I think the biggest problems is how can PGP or GnuPG users tell other users, > > not familar with email encyrption yet, what else to use ... > > At work, when a client insists on email, and I (or the law) > insist on encryption, I provide them with instructions for > installing 7-zip and send them an AES-256 encrypted zip or 7z > file as an attachment. It's the simplest thing I could think > of that I thought most people could cope with. > > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From mirimir at riseup.net Thu Jul 18 06:40:59 2019 From: mirimir at riseup.net (Mirimir) Date: Wed, 17 Jul 2019 21:40:59 -0700 Subject: Essay on PGP as it is used today In-Reply-To: References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190717204647.00006dfe.sac@300baud.de> <20190718021333.bj6iankdv4covvzv@raf.org> Message-ID: On 07/17/2019 07:47 PM, Ryan McGinnis via Gnupg-users wrote: > Is that to send them a message or an attachment? > > You might look into Firefox Send -- not sure if this satisfies the legal requirements, but it is very robust end to end encryption. https://send.firefox.com/ I also like Firefox Send. But being suspicious, I typically encrypt with GnuPG first. When I need to share stuff among GUI-less VPS, with no Javascript capable browser, I sometimes use pastebins. I encrypt with GnuPG, and then base64 encode. > -Ryan McGinnis > https://bigstormpicture.com > PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD > Sent with ProtonMail > > ??????? Original Message ??????? > On Wednesday, July 17, 2019 9:13 PM, raf via Gnupg-users wrote: > >> Stefan Claas via Gnupg-users wrote: >> > >>> Andrew Gallagher wrote: >>> > >>>> - And finally: ?don?t encrypt email?? Yes, well. Email is not going away. >>>> Just like passwords, its death has been long anticipated, yet never arrives. >>>> So what do we do in the meantime? >>>> > >>> > >>> I think the biggest problems is how can PGP or GnuPG users tell other users, >>> not familar with email encyrption yet, what else to use ... >> > >> At work, when a client insists on email, and I (or the law) >> insist on encryption, I provide them with instructions for >> installing 7-zip and send them an AES-256 encrypted zip or 7z >> file as an attachment. It's the simplest thing I could think >> of that I thought most people could cope with. >> > >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From ilf at zeromail.org Thu Jul 18 12:19:55 2019 From: ilf at zeromail.org (ilf) Date: Thu, 18 Jul 2019 12:19:55 +0200 Subject: I deleted 80 % of my keyring, but my keybox file isn't shrinking In-Reply-To: <20190717214135.GH1091@zeromail.org> References: <20190717214135.GH1091@zeromail.org> Message-ID: <20190718101955.GO1091@zeromail.org> Same on a different box with a different keyring. I trimmed it down from ~1250 keys to ~350 keys, but the size of pubring.kbx remains 19M. Does --delete really mean *delete* with keybox? ilf: > This got my keyring down from 4.600 to 1.000 keys: > But the keybox file didn't get any smaller: -- ilf If you upload your address book to "the cloud", I don't want to be in it. From mkesper at schokokeks.org Thu Jul 18 13:04:36 2019 From: mkesper at schokokeks.org (Michael Kesper) Date: Thu, 18 Jul 2019 13:04:36 +0200 Subject: I deleted 80 % of my keyring, but my keybox file isn't shrinking In-Reply-To: <20190718101955.GO1091@zeromail.org> References: <20190717214135.GH1091@zeromail.org> <20190718101955.GO1091@zeromail.org> Message-ID: <931317ce-cc83-e9d0-93ba-3e60c93b3e40@schokokeks.org> Hi all, On 18.07.19 12:19, ilf wrote: > Same on a different box with a different keyring. I trimmed it down from ~1250 keys to ~350 keys, but the size of pubring.kbx remains 19M. > > Does --delete really mean *delete* with keybox? > > ilf: >> This got my keyring down from 4.600 to 1.000 keys: >> But the keybox file didn't get any smaller: You might try exporting your keys and importing them into a completely new pubring. Best Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From ullbeking at andrewnesbit.org Thu Jul 18 13:21:46 2019 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Thu, 18 Jul 2019 12:21:46 +0100 Subject: Essay on PGP as it is used today In-Reply-To: References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190717204647.00006dfe.sac@300baud.de> <20190718021333.bj6iankdv4covvzv@raf.org> Message-ID: <9ce688de-20cd-42d7-9c95-e5a6e006008e@andrewnesbit.org> On 18/07/2019 05:40, Mirimir via Gnupg-users wrote: > When I need to share stuff among GUI-less VPS, with no Javascript > capable browser, I sometimes use pastebins. I encrypt with GnuPG, and > then base64 encode. I love pastebins. I think they are an excellent "first serious web app" type of application. In fact, I've been collecting a list of all (mostly open source) paste bins that I can find, and their implementations. If anybody knows any pastebins of the tops of their heads, please could you send them to me, off-list if you prefer. When the list goes online I will credit anybody who contributed (unless they don't want me to). Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From mirimir at riseup.net Thu Jul 18 14:00:01 2019 From: mirimir at riseup.net (Mirimir) Date: Thu, 18 Jul 2019 05:00:01 -0700 Subject: Essay on PGP as it is used today In-Reply-To: <9ce688de-20cd-42d7-9c95-e5a6e006008e@andrewnesbit.org> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190717204647.00006dfe.sac@300baud.de> <20190718021333.bj6iankdv4covvzv@raf.org> <9ce688de-20cd-42d7-9c95-e5a6e006008e@andrewnesbit.org> Message-ID: <3d767752-4021-4e08-f860-548a938841c0@riseup.net> On 07/18/2019 04:21 AM, U'll Be King of the Stars wrote: > On 18/07/2019 05:40, Mirimir via Gnupg-users wrote: >> When I need to share stuff among GUI-less VPS, with no Javascript >> capable browser, I sometimes use pastebins. I encrypt with GnuPG, and >> then base64 encode. > > I love pastebins.? I think they are an excellent "first serious web app" > type of application. > > In fact, I've been collecting a list of all (mostly open source) paste > bins that I can find, and their implementations. > > If anybody knows any pastebins of the tops of their heads, please could > you send them to me, off-list if you prefer.? When the list goes online > I will credit anybody who contributed (unless they don't want me to). > > Andrew I presume that you know ZeroBin.[0] There's at least one Tor onion implementation.[1] I just got that via DDG, and haven't verified any of the onion URLs. 0) https://github.com/sebsauvage/ZeroBin is 1) https://deepweblinks.net/pastebin/ From wk at gnupg.org Thu Jul 18 14:08:42 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Jul 2019 14:08:42 +0200 Subject: I deleted 80 % of my keyring, but my keybox file isn't shrinking In-Reply-To: <20190717214135.GH1091@zeromail.org> (ilf's message of "Wed, 17 Jul 2019 23:41:35 +0200") References: <20190717214135.GH1091@zeromail.org> Message-ID: <875znz35px.fsf@wheatstone.g10code.de> On Wed, 17 Jul 2019 23:41, ilf at zeromail.org said: > But the keybox file didn't get any smaller: Good catch. In gpg we have not implenteted the compression run: /* FIXME: Do a compress run if needed and no other user is currently using the keybox. */ However, in gpgsm this is done. It does not work immediately but is run only on gpgsm invocation iff there has been np update operaion in the last 3 hours. Thus to force a compression run you can do: faketime -f +3 gpgsm -k foo >/dev/null Note that gpgsm's option --faked-system-time does not work here ( I pushed a fix, though). > PS: This could probably be updated: > >> Well, OpenPGP keys are not implemented, gpg still used the keyring >> file pubring.gpg. Will do. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Thu Jul 18 19:35:52 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 18 Jul 2019 18:35:52 +0100 Subject: [Sks-devel] Fwd [from schleuder dev team]: Signature-flooded keys: current situation and mitigation In-Reply-To: References: <20190717200658.GD19488@debian> Message-ID: <8E387C7E-BEB4-465D-931B-DAA6DA19E3D2@andrewg.com> > On 18 Jul 2019, at 17:46, Todd Fleisher wrote: > > "Unfortunately, there is currently no > good way to distribute revocations that doesn't also reveal the revoked > identity itself. We don't want to distribute revoked identities, so we can't > distribute the identity at all." We can kill two birds with one stone here, using two simple extensions-by-convention of the protocol. A key owner can (preferably automatically) create a ?self-identity? on her primary key consisting of a well-known string that contains no personal information. To avoid breaking legacy search-by-id systems this string should be unique to the primary key. I suggest using ?fpr:00000000000000000000000000000000000?, where the zeros are replaced by the fingerprint of the key. The self-identity (and any revocations on it) can then be safely distributed by keystores that would otherwise refuse to distribute personal info. A recipient can then infer from revocation of the self-identity that the primary key itself has been revoked (and by extension all associated identities, whether published or not). A From thomas.orgis at uni-hamburg.de Thu Jul 18 18:33:41 2019 From: thomas.orgis at uni-hamburg.de (Dr. Thomas Orgis) Date: Thu, 18 Jul 2019 18:33:41 +0200 Subject: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm Message-ID: <20190718183341.46b5b7a4@cortex.rrz.uni-hamburg.de> Hi, I'm trying to switch to my third S/MIME cert after two earlier expired ones in gpgsm. The private key and the certificate are valid into the year 2022, but gpgsm (version 2.2.15) tells me this: shell$ LANG=C gpgsm --sign -u 0x310C60AF [?] gpgsm: certificate is good gpgsm: intermediate certificate is good gpgsm: intermediate certificate is good gpgsm: intermediate certificate has expired gpgsm: (expired at 2019-07-09 23:59:59) gpgsm: root certificate is good gpgsm: DBG: chan_4 -> ISTRUSTED 85A408C09C193E5D51587DCDD61330FD8CDE37BF gpgsm: DBG: chan_4 <- OK gpgsm: root certificate has expired gpgsm: (expired at 2019-07-09 23:59:00) gpgsm: policies not checked due to --disable-policy-checks option gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: validation model used: shell gpgsm: can't sign using '0x310C60AF': Certificate expired secmem usage: 0/16384 bytes in 0 blocks It thinks my fresh certificate is expired. Looking at the certificate chain, there is some weirdness (some lines trimmed): ID: 0x310C60AF Issuer: /CN=DFN-Verein Global Issuing CA/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE Subject: /CN=Thomas Orgis/OU=HPC/OU=Basis-Infrastruktur/OU=RRZ/O=Universitaet Hamburg/L=Hamburg/ST=Hamburg/C=DE validity: 2019-07-05 08:22:41 through 2022-07-04 08:22:41 Certified by ID: 0xD9463C45 Issuer: /CN=DFN-Verein Certification Authority 2/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE Subject: /CN=DFN-Verein Global Issuing CA/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE validity: 2016-05-24 11:38:40 through 2031-02-22 23:59:59 Certified by ID: 0xD3A89A93 Issuer: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust Center/O=T-Systems Enterprise Services GmbH/C=DE Subject: /CN=DFN-Verein Certification Authority 2/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE validity: 2016-02-22 13:38:22 through 2031-02-22 23:59:59 chain length: 2 Certified by ID: 0x61A8CF44 Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust Center/O=Deutsche Telekom AG/C=DE Subject: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust Center/O=T-Systems Enterprise Services GmbH/C=DE validity: 2016-04-25 09:01:39 through 2019-07-09 23:59:59 chain length: unlimited Certified by ID: 0x8CDE37BF Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust Center/O=Deutsche Telekom AG/C=DE Subject: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust Center/O=Deutsche Telekom AG/C=DE validity: 1999-07-09 12:11:00 through 2019-07-09 23:59:00 chain length: 5 Instead of ending with the correct root cert named T-TeleSec GlobalRoot Class 2, there is some cross-signing with the expired Telekom certificates. These signatures themselves look bogus. Colleagues using the same sort of certificates do not have this issue. It seems I am the only one using the GnuPG S/MIME implementation (with Claws Mail) and people give me stange looks as a weirdo among weirdos (normal weirdos use Thunderbird with it's builtin S/MIME or mutt, both of which seem to work fine here). Looking at the source of the key and certs: I got a pkcs12 file exported from Firefox (that I just `gpgsm --import`ed), and a conversion of that via openssl shows these contained signatures: $ grep -e subject -e issuer mycert3.pem subject=C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA issuer=C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2 subject=C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2 issuer=C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 subject=C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 issuer=C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 subject=C = DE, ST = Hamburg, L = Hamburg, O = Universitaet Hamburg, OU = RRZ, OU = Basis-Infrastruktur, OU = HPC, CN = Thomas Orgis issuer=C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA So, you see the chain 4. Thomas Orgis (me) signed by DFN-Verein Global Issuing CA 3. DFN-Verein Global Issuing CA signed by DFN-Verein Certification Authority 2 2. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2 1. T-TeleSec GlobalRoot Class 2 signed by T-TeleSec GlobalRoot Class 2 (root) Compared to what gpgsm sees: 4. Thomas Orgis (me) signed by DFN-Verein Global Issuing CA 3. DFN-Verein Global Issuing CA signed by DFN-Verein Certification Authority 2 2. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2 1. T-TeleSec GlobalRoot Class 2 signed by Deutsche Telekom Root CA 2 0. Deutsche Telekom Root CA 2 signed by Deutsche Telekom Root CA 2 (expired root) How come? I tried to forcedly import the new root cert into gpgsm, but it tells me it has it stored already. shell$ LANG=C gpgsm --import rootcert2019.crt gpgsm: enabled debug flags: ipc gpgsm: total number processed: 1 gpgsm: unchanged: 1 secmem usage: 0/16384 bytes in 0 blocks So it looks to me as if gpgsm somehow constructs a wrong certificate chain. Is this a known problem? Did I do something wrong? Regards, Thomas -- Dr. Thomas Orgis HPC @ Universit?t Hamburg From ilf at zeromail.org Thu Jul 18 21:35:03 2019 From: ilf at zeromail.org (ilf) Date: Thu, 18 Jul 2019 21:35:03 +0200 Subject: I deleted 80 % of my keyring, but my keybox file isn't shrinking In-Reply-To: <875znz35px.fsf@wheatstone.g10code.de> References: <20190717214135.GH1091@zeromail.org> <875znz35px.fsf@wheatstone.g10code.de> Message-ID: <20190718193503.GQ1091@zeromail.org> Thanks, that explains it. And the faketime gpgsm command worked (after installing faketime). But that's a hack, and users should not have to do this. Especially since GnuPG 2.1 defauls to keybox and more people recommend it with of the recent flooding issues. I opened an issue to track this: https://dev.gnupg.org/T4644 Werner Koch: > Good catch. In gpg we have not implenteted the compression run: > faketime -f +3 gpgsm -k foo >/dev/null -- ilf If you upload your address book to "the cloud", I don't want to be in it. From sac at 300baud.de Thu Jul 18 22:07:33 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 18 Jul 2019 22:07:33 +0200 Subject: Essay on PGP as it is used today In-Reply-To: <20190718021333.bj6iankdv4covvzv@raf.org> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190717204647.00006dfe.sac@300baud.de> <20190718021333.bj6iankdv4covvzv@raf.org> Message-ID: <20190718220733.00002550.sac@300baud.de> raf via Gnupg-users wrote: > Stefan Claas via Gnupg-users wrote: > > > Andrew Gallagher wrote: > > > > > * And finally: ?don?t encrypt email?? Yes, well. Email is not going away. > > > Just like passwords, its death has been long anticipated, yet never > > > arrives. So what do we do in the meantime? > > > > I think the biggest problems is how can PGP or GnuPG users tell other users, > > not familar with email encyrption yet, what else to use ... > > At work, when a client insists on email, and I (or the law) > insist on encryption, I provide them with instructions for > installing 7-zip and send them an AES-256 encrypted zip or 7z > file as an attachment. It's the simplest thing I could think > of that I thought most people could cope with. That is simple, indeed. But how do you exchange passphrases for the encrypted files in advance and do you switch them regularly or leave them the same when dealing with many clients? I solved this with using NaCl public keys, bearing no infos of the key owners and having a little key ring, where I only assign nicknames to the pub keys. The software I use is box https://github.com/rovaughn/box in combination with a base91 encoder / decoder, for ASCII armor, when sending encrypted emails. Before that I also experimented with other tools, like dhbitty, MiniLock and Pretty Curved Privacy etc. but for me they all had some disadvantages compared to box. Regards Stefan From wiktor at metacode.biz Fri Jul 19 12:34:13 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 19 Jul 2019 12:34:13 +0200 Subject: [Sks-devel] Fwd [from schleuder dev team]: Signature-flooded keys: current situation and mitigation In-Reply-To: <8E387C7E-BEB4-465D-931B-DAA6DA19E3D2@andrewg.com> References: <20190717200658.GD19488@debian> <8E387C7E-BEB4-465D-931B-DAA6DA19E3D2@andrewg.com> Message-ID: Hi Andrew, On 18.07.2019 19:35, Andrew Gallagher wrote: > A key owner can (preferably automatically) create a ?self-identity? on her primary key consisting of a well-known string that contains no personal information. To avoid breaking legacy search-by-id systems this string should be unique to the primary key. I suggest using ?fpr:00000000000000000000000000000000000?, where the zeros are replaced by the fingerprint of the key. The self-identity (and any revocations on it) can then be safely distributed by keystores that would otherwise refuse to distribute personal info. Minor thing: I suggest using "openpgp4fpr:00000000000000000000000000000000000" instead of "fpr". That'd make the User ID a valid URI as "openpgp4fpr" is an assigned URI Scheme, see: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml Probably the cleanest solution (suggested by others) would be using direct key signature (0x1F) [0] and avoid User IDs entirely. Your suggestion Andrew has the benefit that it's immediately backwards compatible with software "in the wild". [0]: https://tools.ietf.org/html/rfc4880#section-5.2.1 Kind regards, Wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From angel at pgp.16bits.net Sat Jul 20 00:06:24 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sat, 20 Jul 2019 00:06:24 +0200 Subject: Essay on PGP as it is used today In-Reply-To: <20190718021333.bj6iankdv4covvzv@raf.org> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190717204647.00006dfe.sac@300baud.de> <20190718021333.bj6iankdv4covvzv@raf.org> Message-ID: <1563573984.1282.29.camel@16bits.net> On 2019-07-18 at 12:13 +1000, raf wrote: > At work, when a client insists on email, and I (or the law) > insist on encryption, I provide them with instructions for > installing 7-zip and send them an AES-256 encrypted zip or 7z > file as an attachment. It's the simplest thing I could think > of that I thought most people could cope with. Encrypted zip files have several factors that make it a beautiful solution for sending encrypted messages to occasional users that don't care much about it: a) zip is a file format supported out-of-the-box by pretty much every system, and that users are comfortable with. Whereas you would be seen as a weirdo if you sent them a .gpg or other new file that needed a special program, you would likely be asked to just sent it "normally" (ie. unencrypted). b) The format itself supports secure encryption (aes128/256). c) If their client doesn't support AES-Encryption, their client will show that *their program* can't cope with it. This places the onus on the receiver (their zip decompresser isn't "new enough"), rather than the sender (see a). Nevertheless, it has a number of potential problems: * As pointed out by Stefan Claas, you need to exchange the encryption keys. The zip file is just an encryption primitive, so key distribution may become a problem. (raf, may I ask how you are dealing with it? As they are clients, are you providing a set of keys in advance when personally visiting them? Are you providing the key for the new message?) * 7-Zip before 19.00 use a bad PRNG to fill a half-size IV https://threadreaderapp.com/thread/1087848040583626753.html * A naive user trying to reply would easily end up using PKWARE encryption (and reusing the password) Kind regards From dirk.gottschalk1980 at googlemail.com Sat Jul 20 11:01:49 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sat, 20 Jul 2019 11:01:49 +0200 Subject: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm In-Reply-To: <20190718183341.46b5b7a4@cortex.rrz.uni-hamburg.de> References: <20190718183341.46b5b7a4@cortex.rrz.uni-hamburg.de> Message-ID: <1a62fe5742d096d35d4ef5d6b8a7722b3fb43e44.camel@googlemail.com> Hello. Am Donnerstag, den 18.07.2019, 18:33 +0200 schrieb Dr. Thomas Orgis: > Certified by > ID: 0x61A8CF44 > Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust > Center/O=Deutsche Telekom AG/C=DE > Subject: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust > Center/O=T-Systems Enterprise Services GmbH/C=DE > validity: 2016-04-25 09:01:39 through 2019-07-09 23:59:59 > chain length: unlimited > Certified by > ID: 0x8CDE37BF > Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust > Center/O=Deutsche Telekom AG/C=DE > Subject: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust > Center/O=Deutsche Telekom AG/C=DE > validity: 1999-07-09 12:11:00 through 2019-07-09 23:59:00 > chain length: 5 This is the issue here. These two certs of DTAG (Telekom) are exired and that's the reason why gpgsm is complaining correctly. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From sac at 300baud.de Sat Jul 20 11:57:20 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 20 Jul 2019 11:57:20 +0200 Subject: --lsign --add-me or the invisible WoT Message-ID: <20190720115720.000020da.sac@300baud.de> Hi all, now since we have Hagrid and WKD I was wondering if in the future an additional paramemter like --add-me for --lsign would make sense, for people still in need of a WoT? The idea would be that people --lsign each others keys and GnuPG, or other public key crypto software, would then save an additional file in the key ring, allowing users to exchange that blob so that only they can see that other people, which belong to their WoT, have lsigend their pub key. Well, just a thought ... Regards Stefan From sac at 300baud.de Sat Jul 20 12:20:29 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 20 Jul 2019 12:20:29 +0200 Subject: --lsign --add-me or the invisible WoT In-Reply-To: <20190720115720.000020da.sac@300baud.de> References: <20190720115720.000020da.sac@300baud.de> Message-ID: <20190720122029.00001e7f.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Hi all, > > now since we have Hagrid and WKD I was wondering if in the future an > additional paramemter like --add-me for --lsign would make sense, for > people still in need of a WoT? > > The idea would be that people --lsign each others keys and GnuPG, > or other public key crypto software, would then save an additional > file in the key ring, allowing users to exchange that blob so that > only they can see that other people, which belong to their WoT, have > lsigend their pub key. > > Well, just a thought ... To be more precise, when exporting a blob it should be something like --export-blob Alice, so that users can individually choose what parts of the blob will be exchanged, so that they do not have to reveal the whole blob, containing all lsigned users. Regards Stefan From persmule at hardenedlinux.org Sat Jul 20 11:58:31 2019 From: persmule at hardenedlinux.org (Persmule) Date: Sat, 20 Jul 2019 09:58:31 +0000 Subject: Secure algorithm extension of RSA and DSA Message-ID: Hi all. Does GnuPG support OAEP for RSA (PKCS#1 v2 and RFC 2437), RSA-PSS (RFC 4056?), or deterministic usage of (EC)DSA (RFC 6979)? And if GnuPG does support RFC 6979, would it also work with (EC)DSA private keys stored on OpenPGP cards which support (EC)DSA algorithms? Best Regards, Persmule -------------- next part -------------- An HTML attachment was scrubbed... URL: From persmule at hardenedlinux.org Sat Jul 20 12:07:41 2019 From: persmule at hardenedlinux.org (Persmule) Date: Sat, 20 Jul 2019 10:07:41 +0000 Subject: About support of RFC 2437, 4056 and 6979 Message-ID: Hi all. Does GnuPG support OAEP for RSA (PKCS#1 v2 and RFC 2437), RSA-PSS (RFC 4056?), or deterministic usage of (EC)DSA (RFC 6979)? And if GnuPG does support RFC 6979, would it also work with (EC)DSA private keys stored on OpenPGP cards which support (EC)DSA algorithms? Best Regards, Persmule From siemons at cleanfuels.nl Sat Jul 20 13:29:21 2019 From: siemons at cleanfuels.nl (Roland) Date: Sat, 20 Jul 2019 13:29:21 +0200 Subject: Upgrading to GnuPG 2.2.17 In-Reply-To: References: Message-ID: Dear Developers, My OS is Linux Mint 19.1 Cinnamon. The automated software manager says that its GNUPG version is "2.2.4-1ubuntu1.2". For a transfer to GnuPG 2.2.17, what do you recommend?: - To wait for the Mint managers to update their repository - To uninstall GNUPG 2.2.4-1ubuntu1.2, and install v. 2.2.17 (However: for v. 2.2.4, software manager says: "cannot remove" !!! How then?) - Something else Please advise. Roland From thomas.orgis at uni-hamburg.de Sat Jul 20 20:07:37 2019 From: thomas.orgis at uni-hamburg.de (Dr. Thomas Orgis) Date: Sat, 20 Jul 2019 20:07:37 +0200 Subject: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm In-Reply-To: <1a62fe5742d096d35d4ef5d6b8a7722b3fb43e44.camel@googlemail.com> References: <20190718183341.46b5b7a4@cortex.rrz.uni-hamburg.de> <1a62fe5742d096d35d4ef5d6b8a7722b3fb43e44.camel@googlemail.com> Message-ID: <20190720200737.6b6f69c4@plasteblaster> Hi, thanks for looking at this ? am Sat, 20 Jul 2019 11:01:49 +0200 schrieb Dirk Gottschalk : > This is the issue here. These two certs of DTAG (Telekom) are exired > and that's the reason why gpgsm is complaining correctly. Please check again my original post, though. The issue I see is that these certs are not even supposed to be in the chain! To repeat the summary, which may be lost in the noise before it: The chain in the imported new key & cert file how it should be: 4. Thomas Orgis (me) signed by DFN-Verein Global Issuing CA 3. DFN-Verein Global Issuing CA signed by DFN-Verein Certification Authority 2 2. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2 1. T-TeleSec GlobalRoot Class 2 signed by T-TeleSec GlobalRoot Class 2 (root) Compared to what gpgsm sees/shows: 4. Thomas Orgis (me) signed by DFN-Verein Global Issuing CA 3. DFN-Verein Global Issuing CA signed by DFN-Verein Certification Authority 2 2. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2 1. T-TeleSec GlobalRoot Class 2 signed by Deutsche Telekom Root CA 2 0. Deutsche Telekom Root CA 2 signed by Deutsche Telekom Root CA 2 (expired root) The bogus signatures by the old Telekom certificates appear only after importing in gpgsm, and colleagues using the same kind of certificates use them without problem in software not relying on gpgsm. So I assume the presence of the old certificates stirs things up. When I create a fresh user and import the new key with its certs into gpgsm, the chain looks like it should. /home/tester/.gnupg/pubring.kbx ------------------------------- ID: 0x310C60AF Issuer: /CN=DFN-Verein Global Issuing CA/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE Subject: /CN=Thomas Orgis/OU=HPC/OU=Basis-Infrastruktur/OU=RRZ/O=Universitaet Hamburg/L=Hamburg/ST=Hamburg/C=DE validity: 2019-07-05 08:22:41 through 2022-07-04 08:22:41 Certified by ID: 0xD9463C45 Issuer: /CN=DFN-Verein Certification Authority 2/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE Subject: /CN=DFN-Verein Global Issuing CA/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE validity: 2016-05-24 11:38:40 through 2031-02-22 23:59:59 chain length: 1 Certified by ID: 0xD3A89A93 Issuer: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust Center/O=T-Systems Enterprise Services GmbH/C=DE Subject: /CN=DFN-Verein Certification Authority 2/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE validity: 2016-02-22 13:38:22 through 2031-02-22 23:59:59 chain length: 2 Certified by ID: 0x17D894E9 Issuer: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust Center/O=T-Systems Enterprise Services GmbH/C=DE Subject: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust Center/O=T-Systems Enterprise Services GmbH/C=DE validity: 2008-10-01 10:40:14 through 2033-10-01 23:59:59 chain length: unlimited So this looks like a corruption in my keyring that includes the history of using gpgsm for about 5 years:-/ I now could play games with exporting keys and starting with a fresh database ? but I'd like to have understood first what happened here. Regards, Thomas -- Dr. Thomas Orgis HPC @ Universit?t Hamburg From sac at 300baud.de Sat Jul 20 20:47:25 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 20 Jul 2019 20:47:25 +0200 Subject: Essay on PGP as it is used today In-Reply-To: <20190718220733.00002550.sac@300baud.de> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190717204647.00006dfe.sac@300baud.de> <20190718021333.bj6iankdv4covvzv@raf.org> <20190718220733.00002550.sac@300baud.de> Message-ID: <20190720204725.00003a1f.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > raf via Gnupg-users wrote: > > > Stefan Claas via Gnupg-users wrote: > > > > > Andrew Gallagher wrote: > > > > > > > * And finally: ?don?t encrypt email?? Yes, well. Email is not going > > > > away. Just like passwords, its death has been long anticipated, yet > > > > never arrives. So what do we do in the meantime? > > > > > > I think the biggest problems is how can PGP or GnuPG users tell other > > > users, not familar with email encyrption yet, what else to use ... > > > > At work, when a client insists on email, and I (or the law) > > insist on encryption, I provide them with instructions for > > installing 7-zip and send them an AES-256 encrypted zip or 7z > > file as an attachment. It's the simplest thing I could think > > of that I thought most people could cope with. > > That is simple, indeed. But how do you exchange passphrases for > the encrypted files in advance and do you switch them regularly > or leave them the same when dealing with many clients? > > I solved this with using NaCl public keys, bearing no infos of > the key owners and having a little key ring, where I only assign > nicknames to the pub keys. The software I use is box > > https://github.com/rovaughn/box Windows users who are interested to try out box can find a GUI based solution, from inwtx, at github. https://github.com/inwtx/NaClBoxEncryption https://github.com/inwtx/NaClBoxEncryption/releases It uses base64 as armor and the armor headers can be set to 'off'. Regards Stefan From angel at pgp.16bits.net Mon Jul 22 00:44:08 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Mon, 22 Jul 2019 00:44:08 +0200 Subject: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm In-Reply-To: <20190720200737.6b6f69c4@plasteblaster> References: <20190718183341.46b5b7a4@cortex.rrz.uni-hamburg.de> <1a62fe5742d096d35d4ef5d6b8a7722b3fb43e44.camel@googlemail.com> <20190720200737.6b6f69c4@plasteblaster> Message-ID: <1563749048.1449.5.camel@16bits.net> On 2019-07-20 at 20:07 +0200, Dr. Thomas Orgis wrote: > The chain in the imported new key & cert file how it should be: > > 4. Thomas Orgis (me) signed by DFN-Verein Global Issuing CA > 3. DFN-Verein Global Issuing CA signed by DFN-Verein Certification Authority 2 > 2. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2 > 1. T-TeleSec GlobalRoot Class 2 signed by T-TeleSec GlobalRoot Class 2 (root) > > Compared to what gpgsm sees/shows: > > 4. Thomas Orgis (me) signed by DFN-Verein Global Issuing CA > 3. DFN-Verein Global Issuing CA signed by DFN-Verein Certification Authority 2 > 2. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2 > 1. T-TeleSec GlobalRoot Class 2 signed by Deutsche Telekom Root CA 2 > 0. Deutsche Telekom Root CA 2 signed by Deutsche Telekom Root CA 2 (expired root) > > (...) > I'd like to have understood first what happened here. Well, it seems that ?T-TeleSec GlobalRoot Class 2? was cross-signed by ?Deutsche Telekom Root CA 2?. This is typically done with new roots so that people with an older set of roots can trust it through an older one. Now, your problem is that the old Root CA expired and your client is not able to find the new trust path. I would probably try deleting the T-TeleSec GlobalRoot Class 2 and reimporting it from the root, to see if that helps. From gnupg at raf.org Mon Jul 22 01:27:08 2019 From: gnupg at raf.org (raf) Date: Mon, 22 Jul 2019 09:27:08 +1000 Subject: Essay on PGP as it is used today In-Reply-To: <20190718220733.00002550.sac@300baud.de> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190717204647.00006dfe.sac@300baud.de> <20190718021333.bj6iankdv4covvzv@raf.org> <20190718220733.00002550.sac@300baud.de> Message-ID: <20190721232708.tj4uyig6wkrtmc7p@raf.org> Stefan Claas wrote: > raf via Gnupg-users wrote: > > > Stefan Claas via Gnupg-users wrote: > > > > > Andrew Gallagher wrote: > > > > > > > * And finally: ?don?t encrypt email?? Yes, well. Email is not going away. > > > > Just like passwords, its death has been long anticipated, yet never > > > > arrives. So what do we do in the meantime? > > > > > > I think the biggest problems is how can PGP or GnuPG users tell other users, > > > not familar with email encyrption yet, what else to use ... > > > > At work, when a client insists on email, and I (or the law) > > insist on encryption, I provide them with instructions for > > installing 7-zip and send them an AES-256 encrypted zip or 7z > > file as an attachment. It's the simplest thing I could think > > of that I thought most people could cope with. > > That is simple, indeed. But how do you exchange passphrases for > the encrypted files in advance and do you switch them regularly > or leave them the same when dealing with many clients? Passwords are conveyed to clients over the phone and each client has their own. If it were entirely automated and in heavy use, a password would be generated for each file and sent via SMS to the recipient. > I solved this with using NaCl public keys, bearing no infos of > the key owners and having a little key ring, where I only assign > nicknames to the pub keys. The software I use is box > > https://github.com/rovaughn/box > > in combination with a base91 encoder / decoder, for ASCII armor, > when sending encrypted emails. > > Before that I also experimented with other tools, like dhbitty, > MiniLock and Pretty Curved Privacy etc. but for me they all had > some disadvantages compared to box. > > Regards > Stefan From gnupg at raf.org Mon Jul 22 01:40:01 2019 From: gnupg at raf.org (raf) Date: Mon, 22 Jul 2019 09:40:01 +1000 Subject: Essay on PGP as it is used today In-Reply-To: <1563573984.1282.29.camel@16bits.net> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190717204647.00006dfe.sac@300baud.de> <20190718021333.bj6iankdv4covvzv@raf.org> <1563573984.1282.29.camel@16bits.net> Message-ID: <20190721234001.dxjaotjkvrddmdlq@raf.org> ?ngel wrote: > On 2019-07-18 at 12:13 +1000, raf wrote: > > At work, when a client insists on email, and I (or the law) > > insist on encryption, I provide them with instructions for > > installing 7-zip and send them an AES-256 encrypted zip or 7z > > file as an attachment. It's the simplest thing I could think > > of that I thought most people could cope with. > > Encrypted zip files have several factors that make it a beautiful > solution for sending encrypted messages to occasional users that don't > care much about it: > > a) zip is a file format supported out-of-the-box by pretty much every > system, and that users are comfortable with. Whereas you would be seen > as a weirdo if you sent them a .gpg or other new file that needed a > special program, you would likely be asked to just sent it > "normally" (ie. unencrypted). > b) The format itself supports secure encryption (aes128/256). Unfortunately, that's not entirely true. The zip format that is supported out of the box by Windows doesn't support AES-256. The impression I get is that it's v2 of the format which only supports broken zip password protection. Zip v5 format is needed for AES-256 and Windows Explorer doesn't seem to suppoort that. The recipient must either have 7-Zip (which is free) or Winzip (which costs money). I find it hard to believe that the new format isn't supported everywhere but it isn't. Even the command line tool unzip only supports the ancient zip format when encryption is used. > c) If their client doesn't support AES-Encryption, their client will > show that *their program* can't cope with it. This places the onus on > the receiver (their zip decompresser isn't "new enough"), rather than > the sender (see a). > > Nevertheless, it has a number of potential problems: > > * As pointed out by Stefan Claas, you need to exchange the encryption > keys. The zip file is just an encryption primitive, so key distribution > may become a problem. > > (raf, may I ask how you are dealing with it? As they are clients, are > you providing a set of keys in advance when personally visiting them? > Are you providing the key for the new message?) Verbally over the phone (but I think SMS would be OK). > * 7-Zip before 19.00 use a bad PRNG to fill a half-size IV > https://threadreaderapp.com/thread/1087848040583626753.html Luckily we use v19.00 for encrypting (but my macports version is only v16.02). > * A naive user trying to reply would easily end up using PKWARE > encryption (and reusing the password) True. In that case, I'd recommend that they create a .7z file rather than a .zip file. The .7z format only seems to support AES-256. The .zip format supports both AES-256 and PKWARE password protection but it defaults to PKWARE protection (in the 7-Zip GUI). > Kind regards cheers, raf From mercuryrising at hush.ai Mon Jul 22 11:26:10 2019 From: mercuryrising at hush.ai (mercuryrising at hush.ai) Date: Mon, 22 Jul 2019 03:26:10 -0600 Subject: Essay on PGP as it is used today In-Reply-To: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> Message-ID: <20190722092611.296D4E0770@smtp.hushmail.com> From Elwin in Lloydminster, Alberta, Canada (visiting family) July 22, 2019 Ryan & gnupg-users, Concerning "Essay on PGP as it is used today" When I went to the link it said it said, "The PGP Problem" I searched and determined the author is unknown from from what I could see. The Essay suggested a number of alternatives for private messaging. The firstwas Signal. I downloaded it to my phone. Then the thought came to me, "howsecure is signal? I looked for a short time and found this: Signal Desktop Leaves Message Decryption Key in Plain Sight https://www.bleepingcomputer.com/news/security/signal-desktop-leaves-message-decryption-key-in-plain-sight/ Why would the nameless author of this essay suggest people use Signal when anyone given access to a computer be able to just go into unprotected directories and get the key to signal and open all past messages sent. Governments must love this feature. The fact that the author can not be questioned because there is no way to contact him/her is the first big clue someone is trying to crash the faith people have in PGP or GnuPG. This has happened before to me. I went to an EFF (Electronic Frontier Foundation) meeting and a big and tall guy came to me and told me that he had a way of Breaking PGP and told me he had been working on a database program that made this possible and spouted off terms I had never heard before. I turned around for a second or few and turned back and he was gone. I searched the room with my eyes and couldn't find him. I went to the outside door and looked up and down the street to no avail. I went to the Intersection and looked around - nothing. I went back inside, and I couldn't find him. I had questions. Doubts flooded my mind. I went and looked at the fundamentals. The PGP I am interested in is the PGP based on RSA because it cannot be broken using a very large Prime number set that are multiplied together and assuming these numbers are in a supply in the quadrillions times quadrillions. I have had a hobby of codes and ciphers and have around 200 books on what most common people would consider the ways to write things they cannot understand or even see. I was a subway train operator and Railroad brakeman for over 41 years then retired but am not a math wiz. If you had a multi processor computer like at Laurence Livermore National Labs that can independently parallel process millions of possibilities a second how long would it take to break one PGP RSA encoded/enciphered message. So if there are certain prime numbers that do not qualify to be used, how many numbers are left? So you have one qualifying very large prime. You go to a list of other very large prime numbers and separately use each number with your first chosen very large prime number to make a key and test that key against the message with the unknown key. If nothing on the List pans out you choose the next very large prime number and reuse the very large prime number list. How many numbers make up the very large prime number list? Elwin Sent using Hushmail On 7/16/2019 at 9:31 PM, "Ryan McGinnis via Gnupg-users" wrote:More than a bit critical, but a good read all the same. Found on HN. https://latacora.micro.blog/2019/07/16/the-pgp-problem.html HN comment thread here: https://news.ycombinator.com/item?id=20455780 -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicegodgiarc at hotmail.com Mon Jul 22 10:28:59 2019 From: vicegodgiarc at hotmail.com (Craig T) Date: Mon, 22 Jul 2019 08:28:59 +0000 Subject: Essay on PGP as it is used today In-Reply-To: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> Message-ID: Hey Ryan thanks for posting... and this response is not a poke at you, so dont take it personally! but ... groan... honestly who the fck are "latacora", and all the others who sprout shite they read somewhere and regurgitate elsewhere... Yeah I have been seeing posts like this pop up and with variations of content. Today everyone is cool kid security consultant, it's a badge of upper crust 007 techno ability. Show me actual facts and figures, opinions are not fact. Like anything worthwhile, sometimes you need to study and actually apply a bit of effort to do something properly. GPG is no different... The "instant gratification" and simple systems don't enforce good security workflows. Just because Uncle Bob likes and says you should use signal/whatsapp etc etc and shouldn't use whatever, doesn't mean you should follow. If folks like Bruce Schneier suddenly popped up and said "we have a problem" and dumped his PK, I may take notice... Then again that's my opinion, why should you believe me :) Cheers Craig ________________________________ From: Gnupg-users on behalf of Ryan McGinnis via Gnupg-users Sent: 17 July 2019 15:28 To: Konstantin Boyandin via Gnupg-users Subject: Essay on PGP as it is used today More than a bit critical, but a good read all the same. Found on HN. https://latacora.micro.blog/2019/07/16/the-pgp-problem.html HN comment thread here: https://news.ycombinator.com/item?id=20455780 -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail -------------- next part -------------- An HTML attachment was scrubbed... URL: From wiktor at metacode.biz Mon Jul 22 12:32:46 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 22 Jul 2019 12:32:46 +0200 Subject: Essay on PGP as it is used today In-Reply-To: <20190722092611.296D4E0770@smtp.hushmail.com> References: <20190722092611.296D4E0770@smtp.hushmail.com> Message-ID: On 22.07.2019 11:26, Procopius via Gnupg-users wrote: > > I searched and determined the author is unknown from from what I could see. The author is Thomas H. Ptacek, here's contact info: https://news.ycombinator.com/user?id=tptacek FWIW he's known for criticizing crypto that he thinks is unnecessarily complex, such as PGP and DNSSEC. If you want you can browse through his comments to see that the article is mostly a comprehensive collection of his thoughts. Kind regards, Wiktor From rjh at sixdemonbag.org Mon Jul 22 13:07:32 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 22 Jul 2019 07:07:32 -0400 Subject: Essay on PGP as it is used today In-Reply-To: <20190722092611.296D4E0770@smtp.hushmail.com> References: <20190722092611.296D4E0770@smtp.hushmail.com> Message-ID: <24500f0e-7943-f9aa-94a8-5176008f59e9@sixdemonbag.org> > I went to an EFF (Electronic Frontier Foundation) meeting and a big > and tall guy came to me and told me that he had a way of Breaking PGP > and told me he had been working on a database program that made this > possible and spouted off terms I had never heard before. Yeah, these conspiracy theorists always show up. > I went back inside, and I couldn't find him. I had questions. You're in the right place. Mathematicians have come up with different ways to estimate how many primes there were under a certain value -- what we call the prime counting function, or "?(x)" in mathematicalese. There are lots of ways to do it, but they all give answers very close to each other: these are estimates, not precise numbers. The first estimate for ?(x) was "x divided by the natural logarithm of x". Let x be 100. The natural log of 100 is about 4.6. 100 divided by 4.6 is about 22. Thus, we expect there to be about 22 primes under 100. There are in fact 25 -- so while this method isn't perfect it's definitely enough to get us in the neighborhood. If we do that same equation for a 2048-bit key, it turns out there are 10 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 different prime numbers that could go into it. Google's total data storage is about 10 exabytes. In 10 exabytes you could store about 40 000 000 000 000 000 prime numbers. There's just no way anyone on earth has a list of prime numbers that they're trying one after another. Not only isn't there enough hard drive space, but the hard drives required would literally be bigger than the entire Milky Way galaxy! From jerry at seibercom.net Mon Jul 22 13:45:49 2019 From: jerry at seibercom.net (Jerry) Date: Mon, 22 Jul 2019 07:45:49 -0400 Subject: Essay on PGP as it is used today In-Reply-To: <24500f0e-7943-f9aa-94a8-5176008f59e9@sixdemonbag.org> References: <20190722092611.296D4E0770@smtp.hushmail.com> <24500f0e-7943-f9aa-94a8-5176008f59e9@sixdemonbag.org> Message-ID: <20190722074549.00006bec@seibercom.net> On Mon, 22 Jul 2019 07:07:32 -0400, Robert J. Hansen stated: >> I went to an EFF (Electronic Frontier Foundation) meeting and a big >> and tall guy came to me and told me that he had a way of Breaking PGP >> and told me he had been working on a database program that made this >> possible and spouted off terms I had never heard before. > >Yeah, these conspiracy theorists always show up. > >> I went back inside, and I couldn't find him. I had questions. > >You're in the right place. > >Mathematicians have come up with different ways to estimate how many >primes there were under a certain value -- what we call the prime >counting function, or "?(x)" in mathematicalese. There are lots of >ways to do it, but they all give answers very close to each other: >these are estimates, not precise numbers. > >The first estimate for ?(x) was "x divided by the natural logarithm of >x". > >Let x be 100. The natural log of 100 is about 4.6. 100 divided by 4.6 >is about 22. Thus, we expect there to be about 22 primes under 100. >There are in fact 25 -- so while this method isn't perfect it's >definitely enough to get us in the neighborhood. > >If we do that same equation for a 2048-bit key, it turns out there are >10 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 000 000 000 000 000 different prime numbers that could go into >it. > >Google's total data storage is about 10 exabytes. In 10 exabytes you >could store about 40 000 000 000 000 000 prime numbers. > >There's just no way anyone on earth has a list of prime numbers that >they're trying one after another. Not only isn't there enough hard >drive space, but the hard drives required would literally be bigger >than the entire Milky Way galaxy! I am not sure about that. If a good data compression algorithm was employed, they might be able to save the space of a solar system or two. -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Mon Jul 22 16:26:08 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 22 Jul 2019 16:26:08 +0200 Subject: Essay on PGP as it is used today In-Reply-To: <20190722074549.00006bec@seibercom.net> References: <20190722092611.296D4E0770@smtp.hushmail.com> <24500f0e-7943-f9aa-94a8-5176008f59e9@sixdemonbag.org> <20190722074549.00006bec@seibercom.net> Message-ID: <20190722162608.00007062.sac@300baud.de> Jerry wrote: > On Mon, 22 Jul 2019 07:07:32 -0400, Robert J. Hansen stated: > >> I went to an EFF (Electronic Frontier Foundation) meeting and a big > >> and tall guy came to me and told me that he had a way of Breaking PGP > >> and told me he had been working on a database program that made this > >> possible and spouted off terms I had never heard before. > > > >Yeah, these conspiracy theorists always show up. > > > >> I went back inside, and I couldn't find him. I had questions. > > > >You're in the right place. > > > >Mathematicians have come up with different ways to estimate how many > >primes there were under a certain value -- what we call the prime > >counting function, or "?(x)" in mathematicalese. There are lots of > >ways to do it, but they all give answers very close to each other: > >these are estimates, not precise numbers. > > > >The first estimate for ?(x) was "x divided by the natural logarithm of > >x". > > > >Let x be 100. The natural log of 100 is about 4.6. 100 divided by 4.6 > >is about 22. Thus, we expect there to be about 22 primes under 100. > >There are in fact 25 -- so while this method isn't perfect it's > >definitely enough to get us in the neighborhood. > > > >If we do that same equation for a 2048-bit key, it turns out there are > >10 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 > >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 > >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 > >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 > >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 > >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 > >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 > >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 > >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 > >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 > >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 > >000 000 000 000 000 000 000 different prime numbers that could go into > >it. > > > >Google's total data storage is about 10 exabytes. In 10 exabytes you > >could store about 40 000 000 000 000 000 prime numbers. > > > >There's just no way anyone on earth has a list of prime numbers that > >they're trying one after another. Not only isn't there enough hard > >drive space, but the hard drives required would literally be bigger > >than the entire Milky Way galaxy! > > I am not sure about that. If a good data compression algorithm was > employed, they might be able to save the space of a solar system or two. > Regards Stefan From ryan at digicana.com Mon Jul 22 17:46:18 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Mon, 22 Jul 2019 15:46:18 +0000 Subject: Essay on PGP as it is used today In-Reply-To: References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publicKey - ryan at digicana.com - 5c738727ee58786a777c4f1db5aa3fa3486ed7ad.as= c" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tClZlcnNpb246IFBt Y3J5cHRvIEdvbGFuZyAwLjAuMSAoZGRhY2ViZTApCkNvbW1lbnQ6IGh0dHBzOi8v cHJvdG9ubWFpbC5jb20KCnhzRk5CRm95d3BvQkVBQ0dsQ0x6dUl4UHR1VDYwQld3 K1luQ0V3NS9HbFhJeDVYNmwzTkpnRGlUL1FydjZtM0MKWDROSkVIY21VT3J1SWhS L2JJMFdrdnVXVjRSZnh2MEJLUWpwN0puTVdSRE9ZNU54SWNrdk1KR3BsTFRoY3lS agpLcUF2aXhTcnVrc3h0M3YzQTViNzdLeXcxZXlCMytlQzNZbzBnMjh5aGhmbG4x Z2V4enNVc3V6U1crRml4eGd6ClMyS2RKMjZhWjhTYjNnanZmSEx2L01LaFhsdVN3 WWdYSURLTWlVT2liMGlEVmRXUGZGWENwVmJIM28xOFZueFQKZEMzVUkzdlZtbEph clI0TzV4SXA2RndkbVFWdGo3M1pNSGRnWW5RY2VHWWN3b2I4dGFPMGRLZlUrMzEv Ymp1dQpNYU9qeTJ1S25DeDlsZWVLNEgxM0pjYkl5R1NLN2pyQWVRUk53RTU4VXpC SlpVQnMxSURjZFlZN1l2MW9iOWlNClljZmtaaHF6enREaksxUVAzSWJlM0FHMDJY K3JVWExjdmxoOEVjY0RiL1c1MElBK2VqRHk3eUZRYjZTSys0U3AKSXJaSEdQamYx eUQ0eGtraHpORlBKMm1ZR040aENDcm5XckRnL2hDM3J4U3dDcEkzUEV4bFo4T0Y5 ank5alR0cQpJUngvelhTUUtnSmNBRHM0dHNOSGZ6UHJuRXk0MWJzbWNkSTBOcm5j UGNmMjVqRnZhUFR3QkhBQ3lIbG1GWDJ6Ci9HdUNoZW9wYXhtaVZKRnVWbGVxcnR4 ZVRCTjR2NzlMaHhCR3RDVWRZSDlHcmVuRnZ6QTl2OFZNQTZyOWQ3YVcKQ2I3bDBK SEw4d3pEQk9sRENiSk1adlQ3dER4eWwyTUl2MTFMUWVJSW5SbEk2SkJ4TENGWnVo WVB6d0FSQVFBQgp6U1Z5ZVdGdVFHUnBaMmxqWVc1aExtTnZiU0E4Y25saGJrQmth V2RwWTJGdVlTNWpiMjArd3NGMUJCQUJDQUFwCkJRSmFNc0tnQmdzSkJ3Z0RBZ2tR dGFvL28waHUxNjBFRlFnS0FnTVdBZ0VDR1FFQ0d3TUNIZ0VBQUp5TEQvMFQKZUdG YmJ1TnlQZmxUb3NkbW1LQUM2Wnl1RHdKeExqdkwzWW5IQVVQa1RPL2E2eFR0RVoy QjQxL21PeDJPVGN5aApKaGh3dEIwL2xzU043cjVyWEh6VVc0VmU2R1NTOFBFSTNq MUl5TS93ZWN2MytnYjM4ZmZkRkVKQTFiVW45K2YvCnV5aFFJRmFMd0ZwcThVUUd4 RFJKOTFRWGNYRnJQemFsc3Y5S0tOY3QxdFJDbGZWblFSNzdCemtoZklKczJnUWkK eVQxbCtWRnF6WEFoVmlpdXpSZGxKTWFUTGIyMzZVa2VPeC9leU5WRWNpdlZZb3V5 MkJ6TC9kVzI4V0RQUHRkVgpIT2NWbVY0S2ZhWUpwSDRtQkhCL0tQK0pOUXk1c3BW Zk1MTWZDMDhyNWEwRUZFM0J5ZWJsdDNPTlBtKzJ5bXpDClJvdEl0ejhUN3Njd3U0 eFRtSXc1V1dSY0lpM21iRFcvbWVmbzd3aGJYM283TmlkUEJDK1pxSnNxTG9Obm8v YUQKUFlYbnBUekFiczRVVFNxcDZQNDlNSFZXTkY0L24vYVhVM1ZoQnZaeDBoMU5O TmJPMVB6Ui84U3I3ZmVkRDlVQwpuaUpOSmdmYUtodDFpMTlQYytCRjUrc2duYlJa ZUlmU3hIV2ZYRCtrcklXR1ptUkJhQnBHelIzSnIzQUF3Q2NECnVKVmVDWHhJZTE3 WlRIeXdxVlpsb1hGWEVSSkJUZm1KK0FEbjIrc0ZNanBkV0Jhd3NsNXhYLzlmZmlP WWY4aTAKbEdoNnZraWtCbkdaem5YSVp4Y3YvSVZpSHVnYlY3M3FwdktUaVpiME5o WDlhd3kybGJqcWRxZzR4UHhuMlJJbwpwaEY5VTNpYmxhcDRqSnJZMFo2NmdNUEhB b2VVWlVJa1crWjYzT1BJbE03QlRRUmFNc0thQVJBQWlSblptNHVjClBLc0ZEUG5N SjVWcUVkeE9LcVRhbGsxRDM3NzEyemovWjcwNjlaRkV6QnY5UkVUcU9qdmFCQ1ZU dExrWmpVS3UKQXQ5QVF3S0prcUhNbXpHVGdsVGt5cThEM0Z3cDExeVVoQm12M3lP ciswVjVNZUU2OUhNdXFpdHBPNWdYbW9NMQoyQ1VBUERzcWV0OEY4THN0RUpNYlJo cHh2T3NnbU1SV2dGbTVMNzRjeXFPVDQ0K01vOCt1THdldlBIMXBDN2JFCi9rTEVQ ZXdjQUUvNjBwUTBZZ1ZQMkxlNngyaHQ4Q3pEWjdwOGNTSGtYbEJhOXlIa1haUkV0 VStMMFdJSU0rM28KRjBycnhMeENpcmJjU2hOM1pFeHgra0xuTTJ6YjN4bUVRd1k2 YndsVXRIa25ub1ZwSmtaWFBjM21OSlFLYzA4NAorWEdnSWNQYXEwNTN2cElaa093 ZlFib292azZ4cG9sWkdmU254c1FTVnNCTFQ3WFlKR2UydjRTdExuS1UzRzFXCk1J aHk4TitzK1ArUHRPYytZRU9sNS82cmhiZUk2UkFsS21wcisvMGhFWG9lK0Z4USt0 Njc5TS9kR2ptRmM1YlIKVFl0b1k2YlpuaGpHYnZ0dWY0K3pmUFNudmFMOFFtd2Rj bjZYSFExVndCQmFVWXlqYUxJTCtOam1LSjdSWGhrawoyeUs0SU1iZDVYMFl1TDVm dVpnTXE5OUJTbkVtZ1B0QUhwQW9rci9sWXV0VW82NmhIUEQ5OWlBSUwxYUI5aU5l CmpqU0FjdWI1QThQMENaYWJNTWVsdmw5QnRXRGVHZ0d6K3lFQmlJN09MOHdaOUxn NjM0RTZRNjVIUmZBcUFiU2cKc0pyRmRHc0tKM3NuUXRhbGJ6UzJBaldVUnZWOW5T aHpuV3NBRVFFQUFjTEJYd1FZQVFnQUV3VUNXakxDb3drUQp0YW8vbzBodTE2MENH d3dBQU5qSkQvNDFRTmpkSkQ3VzNZR0RkRjd6SXlOMW5FME9WTElsaGh5WHZ4Mk5C UzlFCjhPMzM4V1dpbnMzekxJZTdCenFyNkhTSmdQZUxyRElJWi8rQ29aSW9aZm52 cEI2bllsbWdQME8zdUZuSnNQYysKTjVnc1E0cDEzZEF4QldWMVNBSmJtMDdyZ3VT RVMzNzlpdHdPTWFuSU9KTVNQTnhETHI4YUxLY2pKV0tqNWRnTgpvMEx1eWFYSjdI OU02MWMrMytUV25ZdWNBakZDQ2s3STcrRldtWHZ2OEgzVHBBeEF6K3FPYllKRDRS UDFaL3RSCjdtYVJyQU5NalVZY0lneVR2RzlsNDF2ZG1jR01lZDN4bTc3VS9Yek96 ZlVDbEVEbWFLMzlibU9HNEF1YzVSOHkKNjIrMkhJSS94cmE5V2VlaUlPZXNxTUVN NTB5NkFjUUVSVnAydDQyZjFucld5aU1KMkR6cVMyUlZwMHZiNWNsRApIK25XUUlM bGxuN1VBd09ONHJvaXpQZm5zeTRBOGdiTS9KcXlMazA1Vnl4WlEzWUNUZUJJcVJm anUyUndIM0l2CjRuZFBhaXBIUkY3R3dOZEdKWDJFYmJ4L1hyMHBLbUx3K0tKa211 ZEVuU0VqYUJTeFYwcml1N3dHUHZ6UVFhL3AKWTIrNmlzWDgxeVNibFlqakVwVCsz eDUvdmFzMDcxL3dNdlFaWmJrc29RT3dvZGxZSHFHellGOTlXbFoyMHJySgpnL1F4 R2VQS2xRU01jQWlYalhXUzI4bkYxY2xVZHRlUlNXM0JDbHJsbGcyNFlNNWRZL1ZC RDhzZWp5aERNVUI4CnA3NUNCa1JDTzZ4UlozcnJ5QXBqQTM0QnJlNnd0NlJOT1A5 V1VTYzFnbmhPaUk5K3E1a3oxc0JHWm9VRXRNTmsKZ1E9PQo9SXZXYQotLS0tLUVO RCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0t -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 871 bytes Desc: OpenPGP digital signature URL: From ilf at zeromail.org Mon Jul 22 19:28:16 2019 From: ilf at zeromail.org (ilf) Date: Mon, 22 Jul 2019 19:28:16 +0200 Subject: revoke last valid user ID Message-ID: <20190722172816.GN13064@zeromail.org> Doing more keyring housekeeping, I would like to all revoke user IDs of keypairs with revoked/expired certificates. However, I am getting this error: > gpg: Cannot revoke the last valid user ID. This is also in the documentation: > --quick-revoke-uid user-id user-id-to-revoke > This command revokes a user ID on an existing key. It cannot be used > to revoke the last user ID on key (some non-revoked user ID must > remain) [?] https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Key-Management.html Why it this? I have keypairs with revoked/expired certificates keys in my keyring which have *all* user IDs revoked. And I am sure I want to do this. Is there a way to override this limitation? -- ilf If you upload your address book to "the cloud", I don't want to be in it. From wiktor at metacode.biz Mon Jul 22 21:13:42 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 22 Jul 2019 21:13:42 +0200 Subject: revoke last valid user ID In-Reply-To: <20190722172816.GN13064@zeromail.org> References: <20190722172816.GN13064@zeromail.org> Message-ID: <698702af-6d91-371a-68e9-d32d3018cc54@metacode.biz> On 22.07.2019 19:28, ilf wrote: > Is there a way to override this limitation? I'd try adding one dummy User ID, revoke the rest, then delete that dummy User ID before it gets sent to the keyserver. I guess you don't want to revoke the entire key... Kind regards, Wiktor From metalevel at gmx.net Mon Jul 22 17:19:48 2019 From: metalevel at gmx.net (metalevel at gmx.net) Date: Mon, 22 Jul 2019 17:19:48 +0200 Subject: security of local keyring Message-ID: Hello, I want to use GPG for rather simple authentication of downloaded files. I made a test installation on a Windows box, then imported and validated (via fingerprint) the public keys of some sources. Now I have the following question. Is there some means of access control for the public keyring? It seems, there is no privilege distinction between managing the local keyring and using it. When the user is able to freely import and delete public keys, there's no prevention of some malware tampering with the keyring either. From mwood at iupui.edu Mon Jul 22 22:00:54 2019 From: mwood at iupui.edu (Mark H. Wood) Date: Mon, 22 Jul 2019 16:00:54 -0400 Subject: Essay on PGP as it is used today In-Reply-To: References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> Message-ID: <20190722200054.GD31460@IUPUI.Edu> On Mon, Jul 22, 2019 at 03:46:18PM +0000, Ryan McGinnis via Gnupg-users wrote: > [1]https://www.schneier.com/blog/archives/2018/05/details_on_a_ne.html > > ? 3. Why is anyone using encrypted e-mail anymore, anyway? Reliably and > easily encrypting e-mail is an insurmountably hard problem for reasons > having nothing to do with today's announcement. If you need to > communicate securely, use Signal. If having Signal on your phone will > arouse suspicion, use WhatsApp.? Depends on your threat model. For mine, reliably and easily encrypting email is almost absurdly simple: 1) Use PGP 2) Don't send secrets to people I don't trust to keep them. Anyway, 99% of my PGP use is for the opposite of secrecy: I sign my emails so that (if you care enough to install PGP) you can be highly assured that they're from me. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From ilf at zeromail.org Mon Jul 22 23:40:42 2019 From: ilf at zeromail.org (ilf) Date: Mon, 22 Jul 2019 23:40:42 +0200 Subject: revoke last valid user ID In-Reply-To: <698702af-6d91-371a-68e9-d32d3018cc54@metacode.biz> References: <20190722172816.GN13064@zeromail.org> <698702af-6d91-371a-68e9-d32d3018cc54@metacode.biz> Message-ID: <20190722214042.GQ13064@zeromail.org> Wiktor Kwapisiewicz: > I'd try adding one dummy User ID, revoke the rest, then delete that > dummy User ID before it gets sent to the keyserver. Thanks, that sounds possible. But I wonder, if there is a reason GnuPG won't let me revoke it directly - and if so, if that reasoning is strong enough to not even have a way to override it. Since I have keys with all user IDs revoked and I only ever used GnuPG, it seems I was able to do that once. > I guess you don't want to revoke the entire key... The keys I am trying to do that for *are* revoked or expired. That's why I want to remove the (immediate visibility of the) user IDs, even from the classic SKS keyserver network. -- ilf If you upload your address book to "the cloud", I don't want to be in it. From ryan at digicana.com Tue Jul 23 03:49:13 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Tue, 23 Jul 2019 01:49:13 +0000 Subject: Essay on PGP as it is used today In-Reply-To: <20190722200054.GD31460@IUPUI.Edu> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190722200054.GD31460@IUPUI.Edu> Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publicKey - ryan at digicana.com - 5c738727ee58786a777c4f1db5aa3fa3486ed7ad.as= c" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tClZlcnNpb246IFBt Y3J5cHRvIEdvbGFuZyAwLjAuMSAoZGRhY2ViZTApCkNvbW1lbnQ6IGh0dHBzOi8v cHJvdG9ubWFpbC5jb20KCnhzRk5CRm95d3BvQkVBQ0dsQ0x6dUl4UHR1VDYwQld3 K1luQ0V3NS9HbFhJeDVYNmwzTkpnRGlUL1FydjZtM0MKWDROSkVIY21VT3J1SWhS L2JJMFdrdnVXVjRSZnh2MEJLUWpwN0puTVdSRE9ZNU54SWNrdk1KR3BsTFRoY3lS agpLcUF2aXhTcnVrc3h0M3YzQTViNzdLeXcxZXlCMytlQzNZbzBnMjh5aGhmbG4x Z2V4enNVc3V6U1crRml4eGd6ClMyS2RKMjZhWjhTYjNnanZmSEx2L01LaFhsdVN3 WWdYSURLTWlVT2liMGlEVmRXUGZGWENwVmJIM28xOFZueFQKZEMzVUkzdlZtbEph clI0TzV4SXA2RndkbVFWdGo3M1pNSGRnWW5RY2VHWWN3b2I4dGFPMGRLZlUrMzEv Ymp1dQpNYU9qeTJ1S25DeDlsZWVLNEgxM0pjYkl5R1NLN2pyQWVRUk53RTU4VXpC SlpVQnMxSURjZFlZN1l2MW9iOWlNClljZmtaaHF6enREaksxUVAzSWJlM0FHMDJY K3JVWExjdmxoOEVjY0RiL1c1MElBK2VqRHk3eUZRYjZTSys0U3AKSXJaSEdQamYx eUQ0eGtraHpORlBKMm1ZR040aENDcm5XckRnL2hDM3J4U3dDcEkzUEV4bFo4T0Y5 ank5alR0cQpJUngvelhTUUtnSmNBRHM0dHNOSGZ6UHJuRXk0MWJzbWNkSTBOcm5j UGNmMjVqRnZhUFR3QkhBQ3lIbG1GWDJ6Ci9HdUNoZW9wYXhtaVZKRnVWbGVxcnR4 ZVRCTjR2NzlMaHhCR3RDVWRZSDlHcmVuRnZ6QTl2OFZNQTZyOWQ3YVcKQ2I3bDBK SEw4d3pEQk9sRENiSk1adlQ3dER4eWwyTUl2MTFMUWVJSW5SbEk2SkJ4TENGWnVo WVB6d0FSQVFBQgp6U1Z5ZVdGdVFHUnBaMmxqWVc1aExtTnZiU0E4Y25saGJrQmth V2RwWTJGdVlTNWpiMjArd3NGMUJCQUJDQUFwCkJRSmFNc0tnQmdzSkJ3Z0RBZ2tR dGFvL28waHUxNjBFRlFnS0FnTVdBZ0VDR1FFQ0d3TUNIZ0VBQUp5TEQvMFQKZUdG YmJ1TnlQZmxUb3NkbW1LQUM2Wnl1RHdKeExqdkwzWW5IQVVQa1RPL2E2eFR0RVoy QjQxL21PeDJPVGN5aApKaGh3dEIwL2xzU043cjVyWEh6VVc0VmU2R1NTOFBFSTNq MUl5TS93ZWN2MytnYjM4ZmZkRkVKQTFiVW45K2YvCnV5aFFJRmFMd0ZwcThVUUd4 RFJKOTFRWGNYRnJQemFsc3Y5S0tOY3QxdFJDbGZWblFSNzdCemtoZklKczJnUWkK eVQxbCtWRnF6WEFoVmlpdXpSZGxKTWFUTGIyMzZVa2VPeC9leU5WRWNpdlZZb3V5 MkJ6TC9kVzI4V0RQUHRkVgpIT2NWbVY0S2ZhWUpwSDRtQkhCL0tQK0pOUXk1c3BW Zk1MTWZDMDhyNWEwRUZFM0J5ZWJsdDNPTlBtKzJ5bXpDClJvdEl0ejhUN3Njd3U0 eFRtSXc1V1dSY0lpM21iRFcvbWVmbzd3aGJYM283TmlkUEJDK1pxSnNxTG9Obm8v YUQKUFlYbnBUekFiczRVVFNxcDZQNDlNSFZXTkY0L24vYVhVM1ZoQnZaeDBoMU5O TmJPMVB6Ui84U3I3ZmVkRDlVQwpuaUpOSmdmYUtodDFpMTlQYytCRjUrc2duYlJa ZUlmU3hIV2ZYRCtrcklXR1ptUkJhQnBHelIzSnIzQUF3Q2NECnVKVmVDWHhJZTE3 WlRIeXdxVlpsb1hGWEVSSkJUZm1KK0FEbjIrc0ZNanBkV0Jhd3NsNXhYLzlmZmlP WWY4aTAKbEdoNnZraWtCbkdaem5YSVp4Y3YvSVZpSHVnYlY3M3FwdktUaVpiME5o WDlhd3kybGJqcWRxZzR4UHhuMlJJbwpwaEY5VTNpYmxhcDRqSnJZMFo2NmdNUEhB b2VVWlVJa1crWjYzT1BJbE03QlRRUmFNc0thQVJBQWlSblptNHVjClBLc0ZEUG5N SjVWcUVkeE9LcVRhbGsxRDM3NzEyemovWjcwNjlaRkV6QnY5UkVUcU9qdmFCQ1ZU dExrWmpVS3UKQXQ5QVF3S0prcUhNbXpHVGdsVGt5cThEM0Z3cDExeVVoQm12M3lP ciswVjVNZUU2OUhNdXFpdHBPNWdYbW9NMQoyQ1VBUERzcWV0OEY4THN0RUpNYlJo cHh2T3NnbU1SV2dGbTVMNzRjeXFPVDQ0K01vOCt1THdldlBIMXBDN2JFCi9rTEVQ ZXdjQUUvNjBwUTBZZ1ZQMkxlNngyaHQ4Q3pEWjdwOGNTSGtYbEJhOXlIa1haUkV0 VStMMFdJSU0rM28KRjBycnhMeENpcmJjU2hOM1pFeHgra0xuTTJ6YjN4bUVRd1k2 YndsVXRIa25ub1ZwSmtaWFBjM21OSlFLYzA4NAorWEdnSWNQYXEwNTN2cElaa093 ZlFib292azZ4cG9sWkdmU254c1FTVnNCTFQ3WFlKR2UydjRTdExuS1UzRzFXCk1J aHk4TitzK1ArUHRPYytZRU9sNS82cmhiZUk2UkFsS21wcisvMGhFWG9lK0Z4USt0 Njc5TS9kR2ptRmM1YlIKVFl0b1k2YlpuaGpHYnZ0dWY0K3pmUFNudmFMOFFtd2Rj bjZYSFExVndCQmFVWXlqYUxJTCtOam1LSjdSWGhrawoyeUs0SU1iZDVYMFl1TDVm dVpnTXE5OUJTbkVtZ1B0QUhwQW9rci9sWXV0VW82NmhIUEQ5OWlBSUwxYUI5aU5l CmpqU0FjdWI1QThQMENaYWJNTWVsdmw5QnRXRGVHZ0d6K3lFQmlJN09MOHdaOUxn NjM0RTZRNjVIUmZBcUFiU2cKc0pyRmRHc0tKM3NuUXRhbGJ6UzJBaldVUnZWOW5T aHpuV3NBRVFFQUFjTEJYd1FZQVFnQUV3VUNXakxDb3drUQp0YW8vbzBodTE2MENH d3dBQU5qSkQvNDFRTmpkSkQ3VzNZR0RkRjd6SXlOMW5FME9WTElsaGh5WHZ4Mk5C UzlFCjhPMzM4V1dpbnMzekxJZTdCenFyNkhTSmdQZUxyRElJWi8rQ29aSW9aZm52 cEI2bllsbWdQME8zdUZuSnNQYysKTjVnc1E0cDEzZEF4QldWMVNBSmJtMDdyZ3VT RVMzNzlpdHdPTWFuSU9KTVNQTnhETHI4YUxLY2pKV0tqNWRnTgpvMEx1eWFYSjdI OU02MWMrMytUV25ZdWNBakZDQ2s3STcrRldtWHZ2OEgzVHBBeEF6K3FPYllKRDRS UDFaL3RSCjdtYVJyQU5NalVZY0lneVR2RzlsNDF2ZG1jR01lZDN4bTc3VS9Yek96 ZlVDbEVEbWFLMzlibU9HNEF1YzVSOHkKNjIrMkhJSS94cmE5V2VlaUlPZXNxTUVN NTB5NkFjUUVSVnAydDQyZjFucld5aU1KMkR6cVMyUlZwMHZiNWNsRApIK25XUUlM bGxuN1VBd09ONHJvaXpQZm5zeTRBOGdiTS9KcXlMazA1Vnl4WlEzWUNUZUJJcVJm anUyUndIM0l2CjRuZFBhaXBIUkY3R3dOZEdKWDJFYmJ4L1hyMHBLbUx3K0tKa211 ZEVuU0VqYUJTeFYwcml1N3dHUHZ6UVFhL3AKWTIrNmlzWDgxeVNibFlqakVwVCsz eDUvdmFzMDcxL3dNdlFaWmJrc29RT3dvZGxZSHFHellGOTlXbFoyMHJySgpnL1F4 R2VQS2xRU01jQWlYalhXUzI4bkYxY2xVZHRlUlNXM0JDbHJsbGcyNFlNNWRZL1ZC RDhzZWp5aERNVUI4CnA3NUNCa1JDTzZ4UlozcnJ5QXBqQTM0QnJlNnd0NlJOT1A5 V1VTYzFnbmhPaUk5K3E1a3oxc0JHWm9VRXRNTmsKZ1E9PQo9SXZXYQotLS0tLUVO RCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0t -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 871 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Jul 23 04:57:16 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 22 Jul 2019 22:57:16 -0400 Subject: Essay on PGP as it is used today In-Reply-To: References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190722200054.GD31460@IUPUI.Edu> Message-ID: <7882d008-614b-3045-dd7d-3a1bc69c582e@sixdemonbag.org> > I think that?s the point security researchers like Schneier have been > trying to make: it is easy for all people ? from grandparents who > still think they need AOL to chipheads who can install Arch without > watching a YouTube tutorial ? to screw up encrypted email in a way > that exposes the cleartext. This is true, but it's not because OpenPGP is uniquely difficult. It's because it's uniquely flexible. Signal is intimately tied to the cell platform and cell signaling. Even when using the desktop client, it's using your cell phone as a proxy. The more choices you take away from the user, the easier the remaining experience tends to become. (Which is not the same as saying the remaining experience is a *good* one, just an *easy* one. Go ahead, try using Signal to do a third party noninteractive introduction. Can't do it! That choice is taken away from you. Which means if you don't need third party introductions, the experience is good and easy... and if you do, it's bad and easy: bad, in that you can't do what you need, but easy, in that at least it's very honest about not being able to do what you need.) > Encrypted email is fundamentally unsafe as it currently exists. Given the government uses email to transfer national security secrets, I question this assumption. Email can definitely be made safe enough: the question is whether individual users can be expected to have the training and experience and resources to do so on their own. (I personally think the answer is 'no'.) > But if you?re trying to securely communicate like a normal person who > is not pretending to be Mister Robot, then PGP for email is one of > the least adopted, least safe ways to do so and > Signal/iMessage/WhatsApp are decent solutions. I generally agree. I recommend WhatsApp as a communications client of first recourse for people in non-permissive environments. Number one, it's easy to convince other people you meet to use it. "You can reach me on WhatsApp at..." tends to get reactions of, "oh, yeah, I have it installed" or "I guess I should install that". You don't need to talk about security or code audits or E2E or anything else: just show them it's fun. Number two, switching from SMS to WhatsApp is a *huge* increase in security for the average smartphone user. Number three, the cops don't look at you funny if you've got it on your phone. Especially if you've got some nieces and nephews you can trade funny memes with. Purge the important stuff before you go through a border crossing and if you're asked about WhatsApp just say "my nieces and nephews made me install it so they could share funny stuff with me". Signal fails on #1 ("This is supposed to be a ... a secure communications tool? Why do I need that? I don't want to get in trouble with the cops.") and on #3 ("Why do you need this, citizen?"). From tlikonen at iki.fi Tue Jul 23 06:52:43 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Tue, 23 Jul 2019 07:52:43 +0300 Subject: revoke last valid user ID In-Reply-To: <20190722214042.GQ13064@zeromail.org> References: <20190722172816.GN13064@zeromail.org> <698702af-6d91-371a-68e9-d32d3018cc54@metacode.biz> <20190722214042.GQ13064@zeromail.org> Message-ID: <87lfwpgxno.fsf@iki.fi> ilf at zeromail.org [2019-07-22T23:40:42+02] wrote: > Thanks, that sounds possible. But I wonder, if there is a reason GnuPG > won't let me revoke it directly - and if so, if that reasoning is > strong enough to not even have a way to override it. Since I have keys > with all user IDs revoked and I only ever used GnuPG, it seems I was > able to do that once. Maybe you have previously revoked the whole key. Such key is shown with all its user IDs revoked. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 507 bytes Desc: not available URL: From mercuryrising at hush.ai Tue Jul 23 10:32:25 2019 From: mercuryrising at hush.ai (mercuryrising at hush.ai) Date: Tue, 23 Jul 2019 02:32:25 -0600 Subject: Essay on PGP as it is used today In-Reply-To: References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190722200054.GD31460@IUPUI.Edu> Message-ID: <20190723083225.D4E14C06E7@smtp.hushmail.com> Again, Signal is touted as better than PGP.Why?Look at this problem with signal. Looks really serious. Signal Desktop Leaves Message Decryption Key in Plain Sight https://www.bleepingcomputer.com/news/security/signal-desktop-leaves-message-decryption-key-in-plain-sight/ I don't think PGP does THIS ! Elwin Sent using Hushmail On 7/22/2019 at 7:53 PM, "Ryan McGinnis via Gnupg-users" wrote:I?m not so sure that it does. I think that?s the point security researchers like Schneier have been trying to make: it is easy for all people ? from grandparents who still think they need AOL to chipheads who can install Arch without watching a YouTube tutorial ? to screw up encrypted email in a way that exposes the cleartext. Encrypted email is fundamentally unsafe as it currently exists. It?s really hard to screw up some of the new E2E encrypted messengers. Sure, if your method for secure communications is dropping stego?d memes with encrypted payloads on imgur, then simple tools like Signal and WhatsApp won?t do. But if you?re trying to securely communicate like a normal person who is not pretending to be Mister Robot, then PGP for email is one of the least adopted, least safe ways to do so and Signal/iMessage/WhatsApp are decent solutions. -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail Sent from ProtonMail Mobile On Mon, Jul 22, 2019 at 15:00, Mark H. Wood via Gnupg-users wrote: On Mon, Jul 22, 2019 at 03:46:18PM +0000, Ryan McGinnis via Gnupg-users wrote: > [1]https://www.schneier.com/blog/archives/2018/05/details_on_a_ne.html > > 3. Why is anyone using encrypted e-mail anymore, anyway? Reliably and > easily encrypting e-mail is an insurmountably hard problem for reasons > having nothing to do with today's announcement. If you need to > communicate securely, use Signal. If having Signal on your phone will > arouse suspicion, use WhatsApp. Depends on your threat model. For mine, reliably and easily encrypting email is almost absurdly simple: 1) Use PGP 2) Don't send secrets to people I don't trust to keep them. Anyway, 99% of my PGP use is for the opposite of secrecy: I sign my emails so that (if you care enough to install PGP) you can be highly assured that they're from me. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at digicana.com Tue Jul 23 17:33:49 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Tue, 23 Jul 2019 15:33:49 +0000 Subject: Essay on PGP as it is used today In-Reply-To: <20190723083225.D4E14C06E7@smtp.hushmail.com> References: <_KQlrEA-r848ndYmcAqj42wsbSmTRrnfOk-wCDVDaKp_1OALWNBVk4JvTfaEZJgcVR68-nTop-Flet8oxwqbyFXVXGokAl1y3Mbo_dPaZAs=@digicana.com> <20190722200054.GD31460@IUPUI.Edu> <20190723083225.D4E14C06E7@smtp.hushmail.com> Message-ID: <1BTHnIWvSJivdajViHHZssqjV0N8XORZTdcgsJvM7s4h1OPnEg2rrp1yteUcesjKehZ5slgxkqLyWiBpT9nRz1QTSBCWbQUF_ynGIMJnF28=@digicana.com> It seems kinda cheeky to find one (fixed) bug in the least secure implementation of the program and act like that disqualifies it.? All programs have bugs.? Most implementations of GPG have had some pretty bad bugs over the years.? No programs are going to be free of security flows - the question is whether the app or platform was built with security as a priority and what happens when those flaws are discovered.? I'd argue Signal was built with security it mind and that they're pretty swift at fixing issues as they arise.? Also, not that it makes the bug any less impactful, but I know very few people who make regular use of the desktop implementation of Signal; it's mostly meant for mobile devices.? -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD Sent with ProtonMail ??????? Original Message ??????? On Tuesday, July 23, 2019 3:32 AM, wrote: > Again, Signal is touted as better than PGP. > Why? > Look at this problem with signal. Looks really serious. > > Signal Desktop Leaves Message Decryption Key in Plain Sight > https://www.bleepingcomputer.com/news/security/signal-desktop-leaves-message-decryption-key-in-plain-sight/ > > I don't think PGP does THIS ! > > Elwin > > Sent using Hushmail > > On 7/22/2019 at 7:53 PM, "Ryan McGinnis via Gnupg-users" wrote: > > > I?m not so sure that it does. ?I think that?s the point security researchers like Schneier?have been trying to make: it is easy for all people ? from grandparents?who still think they need AOL to chipheads?who can install Arch without watching a YouTube tutorial ??to screw up encrypted email in a way that exposes the cleartext. ? Encrypted email is fundamentally unsafe as it currently exists. ?It?s really hard to screw up some of the new E2E encrypted messengers. ?Sure, if your method for secure communications is dropping stego?d memes with encrypted payloads on imgur, then simple tools like Signal and WhatsApp won?t do. ?But if you?re trying to securely communicate like a normal person who is?not pretending to be Mister Robot, then PGP for email is one of the least adopted, least safe ways to do so and Signal/iMessage/WhatsApp are decent solutions. ? > > > > -Ryan McGinnis > > https://bigstormpicture.com > > PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD > > Sent with ProtonMail > > > > Sent from ProtonMail Mobile > > > > On Mon, Jul 22, 2019 at 15:00, Mark H. Wood via Gnupg-users wrote: > > > > > On Mon, Jul 22, 2019 at 03:46:18PM +0000, Ryan McGinnis via Gnupg-users wrote: > > > > [1]https://www.schneier.com/blog/archives/2018/05/details_on_a_ne.html > > > > > > > > 3. Why is anyone using encrypted e-mail anymore, anyway? Reliably and > > > > easily encrypting e-mail is an insurmountably hard problem for reasons > > > > having nothing to do with today's announcement. If you need to > > > > communicate securely, use Signal. If having Signal on your phone will > > > > arouse suspicion, use WhatsApp. > > > > > > Depends on your threat model. For mine, reliably and easily > > > encrypting email is almost absurdly simple: > > > > > > 1) Use PGP > > > 2) Don't send secrets to people I don't trust to keep them. > > > > > > Anyway, 99% of my PGP use is for the opposite of secrecy: I sign my > > > emails so that (if you care enough to install PGP) you can be highly > > > assured that they're from me. > > > > > > -- > > > Mark H. Wood > > > Lead Technology Analyst > > > > > > University Library > > > Indiana University - Purdue University Indianapolis > > > 755 W. Michigan Street > > > Indianapolis, IN 46202 > > > 317-274-0749 > > > www.ulib.iupui.edu > > > _______________________________________________ > > > Gnupg-users mailing list > > > Gnupg-users at gnupg.org > > > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From bernd.lentes at helmholtz-muenchen.de Tue Jul 23 21:54:09 2019 From: bernd.lentes at helmholtz-muenchen.de (Lentes, Bernd) Date: Tue, 23 Jul 2019 21:54:09 +0200 (CEST) Subject: new to GPG: "gpg: Fatal: zlib inflate problem: invalid code lengths set" Message-ID: <1120323977.2720763.1563911649986.JavaMail.zimbra@helmholtz-muenchen.de> Hi ML, i'm new to GPG, so please excuse asking silly questions. I managed to create my keys with "gpg2 --gen-key" I wrote an e-Mail to adele at gnupp.de with the subject "Mein ?ffentlicher Schl?ssel", which is german for "my public key". Shortly thereafter i got an encrypted response which, i assume, i have to decrypt with my private key. I pasted the encrypted stuff into a file and then tried to decrypt: gpg2 -d nachricht.txt I've been asked for the passphrase for my private key which i entered, but then i got the following error: gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 "Bernd Lentes (Helmholtz GPG Schluessel) " gpg: Fatal: zlib inflate problem: invalid code lengths set The file has a size of 68 KB, could that be the culprit ? Bernd -- Bernd Lentes Systemadministration Institut f?r Entwicklungsgenetik Geb?ude 35.34 - Raum 208 HelmholtzZentrum m?nchen bernd.lentes at helmholtz-muenchen.de phone: +49 89 3187 1241 phone: +49 89 3187 3827 fax: +49 89 3187 2294 http://www.helmholtz-muenchen.de/idg Perfekt ist wer keine Fehler macht Also sind Tote perfekt Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Prof. Dr. Veronika von Messling Geschaeftsfuehrung: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Heinrich Bassler, Kerstin Guenther Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 From david at gbenet.com Wed Jul 24 02:56:04 2019 From: david at gbenet.com (David) Date: Wed, 24 Jul 2019 01:56:04 +0100 Subject: new to GPG: "gpg: Fatal: zlib inflate problem: invalid code lengths set" In-Reply-To: <1120323977.2720763.1563911649986.JavaMail.zimbra@helmholtz-muenchen.de> References: <1120323977.2720763.1563911649986.JavaMail.zimbra@helmholtz-muenchen.de> Message-ID: <4262cf52-4f5d-4d46-876c-02f0adc8290c@gbenet.com> Lentes, Bernd: > Hi ML, > > i'm new to GPG, so please excuse asking silly questions. > I managed to create my keys with "gpg2 --gen-key" > I wrote an e-Mail to adele at gnupp.de with the subject "Mein ?ffentlicher Schl?ssel", which is german for "my public key". > Shortly thereafter i got an encrypted response which, i assume, i have to decrypt with my private key. > I pasted the encrypted stuff into a file and then tried to decrypt: > > gpg2 -d nachricht.txt > > I've been asked for the passphrase for my private key which i entered, but then i got the following error: > > gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 > "Bernd Lentes (Helmholtz GPG Schluessel) " > gpg: Fatal: zlib inflate problem: invalid code lengths set > > The file has a size of 68 KB, could that be the culprit ? > > Bernd > The simpe rules are as follows: (1) You encrypt to another persons public key (2) You decrypt with your private key That's it! You can sign your emails - this means no one can tamper with them whilst in transit - if it was tampered with then there's an eror in the check sum of the message. Be happy! David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x5C6EE7FBAAD8C47D.asc Type: application/pgp-keys Size: 7763 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 885 bytes Desc: OpenPGP digital signature URL: From vedaal at nym.hush.com Wed Jul 24 03:36:36 2019 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 23 Jul 2019 21:36:36 -0400 Subject: Essay on PGP as it is used today In-Reply-To: <24500f0e-7943-f9aa-94a8-5176008f59e9@sixdemonbag.org> References: <20190722092611.296D4E0770@smtp.hushmail.com> <24500f0e-7943-f9aa-94a8-5176008f59e9@sixdemonbag.org> Message-ID: <20190724013636.4B681E0792@smtp.hushmail.com> On 7/22/2019 at 7:12 AM, "Robert J. Hansen" wrote: >Mathematicians have come up with different ways to estimate how >many >primes there were under a certain value ... >The first estimate for ?(x) was "x divided by the natural >logarithm of x". ... >If we do that same equation for a 2048-bit key, it turns out there >are >10 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 >000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 >000 000 >000 000 000 000 000 000 000 different prime numbers that could go >into it. ===== not really, for GnuPG keys, but for the default size GnuPG key of 4096, it's actually bigger than the number you quoted above ;-) For a GnuPG key of 4096, it's only necessary to compute for primes up to 2^2048. But, Since GnuPG uses 2 primes only in the 2^2048 size, for a 4096 bit key, then the amount of primes is actually: [ (2^2048) / ln(2^2048) ] - [ (2^2047) / ln (2^2047) ] = 1.37 x 10^613 So, not to worry about someone creating a 'database' to crack GnuPG ... vedaal From bernd.lentes at helmholtz-muenchen.de Wed Jul 24 11:52:16 2019 From: bernd.lentes at helmholtz-muenchen.de (Lentes, Bernd) Date: Wed, 24 Jul 2019 11:52:16 +0200 (CEST) Subject: new to GPG: "gpg: Fatal: zlib inflate problem: invalid code lengths set" In-Reply-To: <4262cf52-4f5d-4d46-876c-02f0adc8290c@gbenet.com> References: <1120323977.2720763.1563911649986.JavaMail.zimbra@helmholtz-muenchen.de> <4262cf52-4f5d-4d46-876c-02f0adc8290c@gbenet.com> Message-ID: <1398606081.3029766.1563961936725.JavaMail.zimbra@helmholtz-muenchen.de> ----- On Jul 24, 2019, at 2:56 AM, David david at gbenet.com wrote: > Lentes, Bernd: >> Hi ML, >> >> i'm new to GPG, so please excuse asking silly questions. >> I managed to create my keys with "gpg2 --gen-key" >> I wrote an e-Mail to adele at gnupp.de with the subject "Mein ?ffentlicher >> Schl?ssel", which is german for "my public key". >> Shortly thereafter i got an encrypted response which, i assume, i have to >> decrypt with my private key. >> I pasted the encrypted stuff into a file and then tried to decrypt: >> >> gpg2 -d nachricht.txt >> >> I've been asked for the passphrase for my private key which i entered, but then >> i got the following error: >> >> gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 >> "Bernd Lentes (Helmholtz GPG Schluessel) " >> gpg: Fatal: zlib inflate problem: invalid code lengths set >> >> The file has a size of 68 KB, could that be the culprit ? >> >> Bernd >> > > The simpe rules are as follows: > > (1) You encrypt to another persons public key > (2) You decrypt with your private key > Hi David, thanks for your response. I know these simple rules. > That's it! > > You can sign your emails - this means no one can tamper with them whilst > in transit - if it was tampered with then there's an eror in the check > sum of the message. > I sent a cleartext e-Mail with my public key to adele at gnupp.de (which is an automated system for practicing encryption and decryption) and i got an answer which is encrypted. I think it's encrypted with my public key so i should be able to decrypt it with my private key. That's what i tried. But i got the message while decrypting: gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 "Bernd Lentes (Helmholtz GPG Schluessel) " gpg: Fatal: zlib inflate problem: invalid code lengths set What does this meesage mean ? Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Prof. Dr. Veronika von Messling Geschaeftsfuehrung: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Heinrich Bassler, Kerstin Guenther Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 From johndoe65534 at mail.com Wed Jul 24 12:15:18 2019 From: johndoe65534 at mail.com (john doe) Date: Wed, 24 Jul 2019 12:15:18 +0200 Subject: new to GPG: "gpg: Fatal: zlib inflate problem: invalid code lengths set" In-Reply-To: <1398606081.3029766.1563961936725.JavaMail.zimbra@helmholtz-muenchen.de> References: <1120323977.2720763.1563911649986.JavaMail.zimbra@helmholtz-muenchen.de> <4262cf52-4f5d-4d46-876c-02f0adc8290c@gbenet.com> <1398606081.3029766.1563961936725.JavaMail.zimbra@helmholtz-muenchen.de> Message-ID: On 7/24/2019 11:52 AM, Lentes, Bernd wrote: > > ----- On Jul 24, 2019, at 2:56 AM, David david at gbenet.com wrote: > >> Lentes, Bernd: >>> Hi ML, >>> >>> i'm new to GPG, so please excuse asking silly questions. >>> I managed to create my keys with "gpg2 --gen-key" >>> I wrote an e-Mail to adele at gnupp.de with the subject "Mein ?ffentlicher >>> Schl?ssel", which is german for "my public key". >>> Shortly thereafter i got an encrypted response which, i assume, i have to >>> decrypt with my private key. >>> I pasted the encrypted stuff into a file and then tried to decrypt: >>> >>> gpg2 -d nachricht.txt >>> >>> I've been asked for the passphrase for my private key which i entered, but then >>> i got the following error: >>> >>> gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 >>> "Bernd Lentes (Helmholtz GPG Schluessel) " >>> gpg: Fatal: zlib inflate problem: invalid code lengths set >>> >>> The file has a size of 68 KB, could that be the culprit ? >>> >>> Bernd >>> >> >> The simpe rules are as follows: >> >> (1) You encrypt to another persons public key >> (2) You decrypt with your private key >> > > Hi David, > thanks for your response. > I know these simple rules. > >> That's it! >> >> You can sign your emails - this means no one can tamper with them whilst >> in transit - if it was tampered with then there's an eror in the check >> sum of the message. >> > > I sent a cleartext e-Mail with my public key to adele at gnupp.de (which is an automated system for practicing encryption and decryption) > and i got an answer which is encrypted. I think it's encrypted with my public key so i should be able > to decrypt it with my private key. That's what i tried. But i got the message while decrypting: > > gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 > "Bernd Lentes (Helmholtz GPG Schluessel) " > gpg: Fatal: zlib inflate problem: invalid code lengths set > > What does this meesage mean ? > > I might be rong here, but I would use build-in GPG capability in my e-mail client to decrypt the encrypted e-mail. Do you have the same error if you encrypt and decrypt a file? -- John Doe From bernd.lentes at helmholtz-muenchen.de Wed Jul 24 17:20:15 2019 From: bernd.lentes at helmholtz-muenchen.de (Lentes, Bernd) Date: Wed, 24 Jul 2019 17:20:15 +0200 (CEST) Subject: new to GPG: "gpg: Fatal: zlib inflate problem: invalid code lengths set" In-Reply-To: References: <1120323977.2720763.1563911649986.JavaMail.zimbra@helmholtz-muenchen.de> <4262cf52-4f5d-4d46-876c-02f0adc8290c@gbenet.com> <1398606081.3029766.1563961936725.JavaMail.zimbra@helmholtz-muenchen.de> Message-ID: <236001625.3236871.1563981615347.JavaMail.zimbra@helmholtz-muenchen.de> ----- On Jul 24, 2019, at 12:15 PM, john doe johndoe65534 at mail.com wrote: >> I sent a cleartext e-Mail with my public key to adele at gnupp.de (which is an >> automated system for practicing encryption and decryption) >> and i got an answer which is encrypted. I think it's encrypted with my public >> key so i should be able >> to decrypt it with my private key. That's what i tried. But i got the message >> while decrypting: >> >> gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 >> "Bernd Lentes (Helmholtz GPG Schluessel) " >> gpg: Fatal: zlib inflate problem: invalid code lengths set >> >> What does this meesage mean ? >> >> > > I might be rong here, but I would use build-in GPG capability in my > e-mail client to decrypt the encrypted e-mail. > > > Do you have the same error if you encrypt and decrypt a file? I just tried it and it worked like a charm with a file. Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Prof. Dr. Veronika von Messling Geschaeftsfuehrung: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Heinrich Bassler, Kerstin Guenther Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 From johndoe65534 at mail.com Wed Jul 24 17:58:51 2019 From: johndoe65534 at mail.com (john doe) Date: Wed, 24 Jul 2019 17:58:51 +0200 Subject: new to GPG: "gpg: Fatal: zlib inflate problem: invalid code lengths set" In-Reply-To: <236001625.3236871.1563981615347.JavaMail.zimbra@helmholtz-muenchen.de> References: <1120323977.2720763.1563911649986.JavaMail.zimbra@helmholtz-muenchen.de> <4262cf52-4f5d-4d46-876c-02f0adc8290c@gbenet.com> <1398606081.3029766.1563961936725.JavaMail.zimbra@helmholtz-muenchen.de> <236001625.3236871.1563981615347.JavaMail.zimbra@helmholtz-muenchen.de> Message-ID: <6b552ff5-9210-5e60-54f6-79119cb00781@mail.com> On 7/24/2019 5:20 PM, Lentes, Bernd wrote: > > > ----- On Jul 24, 2019, at 12:15 PM, john doe johndoe65534 at mail.com wrote: >>> I sent a cleartext e-Mail with my public key to adele at gnupp.de (which is an >>> automated system for practicing encryption and decryption) >>> and i got an answer which is encrypted. I think it's encrypted with my public >>> key so i should be able >>> to decrypt it with my private key. That's what i tried. But i got the message >>> while decrypting: >>> >>> gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 >>> "Bernd Lentes (Helmholtz GPG Schluessel) " >>> gpg: Fatal: zlib inflate problem: invalid code lengths set >>> >>> What does this meesage mean ? >>> >>> >> >> I might be rong here, but I would use build-in GPG capability in my >> e-mail client to decrypt the encrypted e-mail. >> >> >> Do you have the same error if you encrypt and decrypt a file? > > I just tried it and it worked like a charm with a file. > Quoting your original e-mail: "i'm new to GPG, so please excuse asking silly questions. I managed to create my keys with "gpg2 --gen-key" I wrote an e-Mail to adele at gnupp.de with the subject "Mein ?ffentlicher Schl?ssel", which is german for "my public key". Shortly thereafter i got an encrypted response which, i assume, i have to decrypt with my private key. I pasted the encrypted stuff into a file and then tried to decrypt: gpg2 -d nachricht.txt I've been asked for the passphrase for my private key which i entered, but then i got the following error: gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 "Bernd Lentes (Helmholtz GPG Schluessel) " gpg: Fatal: zlib inflate problem: invalid code lengths set The file has a size of 68 KB, could that be the culprit ?" Now addressing what I think is the culprit: You encrypt your e-mail with the public key of the recipient. When you are the recipient of an encrypted e-mail, the sender needs your publick key to be able to encrypt the e-mail that will be send to you. You, the recipient, will use your private key to decrypt this e-mail. That having been said, as far as I know, you need to configure your e-mail client (TB/Enigmail, Mutt ...) to do that for you . In otherwords, the encrypted stuff should not be pasted into the file "nachricht.txt". -- John Doe From bernd.lentes at helmholtz-muenchen.de Wed Jul 24 18:38:25 2019 From: bernd.lentes at helmholtz-muenchen.de (Lentes, Bernd) Date: Wed, 24 Jul 2019 18:38:25 +0200 (CEST) Subject: new to GPG: "gpg: Fatal: zlib inflate problem: invalid code lengths set" In-Reply-To: <6b552ff5-9210-5e60-54f6-79119cb00781@mail.com> References: <1120323977.2720763.1563911649986.JavaMail.zimbra@helmholtz-muenchen.de> <4262cf52-4f5d-4d46-876c-02f0adc8290c@gbenet.com> <1398606081.3029766.1563961936725.JavaMail.zimbra@helmholtz-muenchen.de> <236001625.3236871.1563981615347.JavaMail.zimbra@helmholtz-muenchen.de> <6b552ff5-9210-5e60-54f6-79119cb00781@mail.com> Message-ID: <703135219.3263593.1563986305818.JavaMail.zimbra@helmholtz-muenchen.de> ----- On Jul 24, 2019, at 5:58 PM, john doe johndoe65534 at mail.com wrote: >> > > Quoting your original e-mail: > > "i'm new to GPG, so please excuse asking silly questions. > I managed to create my keys with "gpg2 --gen-key" > I wrote an e-Mail to adele at gnupp.de with the subject "Mein ?ffentlicher > Schl?ssel", which is german for "my public key". > Shortly thereafter i got an encrypted response which, i assume, i have to > decrypt with my private key. > I pasted the encrypted stuff into a file and then tried to decrypt: > > gpg2 -d nachricht.txt > > I've been asked for the passphrase for my private key which i entered, > but then > i got the following error: > > gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 > "Bernd Lentes (Helmholtz GPG Schluessel) > " > gpg: Fatal: zlib inflate problem: invalid code lengths set > > The file has a size of 68 KB, could that be the culprit ?" > > Now addressing what I think is the culprit: > You encrypt your e-mail with the public key of the recipient. > When you are the recipient of an encrypted e-mail, the sender needs your > publick key to be able to encrypt the e-mail that will be send to you. > You, the recipient, will use your private key to decrypt this e-mail. > That's exactly what i did. I sent my Public key to adele at gnupp.de, which is a german project for GPG, and the server and adele are for practicing. Adele took my public key and sent me an e-Mail with some text and her public key, so i should be able to decrypt that with my private key. I don't have a plugin for my e-Mail-program because i just use the webinterface of the e-Mail-Server. Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Prof. Dr. Veronika von Messling Geschaeftsfuehrung: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Heinrich Bassler, Kerstin Guenther Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 From andrewg at andrewg.com Wed Jul 24 18:54:04 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 24 Jul 2019 17:54:04 +0100 Subject: new to GPG: "gpg: Fatal: zlib inflate problem: invalid code lengths set" In-Reply-To: <1398606081.3029766.1563961936725.JavaMail.zimbra@helmholtz-muenchen.de> References: <1120323977.2720763.1563911649986.JavaMail.zimbra@helmholtz-muenchen.de> <4262cf52-4f5d-4d46-876c-02f0adc8290c@gbenet.com> <1398606081.3029766.1563961936725.JavaMail.zimbra@helmholtz-muenchen.de> Message-ID: <44e0c668-402a-83a7-c494-718d82be75eb@andrewg.com> On 24/07/2019 10:52, Lentes, Bernd wrote: > I sent a cleartext e-Mail with my public key to adele at gnupp.de (which is an automated system for practicing encryption and decryption) > and i got an answer which is encrypted. I think it's encrypted with my public key so i should be able > to decrypt it with my private key. That's what i tried. But i got the message while decrypting: > > gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 > "Bernd Lentes (Helmholtz GPG Schluessel) " > gpg: Fatal: zlib inflate problem: invalid code lengths set > > What does this meesage mean ? Presuming that F742DB29 really is your key, then the message has been correctly encrypted to you. I've sent a few test messages to adele, but she doesn't seem to like the public key that I've sent her... :-/ It is possible that the message has been mangled in transit, or in the process of copying and pasting it into a file. Did you cut and paste from the raw email source, or from the formatted mail? Could it be that there are invalid characters in the pasted ciphertext? I'll send you a test message off-list. Let me know here if you get it, and if you can decrypt it. Feel free to include it in any replies so that we can see what format it gets to you in. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Wed Jul 24 18:55:13 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 24 Jul 2019 18:55:13 +0200 Subject: new to GPG: "gpg: Fatal: zlib inflate problem: invalid code lengths set" In-Reply-To: <703135219.3263593.1563986305818.JavaMail.zimbra@helmholtz-muenchen.de> References: <1120323977.2720763.1563911649986.JavaMail.zimbra@helmholtz-muenchen.de> <4262cf52-4f5d-4d46-876c-02f0adc8290c@gbenet.com> <1398606081.3029766.1563961936725.JavaMail.zimbra@helmholtz-muenchen.de> <236001625.3236871.1563981615347.JavaMail.zimbra@helmholtz-muenchen.de> <6b552ff5-9210-5e60-54f6-79119cb00781@mail.com> <703135219.3263593.1563986305818.JavaMail.zimbra@helmholtz-muenchen.de> Message-ID: <20190724185513.000059b7.sac@300baud.de> Lentes, Bernd wrote: > That's exactly what i did. > I sent my Public key to adele at gnupp.de, which is a german project for GPG, > and the server and adele are for practicing. > Adele took my public key and sent me an e-Mail with some text and her public > key, so i should be able to decrypt that with my private key. > > I don't have a plugin for my e-Mail-program because i just use the > webinterface of the e-Mail-Server. Maybe others can help you out when writing in English to: adele-en at gnupp.de. Regards Stefan From johndoe65534 at mail.com Wed Jul 24 19:08:59 2019 From: johndoe65534 at mail.com (john doe) Date: Wed, 24 Jul 2019 19:08:59 +0200 Subject: new to GPG: "gpg: Fatal: zlib inflate problem: invalid code lengths set" In-Reply-To: <703135219.3263593.1563986305818.JavaMail.zimbra@helmholtz-muenchen.de> References: <1120323977.2720763.1563911649986.JavaMail.zimbra@helmholtz-muenchen.de> <4262cf52-4f5d-4d46-876c-02f0adc8290c@gbenet.com> <1398606081.3029766.1563961936725.JavaMail.zimbra@helmholtz-muenchen.de> <236001625.3236871.1563981615347.JavaMail.zimbra@helmholtz-muenchen.de> <6b552ff5-9210-5e60-54f6-79119cb00781@mail.com> <703135219.3263593.1563986305818.JavaMail.zimbra@helmholtz-muenchen.de> Message-ID: On 7/24/2019 6:38 PM, Lentes, Bernd wrote: > > > ----- On Jul 24, 2019, at 5:58 PM, john doe johndoe65534 at mail.com wrote: > > > >>> >> >> Quoting your original e-mail: >> >> "i'm new to GPG, so please excuse asking silly questions. >> I managed to create my keys with "gpg2 --gen-key" >> I wrote an e-Mail to adele at gnupp.de with the subject "Mein ?ffentlicher >> Schl?ssel", which is german for "my public key". >> Shortly thereafter i got an encrypted response which, i assume, i have to >> decrypt with my private key. >> I pasted the encrypted stuff into a file and then tried to decrypt: >> >> gpg2 -d nachricht.txt >> >> I've been asked for the passphrase for my private key which i entered, >> but then >> i got the following error: >> >> gpg: encrypted with 2048-bit RSA key, ID F742DB29, created 2019-07-23 >> "Bernd Lentes (Helmholtz GPG Schluessel) >> " >> gpg: Fatal: zlib inflate problem: invalid code lengths set >> >> The file has a size of 68 KB, could that be the culprit ?" >> >> Now addressing what I think is the culprit: >> You encrypt your e-mail with the public key of the recipient. >> When you are the recipient of an encrypted e-mail, the sender needs your >> publick key to be able to encrypt the e-mail that will be send to you. >> You, the recipient, will use your private key to decrypt this e-mail. >> > > That's exactly what i did. > I sent my Public key to adele at gnupp.de, which is a german project for GPG, > and the server and adele are for practicing. > Adele took my public key and sent me an e-Mail with some text and her public key, > so i should be able to decrypt that with my private key. > > I don't have a plugin for my e-Mail-program because i just use the webinterface of the e-Mail-Server. > > In addition to "Andrew Gallagher "'s answer: Can't you use IMAP/POP3 to access your e-mail and SMTP to send your e-mail (1, my German is not that great)? 1) https://docplayer.org/2073295-Neue-e-mail-einstellungen-fuer-pop3-und-imap-benutzer.html -- John Doe From 2017-r3sgs86x8e-lists-groups at riseup.net Thu Jul 25 11:12:00 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Thu, 25 Jul 2019 10:12:00 +0100 Subject: Essay on PGP as it is used today In-Reply-To: <20190724013636.4B681E0792@smtp.hushmail.com> References: <20190722092611.296D4E0770@smtp.hushmail.com> <24500f0e-7943-f9aa-94a8-5176008f59e9@sixdemonbag.org> <20190724013636.4B681E0792@smtp.hushmail.com> Message-ID: <73907579.20190725101200@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 24 July 2019 at 2:36:36 AM, in , vedaal via Gnupg-users wrote:- > but for the default size GnuPG key of 4096, The default key size is 2048. That is the size generated if you use the --quick-generate-key command. - -- Best regards MFPA Man is not a rational animal, he is a rationalising animal. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXTlyd18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +gduAPwI2gnyutM1fWBgNJRZkU/ag0Ni30mH4mlRBG3JxT5ioQEA6qLqt2nJij3N YiuVpTOj/qNuTeV4E6vosZ2kRHY1RAKJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXTlyd18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/32ID/0bQmEOTJgd34X4zPBNhI639ERs DcyPxIfdTU6ax+e54Eq9Gt0shaMgyC0IGQGrRom2cBK+g9SB9TgKDa7Vj+ao1JOi Dzg29insC06OpYa365Suk5Ep5RnqaoyFgYg3x3+v1vqhu7vdQuFYfCGeRY0WaiZW 7QcBGHV5XOicSZVYXDhu5uFDE1DXfukysBjKOoa16xW15oAQi9PX0uKWytShuS28 Q40NTx8Rvhq79XoeO71tKX9WQ+ZO0juXu3nwPeGG/r6kLEKOhTiSaQ2u5GL6oC4o Obz29/jVwUTPODRjYQ97aRpUtRJ8pGposAX6CPBD3e0UZV5mZlfgsvXwGtv81zMS tZYvG5L5myf85TvGjSWinetMORL6R0OjWab5oB2hkE7VoCkffRFVoutd2Y6LFknB NZK4Q9WGvSFkzk7w5o9GABB8b76d0Yz14cWV9egeyzHU7rwoqaw127lfdKL8MUZ+ c3FDQ4B7zO2NCDYESsuUOsSuImd/+NNsZH9QjuwaGzou3TQw4T03uDsemPQ5pBEb WiZmTOsoXvkmTcwnu7o1HmfmZ/C9Xq8rNLeh7kAxrHnAERDhSCuKz7CQH0h7Tc9i iSuasPhX1XCX2AXXXdcN3Bw/SokgBRzrn4+mh3IejUv/KaFqwKcg05tJM9MWtoEo CHnfniEoaNb/C/Llpg== =GKS4 -----END PGP SIGNATURE----- From kynnjo at gmail.com Thu Jul 25 15:46:44 2019 From: kynnjo at gmail.com (Kynn Jones) Date: Thu, 25 Jul 2019 09:46:44 -0400 Subject: Need to implement a gpg/gpg2-compatible tool to encrypt millions of files in unsupervised mode Message-ID: Hi everyone, First, please allow me to define a bit of ad-hoc nomenclature. I will use the uppercase tems "ENCRYPT", "ENCRYPTION", etc. as shorthands for "compress and AES256-encrypt", "compression and AES256 encryption", etc. Likewise, I will use "DECRYPT", etc. as shorthands for "[AES256] decrypt and decompress", etc. I need to ENCRYPT ~20 million files (~150TB) for long-term (>15y) storage. This ENCRYPTION will be done in several batches, and will take place over many months (due to CPU and bandwidth limitations). The ideal solution would produce ENCRYPTED files that can be decrypted using standard off-the-shelf gpg/gpg2. [1] In my search for a library I could use to do this, I found gpgme and libgcrypt. I tried the former, and found it not suitable, due to frequent gpg-agent-related failures. libgcrypt, on the other hand, is a bit too low-level for someone who is not acquainted with the fine details of gpg's ENCRYPTION to replicate it. (AFAICT, using straight-up gcry_cipher_encrypt would not necessarily produce an encrypted file (let alone an ENCRYPTED file) that could be decrypted/DECRYPTED with standard gpg/gpg2.) Is there something in-between gpgme and libgcrypt that would allow me implement the required tool? *Alternatively*, can someone tell me of a more efficient way than reading the gpg2 source code for me to learn how to implement gpg-compatible ENCRYPTION/DECRYPTION using libgcrypt? Thank you all in advance! kj [1] This gpg/gpg2 compatibility requirement is important, as an insurance that the files will be DECRYPTABLE in the "distant" future (10-15y), even the my tool is not properly enough maintained to be operational then. This, of course, assumes that gpg will have greater longevity than a privately implemented, single-user tool like mine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kynnjo at gmail.com Thu Jul 25 20:00:08 2019 From: kynnjo at gmail.com (Kynn Jones) Date: Thu, 25 Jul 2019 14:00:08 -0400 Subject: Where is the "INTEROPERABILITY WITH OTHER OPENPGP PROGRAMS section"? Message-ID: Hi! The GnuPG documentation refers to an "INTEROPERABILITY WITH OTHER OPENPGP PROGRAMS section", but when I search for this title, I find only references to it, not the actual section. Does any one know where that section is? Thank you in advance, kj -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Jul 25 21:22:46 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 25 Jul 2019 15:22:46 -0400 Subject: Need to implement a gpg/gpg2-compatible tool to encrypt millions of files in unsupervised mode In-Reply-To: References: Message-ID: > First, please allow me to define a bit of ad-hoc > nomenclature.? I will use the uppercase tems "ENCRYPT", > "ENCRYPTION", etc. as shorthands for "compress and > AES256-encrypt", "compression and AES256 encryption", etc. > Likewise, I will use "DECRYPT", etc. as shorthands for > "[AES256] decrypt and decompress", etc. For a straightforward purely-symmetric use case, consider using OpenSSL. Just use it wisely: specify your own key and initialization vector, rather than trust OpenSSL's weak password derivation function. $ tar -cJf - mydir | openssl aes-128-cbc -out foo.txz -K DEADBEEFDEADBEEFDEADBEEFDEADBEEF -iv DEADBEEFDEADBEEFDEADBEEFDEADBEEF -out mydir.txz.aes Don't get me wrong: GnuPG can definitely do the job you want. But consider whether you really need RFC4880's baroque packet format, weird CFB mode, and everything else. Sometimes there's a lot to be said for simplicity. > [1] This gpg/gpg2 compatibility requirement is important, as > an insurance that the files will be DECRYPTABLE in the > "distant" future (10-15y), even the my tool is not properly > enough maintained to be operational then.? This, of course, > assumes that gpg will have greater longevity than a privately > implemented, single-user tool like mine. OpenSSL meets your requirement. From dkg at fifthhorseman.net Thu Jul 25 22:10:46 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 25 Jul 2019 16:10:46 -0400 Subject: Where is the "INTEROPERABILITY WITH OTHER OPENPGP PROGRAMS section"? In-Reply-To: References: Message-ID: <87o91hx4c9.fsf@fifthhorseman.net> On Thu 2019-07-25 14:00:08 -0400, Kynn Jones via Gnupg-users wrote: > The GnuPG documentation refers to an "INTEROPERABILITY WITH > OTHER OPENPGP PROGRAMS section", but when I search for this > title, I find only references to it, not the actual section. > > Does any one know where that section is? It appears to be in the info page, which (on my system) i can access with "info gpg" and then searching for "interoperability". In the manual page (gpg(1), accessed via "man 1 gpg") the section is titled just "INTEROPERABILITY" (why this difference between info and man? I don't know or understand!) I reproduce the current version out of info (from 2.2.17) below. Regards, --dkg INTEROPERABILITY WITH OTHER OPENPGP PROGRAMS ******************************************** GnuPG tries to be a very flexible implementation of the OpenPGP standard. In particular, GnuPG implements many of the optional parts of the standard, such as the SHA-512 hash, and the ZLIB and BZIP2 compression algorithms. It is important to be aware that not all OpenPGP programs implement these optional algorithms and that by forcing their use via the '--cipher-algo', '--digest-algo', '--cert-digest-algo', or '--compress-algo' options in GnuPG, it is possible to create a perfectly valid OpenPGP message, but one that cannot be read by the intended recipient. There are dozens of variations of OpenPGP programs available, and each supports a slightly different subset of these optional algorithms. For example, until recently, no (unhacked) version of PGP supported the BLOWFISH cipher algorithm. A message using BLOWFISH simply could not be read by a PGP user. By default, GnuPG uses the standard OpenPGP preferences system that will always do the right thing and create messages that are usable by all recipients, regardless of which OpenPGP program they use. Only override this safe default if you really know what you are doing. If you absolutely must override the safe default, or if the preferences on a given key are invalid for some reason, you are far better off using the '--pgp6', '--pgp7', or '--pgp8' options. These options are safe as they do not force any particular algorithms in violation of OpenPGP, but rather reduce the available algorithms to a "PGP-safe" list. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kynnjo at gmail.com Thu Jul 25 22:28:08 2019 From: kynnjo at gmail.com (Kynn Jones) Date: Thu, 25 Jul 2019 16:28:08 -0400 Subject: Where is the "INTEROPERABILITY WITH OTHER OPENPGP PROGRAMS section"? In-Reply-To: <87o91hx4c9.fsf@fifthhorseman.net> References: <87o91hx4c9.fsf@fifthhorseman.net> Message-ID: @Daniel : thanks!!! On Thu, Jul 25, 2019 at 4:11 PM Daniel Kahn Gillmor wrote: > On Thu 2019-07-25 14:00:08 -0400, Kynn Jones via Gnupg-users wrote: > > The GnuPG documentation refers to an "INTEROPERABILITY WITH > > OTHER OPENPGP PROGRAMS section", but when I search for this > > title, I find only references to it, not the actual section. > > > > Does any one know where that section is? > > It appears to be in the info page, which (on my system) i can access > with "info gpg" and then searching for "interoperability". In the > manual page (gpg(1), accessed via "man 1 gpg") the section is titled > just "INTEROPERABILITY" (why this difference between info and man? I > don't know or understand!) > > I reproduce the current version out of info (from 2.2.17) below. > > Regards, > > --dkg > > INTEROPERABILITY WITH OTHER OPENPGP PROGRAMS > ******************************************** > > GnuPG tries to be a very flexible implementation of the OpenPGP > standard. In particular, GnuPG implements many of the optional parts of > the standard, such as the SHA-512 hash, and the ZLIB and BZIP2 > compression algorithms. It is important to be aware that not all > OpenPGP programs implement these optional algorithms and that by forcing > their use via the '--cipher-algo', '--digest-algo', > '--cert-digest-algo', or '--compress-algo' options in GnuPG, it is > possible to create a perfectly valid OpenPGP message, but one that > cannot be read by the intended recipient. > > There are dozens of variations of OpenPGP programs available, and > each supports a slightly different subset of these optional algorithms. > For example, until recently, no (unhacked) version of PGP supported the > BLOWFISH cipher algorithm. A message using BLOWFISH simply could not be > read by a PGP user. By default, GnuPG uses the standard OpenPGP > preferences system that will always do the right thing and create > messages that are usable by all recipients, regardless of which OpenPGP > program they use. Only override this safe default if you really know > what you are doing. > > If you absolutely must override the safe default, or if the > preferences on a given key are invalid for some reason, you are far > better off using the '--pgp6', '--pgp7', or '--pgp8' options. These > options are safe as they do not force any particular algorithms in > violation of OpenPGP, but rather reduce the available algorithms to a > "PGP-safe" list. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kynnjo at gmail.com Thu Jul 25 22:59:51 2019 From: kynnjo at gmail.com (Kynn Jones) Date: Thu, 25 Jul 2019 16:59:51 -0400 Subject: Need to implement a gpg/gpg2-compatible tool to encrypt millions of files in unsupervised mode In-Reply-To: References: Message-ID: On Thu, Jul 25, 2019 at 3:26 PM Robert J. Hansen wrote: > > First, please allow me to define a bit of ad-hoc > > nomenclature. I will use the uppercase tems "ENCRYPT", > > "ENCRYPTION", etc. as shorthands for "compress and > > AES256-encrypt", "compression and AES256 encryption", etc. > > Likewise, I will use "DECRYPT", etc. as shorthands for > > "[AES256] decrypt and decompress", etc. > > For a straightforward purely-symmetric use case, consider using OpenSSL. > Just use it wisely: specify your own key and initialization vector, > rather than trust OpenSSL's weak password derivation function. > > $ tar -cJf - mydir | openssl aes-128-cbc -out foo.txz -K > DEADBEEFDEADBEEFDEADBEEFDEADBEEF -iv DEADBEEFDEADBEEFDEADBEEFDEADBEEF > -out mydir.txz.aes > Pardon my ignorance, but I gather from this example that I would have to manage not only passphrases but also iv's as well? (That would add to my work's complexity.) Don't get me wrong: GnuPG can definitely do the job you want. But > consider whether you really need RFC4880's baroque packet format, weird > CFB mode, and everything else. Sometimes there's a lot to be said for > simplicity. > Thank you. This is a valuable perspective. I'm all for simplicity! In fact, if I could have it my way, I would use a library that does nothing more than AES256-encrypt/decrypt (as long as I had any confidence that it would still be maintained 5 years from now). In other words, I would love to use a single-purpose tool that is to AES256-encryption/decryption what, for example, gzip is to compression/decompression. Unfortunately, I have not been able to hit upon such a tool, which I find a bit mystifying. Instead, all the tools I have found fall into two distinct categories: (1) ephemeral projects; (2) large systems (like GnuPG or OpenSSL) in which the AES256-encryption/decryption capability is such tiny subcomponent that it is very difficult for me to find out what I need to do for my purposes. (Who knows, maybe in the cryptography domain, complex multifunctionality is what give systems their longevity.) > [1] This gpg/gpg2 compatibility requirement is important, as > > an insurance that the files will be DECRYPTABLE in the > > "distant" future (10-15y), even the my tool is not properly > > enough maintained to be operational then. This, of course, > > assumes that gpg will have greater longevity than a privately > > implemented, single-user tool like mine. > > OpenSSL meets your requirement. > I assume that by this you mean that OpenSSL will still be around 10-15 years from now, and *not* that one can use gpg to decrypt an openssl-encrypted file. (Please correct me if I'm wrong!) Thank you again! kj -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Jul 25 23:26:28 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 25 Jul 2019 17:26:28 -0400 Subject: Need to implement a gpg/gpg2-compatible tool to encrypt millions of files in unsupervised mode In-Reply-To: References: Message-ID: > Pardon my ignorance, but I gather from this example that I would have > to manage not only passphrases but also iv's as well?? (That would add > to my work's complexity.) An AES256 key is only 32 bytes long; an IV, only 16. Keeping track of 48 bytes to decrypt your files isn't exactly a lot. You can fit this on the back of a business card with room left over. I've done it before. Passphrase-based crypto works by converting a passphrase into a (seemingly) random series of bytes. The problem is OpenSSL's passphrase-to-bytes routine is pretty badly substandard. Specify your own key and IV. > In fact, if I could have it my way, I would use a library that does > nothing more than AES256-encrypt/decrypt (as long as I had any > confidence that it would still be maintained 5 years from now). Which language are you looking to use? C#, Java, and Python all include AES256 in the standard library and have excellent long-term support. Many other languages offer it as well. Python has some excellent PyPI packages like passlib and Crypto which can make your task much simpler. > In other words, I would love to use a single-purpose tool that is to > AES256-encryption/decryption what, for example, gzip is to > compression/decompression. OpenSSL. Look at the command line I gave you: it's used as part of a pipeline that creates a tar archive and encrypted output all in one go. > I assume that by this you mean that OpenSSL will still be around 10-15 > years from now Yes. We're getting pretty far afield from GnuPG here: please feel free to follow up off-list. Thank you! :) From david at gbenet.com Fri Jul 26 11:53:59 2019 From: david at gbenet.com (David) Date: Fri, 26 Jul 2019 10:53:59 +0100 Subject: Web Key Directory Message-ID: Hello All, If I create a folder on my server WKSDirectory" then upload my public keys to it - and then give the: https//gbenet.com/wksdirectory - will this do for my key retrieval? They then just pick the public key they want to download????? It's uncomplicated :) David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! https://gbenet.com From brad at fineby.me.uk Fri Jul 26 12:58:53 2019 From: brad at fineby.me.uk (Brad Rogers) Date: Fri, 26 Jul 2019 11:58:53 +0100 Subject: Web Key Directory In-Reply-To: References: Message-ID: <20190726115853.478af88e@abydos.stargate.org.uk> On Fri, 26 Jul 2019 10:53:59 +0100 David wrote: Hello David, >https//gbenet.com/wksdirectory - will this do for my key retrieval? AIUI, that won't work - there are specific requirements regarding key location along with directories and files and their naming that are required. See https://wiki.gnupg.org/WKDHosting -- Regards _ / ) "The blindingly obvious is / _)rad never immediately apparent" We don't give a damn One Chord Wonders - The Adverts -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From vijaikumar.kanagarajan at gmail.com Fri Jul 26 12:27:19 2019 From: vijaikumar.kanagarajan at gmail.com (Vijai Kumar K) Date: Fri, 26 Jul 2019 15:57:19 +0530 Subject: Commands supported by extra socket Message-ID: <20190726102719.GC24622@chikyu> Hi All, Where can I find information on what commands are supported by S.gpg-agent and S.gpg-agent.extra socket? I am looking for some information which clearly differentiates these two sockets. Thanks, Vijai Kumar K From angel at pgp.16bits.net Sat Jul 27 00:16:50 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sat, 27 Jul 2019 00:16:50 +0200 Subject: tool to encrypt millions of files in unsupervised mode (was: Need to implement a gpg/gpg2-compatible tool...) In-Reply-To: References: Message-ID: <1564179410.1075.16.camel@16bits.net> On 2019-07-25 at 16:59 -0400, Kynn Jones via Gnupg-users wrote: > In other words, I would love to use a single-purpose tool that is to > AES256-encryption/decryption what, for example, gzip is to > compression/decompression. > > Unfortunately, I have not been able to hit upon such a tool, which I > find a bit mystifying. Instead, all the tools I have found fall into > two distinct categories: (1) ephemeral projects; (2) large systems > (like GnuPG or OpenSSL) in which the AES256-encryption/decryption > capability is such tiny subcomponent that it is very difficult for me > to find out what I need to do for my purposes. A single-purpose tool that only did AES265-encryption would be finished, needing little to no mainteinance and thus looking like an ephemeral project. AES specification itself is fixed and unlikely to go away (even though in 15 years maybe we will all be using a completely different encryption system). I think the main risk you would bear using a little-test tool would be that it was somehow flawed in a subtle way so that other tools failed to decrypt a tiny fraction of the files. I recommend you to also keep hashes of the original files (maybe in a different encrypted file) in addition to whatever authentication system you plan to be using. Plus, obviously, keeping a copy of the encryption tool (both compiled and in source form) along the backups. As for the actual format to use, I would suggest using zip files with AES encryption. There are many programs supporting it, and it is nowadays an ubiquitousformat (albeit AES encryption support is lower, that is still much bigger than for eg. an openssl enc format). It seems likely that there will still be programs able to decrypt them, even if the original program no longer works. Nevertheless, with a goal like this, you should include a plan wherein there are periodic tests of the data, in which a goal can be to detect that it is no longer possible to decrypt them with commonplace hardware, and perform a migration to a more modern (and supported) encryption schema if actually needed. Best regards From kynnjo at gmail.com Sat Jul 27 03:08:30 2019 From: kynnjo at gmail.com (Kynn Jones) Date: Fri, 26 Jul 2019 21:08:30 -0400 Subject: tool to encrypt millions of files in unsupervised mode (was: Need to implement a gpg/gpg2-compatible tool...) In-Reply-To: <1564179410.1075.16.camel@16bits.net> References: <1564179410.1075.16.camel@16bits.net> Message-ID: On Fri, Jul 26, 2019 at 6:20 PM ?ngel wrote: > On 2019-07-25 at 16:59 -0400, Kynn Jones via Gnupg-users wrote: > > In other words, I would love to use a single-purpose tool that is to > > AES256-encryption/decryption what, for example, gzip is to > > compression/decompression. > > > > Unfortunately, I have not been able to hit upon such a tool, which I > > find a bit mystifying. Instead, all the tools I have found fall into > > two distinct categories: (1) ephemeral projects; (2) large systems > > (like GnuPG or OpenSSL) in which the AES256-encryption/decryption > > capability is such tiny subcomponent that it is very difficult for me > > to find out what I need to do for my purposes. > > A single-purpose tool that only did AES265-encryption would be finished, > needing little to no mainteinance and thus looking like an ephemeral > project. > I see, good point. > I think the main risk you would bear using a little-test tool would be > that it was somehow flawed in a subtle way so that other tools failed to > decrypt a tiny fraction of the files. > Thank you for the heads-up. I had not considered this risk at all until now. I wonder if I can find a good set of test cases, maybe by cannibalizing the test suites of other programs. > > I recommend you to also keep hashes of the original files (maybe in a > different encrypted file) in addition to whatever authentication system > you plan to be using. Plus, obviously, keeping a copy of the encryption > tool (both compiled and in source form) along the backups. > > As for the actual format to use, I would suggest using zip files with > AES encryption. There are many programs supporting it, and it is > nowadays an ubiquitousformat (albeit AES encryption support is lower, > that is still much bigger than for eg. an openssl enc format). It seems > likely that there will still be programs able to decrypt them, even if > the original program no longer works. > > Nevertheless, with a goal like this, you should include a plan wherein > there are periodic tests of the data, in which a goal can be to detect > that it is no longer possible to decrypt them with commonplace hardware, > and perform a migration to a more modern (and supported) encryption > schema if actually needed. > All very sensible advice. Thank you! kj -------------- next part -------------- An HTML attachment was scrubbed... URL: From al-gnupg_users at none.at Sat Jul 27 16:50:36 2019 From: al-gnupg_users at none.at (Aleksandar Lazic) Date: Sat, 27 Jul 2019 16:50:36 +0200 Subject: Need to implement a gpg/gpg2-compatible tool to encrypt millions of files in unsupervised mode In-Reply-To: References: Message-ID: Hi. Am 25.07.2019 um 15:46 schrieb Kynn Jones via Gnupg-users: > Hi everyone, > > First, please allow me to define a bit of ad-hoc > nomenclature.? I will use the uppercase tems "ENCRYPT", > "ENCRYPTION", etc. as shorthands for "compress and > AES256-encrypt", "compression and AES256 encryption", etc. > Likewise, I will use "DECRYPT", etc. as shorthands for > "[AES256] decrypt and decompress", etc. > > I need to ENCRYPT ~20 million files (~150TB) for long-term > (>15y) storage.? This ENCRYPTION will be done in several > batches, and will take place over many months (due to CPU and > bandwidth limitations). > > The ideal solution would produce ENCRYPTED files that can be > decrypted using standard off-the-shelf gpg/gpg2. [1] > > In my search for a library I could use to do this, I found > gpgme and libgcrypt.? I tried the former, and found it not > suitable, due to frequent gpg-agent-related failures. > > libgcrypt, on the other hand, is a bit too low-level for > someone who is not acquainted with the fine details of gpg's > ENCRYPTION to replicate it.? (AFAICT, using straight-up > gcry_cipher_encrypt would not necessarily produce an > encrypted file (let alone an ENCRYPTED file) that could be > decrypted/DECRYPTED with standard gpg/gpg2.) > > Is there something in-between gpgme and libgcrypt that would > allow me implement the required tool? > > *Alternatively*, can someone tell me of a more efficient way > than reading the gpg2 source code for me to learn how to > implement gpg-compatible ENCRYPTION/DECRYPTION using > libgcrypt? > > Thank you all in advance! Have you take a look into libsodium based tools? https://download.libsodium.org/doc/libsodium_users For example https://github.com/TLINDEN/pcp > kj Best regards Aleks > [1] This gpg/gpg2 compatibility requirement is important, as > an insurance that the files will be DECRYPTABLE in the > "distant" future (10-15y), even the my tool is not properly > enough maintained to be operational then.? This, of course, > assumes that gpg will have greater longevity than a privately > implemented, single-user tool like mine. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From kynnjo at gmail.com Sat Jul 27 19:06:36 2019 From: kynnjo at gmail.com (Kynn Jones) Date: Sat, 27 Jul 2019 13:06:36 -0400 Subject: Need to implement a gpg/gpg2-compatible tool to encrypt millions of files in unsupervised mode In-Reply-To: References: Message-ID: On Sat, Jul 27, 2019 at 10:50 AM Aleksandar Lazic wrote: > Have you take a look into libsodium based tools? > https://download.libsodium.org/doc/libsodium_users > No I hadn't. Thank you, it looks amazing. (Still need to wrap my head around it.) kj -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Sun Jul 28 15:12:45 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sun, 28 Jul 2019 14:12:45 +0100 Subject: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information Message-ID: <501932509.20190728141245@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi I have the option "allow-non-selfsigned-uid" in my gpg.conf. I downloaded a key from keys.openpgp.org with no identity information. GnuPG told me:- gpg: Invalid key 0x84D0F6B3F5007E2C made valid by --allow-non-selfsigned-uid but still didn't import the key. This suggests that the message was incorrect and the key was not made valid by the - --allow-non-selfsigned-uid option. I used pgpdump to visualise the packets, and could see no User ID Packet. There was not a non-selfsigned-uid; there was no UID at all. - -- Best regards MFPA People who throw kisses are hopelessly lazy. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXT2fXl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +vR+AP0VwqIvIeaIq1+0TS1d6ObF8+qsLpT4l96E6xXOJeNjMAEA5i/7rY6oK46a ET8s4cYdJuN7YLsim+ZZK8g+Z7aMgQyJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXT2fXl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/8weD/42PTuJYGb/knQ+Y38CoT52oIYI GshQ3EkOiH4u7rTRtiImtk6RwaKqNmUJnBYbXHXotUh+1x0N82MIiqeeqjG+1ZXa /Imxsjua5HAjfWgBD8zWM+ee5DlT8PAuHoIJ9DHsjVAmz6rOECEi8nDAmaf4Ph/T 8LETHTeaO8oi/G4OFegOcPcT3pSiUjw4oowx4t3egvnRxmv3BFIxqWvcNKT9aS0h zmgfYEyRz0SyrAxzLFtlD3JNkq5cAOf3jLvjVTDCP6/kIltpfJG3vTYIviF4sVpW nb4SY7eXfKalxJp5FvFGW5Xi15oF46OyxtFIkn0EATMNoOGb3F4U1v/fU5pTOPr+ 29PXYmf3jvLECuQe1kDos7puEXLBBLyjQJn0GqTGKqn9Pu/9dgeAXMQK2CU/brwm WStWg3zUnHpKXr0GKgU7cJ2qZvO20a1YQeG+sWWnMN/JMm/IzKphAca5ely6CqXe zADss/lWMBR1MKInaVe2mZTzrHxEGQQJP4gaNEaxH5pEAch/MVEdlLLuE8MuXEdd aBu4ZdINdctlwqktMjHlGCA7W15ujZkBiQgKBujjMILx1rYmcOqp+fdOolTOGOif WIYF6rhqIQiSBlkWsSyxM+bbVXKAITKHmrwrq/8my4Ram2/eTMbwLt5XaiZ1/Nbx gLMHLsHGnVsYVH+bEA== =fY43 -----END PGP SIGNATURE----- From thomas.orgis at uni-hamburg.de Mon Jul 29 10:03:02 2019 From: thomas.orgis at uni-hamburg.de (Dr. Thomas Orgis) Date: Mon, 29 Jul 2019 10:03:02 +0200 Subject: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm In-Reply-To: <20190720200737.6b6f69c4@plasteblaster> References: <20190718183341.46b5b7a4@cortex.rrz.uni-hamburg.de> <1a62fe5742d096d35d4ef5d6b8a7722b3fb43e44.camel@googlemail.com> <20190720200737.6b6f69c4@plasteblaster> Message-ID: <20190729100302.65c677f8@plasteblaster> Am Sat, 20 Jul 2019 20:07:37 +0200 schrieb "Dr. Thomas Orgis" : > The issue I see is that > these certs are not even supposed to be in the chain! > the presence of the old certificates stirs things up. When I create a > fresh user and import the new key with its certs into gpgsm, the chain > looks like it should. Shall I open a bug report about this behaviour? Any investigation I could do to make the report more useful? Regards, Thomas -- Dr. Thomas Orgis HPC @ Universit?t Hamburg From dkg at fifthhorseman.net Mon Jul 29 15:43:54 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 29 Jul 2019 09:43:54 -0400 Subject: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information In-Reply-To: <501932509.20190728141245@my_localhost_LG> References: <501932509.20190728141245@my_localhost_LG> Message-ID: <87pnltt0px.fsf@fifthhorseman.net> Hi MFPA-- On Sun 2019-07-28 14:12:45 +0100, MFPA via Gnupg-users wrote: > I have the option "allow-non-selfsigned-uid" in my gpg.conf. A bit of background first, since the documentation around allow-non-selfsigned-uid appears to be confusing/mistaken. the manual says: --allow-non-selfsigned-uid --no-allow-non-selfsigned-uid Allow the import and use of keys with user IDs which are not self-signed. This is not recommended, as a non self-signed user ID is trivial to forge. --no-allow-non-selfsigned-uid disables. But in fact the default (--no-allow-non-selfsigned-uid) does not actually disallow the import or use of an OpenPGP certificate with a user ID which is not self-signed; it simply strips any non-self-signed user IDs from the certificate, and then deals with the remaining trimmed-down certificate as it would have had those user IDs not been present. But none of this means that a certificate *without* any user ID at all is the same as a certificate with a user ID that happens to be unsigned. (though it's trivial to get from the former to the latter by injecting an arbitrary user ID packet into the certificate stream) before any subkey packets. > I downloaded a key from keys.openpgp.org with no identity information. > > GnuPG told me:- > gpg: Invalid key 0x84D0F6B3F5007E2C made valid by --allow-non-selfsigned-uid > but still didn't import the key. This suggests that the message was > incorrect and the key was not made valid by the > --allow-non-selfsigned-uid option. > > I used pgpdump to visualise the packets, and could see no User ID > Packet. There was not a non-selfsigned-uid; there was no UID at all. RFC 4880 mandates a user ID in any "Transferable Public Key" (aka "OpenPGP certificate"): https://tools.ietf.org/html/rfc4880#section-11.1 However, there is an expectation of relaxing this in the next revision of the standard: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-07#section-11.1 GnuPG currently rejects OpenPGP certificates that lack any user ID at all, in part because it is more difficult to manipulate them (they have no user ID to refer to them by), and in part because "we've always done it that way", i think. Perhaps Werner can provide more background on why GnuPG is generally resistant to holding OpenPGP certificates that have no User ID at all in its local keyring. All that said, it's possible for GnuPG to merge a uid-less certificate (including e.g. subkeys, revocation certificates, etc) with a locally-held certificate (i.e., in the "keyring") that *does* have a user ID, so long as both certificates share the same primary key. The resultant merged certificate will have a user ID, and can be reasoned about using the same logic that GnuPG already expects, even if the incoming uid-less certificate would have been ignored if it were imported into an otherwise empty keyring. Doing such a merge would be super helpful, particularly for receiving things like subkey updates and revocation information from abuse-resistant keystores like keys.openpgp.org. The good news is that there are patches outstanding for GnuPG to do so: https://dev.gnupg.org/T4393 If you're using debian or a debian-derived installation of GnuPG, those patches have been merged as of version 2.2.16-2 (ses https://bugs.debian.org/930665), and i'm currently trying to get them merged for the next stable point release of debian "buster" (see https://bugs.debian.org/932684). Hopefully GnuPG will follow suit upstream, as these patches provide critical security defenses for users who refresh their keyrings to check for revocations and subkey rotation. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From thomas.orgis at uni-hamburg.de Tue Jul 30 13:28:32 2019 From: thomas.orgis at uni-hamburg.de (Dr. Thomas Orgis) Date: Tue, 30 Jul 2019 13:28:32 +0200 Subject: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm In-Reply-To: <1563749048.1449.5.camel@16bits.net> References: <20190718183341.46b5b7a4@cortex.rrz.uni-hamburg.de> <1a62fe5742d096d35d4ef5d6b8a7722b3fb43e44.camel@googlemail.com> <20190720200737.6b6f69c4@plasteblaster> <1563749048.1449.5.camel@16bits.net> Message-ID: <20190730132832.60ce70a5@cortex.rrz.uni-hamburg.de> Am Mon, 22 Jul 2019 00:44:08 +0200 schrieb ?ngel : > Well, it seems that ?T-TeleSec GlobalRoot Class 2? was cross-signed by > ?Deutsche Telekom Root CA 2?. > This is typically done with new roots so that people with an older set > of roots can trust it through an older one. Right. But if this is standard procedure ? > Now, your problem is that the old Root CA expired and your client is not > able to find the new trust path. > I would probably try deleting the T-TeleSec GlobalRoot Class 2 and > reimporting it from the root, to see if that helps. ? why does it lead to this situation? I now simply deleted the offending cross-certificate via gpgsm --delete-key 0x61A8CF44 and now gpgsm happily accepts the new root cert. So, removal of an expired signature makes the chain valid. Shouldn't gnupg the just ignore the expired signature? I went further now, deleting the root cert itself: gpgsm --delete-key 0x17D894E9 But I figure that this does not matter at all, as dirmngr has it. I now fail to understand where the cross-signature came from. I don't see it in the certificate file I exported from Firefox (browser-based certification process). I don't see it in the root certificate file that is offered separately for download. As I still have a backup of my .gnupg folder, can I trace where the cross-signature entered the picture? And even with it present, is it correct behaviour for gpgsm to consider the chain invalid instead of just the cross-signature? It _does_ trust the new root cert already ? no need for any further signature. Regards, Thomas PS: Just for fun, I'm trying to sign this post now. Maybe it won't even be broken by the list? -- Dr. Thomas Orgis HPC @ Universit?t Hamburg -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4984 bytes Desc: not available URL: From david at gbenet.com Tue Jul 30 16:09:12 2019 From: david at gbenet.com (David) Date: Tue, 30 Jul 2019 15:09:12 +0100 Subject: Enigmail Message-ID: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> Hello Everyone, I am looking for an alternative to Enigmail - which fails to work. Any ideas as to a suitable replacement?? Regards David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com From sac at 300baud.de Tue Jul 30 16:23:14 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 30 Jul 2019 16:23:14 +0200 Subject: Enigmail In-Reply-To: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> Message-ID: <20190730162314.000021d8.sac@300baud.de> David wrote: > Hello Everyone, > > I am looking for an alternative to Enigmail - which fails to work. > Any ideas as to a suitable replacement?? You may check out another MUA, like Claws-Mail, which I used with GPG plug-ins in the past. It worked fine! Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From david at gbenet.com Tue Jul 30 19:23:19 2019 From: david at gbenet.com (David) Date: Tue, 30 Jul 2019 18:23:19 +0100 Subject: Enigmail In-Reply-To: <20190730162314.000021d8.sac@300baud.de> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> Message-ID: Stefan Claas via Gnupg-users: > David wrote: > >> Hello Everyone, >> >> I am looking for an alternative to Enigmail - which fails to work. >> Any ideas as to a suitable replacement?? > > You may check out another MUA, like Claws-Mail, which I used with > GPG plug-ins in the past. It worked fine! > > Regards > Stefan > Hello Stefan - is it an add-on? Works on Linux? And does it support multiple keys which Enigmail does not? I will go check :) David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com From sac at 300baud.de Tue Jul 30 19:40:44 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 30 Jul 2019 19:40:44 +0200 Subject: Enigmail In-Reply-To: References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> Message-ID: <20190730194044.00003ebe.sac@300baud.de> David wrote: > Stefan Claas via Gnupg-users: > > David wrote: > > > >> Hello Everyone, > >> > >> I am looking for an alternative to Enigmail - which fails to work. > >> Any ideas as to a suitable replacement?? > > > > You may check out another MUA, like Claws-Mail, which I used with > > GPG plug-ins in the past. It worked fine! > > > > Regards > > Stefan > > > Hello Stefan - is it an add-on? Works on Linux? And does it support > multiple keys which Enigmail does not? > > I will go check :) Claws-Mail is a MUA/NUA like Thunderbird. It includes GPG plug-ins. Regarding multiple key, I don't know what you mean, sorry. When I send messages (online) in the past with Claws-Mail I only send to single individuals. If you mean multiple keys for yourself, I never checked this, but assume then you may need also individual accounts in Claws-Mail for multiple keys. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From david at gbenet.com Tue Jul 30 19:47:46 2019 From: david at gbenet.com (David) Date: Tue, 30 Jul 2019 18:47:46 +0100 Subject: Enigmail In-Reply-To: <20190730194044.00003ebe.sac@300baud.de> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> Message-ID: Stefan Claas via Gnupg-users: > David wrote: > >> Stefan Claas via Gnupg-users: >>> David wrote: >>> >>>> Hello Everyone, >>>> >>>> I am looking for an alternative to Enigmail - which fails to work. >>>> Any ideas as to a suitable replacement?? >>> >>> You may check out another MUA, like Claws-Mail, which I used with >>> GPG plug-ins in the past. It worked fine! >>> >>> Regards >>> Stefan >>> >> Hello Stefan - is it an add-on? Works on Linux? And does it support >> multiple keys which Enigmail does not? >> >> I will go check :) > > Claws-Mail is a MUA/NUA like Thunderbird. It includes GPG plug-ins. > > Regarding multiple key, I don't know what you mean, sorry. > > When I send messages (online) in the past with Claws-Mail I only > send to single individuals. > > If you mean multiple keys for yourself, I never checked this, > but assume then you may need also individual accounts in > Claws-Mail for multiple keys. > > Regards > Stefan > Hello Stefan, I have three email accounts with their own keys - Enigmail does not support this - you have to have one key and that's it. Am downloading and installing claws mail now so hope it will import all my Thunderbird and Enigmail settings :) David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com From sac at 300baud.de Tue Jul 30 20:05:56 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 30 Jul 2019 20:05:56 +0200 Subject: Enigmail In-Reply-To: References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> Message-ID: <20190730200556.00006d65.sac@300baud.de> David wrote: Hi David, > I have three email accounts with their own keys - Enigmail does not > support this - you have to have one key and that's it. Ah, o.k. I never tried it, but it should be possible, with different accounts and keys (hopefully). > Am downloading and installing claws mail now so hope it will import all > my Thunderbird and Enigmail settings :) Claws-Mail is a different beast and I think this will not work. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From andrewg at andrewg.com Tue Jul 30 20:28:52 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 30 Jul 2019 19:28:52 +0100 Subject: Enigmail In-Reply-To: References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> Message-ID: <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> > On 30 Jul 2019, at 18:47, David wrote: > > Hello Stefan, > > I have three email accounts with their own keys - Enigmail does not > support this - you have to have one key and that's it. That is simply not true. I used enigmail with multiple keys for years without any issues. If you?re having issues configuring it, perhaps ask on the enigmail list. A From abbot at monksofcool.net Tue Jul 30 22:46:23 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Tue, 30 Jul 2019 22:46:23 +0200 Subject: Enigmail In-Reply-To: References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> Message-ID: <87pnlrz1wg.fsf@ra.horus-it.com> * david at gbenet.com: > I have three email accounts with their own keys - Enigmail does not > support this - you have to have one key and that's it. Nonsense! One can not only configure one PGP key per account (of which there can be many), one can even configure one key per identity. Each TB account can have multiplie identities; one of Thunderbird's killer features as far as I am concerned. Why you would lambast Enigmail for a non-problem, caused by you not configuring things properly, is beyond me. -Ralph From david at gbenet.com Wed Jul 31 00:33:10 2019 From: david at gbenet.com (David) Date: Tue, 30 Jul 2019 23:33:10 +0100 Subject: Enigmail In-Reply-To: <87pnlrz1wg.fsf@ra.horus-it.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <87pnlrz1wg.fsf@ra.horus-it.com> Message-ID: <9b8021b5-56bb-2bed-bb9d-7cf0601a9646@gbenet.com> Ralph Seichter: > * david at gbenet.com: > >> I have three email accounts with their own keys - Enigmail does not >> support this - you have to have one key and that's it. > > Nonsense! One can not only configure one PGP key per account (of which > there can be many), one can even configure one key per identity. Each > TB account can have multiplie identities; one of Thunderbird's killer > features as far as I am concerned. > > Why you would lambast Enigmail for a non-problem, caused by you not > configuring things properly, is beyond me. > > -Ralph > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Ralf, I have had one key pair for over 20 years - for postmaster at gbenet.com I decided to create another key pair last week for my website - site-admin at gbenet.com I set the settings to choose a key by email account select the key manually. I then sent a encrypted and signed test message from postmaster at gbenet.com to site-admin at gbenet.com The email arrived and I could read it - I had no need to decrypt it because it was signed and encrypted to postmaster at gbenet.com I then decided to reply - it selected postmasters key but refused to sign the email - I entered the passphrase three times all by hand the same result. Puzzled by this - I decided to take the checkbox out of picking the right key for the email accounts of postmaster at gbenet.com and site-admin at gbenet.com I decided to send just an encrypted email to postmaster at gbenet.com from site-admin at gbenet.com "I can't find the key" even though I had selected the key - hmmmm.............. I tried then to just send a signed reeply to postmater at gbenet.com not encrypted - the dialogue box popped up to enter the passphrase for site-admin at gbenet.com - again it refused to accept the passphrase for site-admin at gbenet.com Oh and I created a new key pair for david at gbenet.com which are completely useless. I tried with all three keys - the only key to work is my postmaster at gbenet.com which I've used in Thunderbird and Enigmail for over 20 years. And after each of these config changes in Enigmail and Thunderbird I shut down Thunderbird deleted all the caches and rebooted my laptop. The results were all consistent: Enigmail will only work with ONE Key. It does not recognise any other key than the first key that was created. I'd like to use my david at gbenet.com key here - some ages ago complained I was using postmaster at gbenet.com's key to sign emails. I thought it woulld be a good idea to have a key for this email account. BUT I can not use it - I can not sign emails. You moan - but offer no solutions. I can think of only one possible solution that will work delete site-admin's key pair - delete david's key pair and go back to what Thunderbird and Enigmail are happy with one key pair from postmaster at gbenet.com To be frank your comments are just like a bad fart - then they go away. You don't think perhaps can not think - your not too smart as to offer any solution. Regards David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com From david at gbenet.com Wed Jul 31 00:36:26 2019 From: david at gbenet.com (David) Date: Tue, 30 Jul 2019 23:36:26 +0100 Subject: Enigmail In-Reply-To: <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> Message-ID: <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> Andrew Gallagher: > >> On 30 Jul 2019, at 18:47, David wrote: >> >> Hello Stefan, >> >> I have three email accounts with their own keys - Enigmail does not >> support this - you have to have one key and that's it. > > That is simply not true. I used enigmail with multiple keys for years without any issues. If you?re having issues configuring it, perhaps ask on the enigmail list. > > A > I have done so - but have got no advice on the correct settings in Thunderbird or Enigmail. That's why I am considering other solutions. I have been with Thunderbird and Enigmail for over 20 years with one key pair - postmaster at gbenet.com Regards, David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com From david at gbenet.com Wed Jul 31 00:46:28 2019 From: david at gbenet.com (David) Date: Tue, 30 Jul 2019 23:46:28 +0100 Subject: Enigmail In-Reply-To: <20190730200556.00006d65.sac@300baud.de> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <20190730200556.00006d65.sac@300baud.de> Message-ID: <6721cca3-16f9-1e10-5f37-9e03c98d7a7a@gbenet.com> Stefan Claas via Gnupg-users: > David wrote: > > Hi David, > >> I have three email accounts with their own keys - Enigmail does not >> support this - you have to have one key and that's it. > > Ah, o.k. I never tried it, but it should be possible, with different > accounts and keys (hopefully). > >> Am downloading and installing claws mail now so hope it will import all >> my Thunderbird and Enigmail settings :) > > Claws-Mail is a different beast and I think this will not work. > > Regards > Stefan > Hi Stefan, It's all installed - with a main mail box. Am going to see if I can create four email accounts - hopefully not all as sub-accounts of the first one I created - I notice you can not change the name of this mail box :) I've yet to figure out how to use my keys. A learninng curve is in order but late at night 11.45pm!! Regards David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com From abbot at monksofcool.net Wed Jul 31 00:49:29 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Wed, 31 Jul 2019 00:49:29 +0200 Subject: Enigmail In-Reply-To: <9b8021b5-56bb-2bed-bb9d-7cf0601a9646@gbenet.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <87pnlrz1wg.fsf@ra.horus-it.com> <9b8021b5-56bb-2bed-bb9d-7cf0601a9646@gbenet.com> Message-ID: <87ef27t9xi.fsf@ra.horus-it.com> * david at gbenet.com: > Enigmail will only work with ONE Key. > It does not recognise any other key than the first key that was > created. I use multiple keys with Enigmail and Thunderbird, and I have done so for years. > You don't think perhaps can not think - your not too smart as to offer > any solution. Right, try insulting people, that will surely get you far. :-) I owe you exactly nothing. If you cannot figure it out yourself, try the Enigmail mailing list. -Ralph From david at gbenet.com Wed Jul 31 03:27:04 2019 From: david at gbenet.com (David) Date: Wed, 31 Jul 2019 02:27:04 +0100 Subject: Enigmail In-Reply-To: <87ef27t9xi.fsf@ra.horus-it.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <87pnlrz1wg.fsf@ra.horus-it.com> <9b8021b5-56bb-2bed-bb9d-7cf0601a9646@gbenet.com> <87ef27t9xi.fsf@ra.horus-it.com> Message-ID: <27118d53-6014-4d2c-b65d-fd3b2f1babec@gbenet.com> Ralph Seichter: > * david at gbenet.com: > >> Enigmail will only work with ONE Key. >> It does not recognise any other key than the first key that was >> created. > > I use multiple keys with Enigmail and Thunderbird, and I have done so > for years. > >> You don't think perhaps can not think - your not too smart as to offer >> any solution. > > Right, try insulting people, that will surely get you far. :-) I owe you > exactly nothing. If you cannot figure it out yourself, try the Enigmail > mailing list. > > -Ralph > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > I have approached the Enigmail list (if you care to read all the emails) but have had no instructions or help in resolving matters - clearly some people wish to make conversations rather than offering practical help - this failure was what prompted me to look into other solutions. David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com From rjh at sixdemonbag.org Wed Jul 31 04:40:40 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 30 Jul 2019 22:40:40 -0400 Subject: Enigmail In-Reply-To: <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> Message-ID: <5a3c014b-dcea-bd6c-c4f2-e665852cb2fe@sixdemonbag.org> > That's why I am considering other solutions. I have been with > Thunderbird and Enigmail for over 20 years with one key pair - This is simply not possible, as Enigmail didn't exist until 2001. (It took until about 2003 before it became really usable.) From patrick at enigmail.net Wed Jul 31 07:58:45 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 31 Jul 2019 07:58:45 +0200 Subject: Enigmail In-Reply-To: <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> Message-ID: On 31.07.2019 00:36, David wrote: > Andrew Gallagher: >> >>> On 30 Jul 2019, at 18:47, David wrote: >>> >>> Hello Stefan, >>> >>> I have three email accounts with their own keys - Enigmail does not >>> support this - you have to have one key and that's it. >> >> That is simply not true. I used enigmail with multiple keys for years without any issues. If you?re having issues configuring it, perhaps ask on the enigmail list. >> >> A >> > > I have done so - but have got no advice on the correct settings in > Thunderbird or Enigmail. That's not true. I have asked you for more details on the Enigmail mailing list. But instead of responding, you came here to ask the same questions. As Enigmail uses GnuPG for any crypto-operations, I don't think that the problem is in Enigmail, but in your setup. Feel free to answer my questions on the Enigmail mailing list, and I'll continue to try to find out what goes wrong. -Patrick From david at gbenet.com Wed Jul 31 08:56:06 2019 From: david at gbenet.com (David) Date: Wed, 31 Jul 2019 07:56:06 +0100 Subject: Enigmail In-Reply-To: References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> Message-ID: <117d1127-8d10-88c7-8648-7b4404ec231e@gbenet.com> Patrick Brunschwig: > On 31.07.2019 00:36, David wrote: >> Andrew Gallagher: >>> >>>> On 30 Jul 2019, at 18:47, David wrote: >>>> >>>> Hello Stefan, >>>> >>>> I have three email accounts with their own keys - Enigmail does not >>>> support this - you have to have one key and that's it. >>> >>> That is simply not true. I used enigmail with multiple keys for years without any issues. If you?re having issues configuring it, perhaps ask on the enigmail list. >>> >>> A >>> >> >> I have done so - but have got no advice on the correct settings in >> Thunderbird or Enigmail. > > That's not true. I have asked you for more details on the Enigmail > mailing list. But instead of responding, you came here to ask the same > questions. > > As Enigmail uses GnuPG for any crypto-operations, I don't think that the > problem is in Enigmail, but in your setup. Feel free to answer my > questions on the Enigmail mailing list, and I'll continue to try to find > out what goes wrong. > > -Patrick > Hello Patrick, I did not approach this list for answers - I just asked if anyone knew of an alternative. I then got drawn in to what was the problem. People say "Oh your settings are wrong" But the FAIL to give the RIGHT SETTINGS!! And then go waffling on.................... I have turned back the clock some 20 years - so have no settings to support further keys. Having said that - I would appreciate exactly what settings will work to enable me to sign with other emails and the public key associated with it and to be able to encrypt and sign with differing emails and keys. I want specific instructions - not moaning and groaning my settings are wrong and I don't know what I'm doing - that approach does not lead to a solution. Regards, David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 885 bytes Desc: OpenPGP digital signature URL: From david at gbenet.com Wed Jul 31 08:58:02 2019 From: david at gbenet.com (David) Date: Wed, 31 Jul 2019 07:58:02 +0100 Subject: Enigmail In-Reply-To: <5a3c014b-dcea-bd6c-c4f2-e665852cb2fe@sixdemonbag.org> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <5a3c014b-dcea-bd6c-c4f2-e665852cb2fe@sixdemonbag.org> Message-ID: <611e7283-e658-bcb9-87a6-47e839cb90f7@gbenet.com> Robert J. Hansen: >> That's why I am considering other solutions. I have been with >> Thunderbird and Enigmail for over 20 years with one key pair - > > This is simply not possible, as Enigmail didn't exist until 2001. (It > took until about 2003 before it became really usable.) > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Ok two years out - thank you for the correction David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 885 bytes Desc: OpenPGP digital signature URL: From gnupg at eckner.net Wed Jul 31 09:27:47 2019 From: gnupg at eckner.net (Erich Eckner) Date: Wed, 31 Jul 2019 09:27:47 +0200 (CEST) Subject: Enigmail In-Reply-To: <611e7283-e658-bcb9-87a6-47e839cb90f7@gbenet.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <5a3c014b-dcea-bd6c-c4f2-e665852cb2fe@sixdemonbag.org> <611e7283-e658-bcb9-87a6-47e839cb90f7@gbenet.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi David, here is, how I had thunderbird + enigmail running for several years with two keys and without problems (I have switched away from thunderbird since one year ago, because it got too heavy and slow for my taste): For each sending address, I have an identity "Edit" -> "Account Settings" -> "Manage Identities ..." and for each I set up the correct pgp key to use "Edit ..." (in the Identities-window) -> "OpenPGP Security" -> "Use email address of this identity to identify OpenPGP key" (where the address matches) and "Use specific OpenPGP key ID" (where the address does not match). Sry, If this does not help and you mentioned it already, but the previous mails contained too much emotion to completely be read by me. Anyways, since you originally asked for an alternative: I am currently using alpine + topal - which get's the multiple-keys part well, too, but has deficits regarding MIME/multipart encryption. regards, Erich Eckner Friedrich-Schiller-Universit?t Jena Institut f?r Optik und Quantenelektronik Helmholtzweg 4 07743 Jena Tel. +49 3641 9-47238 On Wed, 31 Jul 2019, David wrote: > Robert J. Hansen: >>> That's why I am considering other solutions. I have been with >>> Thunderbird and Enigmail for over 20 years with one key pair - >> >> This is simply not possible, as Enigmail didn't exist until 2001. (It >> took until about 2003 before it became really usable.) >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > > Ok two years out - thank you for the correction > > David > > > -- > People Should Not Be Afraid Of Their Government - Their Government > Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION > Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" > https://gbenet.com > > -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl1BQvYACgkQCu7JB1Xa e1q52BAAlXkDN78Rm0OOcajjf099eEN3D/yLgkjv9kdd6GnoAaZwGvOGvRaZXd4A b2TXNebVKrTqVbEeSC6R3eHEN0F7jotEiyIrcIMKhBK7S4KfKtrVX2F5bnJoW/zw PJKwlXwZor9KskrSu39AWdPREpEFfOiCHoegI5r3Yr00XlUUxeEy0xAnUI3Y6SMB YzemIQj8P4rDfM8XHX/YUuYM/vL4yC/J/W3sCT4VRldfuZgnX2W4W3OklQi7O32J lYRXEzwiY3M5l89Aqso08+SqrpRwr7yrHCweHElVHqOh2wM0BWnCXdn/itYkvvRH 6Ys3fMSnxjw8SDb5xG3pP2RYiE2XUxuH310YwMpa05iykktaqjrvS2JBlMpTdgI8 J+AaWM1ewBbidHeJH4CJgUfwXy/kqqzrhTgCDhnfa2Gtbj6Io4AlwtubE+av2l9M 5B736PIr7pP0hBZwhggHNNsa/vb0bhckDXRk2dSUbK2eJPElcpL4gsf98/LlEg1S HYUhg/4y5puWVl9/QMCvk4Vxyp6ld7XlfcrvaRrKeIjlmh9aAVp2Cqk9hG49tMqy FVCYVBUmUNg5599IGzaqTFfROzQQh5h+u3veQnTNM+CG8VT05Fjj6HVE3p8s+O5c wl1dJ9+3hadokD2VadD44HCBEIxKFKjuXieQmNya8I6VQud3wR8= =3/C1 -----END PGP SIGNATURE----- From david at gbenet.com Wed Jul 31 13:46:27 2019 From: david at gbenet.com (David) Date: Wed, 31 Jul 2019 12:46:27 +0100 Subject: Enigmail In-Reply-To: References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <5a3c014b-dcea-bd6c-c4f2-e665852cb2fe@sixdemonbag.org> <611e7283-e658-bcb9-87a6-47e839cb90f7@gbenet.com> Message-ID: <6583ff10-ed66-bf4d-d9b6-67d36d32309d@gbenet.com> Erich Eckner via Gnupg-users: > Hi David, > > here is, how I had thunderbird + enigmail running for several years with > two keys and without problems (I have switched away from thunderbird > since one year ago, because it got too heavy and slow for my taste): > > For each sending address, I have an identity > "Edit" -> "Account Settings" -> "Manage Identities ..." > and for each I set up the correct pgp key to use > "Edit ..." (in the Identities-window) -> "OpenPGP Security" -> "Use > email address of this identity to identify OpenPGP key" (where the > address matches) and "Use specific OpenPGP key ID" (where the address > does not match). > > Sry, If this does not help and you mentioned it already, but the > previous mails contained too much emotion to completely be read by me. > > Anyways, since you originally asked for an alternative: I am currently > using alpine + topal - which get's the multiple-keys part well, too, but > has deficits regarding MIME/multipart encryption. > > regards, > Erich Eckner > Friedrich-Schiller-Universit?t Jena > Institut f?r Optik und Quantenelektronik > Helmholtzweg 4 > 07743 Jena > > Tel. +49 3641 9-47238 > > > On Wed, 31 Jul 2019, David wrote: > >> Robert J. Hansen: >>>> That's why I am considering other solutions. I have been with >>>> Thunderbird and Enigmail for over 20 years with one key pair - >>> >>> This is simply not possible, as Enigmail didn't exist until 2001. (It >>> took until about 2003 before it became really usable.) >>> >>> >>> _______________________________________________ >>> Gnupg-users mailing list >>> Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>> > >> Ok two years out - thank you for the correction > >> David > > >> -- >> People Should Not Be Afraid Of Their Government - Their Government >> Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION >> Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" >> https://gbenet.com > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Hello Erich, I did what you said - associated each email address with it's own key. I then shut down Thunderbird re-started and carried out the following test: Test One: I sent an encrypted and signed email to site-admin from postmaster. I received the email - it took 6 attempts to decrypt it. I then decided to reply - so I sent an encrypted and signed email to postmaster - I was unable to sign as site-admin - after 9 attempts of entering the passphrase - each time rejected by Enigmail. I was unable to send a signed and encrypted email to postmaster. Test Two: I sent an encrypted and signed email to david - when selecting the right public key there was always a tick in postmaster which I removed and selected the right key to encrypt too. BUT Enigmail REFUSED to accept my passphrase after 9 attempts. Test Three: I decided to send a signed and encrypted email to postmaster from David. With the following results: For some strange reason Enigmail encrypted to postmaster and signed: Decrypted message Good signature from David Key ID: 0x3299975EAD1E968848D19945459E3AE3EA13E1A3 / Signed on: 31/07/19, 12:18 Key fingerprint: 3299 975E AD1E 9688 48D1 9945 459E 3AE3 EA13 E1A3 Used Algorithms: RSA and SHA256 Note: The message is encrypted for the following User ID's / Keys: 0xD21B4405FDDA1EF2 (postmaster (There's always light at the end of the tunnel) ), 0xCF833B99EBD6222A (David From wk at gnupg.org Wed Jul 31 13:45:40 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 31 Jul 2019 13:45:40 +0200 Subject: --lsign --add-me or the invisible WoT In-Reply-To: <20190720115720.000020da.sac@300baud.de> (Stefan Claas via Gnupg-users's message of "Sat, 20 Jul 2019 11:57:20 +0200") References: <20190720115720.000020da.sac@300baud.de> Message-ID: <87zhkubf6j.fsf@wheatstone.g10code.de> On Sat, 20 Jul 2019 11:57, gnupg-users at gnupg.org said: > additional paramemter like --add-me for --lsign would make sense, for --quick-sign-key fpr [names] --quick-lsign-key fpr [names] Directly sign a key from the passphrase without any further user interaction. The fpr must be the verified primary fingerprint of a key in the local keyring. If no names are given, all useful user ids are signed; with given [names] only useful user ids matching one of theses names are signed. By default, or if a name is prefixed with a '*', a case insensitive substring match is used. If a name is prefixed with a '=' a case sensitive exact match is done. The command --quick-lsign-key marks the signatures as non-exportable. If such a non-exportable signature already exists the --quick- sign-key turns it into a exportable signature. This command uses reasonable defaults and thus does not provide the full flexibility of the "sign" subcommand from --edit-key. Its intended use is to help unattended key signing by utilizing a list of verified fingerprints. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From patrick at enigmail.net Wed Jul 31 14:25:49 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 31 Jul 2019 14:25:49 +0200 Subject: Enigmail In-Reply-To: <117d1127-8d10-88c7-8648-7b4404ec231e__10128.4245656402$1564556265$gmane$org@gbenet.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <117d1127-8d10-88c7-8648-7b4404ec231e__10128.4245656402$1564556265$gmane$org@gbenet.com> Message-ID: <02b9d27b-fd8e-711b-8fac-562b68597615@enigmail.net> On 31.07.2019 08:56, David wrote: > Patrick Brunschwig: >> On 31.07.2019 00:36, David wrote: >>> Andrew Gallagher: >>>> >>>>> On 30 Jul 2019, at 18:47, David wrote: >>>>> >>>>> Hello Stefan, >>>>> >>>>> I have three email accounts with their own keys - Enigmail does not >>>>> support this - you have to have one key and that's it. >>>> >>>> That is simply not true. I used enigmail with multiple keys for years without any issues. If you?re having issues configuring it, perhaps ask on the enigmail list. >>>> >>>> A >>>> >>> >>> I have done so - but have got no advice on the correct settings in >>> Thunderbird or Enigmail. >> >> That's not true. I have asked you for more details on the Enigmail >> mailing list. But instead of responding, you came here to ask the same >> questions. >> >> As Enigmail uses GnuPG for any crypto-operations, I don't think that the >> problem is in Enigmail, but in your setup. Feel free to answer my >> questions on the Enigmail mailing list, and I'll continue to try to find >> out what goes wrong. >> >> -Patrick >> > > Hello Patrick, > > I did not approach this list for answers - I just asked if anyone knew > of an alternative. I then got drawn in to what was the problem. > > People say "Oh your settings are wrong" But the FAIL to give the RIGHT > SETTINGS!! And then go waffling on.................... > > I have turned back the clock some 20 years - so have no settings to > support further keys. > > Having said that - I would appreciate exactly what settings will work to > enable me to sign with other emails and the public key associated with > it and to be able to encrypt and sign with differing emails and keys. > > I want specific instructions - not moaning and groaning my settings are > wrong and I don't know what I'm doing - that approach does not lead to a > solution. Here are the instructions: 1. Open the Thunderbird Account Settings (menu Tools > Account Settings) 2. switch to the tab "OpenPGP Security" 3. make sure that "Enable OpenPGP support" is checked 4. click on the button "Select key" 5. select the key that matches the email address of the account Repeat Steps 2-5 for each and every of your accounts/email addresses. If you follow(ed) these instructions, then everything else /should/ go automatically and you /should/ not have any issues. If you do have issues, then there are no simple instructions - we have to dig to find out what's wrong. The questions I asked on the Enigmail mailing list are the 1st step into trying to find out why things don't work as expected, as I assumed that -- as a long-term user -- you already did configure Enigmail correctly. -Patrick From david at gbenet.com Wed Jul 31 14:26:54 2019 From: david at gbenet.com (David) Date: Wed, 31 Jul 2019 13:26:54 +0100 Subject: Enigmail In-Reply-To: <6583ff10-ed66-bf4d-d9b6-67d36d32309d@gbenet.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <5a3c014b-dcea-bd6c-c4f2-e665852cb2fe@sixdemonbag.org> <611e7283-e658-bcb9-87a6-47e839cb90f7@gbenet.com> <6583ff10-ed66-bf4d-d9b6-67d36d32309d@gbenet.com> Message-ID: <48dfa4f1-0b93-1d95-5b09-d965b11bed96@gbenet.com> David: > Erich Eckner via Gnupg-users: >> Hi David, >> >> here is, how I had thunderbird + enigmail running for several years with >> two keys and without problems (I have switched away from thunderbird >> since one year ago, because it got too heavy and slow for my taste): >> >> For each sending address, I have an identity >> "Edit" -> "Account Settings" -> "Manage Identities ..." >> and for each I set up the correct pgp key to use >> "Edit ..." (in the Identities-window) -> "OpenPGP Security" -> "Use >> email address of this identity to identify OpenPGP key" (where the >> address matches) and "Use specific OpenPGP key ID" (where the address >> does not match). >> >> Sry, If this does not help and you mentioned it already, but the >> previous mails contained too much emotion to completely be read by me. >> >> Anyways, since you originally asked for an alternative: I am currently >> using alpine + topal - which get's the multiple-keys part well, too, but >> has deficits regarding MIME/multipart encryption. >> >> regards, >> Erich Eckner >> Friedrich-Schiller-Universit?t Jena >> Institut f?r Optik und Quantenelektronik >> Helmholtzweg 4 >> 07743 Jena >> >> Tel. +49 3641 9-47238 >> >> >> On Wed, 31 Jul 2019, David wrote: >> >>> Robert J. Hansen: >>>>> That's why I am considering other solutions. I have been with >>>>> Thunderbird and Enigmail for over 20 years with one key pair - >>>> >>>> This is simply not possible, as Enigmail didn't exist until 2001. (It >>>> took until about 2003 before it became really usable.) >>>> >>>> >>>> _______________________________________________ >>>> Gnupg-users mailing list >>>> Gnupg-users at gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>>> >> >>> Ok two years out - thank you for the correction >> >>> David >> >> >>> -- >>> People Should Not Be Afraid Of Their Government - Their Government >>> Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION >>> Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" >>> https://gbenet.com >> >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > > Hello Erich, > > I did what you said - associated each email address with it's own key. > I then shut down Thunderbird re-started and carried out the following test: > > Test One: > > I sent an encrypted and signed email to site-admin from postmaster. I > received the email - it took 6 attempts to decrypt it. > > I then decided to reply - so I sent an encrypted and signed email to > postmaster - I was unable to sign as site-admin - after 9 attempts of > entering the passphrase - each time rejected by Enigmail. I was unable > to send a signed and encrypted email to postmaster. > > Test Two: > > I sent an encrypted and signed email to david - when selecting the right > public key there was always a tick in postmaster which I removed and > selected the right key to encrypt too. BUT Enigmail REFUSED to accept my > passphrase after 9 attempts. > > Test Three: > > I decided to send a signed and encrypted email to postmaster from David. > With the following results: For some strange reason Enigmail encrypted > to postmaster and signed: > > Decrypted message Good signature from David Key ID: > 0x3299975EAD1E968848D19945459E3AE3EA13E1A3 / Signed on: 31/07/19, 12:18 > Key fingerprint: 3299 975E AD1E 9688 48D1 9945 459E 3AE3 EA13 E1A3 Used > Algorithms: RSA and SHA256 Note: The message is encrypted for the > following User ID's / Keys: 0xD21B4405FDDA1EF2 (postmaster (There's > always light at the end of the tunnel) ), > 0xCF833B99EBD6222A (David > I just copied and pasted the passphrase into the check box - I did the > same with david at gbenet.com and entered it in by hand 6 times. > > Test Four: > > I decided to send a signed and encrypted email from skipper to David > with the following results: The message was signed Enigmail accepted the > passphrase. The message was decrypted - even though Enigmail asked me > for david's passphrase. When I clicked on show info about the signer no > results came back. I do not know if david at gbenet.com or > postmster at gbenet.com actually decrypted the email :) Hahhhaha!!! > > When selecting a public key to encrypt too - postmaster at gbenet.com's key > is always selected. One hundred per cent of the time. > > Test Five > > I am going to attempt to sign and encrypt a "test" email to you: > I selected your key - no passphrase was asked for - the email was sent. > Who signed it - I have no idea. > > Enigmail fails to read it's own settings - and fails to accept valid > passphrases associated with valid keys. > > Enigmail always defaults to one PRIMARY KEY which is postmaster at gbent.com > > Coffee > > Regards > > David > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > An update Consider the fact that for 30 times Enigmail refused to accept the passphrase for david at gbenet.com I decided to send an encrypted email to Erich. When selecting his private key there was no automatic tick in postmaster. But a tick in Erich's public key On sending I thought I was going to be asked for david's passphrase yet again - but no - the email passed very quickly. This begs the following questions: (1) Why is postmaster always selcected as the default public key? (2) Why is it on failing 30 times to accept david's passphrase why does enigmail mysteriously remember it when it rejected 30 times? Answers on a postcard please David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 885 bytes Desc: OpenPGP digital signature URL: From patrick at enigmail.net Wed Jul 31 14:31:34 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 31 Jul 2019 14:31:34 +0200 Subject: Enigmail In-Reply-To: <6583ff10-ed66-bf4d-d9b6-67d36d32309d__29071.944991459$1564573707$gmane$org@gbenet.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <5a3c014b-dcea-bd6c-c4f2-e665852cb2fe@sixdemonbag.org> <611e7283-e658-bcb9-87a6-47e839cb90f7@gbenet.com> <6583ff10-ed66-bf4d-d9b6-67d36d32309d__29071.944991459$1564573707$gmane$org@gbenet.com> Message-ID: <501ff1a1-5e71-a22a-8b98-669e3f2d471f@enigmail.net> On 31.07.2019 13:46, David wrote: > Hello Erich, > > I did what you said - associated each email address with it's own key. > I then shut down Thunderbird re-started and carried out the following test: > > Test One: > > I sent an encrypted and signed email to site-admin from postmaster. I > received the email - it took 6 attempts to decrypt it. > > I then decided to reply - so I sent an encrypted and signed email to > postmaster - I was unable to sign as site-admin - after 9 attempts of > entering the passphrase - each time rejected by Enigmail. I was unable > to send a signed and encrypted email to postmaster. I'm sorry, but there's a misunderstanding. Enigmail does /not/ query your passphrase. Enigmail calls GnuPG, and GnuPG asks for your passphrase if needed. If the passphrase is rejected that's not related to Enigmail. -Patrick From david at gbenet.com Wed Jul 31 14:36:25 2019 From: david at gbenet.com (David) Date: Wed, 31 Jul 2019 13:36:25 +0100 Subject: Enigmail In-Reply-To: <02b9d27b-fd8e-711b-8fac-562b68597615@enigmail.net> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <117d1127-8d10-88c7-8648-7b4404ec231e__10128.4245656402$1564556265$gmane$org@gbenet.com> <02b9d27b-fd8e-711b-8fac-562b68597615@enigmail.net> Message-ID: Patrick Brunschwig: > On 31.07.2019 08:56, David wrote: >> Patrick Brunschwig: >>> On 31.07.2019 00:36, David wrote: >>>> Andrew Gallagher: >>>>> >>>>>> On 30 Jul 2019, at 18:47, David wrote: >>>>>> >>>>>> Hello Stefan, >>>>>> >>>>>> I have three email accounts with their own keys - Enigmail does not >>>>>> support this - you have to have one key and that's it. >>>>> >>>>> That is simply not true. I used enigmail with multiple keys for years without any issues. If you?re having issues configuring it, perhaps ask on the enigmail list. >>>>> >>>>> A >>>>> >>>> >>>> I have done so - but have got no advice on the correct settings in >>>> Thunderbird or Enigmail. >>> >>> That's not true. I have asked you for more details on the Enigmail >>> mailing list. But instead of responding, you came here to ask the same >>> questions. >>> >>> As Enigmail uses GnuPG for any crypto-operations, I don't think that the >>> problem is in Enigmail, but in your setup. Feel free to answer my >>> questions on the Enigmail mailing list, and I'll continue to try to find >>> out what goes wrong. >>> >>> -Patrick >>> >> >> Hello Patrick, >> >> I did not approach this list for answers - I just asked if anyone knew >> of an alternative. I then got drawn in to what was the problem. >> >> People say "Oh your settings are wrong" But the FAIL to give the RIGHT >> SETTINGS!! And then go waffling on.................... >> >> I have turned back the clock some 20 years - so have no settings to >> support further keys. >> >> Having said that - I would appreciate exactly what settings will work to >> enable me to sign with other emails and the public key associated with >> it and to be able to encrypt and sign with differing emails and keys. >> >> I want specific instructions - not moaning and groaning my settings are >> wrong and I don't know what I'm doing - that approach does not lead to a >> solution. > > Here are the instructions: > > 1. Open the Thunderbird Account Settings (menu Tools > Account Settings) > 2. switch to the tab "OpenPGP Security" > 3. make sure that "Enable OpenPGP support" is checked > 4. click on the button "Select key" > 5. select the key that matches the email address of the account > > Repeat Steps 2-5 for each and every of your accounts/email addresses. > > If you follow(ed) these instructions, then everything else /should/ go > automatically and you /should/ not have any issues. If you do have > issues, then there are no simple instructions - we have to dig to find > out what's wrong. > > The questions I asked on the Enigmail mailing list are the 1st step into > trying to find out why things don't work as expected, as I assumed that > -- as a long-term user -- you already did configure Enigmail correctly. > > -Patrick > Patrick, When I first created my keys that is exactly what I did. It all failed. Enigmail always defaults to the first set of keys one created - for example site-addmin wants to an encrypted and signed mail to skipper - when you go to select the public key of skipper - postmaster is always selected. Also - why is it that enigmail and reuse a passphrase 30- times - then suddenly remember to use it?? Enigmaill does not always read it's own settings. Even when you flush the cache and reboot your laptop or desktop. It always defaults to the first key you created for signing and encryption when using local keys ie david at gbenet.com site-addmin at gbenet.com skipper at gbenet.com be Happy - but there's something amiss somewhere in the code - what that something is I have no idea. David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 885 bytes Desc: OpenPGP digital signature URL: From david at gbenet.com Wed Jul 31 14:39:08 2019 From: david at gbenet.com (David) Date: Wed, 31 Jul 2019 13:39:08 +0100 Subject: Enigmail In-Reply-To: <501ff1a1-5e71-a22a-8b98-669e3f2d471f@enigmail.net> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <5a3c014b-dcea-bd6c-c4f2-e665852cb2fe@sixdemonbag.org> <611e7283-e658-bcb9-87a6-47e839cb90f7@gbenet.com> <6583ff10-ed66-bf4d-d9b6-67d36d32309d__29071.944991459$1564573707$gmane$org@gbenet.com> <501ff1a1-5e71-a22a-8b98-669e3f2d471f@enigmail.net> Message-ID: <26912a0c-902c-6606-9016-5f6a588432e7@gbenet.com> Patrick Brunschwig: > On 31.07.2019 13:46, David wrote: >> Hello Erich, >> >> I did what you said - associated each email address with it's own key. >> I then shut down Thunderbird re-started and carried out the following test: >> >> Test One: >> >> I sent an encrypted and signed email to site-admin from postmaster. I >> received the email - it took 6 attempts to decrypt it. >> >> I then decided to reply - so I sent an encrypted and signed email to >> postmaster - I was unable to sign as site-admin - after 9 attempts of >> entering the passphrase - each time rejected by Enigmail. I was unable >> to send a signed and encrypted email to postmaster. > > I'm sorry, but there's a misunderstanding. Enigmail does /not/ query > your passphrase. Enigmail calls GnuPG, and GnuPG asks for your > passphrase if needed. If the passphrase is rejected that's not related > to Enigmail. > > -Patrick > So we go and ask Werner :) hahahaha!!! David - -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 885 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Jul 31 15:18:19 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 31 Jul 2019 14:18:19 +0100 Subject: Enigmail In-Reply-To: References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <117d1127-8d10-88c7-8648-7b4404ec231e__10128.4245656402$1564556265$gmane$org@gbenet.com> <02b9d27b-fd8e-711b-8fac-562b68597615@enigmail.net> Message-ID: On 31/07/2019 13:36, David wrote: > Enigmail always defaults to the first set of keys one created Enigmail will default to the first set of keys in your keyring that matches the selection criteria. Do you have more than one ID on each key? Do you have more than one key for each ID? This could be causing some confusion. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From abbot at monksofcool.net Wed Jul 31 15:38:51 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Wed, 31 Jul 2019 15:38:51 +0200 Subject: Enigmail In-Reply-To: <117d1127-8d10-88c7-8648-7b4404ec231e@gbenet.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <117d1127-8d10-88c7-8648-7b4404ec231e@gbenet.com> Message-ID: <87tvb2tjbo.fsf@ra.horus-it.com> * david at gbenet.com: > People say "Oh your settings are wrong" But the FAIL to give the RIGHT > SETTINGS!! And then go waffling on.................... People don't fail you. Your entitlement issues do. Falsely stating software X cannot do Y when you are not using it right, expecting answers on a silver platter, and offering insults to people is simply not the way to behave on a public mailing list when you want free support (from people who don't owe you any assistance whatsoever) and answers beyond "PEBKAC, so you figure it out". > I want specific instructions - not moaning and groaning my settings > are wrong and I don't know what I'm doing Oh, you /want/ that, do you? As Clark Gable once said: "Frankly, my dear, I don't give a damn". :-) -Ralph From sac at 300baud.de Wed Jul 31 15:58:57 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 31 Jul 2019 15:58:57 +0200 Subject: --lsign --add-me or the invisible WoT In-Reply-To: <87zhkubf6j.fsf@wheatstone.g10code.de> References: <20190720115720.000020da.sac@300baud.de> <87zhkubf6j.fsf@wheatstone.g10code.de> Message-ID: <20190731155857.00000125.sac@300baud.de> Werner Koch wrote: > On Sat, 20 Jul 2019 11:57, gnupg-users at gnupg.org said: > > > additional paramemter like --add-me for --lsign would make sense, for > > --quick-sign-key fpr [names] > --quick-lsign-key fpr [names] > > Directly sign a key from the passphrase without any > further user interaction. The fpr must be the verified > primary fingerprint of a key in the local keyring. If no > names are given, all useful user ids are signed; with > given [names] only useful user ids matching one of theses > names are signed. By default, or if a name is prefixed > with a '*', a case insensitive substring match is used. > If a name is prefixed with a '=' a case sensitive exact > match is done. > > The command --quick-lsign-key marks the signatures as > non-exportable. If such a non-exportable signature > already exists the --quick- sign-key turns it into a > exportable signature. > > This command uses reasonable defaults and thus does not > provide the full flexibility of the "sign" subcommand from > --edit-key. Its intended use is to help unattended key > signing by utilizing a list of verified fingerprints. Thank you, but what I mean is having an exportable 'blob' for the lsign command, which can be then exchanged and would not be compatible with key servers, in case someone would try to upload such a blob. This is what I mean with invisible WoT, so that users do not need to --sign a key, use lsign instead but still having WoT sigs, without revealing their WoT to other third parties. Hope this makes sense. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From andrewg at andrewg.com Wed Jul 31 16:05:07 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 31 Jul 2019 15:05:07 +0100 Subject: --lsign --add-me or the invisible WoT In-Reply-To: <20190731155857.00000125.sac@300baud.de> References: <20190720115720.000020da.sac@300baud.de> <87zhkubf6j.fsf@wheatstone.g10code.de> <20190731155857.00000125.sac@300baud.de> Message-ID: On 31/07/2019 14:58, Stefan Claas via Gnupg-users wrote: > an exportable 'blob' for the lsign > command, which can be then exchanged and would not be compatible with > key servers, in case someone would try to upload such a blob The keyservers (SKS at least) blacklist lsign packets already, so you're not gaining anything here. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Wed Jul 31 16:25:37 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 31 Jul 2019 16:25:37 +0200 Subject: --lsign --add-me or the invisible WoT In-Reply-To: References: <20190720115720.000020da.sac@300baud.de> <87zhkubf6j.fsf@wheatstone.g10code.de> <20190731155857.00000125.sac@300baud.de> Message-ID: <20190731162537.00005c16.sac@300baud.de> Andrew Gallagher wrote: > On 31/07/2019 14:58, Stefan Claas via Gnupg-users wrote: > > an exportable 'blob' for the lsign > > command, which can be then exchanged and would not be compatible with > > key servers, in case someone would try to upload such a blob > > The keyservers (SKS at least) blacklist lsign packets already, so you're > not gaining anything here. > Correct. To make it a bit more clear ... I lsign Bob's key so third parties do not know (normally) that I did this. But how could my friend Alice trust Bob's key she has without my non-exportable lsign sig? What I tried to propose is an additional parameter, like --add-me which would write a 'blob' to a second file.db where I can export then Bob's blob (non-compatible to SKS etc.) with my --lsign sig, and give it to my friend Alice. Later If Alice knows Bob better or personally knows him she can --lsign --add-me Bob's key ('blob') too and give it to her friend Mary. Mary would have then a 'blob" from Bob containing my and Alice's lsigs, which are non-compatible to key servers, but would be IMHO equal to classic WoT sigs. So to speak it is meaned for little WoTs (for those who needs them) where participants don't have to fear that their sigs are published in the future on whatever key servers we have, to not reveal their social graphs. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From ryan at digicana.com Wed Jul 31 16:36:55 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Wed, 31 Jul 2019 14:36:55 +0000 Subject: Forbes article: The Encryption Debate Is Over - Dead At The Hands Of Facebook Message-ID: Kicking the can down to the endpoints -- but really, haven't you always had to trust your app / OS? Unless you coded or audited it yourself from top to bottom and built your own hardware (hah), there is always a level of trust required in the code/device.? Trusting Facebook seems... unwise.? But not everyone is churning out industrial grade evil like Facebook. https://www.forbes.com/sites/kalevleetaru/2019/07/26/the-encryption-debate-is-over-dead-at-the-hands-of-facebook/#55ac36aa5362 -Ryan McGinnis https://bigstormpicture.com PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD https://keybase.io/digicana Sent via ProtonMail -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Jul 31 16:52:52 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 31 Jul 2019 15:52:52 +0100 Subject: Forbes article: The Encryption Debate Is Over - Dead At The Hands Of Facebook In-Reply-To: References: Message-ID: On 31/07/2019 15:36, Ryan McGinnis via Gnupg-users wrote: > haven't you always had to trust your app / OS? Unless you coded or > audited it yourself from top to bottom and built your own hardware > (hah), there is always a level of trust required in the code/device Facebook are being expected to act as both poacher and gamekeeper simultaneously. Cory Doctorow has an interesting viewpoint - we can either regulate the internet giants and expect them to act as an arm of the state, or we can break them up and expect them to act on behalf of the customer. But we can't reasonably expect both. There's a balance to be had between the needs of personal privacy and public security, and the best way to ensure it's done honestly is for different agents to take different sides and have it out in public. It's conflicts of interest and the inevitable closed-door decision making where the problems really start. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From patrick at enigmail.net Wed Jul 31 17:53:22 2019 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 31 Jul 2019 17:53:22 +0200 Subject: Enigmail In-Reply-To: <48dfa4f1-0b93-1d95-5b09-d965b11bed96__24285.6066719227$1564576068$gmane$org@gbenet.com> References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <5a3c014b-dcea-bd6c-c4f2-e665852cb2fe@sixdemonbag.org> <611e7283-e658-bcb9-87a6-47e839cb90f7@gbenet.com> <6583ff10-ed66-bf4d-d9b6-67d36d32309d@gbenet.com> <48dfa4f1-0b93-1d95-5b09-d965b11bed96__24285.6066719227$1564576068$gmane$org@gbenet.com> Message-ID: <968a0884-2a72-5954-1617-997a77df3bfc@enigmail.net> On 31.07.2019 14:26, David wrote: > Consider the fact that for 30 times Enigmail refused to accept the > passphrase for david at gbenet.com > > I decided to send an encrypted email to Erich. When selecting his > private key there was no automatic tick in postmaster. But a tick in > Erich's public key > > On sending I thought I was going to be asked for david's passphrase yet > again - but no - the email passed very quickly. > > This begs the following questions: > > (1) Why is postmaster always selcected as the default public key? > (2) Why is it on failing 30 times to accept david's passphrase why does > enigmail mysteriously remember it when it rejected 30 times? > > Answers on a postcard please I start to believe that your expectation of what should happen differs from what actually happens. The way things work in Enigmail are as follows: you select a *sender account* in the Thunderbird message composition window. Based on that sender account configuration (and nothing else), Enigmail decides which key to use for *signing* your message. Remember, the passphrase is needed for signing, not for encryption - it does not matter if Postmaster or Erich are in the recipients list. If you get a dialog to choose the key(s) _after_ you hit the send button, then those are the keys to which the message is *encrypted* to. But again, you don't need a passphrase for any of these keys. Thus, if you tell me that you expected to have to tick Postmaster in the dialog, then that won't let you choose the key for signing. HTH -Patrick From maxim at fomin.one Wed Jul 31 18:40:32 2019 From: maxim at fomin.one (Maksim Fomin) Date: Wed, 31 Jul 2019 16:40:32 +0000 Subject: Forbes article: The Encryption Debate Is Over - Dead At The Hands Of Facebook In-Reply-To: References: Message-ID: ??????? Original Message ??????? On Wednesday, 31 July 2019 ?., 17:36, Ryan McGinnis via Gnupg-users wrote: > Kicking the can down to the endpoints -- but really, haven't you always had to trust your app / OS? Unless you coded or audited it yourself from top to bottom and built your own hardware (hah), there is always a level of trust required in the code/device. Trusting Facebook seems... unwise. But not everyone is churning out industrial grade evil like Facebook. > > https://www.forbes.com/sites/kalevleetaru/2019/07/26/the-encryption-debate-is-over-dead-at-the-hands-of-facebook/#55ac36aa5362 > > -Ryan McGinnis > https://bigstormpicture.com > PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD > https://keybase.io/digicana > Sent via ProtonMail Facebook receives disproportionally high criticism in recent years not because of technical reasons but because of politics. The wave of attacks on Facebook began after 2016 US election. Initially it was like "fake news in facebook helped one candidate to win" and the idea was to allow journalists of big media companies to mark information in facebook as "fake" and probably delete. Later the attack has spread in all directions. Nowadays everyone tries to punch Facebook in order to look smart. Regarding techincal reasons. The author argues that if devices are compromised, then encrypted communication between them is too. But this is not a surprise, it has always been. July 2019 in this aspect is not different from January 2019, or 2017, or 2007. In addition, not only Facebook, but other big tech firms (Microsoft, Apple, Twitter and so on) can download unencrypted data from user device for analysis before encryption. As an exercise, one can replace "Facebook" in that article with "Apple", the bias will be more evident. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at digicana.com Wed Jul 31 20:58:00 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Wed, 31 Jul 2019 18:58:00 +0000 Subject: Forbes article: The Encryption Debate Is Over - Dead At The Hands Of Facebook In-Reply-To: References: Message-ID: In my personal opinion, Facebook has earned their reputation.? Their stance towards privacy has always publicly been "Uhh, what?? Privacy?? Uhhhhh, yeah... we love privacy!" while they fill their platform with dark patterns and extract every last bit of usable data you give them into something they can monetize.? They were selling the 2FA phone numbers people would supply for increased login security to advertisers for Pete's sake.? Sometimes that giant space station that looks like a moon with that thing that looks suspiciously like a janky planet-busting laser slapped to the side of it really is something to worry about. I do agree you can say this about any platform, but I don't agree that they're all equally suspicious.? Apple *could* be secretly building a data empire out of their users, but they way they've structured their business plans, the way they market, the way they continually design their devices with security and privacy not just in mind but as a top priority... it's doubtful that they're secretly the bad guys.? Possible, sure, but if you're going to pick a closed source hardware/software platform, you could do waaay worse. ? -Ryan McGinnis https://bigstormpicture.com https://keybase.io/digicana Sent via ProtonMail ??????? Original Message ??????? On Wednesday, July 31, 2019 11:40 AM, Maksim Fomin via Gnupg-users wrote: > ??????? Original Message ??????? > On Wednesday, 31 July 2019 ?., 17:36, Ryan McGinnis via Gnupg-users wrote: > > > Kicking the can down to the endpoints -- but really, haven't you always had to trust your app / OS? Unless you coded or audited it yourself from top to bottom and built your own hardware (hah), there is always a level of trust required in the code/device.? Trusting Facebook seems... unwise.? But not everyone is churning out industrial grade evil like Facebook. > > > > https://www.forbes.com/sites/kalevleetaru/2019/07/26/the-encryption-debate-is-over-dead-at-the-hands-of-facebook/#55ac36aa5362 > > > > -Ryan McGinnis > > https://bigstormpicture.com > > PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD > > https://keybase.io/digicana > > Sent via ProtonMail > > Facebook receives disproportionally high criticism in recent years not because of technical reasons but because of politics. The wave of attacks on Facebook began after 2016 US election. Initially it was like "fake news in facebook helped one candidate to win" and the idea was to allow journalists of big media companies to mark information in facebook as "fake" and probably delete. Later the attack has spread in all directions. Nowadays everyone tries to punch Facebook in order to look smart.? > > Regarding techincal reasons. The author argues that if devices are compromised, then encrypted communication between them is too. But this is not a surprise, it has always been. July 2019 in this aspect is not different from January 2019, or 2017, or 2007. In addition, not only Facebook, but other big tech firms (Microsoft, Apple, Twitter and so on) can download unencrypted? data from user device for analysis before encryption. As an exercise, one can replace "Facebook" in that article with "Apple", the bias will be more evident. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - ryan at digicana.com - 0x5C738727.asc Type: application/pgp-keys Size: 3215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From guru at unixarea.de Wed Jul 31 21:39:36 2019 From: guru at unixarea.de (Matthias Apitz) Date: Wed, 31 Jul 2019 21:39:36 +0200 Subject: Forbes article: The Encryption Debate Is Over - Dead At The Hands Of Facebook In-Reply-To: References: Message-ID: <20190731193936.GA2823@c720-r342378> Can you please move this discussion elsewhere. The purpose of this list is: https://lists.gnupg.org/mailman/listinfo/gnupg-users About Gnupg-users GnuPG user help mailing list. The topic of this is list is help and discussion among users of GnuPG. This includes questions on how to script GnuPG, how to create or sign keys and general discussion on encryption and digital signatures as long as it somehow pertains to GnuPG. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Thanks. matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: ???????? ????????????! Thank you very much, Russian liberators! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: