Wormhole Seeds

[piegamesde]

Migrated from magic-wormhole/magic-wormhole#77, as I think it's a good idea to discuss feature that are not Python-exclusive here.

---

Basically, both sides of a Wormhole connection would derive a 128-bit mailbox-id and a 256-bit wormhole secret (from the PAKE session key), and store it for later use as a "Seed". This seed is used exactly like a normal wormhole code, except that the mailbox ID is used directly (instead of being treated as a "nameplate" which then points to a mailbox), and the Seed can be reused.

(we don't strictly need to use PAKE each time, but it happens to provide forward-secrecy, and we already have all the code in place.. it'd actually be more work to use a simple non-PAKE KDF).

(also, the wormhole secret could be considerably shorter, and still be safe, but there's no harm in making it full-sized)

[piegamesde]

Some thoughts about the UX:

• Every client generates a UUID and also a human-readable username
• Connections between clients that support Wormhole Seeds will exchange their IDs and other relevant information. It is stored in a local database.
• After the transfer, a hint "to reconnect with this person again, you can also …"
• The mapping display name -> UUID must be unique within the database on each machine. There needs to be some collision handling.
• Maybe some timestamp expiry of entries to keep the database from growing forever?

To be fair, this is mostly independent from the protocol, but some details – like exchanging the IDs – are. An alternative would be to make pairings explicit using a wormhole pair command. In that case, the IDs would be user-generated (every user names all their communication partners).

[meejah]

Thanks for moving / continuing this discussion! Some thoughts after reading above:

• it would be good to specify in the protocol a method to allow extra information to flow each way, at first perhaps just a "petname hint" to give a good default to the other side (e.g. mine might send {"preferred_petname": "meejah"}).
• likely makes sense to keep a suggested list of "relevant information" that implementations should store locally so that APIs etc can stay more in-sync with each other (e.g. mailbox_id, seed, petname, ...)

[warner]

One more comment to migrate from the old ticket:

The API I'm thinking of would be like:

w = wormhole.create(stuff)
w.set_code(code)
w.connect() # ...
seed = w.get_seed()

# later
w = wormhole.from_seed(seed)
w.connect()

[piegamesde]

Working on this again, and some design questions coming up:

• Should the clients store a nameplate or a mailbox to find each other?
• If the latter, how does this work client-server-protocol wise? Can the client simply open any mailbox they want without having claimed it beforehand or should there be a new client->server message for this?
• Generally, should this be part of the core Wormhole protocol, or should this be a application-layer feature (i.e. only for file transfer, and any other application chooses whether they want to have this or not)?

By the way I'm thinking about renaming this to "Wormhole resumption" or something because it's more intuitive.

[meejah]

Generally, should this be part of the core Wormhole protocol, or should this be a application-layer feature (i.e. only for file transfer, and any other application chooses whether they want to have this or not)?

It should be a general feature.
"Seeds" is what gives us a long-term way to connect with others and seems immediately useful for use-cases besides file-transfer.

Should the clients store a nameplate or a mailbox to find each other?

99% sure "mailbox" is correct here (but I haven't had time to delve all the way in again).

[meejah]

Re: naming, I do kind of like more whimsical names sometimes because it helps reduce preconceived notions.

A "Wormhole Seed" requires you to look up at least a short definition; "wormhole resumption" lets you immediately decide your own expectation for what "resume" means to you...which can be a bad thing if those don't end up lining up with reality.

"Grow a new wormhole from a Seed" might be more accurate than "resume a previous Wormhole" anyway because IIUC the key-material will be different on each wormhole (more like "grow a new one, that's really similar"?)

[warner]

Clients should store a mailbox, not a nameplate. We only use nameplates because they're short and easy to dictate/transcribe. As such, they're short lived, and mutable (the 2- I use today is pointing to a different mailbox than the 2- that you use tomorrow). Since the clients are able to remember a full-length identifier, and full-length identifiers are not scarce, they don't need a layer of indirection.

And yeah, clients can open any mailbox they want. This is exactly what they do when re-connecting (after they've released the nameplate), such as when their network connection to the mailbox server drops and comes back up, or when their state is saved to disk and the application is restarted. They forget about the nameplate entirely once they've seen evidence that the peer has started using the mailbox.

Agreed that this should be a general feature.

+1 on "seed". Apart from the utility as non-preconceived jargon, it also fits the overall whimsical style of Magic Wormhole. Call it part of our "brand" :).

[piegamesde]

Thank you for the input. I noticed that handling identifiers is more tricky than I initially thought: since anybody can take anyone's UUID, there still be some collision handling required. I'm evaluating a public/private key pair approach to identify and authenticate wormhole devices. I'm also evaluating the usage of the shared mailbox name or something like that as an identifier.

Generally, making connection pairing explicit would make things a lot easier. However, I really like the concept of doing things automatically, because otherwise a lot of people are going to miss this feature.

[meejah]

The "unique thing" is the mailbox-id. They're long enough that there are no collisions.

I thought you'd proposed UUIDs for local serialization; what other purpose might they serve? (Anyway, a long-enough UUID can also be counted on to be unique).

[piegamesde]

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 don't have any central naming instance. See the following threat example:

• A, B and E have exchanged files with each other.
• E exchanges a file with A, but takes the identity of B
• A uses send-to B, but actually E will receive the file.

I know it is a rather weird threat model, but it shows that for seeds you need to trust peers more than I'd like to. It would be fine with manual peering, but I don't think this is acceptable for an automatic mechanism (some people send things to randoms on the internet they don't necessarily want to trust).

[meejah]

Okay, I agree that there can be issues making sure that users are able to communicate to the software which connection they mean. I think this is up to the frontends though -- that is, a UI/UX issue. I'm not really sure what you mean by "takes the identity of B" above (but I assume some social manipulation to make the other user save that wormhole as a different name...?)

For example, a GUI might choose to display a list with names that the user themselves had previously given those connections.

In the Python client, I'd probably choose something similar: a user-assigned petname for that connection. I would also have this be "opt-in" only and not automatically remember any connections at all unless told. That is, something like --save-user alice off the top of my head.

Whether internally those are serialized in a database with UUIDs or use some other mechanism: don't care. We can certainly give guidance as to the desired UX but ultimately this is all up to the UI designers. We could also give some guidance as to the dangers etc that might arise.

To relate this back to @warner 's python pseudo-code above: what the application program does between seed = ... and w = from_seed(...) is up to the program. For example, I would imagine a phone-based program might want to put the seed into the "Contacts" database.

I guess for more context here is how I imagine this functioning for a file-transfer application. If I'm making a GUI client then the basic version just always gives you a code to exchange. A more-featured version might give you the option to save the contact for future use ("[ ] - remember this connection") at which point it would demand a name (from the user on the local end) or some other mechanism for the user to identify that connection again (maybe an icon makes sense to some designers). Then if you initiate another transfer the user can choose between "create a new code" or "re-establish a previous connection"; in the latter case they have to identify it (e.g. picking the name or touching the icon they remember for the other device). Note that the intended recipient also has to do this for it to be successful. That is, Alice tells her software "do another transfer with Bob" and Bob tells his software "do another transfer with Alice" and because they've both remembered the same mailbox-id, it works.

[piegamesde]

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 of the two armies problem, we must expect this might happen).

My suggested solution is to do a key update on every wormhole connection between both peers, even without seeds. Thus, a broken seed could simply be repaired by sending a file with a code; the seed would be self-healing in a way.

But that exact update mechanism opens an attack vector for impersonation I mentioned, if not defended by authenticating the connection peers. Adding a bit of public/private key crypto for this is not a big deal IMO, but let me know what you think.

---

An obvious alternative solution would be to always use the same keys for a seed. We would lose the forward secrecy, but it would also give us the possibility for multi-client support. (Is there a way to have multi-client support and forward secrecy?)

[meejah]

Do you mean the Two Generals Problem?

Can you describe what you think might get out of sync (with Seeds)? In the original proposal I don't see any way to update them so I don't see how they can get out of sync...? (That is, my understanding is you'd use the same mailbox-id and the same 256-bit Seed on every new wormhole to the other device for whatever named connection it is -- the actual session key will be different each time though, since the Seed is used as SPAKE2 input not as a key directly).

(I can't even really picture what "multi-client support" means in the context of magic-wormhole -- that should probably be a separate discussion no matter what).

[piegamesde]

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 Seed on every new wormhole to the other device for whatever named connection it is -- the actual session key will be different each time though, since the Seed is used as SPAKE2 input not as a key directly

That's where our understanding differs and the most important question to resolve. I understand it that the used code must be derived from the previous session's key in order to provide forward secrecy. On the other hand, without that mechanism the two generals problem indeed disappears.