4 ms·

Yes, I didn't capitalize it, but I did spell out OTPs in my original post. Here's the part where CompSci people lose me: > If I want to send you 1GB of data,

Yes, I didn't capitalize it, but I did spell out OTPs in my original post. Here's the part where CompSci people lose me: > If I want to send you 1GB of data, we should not require 1GB of shared secret random data. I agree if the data is something trivial like video but it doesn't follow to me that OTPs shouldn't be used for something as critical as code updates for autonomous vehicles control systems. > How would you do 'code signing' with an OTP? We don't take anything away. We don't discard our normal cryptographic methods of encryption and code signing. We simply layer them. That way if the cryptographic method is flawed, or the keys compromised, an attacker would also need to compromise the OTP. Just as structural engineers layer their defences for structural collapse, I fail to see how introducing a OTP presents a serious burden to autonomous device makers compared to the stakes involved. It makes class-attacks far less relevant because the OTPs would need to be breached too. Even if our OTPs were solely used for the cryptographic signature (as opposed to the whole encrypted code update) we would still be leagues better in the event of a compromise. I know we shouldn't need to, but mistakes keep happening. I know we shouldn't trust physical security over cryptographic security, but if we're layering them how does it hurt?

rocqua 8y ago
OTPs come with a lot of overhead. In order to get value out of them, it takes a trusted channel between both end points to establish a good OTP. This alone is hard, very hard! There are significant size issues, but those are solved by replacing an OTP with a fixed size key K that is expanded somehow. eg a stream like [ sha(K, 1); sha(K, 2) ... ] Though to be honest I am just reinventing AES-CTR here. However, besides this the biggest issue is keeping state. You don't just need to keep all of the shared keys, but you need to remember and be synchronized on where in the stream you are. In the end, essentially all you want to achieve can be done using AES-CTR or really any kind of symmetric encryption. In general, symmetric encryption has been pretty reliable. OTPs are just not worth the trade-off with respect to symmetric encryption.
- 3pt14159 8y ago
  > it takes a trusted channel between both end points to establish a good OTP. This alone is hard, very hard! Right, and this is why we don't use them for arbitrary communication between networked computers, but for manufactured cars (or other cyber-physical devices) we have a trusted channel already! The factory that builds the car! We create the pads. We put one in the car and one in a locked case. We open the case in the server room and plug it into a large bank of pads. When updates are necessary they're run through the pad and broadcast. If an auto company can't keep pads synced or keep pads physically isolated from malactors I really think we have bigger issues at hand. Syncing a pad could be as easy as requiring them to be read per-megabyte, with unused pad where not required, though I'm sure there are countless better ways. > OTPs are just not worth the trade-off with respect to symmetric encryption. I agree that if it were a choice between OTPs and symmetric encryption I'd go symmetric encryption every time, but I fail to see the downside in layering them. Further; I've seen symmetric encryption implemented insecurely in practice even if it is theoretically more secure than OTPs or PKI. I appreciate you entertaining my questions, and I apologize if I'm inadvertently being obstinate. I really want to understand why I'm wrong here, but I still don't see it.
  - throwawaymath 8y ago
    One time pads are theoretically more secure than any other form of encryption. If implemented correctly they offer information theoretic security, whereas modern encryption schemes can only provide computational security. Information theoretic security essentially means that we cannot learn anything whatsoever about a plaintext from a ciphertext. There exists no information leakage. In order to achieve this we need to 1) use an encryption key at least as long as the plaintext, 2) generate that key secure and (truly) randomly, and 3) never reuse that key for the duration of the session. Computational security was invented (in part) because this is a completely unrealistic ideal to strive for in approximately all communication. If I want to securely send you an plaintext with a size of 1GB, I need to first securely generate a truly random 1GB string and exchange that with you. Since that secure exchange would obviate the encryption in the first place, it's more likely I'd generate a significantly larger key and exchange that with you first, then only use as much of the key as necessary for each exchanged message in the session. This makes one time pads extremely inefficient - in order to achieve the information theoretic advantages of one time pads all messages must be doubled in size and no part of the key can ever encrypt the same part of the text. It's effectively a stream cipher. If you and I encrypt recurring metadata, or we reuse common idioms or greetings under the same key, we immediately lose information theoretic security. Then we're downgraded to a ridiculously inefficient stream cipher with computational security. At that point we might as well use AES, or ChaCha-Poly. One time pads are used (typically by the government), but it's very uncommon and reserved for areas where literally no expense is spared. The purpose of computational security is to make cryptography more efficient and practical via a simple tradeoff. We get disproportionately more efficiency back by accepting infeasibility instead of impossibility. Does that help clarify things for you?

rocqua 8y ago

OTPs come with a lot of overhead. In order to get value out of them, it takes a trusted channel between both end points to establish a good OTP. This alone is hard, very hard! There are significant size issues, but those are solved by replacing an OTP with a fixed size key K that is expanded somehow. eg a stream like [ sha(K, 1); sha(K, 2) ... ] Though to be honest I am just reinventing AES-CTR here. However, besides this the biggest issue is keeping state. You don't just need to keep all of the shared keys, but you need to remember and be synchronized on where in the stream you are. In the end, essentially all you want to achieve can be done using AES-CTR or really any kind of symmetric encryption. In general, symmetric encryption has been pretty reliable. OTPs are just not worth the trade-off with respect to symmetric encryption.

3pt14159 8y ago
> it takes a trusted channel between both end points to establish a good OTP. This alone is hard, very hard! Right, and this is why we don't use them for arbitrary communication between networked computers, but for manufactured cars (or other cyber-physical devices) we have a trusted channel already! The factory that builds the car! We create the pads. We put one in the car and one in a locked case. We open the case in the server room and plug it into a large bank of pads. When updates are necessary they're run through the pad and broadcast. If an auto company can't keep pads synced or keep pads physically isolated from malactors I really think we have bigger issues at hand. Syncing a pad could be as easy as requiring them to be read per-megabyte, with unused pad where not required, though I'm sure there are countless better ways. > OTPs are just not worth the trade-off with respect to symmetric encryption. I agree that if it were a choice between OTPs and symmetric encryption I'd go symmetric encryption every time, but I fail to see the downside in layering them. Further; I've seen symmetric encryption implemented insecurely in practice even if it is theoretically more secure than OTPs or PKI. I appreciate you entertaining my questions, and I apologize if I'm inadvertently being obstinate. I really want to understand why I'm wrong here, but I still don't see it.
- throwawaymath 8y ago
  One time pads are theoretically more secure than any other form of encryption. If implemented correctly they offer information theoretic security, whereas modern encryption schemes can only provide computational security. Information theoretic security essentially means that we cannot learn anything whatsoever about a plaintext from a ciphertext. There exists no information leakage. In order to achieve this we need to 1) use an encryption key at least as long as the plaintext, 2) generate that key secure and (truly) randomly, and 3) never reuse that key for the duration of the session. Computational security was invented (in part) because this is a completely unrealistic ideal to strive for in approximately all communication. If I want to securely send you an plaintext with a size of 1GB, I need to first securely generate a truly random 1GB string and exchange that with you. Since that secure exchange would obviate the encryption in the first place, it's more likely I'd generate a significantly larger key and exchange that with you first, then only use as much of the key as necessary for each exchanged message in the session. This makes one time pads extremely inefficient - in order to achieve the information theoretic advantages of one time pads all messages must be doubled in size and no part of the key can ever encrypt the same part of the text. It's effectively a stream cipher. If you and I encrypt recurring metadata, or we reuse common idioms or greetings under the same key, we immediately lose information theoretic security. Then we're downgraded to a ridiculously inefficient stream cipher with computational security. At that point we might as well use AES, or ChaCha-Poly. One time pads are used (typically by the government), but it's very uncommon and reserved for areas where literally no expense is spared. The purpose of computational security is to make cryptography more efficient and practical via a simple tradeoff. We get disproportionately more efficiency back by accepting infeasibility instead of impossibility. Does that help clarify things for you?