Live data from Hacker News

“Pest” vs. 0xFE

loper-os.org

11–20 of 35 posts

Re: “Pest” vs. 0xFE

#11
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 that/why HTTPS is important for security even if you only provide read only content with making proper crypto/security decisions?

Re: “Pest” vs. 0xFE

#12
"Firefox does not trust this site because it uses a certificate that is not valid for www.loper-os.org. The certificate is only valid for the following names: *.nfshost.com, nfshost.com"

Re: “Pest” vs. 0xFE

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

“Message forgery by the recipient” is a bit strong. It's more like “lying by the recipient”, since the signature is only meaningful to the recipient.

This stops stuff you say in chat from following you around, unless you choose to sign it with your regular private key.

Re: “Pest” vs. 0xFE

#14

Title should be updated to match the original: "Pest" v. 0xFE "vs." being an abbreviation for versus carries an entirely different meaning than the intended version.

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.

Re: “Pest” vs. 0xFE

#15

Title should be updated to match the original: "Pest" v. 0xFE "vs." being an abbreviation for versus carries an entirely different meaning than the intended version.

In all brutal honesty I would have read "v." as versus, whereas just "v" as in "v 4.2.0" would be version.

Re: “Pest” vs. 0xFE

#16

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…

“Message forgery by the recipient” is a bit strong. It's more like “lying by the recipient”, since the signature is only meaningful to the recipient. This stops stuff you say in chat from following you around, unless you choose to sign it with your regular private key.

“Message forgery by the recipient” is a bit strong.

It's exactly what it allows: The recipient can forge a message they supposedly did receive.

Try explaining "yes it's encrypted and prevents forgery, but not if it's forged by the recipient" to a judge or the media after there was a scandal ;=)

Re: “Pest” vs. 0xFE

#17
post #14

Title should be updated to match the original: "Pest" v. 0xFE "vs." being an abbreviation for versus carries an entirely different meaning than the intended version.

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.

Re: “Pest” vs. 0xFE

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

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?

Re: “Pest” vs. 0xFE

#19
post #3

> 1.1. What is Pest? > Pest is a peer-to-peer network protocol intended for IRC-style chat. It is designed for decentralization of control, resistance to natural and artificial interference, and fits-in-head mechanical simplicity -- in that order. > Pest explicitly rejects the inherently-centralizing concepts of IRC

> 1.2.1. One Station -- One Operator.

> An IRC server is typically inhabited by a multitude of casual users and policed by a small group of privileged curators. A Pest station, on the other hand, is under the exclusive control of one person: its operator.

> 1.2.2. Nets Instead of Channels.

> Pest stations organize into nets. A net is formed by a group of station operators with a common interest. An operator who wishes to join a net must peer with at least one of the stations in that net. A broadcast message is sent to every member of a station's net. Nets may easily and organically undergo schismatic splits, or, on the contrary, combine into larger nets, whenever the individual station operators so desire.

This is interesting stuff. The basic model seems kind of elegant and should be relatively straightforward to implement. It also seems like it should be relatively easy to set up a station that "bridges" to other chat platforms like Matrix, IRC, etc.

However I suspect that moderation being nonexistent could pose a problem. Un-peering with somebody is equivalent to blocking them, which is certainly a valid tool for dealing with troublemakers, but it doesn't carry the same weight as being able to centrally found somebody. But I suppose that's part of the deliberate design here.

Re: “Pest” vs. 0xFE

#20

Earlier quoted context omitted.

“Message forgery by the recipient” is a bit strong. It's more like “lying by the recipient”, since the signature is only meaningful to the recipient. This stops stuff you say in chat from following you around, unless you choose to sign it with your regular private key.

“Message forgery by the recipient” is a bit strong. It's exactly what it allows: The recipient can forge a message they supposedly did receive. Try explaining "yes it's encrypted and prevents forgery, but not if it's forged by the recipient" to a judge or the media after there was a scandal ;=)

Messages are put into wax-sealed envelopes before being sent over the internet. This evidence is an open envelope with some wax on it.

This digital signature proves the message was written by a party to the communication, but it doesn't prove which one.

Encryption keys can be used to make digital signatures. Anyone with the key for this communication could've made that signature; not just the sender, but the receiver as well.

(I'm sure you can think of more.)

Post reply on HN