So a while back I had a few features in mind, most of which required devices knowing each others public keys for the purpose of encrypting secrets to each other without having been connected.
Currently there is really no way to know that ahead of time.
We have the key available in discovery server, so I was thinking of adding support for discovery server to store that, and returning during discovery lookup (or could be separate endpoint).
The devices would then store that value locally (or store it on connection if they don’t get it via discovery), so if it was a separate endpoint it would only be called once.
I don’t have concrete feature in mind, but I think this would be generally useful to have, as it allows to craft messages only readable by the destination.
A few things where this might be useful:
Some sort of side-channel for the future folder password sharing? If I know I want to share folder X with device D and allow it to decrypt it, I could have a blob that is encrypted with Ds public key that only D can read folding the details. I guess the same could be done with encrypting it with a passphrase that both sides know, but just thinking out loud here.
This could be useful for encrypted discovery (yet it does not work for bootstrapping, as you can’t encrypt addresses for devices that you don’t know that want to talk to you).
Something something, trusted token for auto-accepting remote devices or something? I guess this can just be a passphrase and doesn’t really need to be something that is public key encrypted, but I guess going from a small token to a device + folder + proof combo is more interesting.
I had a branch with encrypted discovery once, using the peer device ID as a PSK (so removing the need to have their whole pubkey stashed). I think it fell down on the bootstrapping problem, in that you can’t find a device until they’ve also added you so the whole “this device wants to connect” thing breaks.
Otherwise I guess what we need for cool invitations is just a place to stash a random blob of data under a random token of sorts. I would then create a blob with my device ID and folder ID(s) in, encrypt it with a PIN, sign it with my secret key, and store it “somewhere” under a random token. Tell the token and PIN to someone. They grab the data using the token, decrypt it using the PIN, add the device ID and folders locally, and present the signed token on first connect.
(This is essentially an elaborate JWT if we want to reuse some similar existing tech.)
Yeah, you might not even need signatures, you could just store “this secret phrase inside the encrypted message allows 3 devices to connect to me”, and you could do usage counting locally.
Anyways, this was more about whether we should set up PK sharing infrastructure, because it feels useful, even if I can’t find a usecase for it yet
Yeah I was kind of subtly trying to say I don’t see a use for PK sharing for any of the known potential use cases. So no, if you ask me.
But some sort of scheme to share a piece of information with another device using a key shorter than the information itself is useful. But that really just means something that can GET/PUT things under a key.
I guess in theory we might not even need blob storage, but my I wanted something that you could physically write down on a post it, which device id + folder + some magic token is a bit too much.
I think we need some kind of blob storage because you want the thing on the post-it to be maybe 16 characters, tops. And that should result in the recipient device getting info about at least one device ID and multiple folder IDs, and some longer magic admit-one-device token or so. Those sixteen characters could be maybe eight characters random storage key (the blob server gets these) and eight characters encryption key (so the blob server can’t interpret/use the blob in question). (Eight chars password isn’t a lot but we can use like a million rounds of PBKDF2 to ensure the blob server can’t reasonably brute force it.)
So no, if you ask me.