Involving servers ain't gonna work unless there's an easy way for any user to verify that the encryption is happening locally and there's no way for the servers to have access to the keys. Unfortunately, that's impossible. A trojan horse app could easily encrypt stuff locally and slip the key in and encrypt it with the server's key. Everything looks good on the user's end. Things are encrypted locally. Then they send the message and the server decrypts it to get the key, which can be used to decrypt the message. The encrypted message can be forwarded on to the recipient.
Any system that "does the encryption for you" is suspect.
Involving servers ain't gonna work unless there's an easy way for any user to verify that the encryption is happening locally
In one implementation, serves only act to mediate two or more people connecting and then hand it off, so thats a non issue. One time pads are easily verified as secured. They're secure by definition when done correctly.
happening locally and there's no way for the servers to have access to the keys.
That was the hurdle I overcame. Its not impossible its actually relatively straightforward once you sit down to figure it out.
A trojan horse app could easily encrypt stuff locally and slip the key in and encrypt it with the server's key.
The nature of a one time pad is that its always the size of the key is always the size of the content (unlike public-private key systems), and the keypad is never to be reused. It has what is called "perfect information-theoretic security." That means its mathematically indistinguishable from noise once encrypted, unless you have the original pad.
Any system that "does the encryption for you" is suspect.
Thats why you give access to the source code. And you do all your encryption and decryption locally.
(post is archived)