[doomrobo]

If the server stores the transcript of a session, can it brute force the PIN later on?

Magic Wormhole (https://github.com/magic-wormhole/magic-wormhole) avoids this by using a password authenticated key exchange (PAKE) protocol. If you don’t use a PAKE, you get trivial brute force attacks from anyone with a transcript.

[avovsya]

What do you mean by transcript? If you mean the messages that were shared - the answer is no, server sees no messages at all as message exchange is peer to peer via WebRTC. As soon as session is over(eg. When all clients disconnect) - message history is lost for good. Brute force attacks are theoretically possible for sessions in progress(though hard due to alphanumeric 6 character PIN and server throttling), so I'll introduce "safe session" as suggested by some of the commenter by introducing "waiting rooms" so the newly connected clients have to be approved. I'd definitely leave the current workflow as is as its frictionless and works for some of my usecases(quick link or log sharing, etc)

[doomrobo]

There are middle boxes between the two peers, yes? Routers and such. They observe the encrypted messages. They can brute force the password, even after the session is over.

Even if you assume the PIN is uniformly random (you should not assume this), it is only log2((10+26)^6) ~ 31 bits of entropy. This does not satisfy standard notions of secure channel establishment.

[nenaoki]

The pin would just be for coordination, not encryption.

[doomrobo]

Ah ok. How is the encryption key, if there is one, established then?

[nenaoki]

I think they just use the encryption and key exchange that WebRTC has cooked in https://datatracker.ietf.org/doc/html/rfc5764

[lxgr]

tl;dr: One peer generates a self-signed certificate and sends the fingerprint of that over the signalling channel; the other connects to it as a "client".

The resulting DTLS keying material is subsequently used for SRTP encryption (for media) and SCTP over DTLS (for the data channel, which is presumably what's being used here).

[avovsya]

You're right, thank you for answering!

[lxgr]

WebRTC is end-to-end encrypted by default and only requires a tamper-proof, but not confidential, signaling channel for that encryption to be secure, so retroactive, or even ongoing passive, signalling server compromises are not a concern.