Asymmetric authentication

[bakape]

• [x] Instead of keeping around many kinds of session like login sessions use nonce signing + public key UUID
• [X] When a client connects to the server for the first time, create and store a key pair.
• [X] If we move all traffic to websockets, session management (including antispam) becomes easier, as the client only needs to sign the handshake request.
• [ ] Can replace login sessions and passwords
• [ ] Can replace captcha sessions
• [ ] Can replace post passwords
• [ ] Can be used for OP moderation rights
• [ ] Add token credential and export buttons to Identity settings modal
• [x] Send either a registered pub key by UUID with a nonce (both concatenated and signed) or the public key, if it has not been registered yet.
• [ ] Return UUID on successful initial handshake.
• [ ] Identify all posts with public key foreign key for 7 days
  • [ ] Don't clear foreign key for OPs for moderation authorization
  • [ ] Use public key UUID + thread ID + salt to generate thread-local user IDs
  • [ ] Cache these on Client to not regenerate each time
• [x] Use 4096 bit private key
• [ ] Limit size of public key accepted by server.
• [ ] Sign image SHA-1 hash (because we compute that anyway) on image upload

@Chiiruno Any input?

[Chiiruno]

It looks great, so far. I'll try to think of some edge cases tomorrow. Only immediate issue I can think of is local storage and whether that's going to reliably keep a private/public key, but if the OP is enough of a bwaka to not save the key and for some reason kill the entire browser cache, then oh well.

[Chiiruno]

Also wouldn't this kill the need for TLS and maybe even gzip for a rather large part, other than statically served HTML, etc?

[Chiiruno]

No, TLS would still be needed, not all websocket connections are guaranteed to be guarded by async crypto.

[bakape]

Only the initial connection request will be signed.

[Chiiruno]

Is there any way we can reuse TLS in this case?

[Chiiruno]

As in, instead of a custom async system, reuse TLS.

[bakape]

In a browser? Think not, but you can research that.

On Sun, 10 Nov 2019, 17:40 チルノ, notifications@github.com wrote:

As in, instead of a custom async system, reuse TLS.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bakape/meguca/issues/1151?email_source=notifications&email_token=AB347MBYRACGF7JYJMUYGCTQTATONA5CNFSM4JLMU3Y2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDU73NA#issuecomment-552205748, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB347MGEOQGTNLYWIVLLZPLQTATONANCNFSM4JLMU3YQ .

[Chiiruno]

Can't reuse TLS, since there's a timeout on TLS resumption. Unless, assuming we can somehow hook into the private/public key in-browser, we use this as a temporary session.

[Chiiruno]

Would be pointless for it to be temporary though, it would nullify the point of this. Rolling our own key pair seems to be for the best.

[Chiiruno]

Assuming threads never expire, key pair should never expire. Speaking of things never expiring, how are we going to handle IP retention? Just continuously delete posts in-thread other than OP?

[Chiiruno]

In that case, OP post should not have IP attached to it, past 7 days.

[the8472]

Some concerns about using asymmetric crypto:

• privacy, the keys could act as user-identifiers that are more long-lived than the IP
• DoS (asymmetric operations are comparatively expensive)
• easy to get wrong when you work with the low-level primitives

[bakape]

We can provide a button to explicitly regenerate the cert and to swap it for a different one, if they want . Does this clear the privacy concerns?

I'll need to investigate the performance penalties, but it should not be that big of an issue, considering cert checks can be done lazily after a valid captcha is solved. Once you do have a captcha, you can spam the cert check on connection. Perhaps that can increment the spam score.

On Tue, 12 Nov 2019, 00:36 the8472, notifications@github.com wrote:

Some concerns about using asymmetric crypto:

• privacy, the keys could act as user-identifiers that are more long-lived than the IP
• DoS (asymmetric operations are comparatively expensive)
• easy to get wrong when you work with the low-level primitives

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bakape/meguca/issues/1151?email_source=notifications&email_token=AB347MCVDBIKFGANUJVZVETQTHM6FA5CNFSM4JLMU3Y2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDYL5AI#issuecomment-552648321, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB347MCCKPC7B75LZATJLGLQTHM6FANCNFSM4JLMU3YQ .

[bakape]

Or we could just use 1 KB of random data as the global password for anything a user does, which has to be submitted on establishing a WS connection and performing image uploads. The whole signing bit seems pointless complexity on second thought.

[the8472]

why 1kB? 256bits chosen at random gives you 128bits of collision space (birthday paradox), i.e. 2^128 possible users before collisions become likely.

[bakape]

The question is not collision space but enough entropy to use it as a non-expiring authentication token. But yes, 1 KB is too much. 64 bytes will suffice.

On Tue, 3 Dec 2019, 22:20 the8472, notifications@github.com wrote:

why 1kB? 256bits chosen at random gives you 128bits of collision space (birthday paradox), i.e. 2^128 possible users before collisions become likely.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bakape/meguca/issues/1151?email_source=notifications&email_token=AB347MHE5HHOZXSE6E6RN73QW25QZA5CNFSM4JLMU3Y2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF2V4AY#issuecomment-561339907, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB347MEGTSCC5BYGYG4JRQDQW25QZANCNFSM4JLMU3YQ .