Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Pest” vs. 0xFE

loper-os.org

Post reply on HN
Print view View original

31–35 of 35 posts

Re: “Pest” vs. 0xFE

#31

Post by dathinab »

asciilifeform wrote: post #24
dathinab wrote: post #11

Earlier quoted context omitted.

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

> at the start, there is a PGP-signed copy of the text offered

Which shows you don't understand the problem.

HTTPS on content only sides is primary about preventing people with tampering with the website in ways which potentially can hurt you from just opening them. The increased trust-ability of the content is important too, but only secondary.

A PGP signed copy helps me to verify the content after I already fully loaded it with a lot of additional overhead.

It doesn't prevent JS injected into your side from being executed, does it prevent a injected http redirect to a fingerprinting site or similar (which e.g. could use non JS fingerprinting or potential non JS based RCE attack vectors, which luckily I haven't heard of in browsers in recent years but are not impossible at all.).

As long a browsers don't check the signature before loading/parsing any content it isn't secure.

EDIT: In general in 2021 using HTTS "doesn't cost you anything" (in the sense of nearly anyone can afford it), neither does it prevent you from still doing what you currently do (standing by PGP(oversimplified)) and being against the by now pretty much not-undoable not-decentralized HTTS infrastructure. But realism is a important part of security.

Re: “Pest” vs. 0xFE

#32

Post by asciilifeform »

dathinab wrote: post #31
asciilifeform wrote: post #24

Earlier quoted context omitted.

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

> at the start, there is a PGP-signed copy of the text offered Which shows you don't understand the problem. HTTPS on content only sides is primary about preventing people with tampering with the website in ways which potentially can hurt you from just opening them. The increased trust-ability of the content is important too, but only secondary. A PGP signed copy helps me to verify the content after I already fully l…

> HTTPS on content only sides is primary about preventing people with tampering with the website

"people" here specifically excluding Verisign & its successor racketeers, the NSA (plus bananistani national equivalents thereof).

> in ways which potentially can hurt you from just opening them

Running shitware is optional.

> It doesn't prevent JS injected into your side from being executed

The only solution to malicious JS is... to switch off JS. Asking people you don't know to pay the cert tax does not somehow guarantee that their JS is not malicious.

> ... check the signature before loading/parsing any content it isn't secure.

"Secure content" is what you obtained from someone you actually trust and verified with a pubkey you received out of band (ideally -- meatspace). All other content may as well have been authored by evil martians, despite any pretense to the contrary.

> by now pretty much not-undoable not-decentralized HTTS infrastructure

What part of "Where I still have the freedom not to use the Reich's master-keyed pseudocryptographic garbage - I will not use it" is hard to understand?

IMHO it is quite strange that the "HTTPS-everywhere" nonsense isn't immediately understood by everyone for what it is -- simply Google's latest effort to stymie ad-blocking (with the applause of NSA, whose mission today consists largely of efforts to retard the development of actual - i.e. not masterkeyed and not escrowed - crypto.)

Re: “Pest” vs. 0xFE

#33

Post by asciilifeform »

edave64 wrote: post #30
asciilifeform wrote: post #29

Earlier quoted context omitted.

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.

Indirect messages must be marked as hearsay, given as (barring the use of asymmetric crypto, which is AFAIK impossible to carry out at Gb+/s line-rate without specialized hardware) there is no way to verify, in any useful sense, their authorship.

The most that can be done to infer authenticity of indirect messages is to see whether such a message rejects the authorship of a known previous message having the same handle -- via the SelfChain. In virtually any case of handle collision, this will occur.

Re: floods -- a station only processes messages from a peer. So in fact in all cases the proximate cause of a flood is identifiable, and you can "UNPEER" and "GAG" him.

Flooding by a peer is annoying, but is not what people normally think of as "DDOS" (normally the term implies a flood of rubbish received directly from unauthenticated third parties.)

How liberally to peer -- is a matter for an individual station operator. Peering with every passing acquaintance has obvious down-sides.

Re: “Pest” vs. 0xFE

#35

Post by eru »

nerdponx wrote: post #18
dathinab wrote: post #11

Earlier quoted context omitted.

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

I find this weird and almost the opposite of what I would want. I would want a system where I cannot repudiate messages that I sent, but I must repudiate (i.e. cannot claim authorship of) messages that I did not send. As far as I understand, isn't that how asymmetric encryption typically works? What's the advantage of symmetric encryption in this case?

See https://en.wikipedia.org/wiki/Off-the-Record_Messaging
Post reply on HN