Re: [Sks-devel] sks.daylightpirates.org is staying...again

[Yegor Timoshenko]

> Do you happen to have a long-term patch also, or just the
> hardcoded poison key?

I don't, and most importantly, I don't think a long-term patch is
even possible without completely overhauling SKS.

Fundamentally, given current implementation, this attack means
two things: attacker can take down the whole network via OpenPGP
packet spamming pinged back and forth by recon, and attacker can
deny recon to any specific key by adding a bunch of garbage
packets to that key to the point of making its recon impossible.
Both attacks are feasible today to anyone and do not require any
resources.

I can imagine how to fix the first problem while retaining full
compatibility with SKS, but not without making the latter even
worse than it is now which is in my opinion the more critical
problem.

1) If max key size is set, it means any key can be denied further
updates by uploading signatures up to that size (which will be a
valid attack even against validating keyservers; against
non-validating keyservers, any kind of packet will work). This
means at the very least being able to deny any further signatures
to that key, making it possible to undermine WoT, and unless a
complex per-packet-type disk quota system is implemented, any
further changes (like revocations!) whatsoever.

2) If max key size is not set, it is possible to add so many
signatures (or any kind of packet if there is no validation) to a
key that it becomes realistically impossible to fetch. That's the
attack I was going for initially, and was not aware about
implications outlined in 1). Performance issues of merging, and
any workarounds other than setting max key size also go in here.

So there are two fundamental issues with current design.

The first and more prominent one is
https://bitbucket.org/skskeyserver/sks-keyserver/issues/41, lack
of validation, closed as WONTFIX. That is also a critical UI flaw
that makes it easy to trick users who use HTTP interface.

The second and somewhat less critical is ability to append
packets to someone's key. It is imaginable to store signatures
with the user who has issued them, rather than with key which is
being signed. That will resolve this attack, but drastically
changes how WoT works.

To reiterate: any perceived long-term fix of this issue to the
current SKS codebase (e.g. max key size) will make it much easier
to do targeted attacks on keys, muting any future key updates for
them, which is already possible today. In my opinion, this is a
fatal flaw and the very thing that SKS design was supposed to
avoid.

> I wonder why nobody thought about this possibility before.. so
> any lasting fix besides hardcoded blacklisting?

People did think about those kinds of issues a decade ago, but
never acted upon them.
 
> It is very easy to test for vulnerabilities if you actually
> install sks on your own machine first, and try to also fix it
> before publishing/exploiting it. Many have tutorials on this
> subject and all you need is a copy of a key dump.

Not really. This particular key poison vulnerability can only be
seen if you have a testing network of at least three keyservers.

I didn't know the extent of damage my attacks will have: I was
just poking SKS for basic attack vectors that, at that time, I
was sure would have no effect at the network at large. I haven't
looked at SKS source code while testing any of the attacks
whatsoever.

I didn't even know these attacks had any pronounced long-term
effect on the network before ~3 weeks ago when I took a look at
sks-devel@ mailing list and found a huge discussion on the topic.
(I was never approached about this until recently.)

Now that I did take a look at source code, I think there might be
a way to corrupt any key (similar to
https://bitbucket.org/skskeyserver/sks-keyserver/issues/57 that
was fixed in GPG but AFAIK still not released), but point of
pursuing a tangible exploit is moot because other issues that
have been reported are comparably critical but have not been
fixed.

Historically speaking, it would seem as if benevolently attacking
the network was the most effective way to have it evolve. Say,
consider Evil 32, which was an effort that included bruteforcing
a 32-bit fingerprint lookalike to every key in trusted set
(https://evil32.com) and uploading it to keyservers. By then, the
danger of 32-bit key fingerprints was known for a long time, but
no one did anything about it.

> There are other ways of bringing an sks server down, and BDB
> might not be the best idea for a server, still the network is
> important for both free software and individuals using it.

There are likely other low-effort ways of bringing an SKS server
down :-(

You are right that SKS network is still important to a lot of
people, however I believe that this trust has been misplaced.
Hopefully these attack vectors (and potential mitigations) being
public will bring awareness to the issue and motivate someone to
create a more robust alternative to SKS, and users to prefer less
exploitable ways to share keys (or choose a different encryption
scheme entirely, say one that has forward secrecy, or pursue more
contained tools for signatures such as OpenBSD signify(1) or
minisign).

> Blockchain technology has larger issues when it comes to GDPR
> yet we don't see blockchain nodes going away for this very
> reason.

I don't think so. First, you can have a blockchain where nodes
can agree to delete data from it while retaining e.g. checksum of
the data so that future blocks are not invalidated. Second, space
on the blockchain is very scarce and thus at premium (requires
very expensive proof of work), while anyone can upload megabytes
of publicly available data to keyservers and have it mirrored by
all SKS operators worldwide.

> The SKS network is even more important after the recent privacy
> incidents that everybody knows about, and I wonder how safe is
> PGP done in javascript, or sks key generation on Raspberry PI:)
> . There were issues for ssh key pairs.

I don't think that SKS in its current state is safe to use.

> [...]
> 
> The noise provided by the webcam seems to be sufficient for
> initializing /dev/random so when the webcam is covered with
> plastic foil the command is still useful, maybe at boot/reboot
> time.

I don't think any of these methods produce good entropy. You
might want to look at modular entropy multiplier based hardware
RNGs like Inifinite Noise:

https://www.crowdsupply.com/13-37/infinite-noise-trng