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: 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.