Then you have the problem of keeping the OTP secure at all ends of the conversation.
Then you have the problem of keeping the OTP secure at all ends of the conversation.
I solved for that already.
A zero trust model is easy to come up with in one sitting, so I did.
Theres actually two approaches. One where a service (potentially selectable on the users side, much like torrent trackers) acts as a mediator for initial connection. And one where dedicated servers are more involved, but theres still no server-side decryption (tradeoff is latency because it requires multiple back and forth round trips for encrypting, sending, and decrypting on the other users end).
Number I wrote is what it would cost me to drop work right now, and build it. Once built though, it would only cost somewhere between $10 per user on the low end for one implementation, up to $35-40 per user on the high end implementation. Those are the actual numbers for the two specific implementations.
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)