Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SKS Keyserver Network Under Attack

gist.github.com

Post reply on HN
Print view View original

71–80 of 197 posts

Re: SKS Keyserver Network Under Attack

#71

Post by Sir_Cmpwn »

AnaniasAnanas wrote: post #70
Sir_Cmpwn wrote: post #56

Earlier quoted context omitted.

Efail was a symptom of bad PGP implementations in email clients, not a flaw in PGP. It was overblown trash designed to bring fame to the "discoverers" at the expense of the reputation of PGP and its authors. If you think that this statement doesn't belong here, you can take it up with the mods, a group which spending lots of time on HN does not qualify you for.

As much as I believe that Efail was the result of badly implemented email clients it's not like the OpenPGP standard hadn't any involvement with it whatsoever. DJB for example suggests small authenticated and encrypted packets, something that OpenPGP does not have. See https://groups.google.com/forum/#!original/boring-crypto/BpU... Since I am apparently replying too fast and I need to slow down, here is my reply to t…

I don't really see the link between the email you posted and efail, other than the fact that PGP encrypts the whole message. I don't understand how, if it encrypted smaller parts of the message, efail could have been avoided.

Re: SKS Keyserver Network Under Attack

#72

Post by tptacek »

Sir_Cmpwn wrote: post #71
AnaniasAnanas wrote: post #70

Earlier quoted context omitted.

As much as I believe that Efail was the result of badly implemented email clients it's not like the OpenPGP standard hadn't any involvement with it whatsoever. DJB for example suggests small authenticated and encrypted packets, something that OpenPGP does not have. See https://groups.google.com/forum/#!original/boring-crypto/BpU... Since I am apparently replying too fast and I need to slow down, here is my reply to t…

I don't really see the link between the email you posted and efail, other than the fact that PGP encrypts the whole message. I don't understand how, if it encrypted smaller parts of the message, efail could have been avoided.

PGP has semi-optional, strippable authenticators. Serious cryptographic protocols do not. Plaintext encrypted with a modern AEAD cipher --- forget protocols, here we're just talking about selecting reasonable primitives --- can't be decrypted without simultaneously authenticating. That's not how PGP (or S/MIME) works, and that malleability led to Efail.

No competent engineer would accept in 2019 (or, for that matter, 2009) a new cryptosystem that functioned the way PGP does.

Re: SKS Keyserver Network Under Attack

#73

Post by Whatitat90 »

dngray wrote: post #49
Valodim wrote: post #36

Earlier quoted context omitted.

It would be a better way, but the technology hinges on support by e-mail providers. I wouldn't recommend holding your breath. The other contender is Autocrypt, which performs key exchange inline in emails in an automated fashion. It only depends on client support, and has gained at least some traction (enigmail, k9, mailvelope, gpgOL, delta.chat, and some others).

> It would be a better way, but the technology hinges on support by e-mail providers. I wouldn't recommend holding your breath. Ah. > The objective of the project was to develop new mechanisms for the reliable and automatic public PGP key exchange between e-mail providers. The results have also contributed to the WKS/WKD standard that is part of the GnuPG project. https://mailbox.org/en/security I was looking at goin…

> Part of the reason I changed my email is because I had in the past submitted a few keys to the sks network which I lost the private keys to, they were also submitted with an infinite expiry. I was a stupid kid.

That's why most recent versions of GnuPG automatically create keys with expiry set to 2 years.

Re: SKS Keyserver Network Under Attack

#74

Post by perlin »

Now may be a good time to plug a project we worked on at my last gig. KeySpace uses IPFS to store PGP keys in a decentralized file system. We used a smart contract on the Ethereum blockchain to store an address-hash lookup. What this achieves is fully decentralized peer-to-peter encrypted communication. We used it to facilitate trustless OTC negotiation and trading.

https://medium.com/fluidity/keyspace-end-to-end-encryption-u...

Re: SKS Keyserver Network Under Attack

#75

Post by Whatitat90 »

dngray wrote: post #34

Isn't WKD supposed to help out with key distribution for email? * https://wiki.gnupg.org/WKD * https://tools.ietf.org/html/draft-koch-openpgp-webkey-servic... I'm thinking that's a better way to publish keys these days anyway. I have my own domain, so maybe OPENPGPKEY record in my domain as well DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP https://tools.ietf.org/html/rfc7929

> I have my own domain, so maybe OPENPGPKEY record in my domain as well

> DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP

WKD has some benefits over OPENPGPKEY - it keeps the request confidential (as WKD uses plain HTTPS). WKD is just easier to get right, that's why it's more broadly supported. GnuPG, that supports both of them, defaults to WKD. If OPENPGPKEY request is made it seems GnuPG doesn't even validate DNSSEC signatures: https://lists.gnupg.org/pipermail/gnupg-users/2011-December/...

Re: SKS Keyserver Network Under Attack

#76

Post by tptacek »

I'd like to gingerly suggest that this is not the way a project that has deliberately set as its adversaries hostile world governments should respond to a trivial, predictable† vandalism attack.

Rather, if they're serious about what they're doing – Hansen, in a related document, talks about the "good advice" he gave to dissidents in Venezuela about using GnuPG – they should thank whoever did this. This attack apparently only hit the accounts of two maintainers – that is, two people who are, or should be, exquisitely capable of distilling signal from the attack, and making sensible decisions to mitigate it going forward.

A serious attacker, on the scale of the adversaries this project has, again, deliberately selected for itself, wouldn't waste the vulnerability this way. They'd wait for the most opportune time and apply the attack broadly to accomplish their own state-level goals.

This isn't the first time the GnuPG ecosystem has responded this way to attacks. They similarly (and dishonestly) attacked the Efail researchers, and in the same document I referred to above, Hansen attacked EFF and Micah Lee for publishing exploit code; "Academic freedom should not be construed as permission to publish attack tools against a critical service with known vulnerabilities". This is what you'd expect from one of the vendors posting about a tempfile race condition on the CORE clique list in 1992; it's preposterously out of step with how the field handles vulnerability research today.

If you're relying on GnuPG for anything serious, you should be alarmed at the way they react to security setbacks.

† Indeed, repeatedly predict-ed

Re: SKS Keyserver Network Under Attack

#77

Post by baby »

hinkley wrote: post #43
ghuntley wrote: post #35

Earlier quoted context omitted.

I get that but in this case though this codebase has safety guarantees baked in via the Hindley–Milner (HM) type system whereas your python code base did not. Additionally there's a published, peer reviewed paper for this software that serves as a written specification. Those two things are fantastic resources when coming up to speed with an unfamiliar codebase.

I’m an old school strong, static typing proponent (strong typing shall rise again!) but I laugh at the notion that it protects you from crypto attacks. Are you a maintainer or an armchair critic? I hope the latter, because if you think type safety is anything more than necessary but insufficient, then that’s number three.

Did he say it defends you against crypto attacks? It does defend you against a lot of attacks that would still endanger the system. Think denial of service attacks for exemple. Extremely easy in Python because bugs don't get caught at compile time.

Re: SKS Keyserver Network Under Attack

#78

Post by [deleted] »

diafygi wrote: post #47
Shoop wrote: post #5

> It's written in an unusual programming language called OCaml, and in a fairly idiosyncratic dialect of it at that. This is of course no problem for a proof of concept meant to support a Ph.D thesis, but for software that's deployed in the field it makes maintenance quite difficult. Not only do we need to be bright enough to understand an algorithm that's literally someone's Ph.D thesis, but we need expertise in obs…

> Any particular reason it's difficult to maintain (other than the lack of popularity of FP in general)? A much bigger issue than the language itself is the overall architecture of the server. It uses Berkeley DB as the main database and only handles one connection at a time. So, if your gossip process starts syncing a huge spam key, you block all front-end web requests (see my issue #61[1]). Also, the keyserver is c…

[deleted]

Re: SKS Keyserver Network Under Attack

#79

Post by giomasce »

diafygi wrote: post #45

I have maintained keyserver in the pool for many years[1], and attacks like this are, in theory, able to be easily mitigated. I mean, we're only talking about appending spam to public keys. It's not like the attackers found some flaw in OpenPGP that breaks public keys or valid signatures. In theory, all these attacks to do is cause bloat on keyservers. So why can't we deal with these types of attacks? IMO, the main r…

I don't think that the base issue lies in the implementation: you can make it as scalable, parallel and document as you wish, but if what you are doing is basically receive data from whoever sends you something, store it, pass it to other server and do not offer any form of accountability over who can store such data or who can delete it, it will always be trivial to write a script that just sends lots of data and bloats your service. The problem lies in the architecture itself.

Re: SKS Keyserver Network Under Attack

#80

Post by mzs »

tptacek wrote: post #76

I'd like to gingerly suggest that this is not the way a project that has deliberately set as its adversaries hostile world governments should respond to a trivial, predictable† vandalism attack. Rather, if they're serious about what they're doing – Hansen, in a related document, talks about the "good advice" he gave to dissidents in Venezuela about using GnuPG – they should thank whoever did this. This attack apparen…

indeed: https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54...
Post reply on HN