I'm not seeing much detail about the crypto (other than serpent and HMAC-512). Also: there is a claim of being DDOS-proof, but I haven't found an explanation as to how. Also: is there actual implementation or even a mock?
“Pest” vs. 0xFE
21–30 of 35 posts
Re: “Pest” vs. 0xFE
#22Do I allow a hearsay message to fork one of my peers? Can a rouge peer just come in, fork everyone, and leave?
Re: “Pest” vs. 0xFE
#23Earlier quoted context omitted.
It's supposed to mean "version"? The post seems to be the successor/continuation of "Pest v. 0xFF", replacing it by ... decreasing the version number? Then it starts off saying that you're going to need a "vtree", and for that obviously you need a "V-tron" and that's about where I gave up. It was like trying to read something from a parallel world.
Apparently this is something related to using the Bitcoin blockchain to produce a cryptographically verifiable sequence/tree/dag(?) of revisions. Like Git but more crypto-ey.
Vpatches are backwards-compatible with ordinary gnupatch. (can simply execute "patch -p0 < nameofpatch" for the sequence.) "V" has nothing directly to do with Bitcoin.
Re: “Pest” vs. 0xFE
#24Very neat: > 1.2.4. Messages are Authenticable, but not Opposable. > All Pest messages are authenticable -- a station will only process a message if it carries a valid signature from a peer (though in some cases, the message may not have been authored by that peer.) > However, they are also repudiatable (i.e. non-opposable) -- since all packet signatures are produced with symmetric keys, the recipient of a message ca…
> However, they are also repudiatable (i.e. non-opposable) -- since all packet signatures are produced with symmetric keys, the recipient of a message cannot, at any point in time, prove to a third party that he was not in fact the author of that message. So basically there is intentionally no way to prevent message forgery by the recipient. Why? Also tbh. how can I trust a person who in 2021 still hasn't understood…
This flame is doubly funny given how the article specifically concerns algorithms for possible decentralized cryptonets.
HTTPSism is deliberately broken on my WWW, to annoy unthinking servants of the PKI Reich.
For the thick: at the start, there is a PGP-signed copy of the text offered. And yes I in fact live and die by my PGP identity. And not Verisign et al's NSA-controlled PKI horror, no.
Re: “Pest” vs. 0xFE
#25I'm not seeing much detail about the crypto (other than serpent and HMAC-512). Also: there is a claim of being DDOS-proof, but I haven't found an explanation as to how. Also: is there actual implementation or even a mock?
I also don't see much DDOS proofing in this. Best I can find is that you can unpeer people, but since every message is rebroadcasted by everyone, that doesn't seem like much of a protection. Especially since, if the DDOSer has a lot of peers, it seems can be pretty imposible to know who the attacker even is, since there is no singed journal of hops or something.
Re: “Pest” vs. 0xFE
#26Earlier quoted context omitted.
FWIW, I would have read "v." the same, as "v." is also an abbreviation--mostly used in legal documents and court cases--for versus.
Looks like the versions count down toward zero. Pest v. 0xFF is an older article by several days.
Re: “Pest” vs. 0xFE
#27I can't wait to try out some implementations.
Re: “Pest” vs. 0xFE
#28Earlier quoted context omitted.
I also don't see much DDOS proofing in this. Best I can find is that you can unpeer people, but since every message is rebroadcasted by everyone, that doesn't seem like much of a protection. Especially since, if the DDOSer has a lot of peers, it seems can be pretty imposible to know who the attacker even is, since there is no singed journal of hops or something.
"every message is rebroadcasted by everyone" is not factual per the spec.
There is also a bounce limit, but I would expect that (average number of peers) ^ 3 might be plenty amplification
Re: “Pest” vs. 0xFE
#29Earlier quoted context omitted.
"every message is rebroadcasted by everyone" is not factual per the spec.
Do you mean some technicality like "only broadcast messages" and the deduplication list or something that can actually stop DDOS? There is also a bounce limit, but I would expect that (average number of peers) ^ 3 might be plenty amplification
You can be DOSed, so to speak, by one of your peers, but not DDOSed by a third party -- a reasonable machine can reject signature-failing or replayed-stale packets from multiple NICs at line rate, so long as your WOT is compact (i.e. less than 100 entries). This of course remains to be experimentally tested. Currently there is only an algorithm!
Re: “Pest” vs. 0xFE
#30Earlier quoted context omitted.
Do you mean some technicality like "only broadcast messages" and the deduplication list or something that can actually stop DDOS? There is also a bounce limit, but I would expect that (average number of peers) ^ 3 might be plenty amplification
Only validly-signed (from one of the station's peers) messages move past the decoding stage ("prologue"), and of these only ones with timestamp +/-15min. of station's time; these finally searched for in dedupe queue; and at the end may be rebroadcast, if so marked, to the station's peers strictly. You can be DOSed, so to speak, by one of your peers , but not DDOSed by a third party -- a reasonable machine can reject…
And the trick is that you can't just be DOSed by a peer, you can be DDOSed by the peers of your peers of your peers, as I see it.