SoylentNews is people
SoylentNews
OpenPGP protocol developer, Daniel Kahn Gillmor, has written up what is happening with an attack against the OpenPGP's infrastructure. In recent days the SKS keyserver network has come under a particularly hard to mitigate attack which is, problematically, also difficult to resolve permanently. The problem lies with the design of that part of the infrastructure. Although replacements are available, the move has not yet happened.
Some time in the last few weeks, my OpenPGP certificate, 0xC4BC2DDB38CCE96485EBE9C2F20691179038E5C6 was flooded with bogus certifications which were uploaded to the SKS keyserver network.
SKS is known to be vulnerable to this kind of Certificate Flooding, and is difficult to address due to the synchronization mechanism of the SKS pool. (SKS's synchronization assumes that all keyservers have the same set of filters). You can see discussion about this problem from a year ago along with earlier proposals for how to mitigate it. But none of those proposals have quite come to fruition, and people are still reliant on the SKS network.
Also covered at Vice as Someone Is Spamming and Breaking a Core Component of PGP's Ecosystem and ZDNet
Earlier on SN: Op-Ed: Why I'm Not Giving Up on PGP (2016)
(Score: 4, Interesting) by sshelton76 on Friday July 05 2019, @02:54AM (4 children)
This is a legitimate application of blockchain technology.
Remember a blockchain is nothing more than a cryptographically secure, time stamped ledger. Consensus and spam control are vital aspects of that design in order to keep the chain from growing out of control, which is exactly what is happening with OpenPGP here.
The attack presently underway works because there is little to no cost to the attacker to execute it, but the cost to the network is horrendous.
We don't even need a full on blockchain, just proof of work.
Proof of work involves a puzzle that is NP hard. This means that it is hard to solve, but once solved, the answer is verifiable.
An example of proof of work would be something like.
Given
f = some hash function such as scrypt or SHA
n = nonce (a 32 or 64 bit integer)
d = data being appended or updated
x = final result
t = target (a number chosen by the server and smaller than the bitwidth of the output of f
Solve
x =t where x = f(d+n++)
Return d,x,n
This is easily verified since the whole point is to search the space of integers looking for an nonce (n) that when hashed with the data produces a hash smaller than target t.
Once one is found, it is immediately verifiable even though it can take a hell of a long time to search for n in the first place.
A change of protocol to require proof of work would be more than enough to thwart it at least for the short term, especially if the proof of work algorithm is something that cannot be gamed easily. This is actually a solved problem and one of the major reason that cryptos like Bitcoin are so slow and expensive to conduct business on once they reach a certain critical mass. The cost to the spammer is too high to make that little bit of thrill he/she gets from being a douche worth their while.
(Score: 2) by sshelton76 on Friday July 05 2019, @03:00AM
Well that formula didn't come through at all, so let me try again.
Solve
x <=t where x = f(d+n++)
(Score: 2) by jasassin on Friday July 05 2019, @11:47AM (2 children)
You are obviously better than math at me, but when you take into consideration the amount of emails vs bitcoin transactions, is the delay feasible when the chain deals with that massive amount of entries?
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 0) by Anonymous Coward on Saturday July 06 2019, @01:22AM
...bitcoin?
this is a problem for BLOCKCHAIN. Bitcoin would be one of the worst blockchains for this purpose due to transaction cost and timing.
(Score: 3, Interesting) by sshelton76 on Saturday July 06 2019, @10:21PM
Blockchains don't need to have a delay to them. The bitcoin blockchain has a 10 minute delay in order for blocks to propagate around the globe even on slower connections.
It needs this delay today because that delay also slows the amount of new money entering the system, because each new block generates new coin.
If your goal is simply to witness that a transaction occurred and it really doesn't matter how many blocks that transaction gets included in, you can completely dispense with any sort of metering on blocks, even consensus doesn't need to be hard consensus and can be a form of soft consensus instead.
To really limit spam though, from both spam sigs and spam blocks, the network can collectively agree to adjust "t" using some formula that results in an average of x new blocks per u time, while setting another t, for certificate signatures. (t1 = block difficulty & t2 = transaction difficulty)
Keep in mind though, this is changing a certificate by counter-signing it, it is not sending an email. Ergo, the limit is on how often you are updating your own certificate. Once the data is in the blockchain, it is easily and instantly verifiable.