Sharing codes

Development
1

So when I initially added the hello message, the idea behind it was that we would add additional fields in the future for handshaking which would allow supporting “sharing codes” for folders.

These codes, just like existing possible folder setups would not be authorative (as in, there is no such thing as read only codes as we don’t have signing of messages etc), and are purely cosmetical for the purpose of establishing a relationship.

I am thinking of the following of the following workflow.

  1. You on device A “Share” a folder which generates a code, the code is probably time based (valid for N days) and count based (valid for a single use, or valid for 3 relationship establishments). The code has some significant entropy not to be bruteforceable.
  2. The code is stored in the config, with validity, usage count.
  3. A payload is posted to hello.syncthing.net. The payload contains: SHA(code), Validity, AES(code, {deviceId, folderId, otherStuff}).
  4. The hello.syncthing.net service promises to store the payload under SHA(code) lookup key until Validity.
  5. On the other side, device B, the user can use the code to join (accept?) the folder, which does a lookup in hello.syncthing.net, and retrieves the AES encrypted payload by looking up SHA(code), checks validity.
  6. Device B decrypts the payload using code, asks the user to configure the folder path (or shares an existing folder based on auto-introduce logic probably), adds device A to it’s own config (which it found in the payload), and stores the pending code association with the device A (ala device.pendingCodes = append(device.pendingCodes, newCode)). A becomes a normal device on B.
  7. Upon B connecting to the remote device A (where A is not yet aware of B), we include any pending codes in the hello message addressed to device A. If we get past Hello, we discard any codes that were pending (or blow up in flames if the code is no longer valid or something like that, or the folder we expected to get shared is no longer there?)
  8. Remote device A accepts hello message, checks for known codes that were issued, if the code is still valid and still has use attempts, it adds that device and shares that folder with the device and adjusts code usage accordingly.

Thoughts?

If we ever get to elliptic curve based signing and AES encryption of folders, the payload could include private EC key for signing, or just the AES key for decryption, so you would have different features part of the code.

2 Likes
2

I guess it doesn’t improve the workflow alot, other than being able to generate a shared secret that prevents the need for having access on both sides to establish the initial trust.

This also helps these random “I want to deploy syncthing to one billion devices all connecting central server” horror scenarios…

1 Like
3

Sounds reasonable to me at first glance

4

Hi. I’m the one who implement that horror scenarios from time to time :wink: I try to interest some people to use syncthing, especially some customers who want share some really sensitive data in quite big group. So far having to connect each new person on source machine is a bit pain in the butt for some of them. So it looks like it would be very useful feature, so please keep an eye on it guys.

Regards.

1 Like
5

Does this potentially cause issues if the code usage cannot be adjusted in a timely manner on hello.syncthing.net? E.g. other users trying to click your link to add themselves but not being told that the link has expired/been used up.

6

Making sure to only allow a single-use code once and things like that would need to be up to the accepting device. It’ll adjust a counter in the database or remove the code from where it’s store (database or config), etc. The hypothetical “hello” service should only be a passive place to store a small piece of data under a random name for a short while.

I’m sure it will happen that someone tries to use a code only to then have the connection denied for whatever reason. (Code expired, code used, other device forgot about the code, user revoked it, …) It would probably be good if the connecting device understood this specifically and said something like “the code you used was not accepted” instead of just mysterious connection failure.