Live data from Hacker News

“Pest” vs. 0xFE

loper-os.org

21–30 of 35 posts

Re: “Pest” vs. 0xFE

#21

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?

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

#22
The concept of the "SelfChain" confuses me. It sounds like it would fall apart completely for anything except direct messages. If one person goes offline and all other people continue to talk, does that mean the next day my station considers all other speakers "forked"? And I have to unfork all of them? It's not like I can catch up since all messages are stale and discarded after 15 minutes.

Do 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

#23
post #14

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

"V" is a very simple versioned publication system (there's an explanatory link in the article.)

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

#24
post #7

Very 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…

Author of linked article speaking. (How it ended up here -- I have no idea, I'm rather surprised that it was of interest to more than the 3 people for whom it was written.)

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

#25
post #21

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?

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.

Re: “Pest” vs. 0xFE

#26
post #6

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

This is correct, and is described in the article ("Kelvin versioning".) The concept is not original to the author.

Re: “Pest” vs. 0xFE

#28
post #21

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

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

Re: “Pest” vs. 0xFE

#29
post #28

Earlier 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

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

#30
post #28

Earlier 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…

The fact that indirect messages are marked as unverifiable "hearsay" (seemingly regardless of how many peers confirm it), the fact you can only join the network if you peer with someone, and the bounce limit seems to imply that you would want to peer very liberally.

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.

Post reply on HN