freenode/#shirakumo - IRC Chatlog
Search
16:25:34
Shinmera
I've started thinking about supporting a limited form of decentralisation for Lichat.
16:26:26
Shinmera
The rest would be client-side stuff so you can easily support multiple connections at once, and merge user information across multiple servers.
16:30:12
Shinmera
I suppose the easiest way to do that would be to use the pgp public key user field.
16:31:25
Shinmera
So the server would have to supply a challenge token that is unique to the server, which the user encrypts, and other users can then verify using the public key.
16:32:04
Shinmera
Only issue is that most people won't know about pgp, let alone care to do all that, so there has to be a way to automate it almost all the way.
17:04:11
SAL9000
Shinmera: perhaps an explicit "identity verification" framework that users can use when they want to?
17:07:15
Shinmera
I've been thinking of something on the client side that would automate this process. Meaning we make the signature generation completely autamatable and just specify that clients should allow importing a private key to use, or generating one if requested.
17:07:52
Shinmera
We already have a field for the public key, so the extension would only require a verification token field on the server side.
17:09:03
SAL9000
why would server ID matter, if the goal is to let users prove to other users that "yes, I'm the same XYZ as you met on the other server"?
17:09:50
Shinmera
So the client would encrypt the server ID, set that on the user profile, and others would decrypt it and check if it matches the server ID they got.
17:11:25
SAL9000
If I set up my own Lichat server, with the same server-ID, then I can assign myself whatever user ID I want
17:12:26
SAL9000
Simple design: server generates nonce, user encrypts nonce, server sets "verified" flag. This requires the other users to trust the server.
17:12:56
SAL9000
For independent verification, the first thing that comes to mind is publishing that nonce along with the signature.
17:15:38
SAL9000
OTR only makes sense in a 1-to-1 context, though, unless that's changed since I last looked
17:16:32
SAL9000
i.e. you can use OTR to prove that you're talking to the same person you talked to last time; proving that they are the person you want to talk to in the first place is up to you.
17:19:32
SAL9000
(in other news... ouch, turns out I had a backup job crontab being installed twice. with the same time specification. welcome to borked backups!)
17:21:21
Shinmera
Anyway, I've been thinking about using the planned signing extension with an extra update for prodding a user instead.
17:22:21
Shinmera
Meaning verifying that the user is genuine would require: 1. check the public key published in the user fields is the same 2. send a nonce update to the user 3. receive the nonce update from the user, which must include the signature parameter 4. verify the signature.
17:23:15
Shinmera
the only thing the server would have to facilitate for this is channel-less communication for this update.
17:26:25
SAL9000
This kind of thing is where the "never reuse your keys" advice comes from, as far as I know.
17:26:27
Shinmera
Oh, you mean they can send a nonce they want and thus make messages for themselves
17:27:22
Shinmera
well one part of this is that the signature is of the whole update, not the nonce alone.
17:28:30
Shinmera
How about sending a "prod" request to the server, which then generates a nonce to send to the user (and back to the requester)?
17:28:31
SAL9000
maybe we need to allow 2 public key fields? not sure if one can discover sibling/parent keys given a subkey.
17:30:42
Shinmera
How about this instead then: the requester sends a signed prod update. This ensures that the requestee can verify the integrity, too. Second, the signee removes the signature and signs the update themselves, then sends it back.
17:31:10
Shinmera
As in, people are not likely to know wtf that is and are going to be confused and worried by it.
17:32:18
Shinmera
the idea would be that now there's no nonce to create an oracle with, just a timestamp to ensure we're recent.
17:33:14
Shinmera
though I suppose it creates a problem with a chain of trust -- as in, where do you start trusting people if you can't verify them.
17:33:38
SAL9000
Keybase is a step in the right direction -- automated bootstrapping using existing services
17:36:57
Shinmera
pushed a draft for the signature protocol https://github.com/Shirakumo/lichat-protocol#717-signing-shirakumo-sign
17:36:58
Colleen
github.com/Shirakumo/lichat... Website (HTML), Title: GitHub - Shirakumo/lichat-protocol: Protocol definition and specification for the Lichat chat system
17:39:42
SAL9000
One signature per message fits with your design of a signature field on the update.
17:42:11
SAL9000
You mention UTF-8; might be worth locking down some aspects of that, like overlong representations.
17:43:42
SAL9000
Yes, Windows allows UTF-8 overlong in filenames. Windows allows UTF-16 surrogate codepoints encoded as UTF-8 in filenames.
17:46:12
SAL9000
compression, encryption, fancy techs, they all trade off recoverability for speed/safety
17:46:37
Shinmera
Wonder whether the sorting should be on the codepoint level. That seems the most stable, since the UCA can change.
17:47:53
Shinmera
it's not actually rendered text after all, we just care about getting a standardised sequence that is predictable.
17:48:05
SAL9000
I mean that if signature is only [0, 127] then you don't need to care about Unicode
17:49:08
SAL9000
i.e. you can represent, say, "å" as a single codepoint, or as "a" followed by a combining character.
17:49:39
SAL9000
if fields are not canonicalized anywhere, then you don't need to care for the signature either
17:50:34
SAL9000
"The wire format is based on UTF-8 character streams on which objects are serialised in a secure, simplified s-expression format"
17:54:11
SAL9000
haha... restic folks talking about "unattended encrypted backups w/o key disclosure" and people bring up `restic backup --password-file <(gpg --decrypt keyfile.gpg)`
17:54:33
SAL9000
that is still just as much key disclosure. asymmetric encryption is the only way to go to actually get that goal.