> 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
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
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
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
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.
> 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
> 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
> 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
> 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
On Sun, 30 Jun 2019 at 22:23:11 +, 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
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
* da...@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
On Sun, 30 Jun 2019 at 00:36:19 -0700, Mirimir via Gnupg-users wrote:
> | High-risk users should stop using the keyserver network immediately.
>
> So OK, I can purge requests to SKS keyservers from my machines. But what
> about upstream impacts? As I understand it, GnuPG authentication is
>
Your Thoughts :)
https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/
--
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
> 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
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?
> 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
On Sun, Jun 30, 2019 at 03:49:55AM -0700, Mirimir via Gnupg-users wrote:
c) what happens when they go after more certificates?
If you're willing to blackhole two certs, great. Where does it stop?
How many certs can the strong set stand to lose?
Your third point is actually why I suggested
> 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?
Hm, that’s not how I read it, although I could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, 30 Jun 2019, Andrew Gallagher wrote:
On 2019/06/30 11:49, Mirimir via Gnupg-users wrote:
It would stop when certs can no longer be poisoned. And I don't see the
downside. I mean, what good does it do to have people downloading keys
that
> "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
On Sun, 30 Jun 2019 08:44:43 -0400, Robert J. Hansen stated:
>> What would have prevented a state level actor from activating this
>> exploit on a wide level during a time when it would have been most
>> effective for them?
>
>A nation-state with a professional intelligence service probably
I can’t speak for others, but I wasn’t suggesting you were personally
responsible for where things are right now, only making observations about the
utility of continuing to use the product going forward, and what the targeted
end users likely expect from the software.
-Ryan McGinnis
> 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
On 2019/06/30 11:49, Mirimir via Gnupg-users wrote:
> It would stop when certs can no longer be poisoned. And I don't see the
> downside. I mean, what good does it do to have people downloading keys
> that break their stuff?
>
> I don't see that as "doing the bad guys’ work for them". I see it as
> I guess that’s one way to look at it, but if your end users are
> dissidents and journalists communicating in happy fun places or
> developers signing critical software, then surely you’d want the
> product to be resilient against 10 year old trivial attacks from your
> users’ adversaries.
I
I guess that’s one way to look at it, but if your end users are dissidents and
journalists communicating in happy fun places or developers signing critical
software, then surely you’d want the product to be resilient against 10 year
old trivial attacks from your users’ adversaries. I do
> What would have prevented a state level actor from activating this
> exploit on a wide level during a time when it would have been most
> effective for them?
A nation-state with a professional intelligence service probably isn't
very interested in taking down the keyserver network. Why should
What would have prevented a state level actor from activating this exploit on a
wide level during a time when it would have been most effective for them? I
have to believe that the fine folks who can put an APT in your air-gapped
computer’s video card bios have been aware of this attack for
On 30/06/2019 09:19, Robert J. Hansen wrote:
> Right now only three certificates are known to be affected: mine, dkg's,
> and Kristian's.
I must have missed the memo describing the exact nature of the problem.
Could you please provide a link to something (email message, web page)
that explains
On 06/30/2019 03:10 AM, Robert J. Hansen wrote:
>> Because a) it’s enumerating badness [1] but more importantly b) it’s
>> punishing the victim. Protecting the ecosystem by banning RJH and DKG’s
>> keys from the keyservers entirely is doing the bad guys’ work for them.
Currently, we know that
> Because a) it’s enumerating badness [1] but more importantly b) it’s
> punishing the victim. Protecting the ecosystem by banning RJH and DKG’s
> keys from the keyservers entirely is doing the bad guys’ work for them.
There's an important c):
c) what happens when they go after more
> On 30 Jun 2019, at 11:01, Vincent Breitmoser wrote:
>
> The single biggest issue is
> importing keys that don't have identity info on them. I submitted a patch to
> GnuPG to fix this issue, but for some reason that is beyond me there seems to
> be
> resistance to merging it:
Unfortunately
> On 30 Jun 2019, at 10:21, Mirimir via Gnupg-users
> wrote:
>
> This is undoubtedly a naive question. But anyway, would it be feasible
> to test keys by importing them, and seeing which ones break OpenPGP?
> Maybe do it in minimal Docker containers? And then somehow block access
> to those
> 3. interoperability. The replacement service would need to be fully compatible
> with all existing clients.
Depending on what you mean by "fully compatible". The single biggest issue is
importing keys that don't have identity info on them. I submitted a patch to
GnuPG to fix this issue, but
Robert J. Hansen wrote:
> > Can someone please explain to me why the GnuPG flag for key servers
> > --no-modify is in GnuPG and why the authors of key server software
> > did not implemented this feature?
>
> It's pretty unreasonable to think a piece of software from 2003, meant
> as a drop-in
> Can someone please explain to me why the GnuPG flag for key servers
> --no-modify is in GnuPG and why the authors of key server software
> did not implemented this feature?
It's pretty unreasonable to think a piece of software from 2003, meant
as a drop-in replacement for software written in
Andrew Gallagher wrote:
>
> > On 30 Jun 2019, at 09:19, Robert J. Hansen wrote:
> >
> > The next version of Enigmail will no longer use the SKS network by
> > default. Great! But what about existing Enigmail users? They'll see a
> > signature, click "Import Key", and ... bam. They're
On 06/30/2019 01:34 AM, Andrew Gallagher wrote:
>
>> On 30 Jun 2019, at 09:19, Robert J. Hansen wrote:
>>
>> The next version of Enigmail will no longer use the SKS network by
>> default. Great! But what about existing Enigmail users? They'll see a
>> signature, click "Import Key", and ...
> Thankfully there is a practical - if drastic - solution for all
> OpenPGP users everywhere. Point pool.sks-keyservers.net (and its
> various aliases) somewhere else. The question is where to and how
> soon.
(I am certain Andrew has already considered this: I am making explicit
what I think
>> Thankfully there is a practical - if drastic - solution for all
>> OpenPGP users everywhere. Point pool.sks-keyservers.net (and its
>> various aliases) somewhere else. The question is where to and how
>> soon.
>
> (I am certain Andrew has already considered this: I am making explicit
> what I
> On 30 Jun 2019, at 09:19, Robert J. Hansen wrote:
>
> The next version of Enigmail will no longer use the SKS network by
> default. Great! But what about existing Enigmail users? They'll see a
> signature, click "Import Key", and ... bam. They're likely not going to
> think that
> How bad could this get?
(I am sputteringly angry over this entire thing: please understand this
and give a charitable read to what I write. I appreciate it.)
Hard to say.
One of the big problems we have is the size of the existing codebase.
Once people have GnuPG installed people
On 06/29/2019 11:26 PM, Robert J. Hansen wrote:
>> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
>
> I stand by what I wrote.
>
> As usual, don't read the comments unless you want to despair for humanity.
It sounds like SKS is dead meat. And hagrid is coming. And you advise:
> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
I stand by what I wrote.
As usual, don't read the comments unless you want to despair for humanity.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
44 matches
Mail list logo
