4 ms·
> How do you distribute the one time pad in the first place? I'm fairly naive to this area, but wouldn't video chat initiated with public keys suffice? Then co
by ihnorton 10y ago
> How do you distribute the one time pad in the first place?
I'm fairly naive to this area, but wouldn't video chat initiated with public keys suffice? Then confirm identities and exchange secrets. To me this seems substantially equivalent to in-person key exchange for non-Three Letter Agency threat models. 20 years ago this wouldn't really have been feasible, but today it (mostly) is -- from a quick glance at the FAQ, Signal may even support something like this already.
(If your threat model includes "abduction and coercion", then aren't you kind of hosed even with previous in-person OTPs?)
- PuffinBlue 10y agoIf a video chat with public keys is secure enough to exchange a one time pad, why would you need to bother with the one time pad at all? By transmitting your OTP it is no stronger than the method used to protect it in transport, so if that transport method is secure enough to guarantee the security of the OTP, why not simply use that method for everything and forget about the OTP?
- ihnorton 10y agoI did say "exchange secrets" for a reason -- that secret may be a key for later use (e.g. for data dumps), or actual information. What I'm trying to understand is whether the (relatively new) feasibility of interactive video channels allows for building roughly the same level of trust as would be provided by in-person key exchange. I'm basing this on the understanding, possibly incorrect, that encryption with a public key allows for creating a secure communication channel, but not necessarily a trusted one. The hypothesis is that the capability to conduct interactive video provides a way to verify identity and establish trust at roughly the same level as would be provided by in-person exchange (again, assuming 1-1 trust, and excluding TLA threat models).
- mcbits 10y agoI might trust a video chat today to verify an identity, but only because it would be a relatively new method. Definitely not in a few years if it ever took off. It's already possible to forge a talking head and fall back on "sorry, bad connection out here in the field" to hide glitches.
- cortesoft 10y agoYou are forgetting a key part of the 'trust' thing; you have no way of knowing if someone is man in the middle attacking your video chat. Example: Alice wants to video chat with Bob to exchange the secret key and verify identity. Mallory sets up a MITM attack, and gives her own public key to both Alice and Bob. Alice and Bob think they are securely talking with each other, but they are actually securely talking with Mal, who decrypts the video, watches it, then forwards it on to the other person. This is why you can't have a secure communication channel without trust; you don't know if your secure communication is being intercepted, read, and then passed on.
- IncRnd 10y agoA video chat is not enough to safeguard secrets to be used in the future. For one, if the video chat is secure enough for an otp exchange, the otp isn't needed. Secondly, if your video chat gets recorded, which may very well happen, you need to use ephemeral keys. Thirdly, since the video chat is likely recorded, at least the meta information, the effective security of your otp degrades over time, as new breaks or speedup s are created for the video chat cipher.
- ihnorton 10y agoInteresting, thanks. Am I understanding correctly that point 2 & most of point 3 are risks because of the possibility of either future device compromise, or e.g. quantum decryption technology? These are very general risks, so why do they apply here any more than elsewhere? I realized I probably should not have replied to the part about OTPs specifically. What I'm curious about is remote trust verification via secure video.
- IncRnd 10y agoPartially, it's not just future device compromise but also Internet recording. It is best to assume that any communication over the Internet is recorded. From that standpoint, once the keys (not the device) are cracked the internal secret is also disclosed. This was why I recommended ephemeral keys. By "cracking the keys" a cryptographic break is not always required. It can also happen via disclosure, a weak implementation, problems with the protocol, etc. One can scan a list of recent vulnerabilities for this: session reuse, master secret reuse, session resumption, heartbleed, etc. I would call these out in particular here, because secrets are being exchanged. If those inner secrets are used to protect (directly or indirectly) multiple messages, the key disclosure becomes more pronounced. You are quite correct regarding quantum computing. QC is guaranteed to break elliptic curve, DH, or RSA for example. The determining factor is the number of q-bits. What do you mean by remote trust verification via secure video. That sounds quite interesting. Do you mean facial recognition inside a channel assumed to be secure, as a secondary validation of an otherwise "pre-trusted" party?