piegames

Okay, this is not the uniqueness-problem I am facing right now. The issue is that users need to be able to identify their peers in a reliable way, but we...

I think I've further narrowed down the problem I mentioned earlier: It starts with the question of what happens if the two sides get their key out of sync (because...

> Do you mean the Two Generals Problem? Yes, I remembered the name wrong somehow. > That is, my understanding is you'd use the same mailbox-id and the same 256-bit...

You are right, the way you understand it [kind of](https://eprint.iacr.org/2019/351.pdf) gives us forward secrecy. > If you manage to steal the Seed itself, then of course you could impersonate one...

> Isn't that kind of the whole point of Seeds? Well, yes and no. I know to *whom* (as a person) to connect (as in, one UUID and a known...

## Proposal A (as before) - **Initialization:** - Both sides initially generate a shared secret from the session key. - They also exchange UUIDs to identify themselves, and also a...

You are right, they aren't directly needed for Protocol A, at least from a cryptographic point of view. Any other fixed mailbox would do as well. I still kept them...

Okay, so I'd like to be able to tell for a "normal" connection whether or not a seed with that peer has already been established. This is not required, but...

I think I have solved all my previous problems with the following solution: ## Proposal C **Initialization on normal connections:** - Both sides derive the seed from the shared session...

> I'm worried we've got too many concerns competing here. What is the point of the "auto discovering intersections" between existing seeds? (That does leak privacy information: it tells both...