You might be able to do something diffie-helman shaped at the javascript level (hard to ensure it actually works) to show a fingerprint of the shared secret that could be confirmed via outside channels.
But all-in-all this does not offer ANY security over a server because there is no way to show it is not just being stored on a server.
- Build a DHT style overlay network of "meet in the middle" servers
- Have a standalone html file, that uses websockets to connect to the network of servers.
- Have both clients generate keys, exchange them via other channels.
- Both users have a shared key, they both lookup the server that hosts the shared key on the DHT network (that actually can be done without leaking the key to every server) then they use that server to exchange NAT-busting messages
Ideally, you would have a lot of different use cases using the same network in such a way that it is hard for a server to figure out what you are using it for, and it is essentially impossible for a server to target MITM a specific pair. What this does leave open is sybil attacking and MITM-ing everything opportunistically. At this point we essentially start to build TOR via websockets and WebRTC and it all breaks down.
I'm a little worried, that because the browser get it's own address from the server there might be a way to build a lie that looks plausible to both users, but I can't think of a way to do that off the top of my head.
Mega[1] users JS based crypto and it's been fine
[1]: http://mega.co.nz
https://bitf.ly/1b4b7ee4fe39312afbfffbe47d831f99#someaeskey
That way, the server never sees the key (it's client-side and fragments don't get sent), but nobody except the recipient can decrypt the data.
essentially, now the STUN is the MITM. STUN server lies to both parties about what their IP addresses are and responds with IPs that it controls. Both parties connect to those IPs and the messages are relayed between them.
This will betray my lack of domain knowledge but it sort of opperates like a double encryption, so basically the data is encrypted maybe then sent, then it is encrypted by a forwarding proxy which also has a priv./pub key. You query for the hash, get the hash, decrypt it, and send it back.
Could you use this as the broker for webrtc? I know that wasn't exactly Nakomoto's BitcoinD paper, but their model seems to make sense, and a lot in this context.
