OK #radical idea. No signatures, no certificates. Deniable authentication between peers, and nothing else, but with relaying. If Alice sends you Bob's feed, you just blindly trust that it's Bob's feed, allowing Alice to MITM you and Bob whenever she wants. Crazy, right? Well, if you're also peering with Bob, then you can tell if Alice is lying...

Let's say you peer with Alice and Bob, and Alice sends you Claire's feed. You just blindly trust that it's Claire's feed, but then Bob also sends you Claire's feed. If Bob and Alice send you different feeds for Claire, but they also send you their own feeds, you can tell if Bob is lying about Alice's feed. If he isn't, then that's 2:0 odds he's telling the truth about Claire, with only 1:1 odds for Alice, since you can verify she lies once, tells the truth once (her own feed).

Short of an outright Sybil attack, which can be defeated by steganography or having just one single peer outside the adversary's control, you can estimate whose version of someone's feed is the legit version by looking at the odds that your known peers are telling the truth. That means you can basically get someone's feed without ever connecting to them, or verifying their identity at all. You can build trust with them, without any signatures or even authentication.


@cy Both Alice and Bob might get Claire's feed from Dave, and only Dave, who messes with it.

Signatures make it easier to mitigate against more difficult to control scenarios.

However, *authentication* can be mostly skipped either way. You can trust Claire's signature whether or not you verify that the private key is in possession of any particular individual.

@jens Right, so there has to be some degree of separation. You don't have as good of odds, if Dave messes with his feeds, even though Bob doesn't. So the odds would be a combination of Bob and Dave, or Alice and Dave. Plus nobody is only connecting to one peer; Claire had better trust Dave a whole lot to do that. You can pretty much assume Claire is Dave, if she "decides" not to peer with anyone else.

@cy Especially when bootstrapping a node, chances are *very* high you peer with only one party, or a very limited subset.

Also, here both Alice and Bob peer with Dave and each other. It's not what I'm describing. I'm describing another kind of bootstrapping where some content / feed is only available from a single source (in reach).

That is going to be a typical case for anything long tail.

@jens Bootstrapping is a problem in any network, with or without signatures. If the only person you can trust is Dave, then you have to trust him with everything you can't do yourself.
With content, it sorta doesn't matter who the source was, if the content is good. You want the source to be less known actually, because that's who they go after first!

@cy Hard disagree on the conclusions, but I suspect I'm mostly writing this for the record.

Bootstrapping is an issue in every network, which is why it's a likely attack point. That's exactly why putting effort here is necessary, and it shouldn't be dismissed.

Content being good is true, but also a red herring in the age of fake news. A compromised source can wreak havoc.

Signatures do not protect against compromised keys, but against inserting damaging content into a legit stream.

@jens A compromised source can wreak havoc, only if you believe that it isn't compromised. This network allows for a range of trust, when you don't even trust someone enough to authenticate with them, but can still communicate, probably.
Once you trust someone enough that you believe that they won't be compromised, then you'll exchange keys and can directly peer with each other.

@jens The problem with signatures is Claire reveals something forbidden to me, and then the authorities catch me and beat me with a rubber hose until I give them her signed message. Then they beat her with a rubber hose until she gives them her private key. Now they have proof that she was the one who sent it, and can continue beating her with rubber hoses. If she didn't sign it, they could only guess which peer she was.

@jens Or more likely I sold out to them long ago, and have been feeding them her signed messages for the past 3 months. I can't tell who she is with or without her signature, but if someone gets her private key, then they can, unless she doesn't sign her posts.

@cy You can't tell who she is with the signature, either, you need additional (signed) info. You can only tell that multiple pieces of content were authored by the same source. You know nothing else about the source without more authentication.

If the source is already compromised, that could lead to issues as you describe. The easy thing here is to rotate keys.

@jens What people are afraid of is after the authorities confiscate your private key. They can prove you authored those messages then, retroactively. If your private key is secure, then yes, it's possible to be private and still sign stuff.
Deniable authentication means I can't sell you out that way, even though I'm 100% sure you authored what you sent me.

@cy Protecting the private key is the holy grail, yes. Removable and shreddable trust modules (aka tokens, etc) are a pretty good step here.

@jens Oh, key rotation is good too. That and key chains. If your main key signs your daily key, and some thugs get both of them, all they can prove is what you signed today, and that you signed keys in the past, but not what those keys themselves signed.

@jens @cy aren't signatures and certificates already a form of deniable authentication? "i didn't sign that: somebody stole my keys".

@colin @cy Well, that's an interesting question, and it depends on your use case is the answer. Mostly no.

You can copy signed stuff and pretend it's all yours. You need some kind of authentication to break that pretense.

Usually it means the challenger generating and encrypting some data, and expecting it to be returned. Only who is in possession of the private key can do so. That's sort of the minimal authentication.

But if you're only interested in all content...

@colin @cy ... coming from the same source, and you don't care who relays it, then I suppose so.

Most forms of authentication go beyond a challenge / response cycle. They expect e.g. certificates that tie extra information about an entity to a key. Could be a user name, could be more.

You can't really trust the challenged party with this, so you need a signature from some "higher" authority. And that's what you have with TLS, and most corporate authentication.

Sign in to participate in the conversation
Finkhäuser Social

A private instance for the Finkhäuser family.