4 ms·

I have a few comments/questions about the post: 1) Why is a mobile phone random number generator good enough to generate encryption keys, but not good enough t

by utnick 12y ago

I have a few comments/questions about the post: 1) Why is a mobile phone random number generator good enough to generate encryption keys, but not good enough to generate one time pads? What extra weaknesses do one time pads expose? 2) For their 2nd point, Zendo has said that the pad exchange happens locally ( device to device ). So you would need to be in the room to eavesdrop. So the transport mechanism they choose there is a little bit less of a risk I think. 3) Their 3rd point also doesn't seem to be that big enough of a deal to warrant the tone... if sha256 is broken, a man in the middle would be able to corrupt messages, but not in a meaningful way ( ie switching yes to no ), it would just look like garbage to the other person... I think #1 is probably the biggest issue, I'd like to understand it a bit more.

deleted 12y ago
[deleted]
Nursie 12y ago
>> Why is a mobile phone random number generator good enough to generate encryption keys, but not good enough to generate one time pads? It amounts to basically the same thing. That's the point there, what's happening in the phone is a small amount of random data is being used to generate a large amount of pseudo-random data. The security of the OTP is therefore dependent upon the PRNG and in effect you are using the PRNG as your stream-cipher. It doesn't buy you anything. >> So you would need to be in the room to eavesdrop. So the transport mechanism they choose there is a little bit less of a risk I think. With other schemes that use similar things, the exchange is of public keys. Zendo appears to use the barcode as a symmetric key, meaning that the transfer can be eavesdropped/intercepted/impersonated a bit more easily. In an asymmetric situation you could encrypt all messages with the receiver's public key and ensure only they can decrypt. >> Their 3rd point also doesn't seem to be that big enough of a deal to warrant the tone... This is more of a criticism of style, and how little they have disclosed.
falcolas 12y ago
Encryption keys don't need to be as long as one time pads. One time pads need to be large enough to encompass the size of all communications which are encrypted by them. Encryption keys need to be a couple k in size at most. For 2 and 3, basically the author is stating that the use of a one time pad is redundant at best, and potentially crippling at worst (since the capture of a copy of the OTP compromises all communications, backwards and forwards, and it would be tempting to re-use the OTP instead of constantly having to meet back up and generate a new one).
tptacek 12y ago
1. It's not that SecureRandom isn't "good enough" for an OTP. It's that it's not an OTP. It's a keyed deterministic bit generator. Its security depends on attackers not having its key. The problem isn't that SecureRandom is a devastating weakness; it's that using it for a pretend OTP creates not an OTP but instead a stream cipher based on an HMAC keystream. The irony is that the hash function underneath HMAC is far more likely to fail than AES is. But it's a theoretical observation, not a cryptanalysis. 2. It's a key exchange that can be attacked with a video recorder and, more importantly to this analysis, that depends on AES. There is no point in using a one time pad whose key is encrypted with AES; you might as well eliminate the added risks of a one time pad and just use AES. 3. Integrity failures in cryptosystems tend to produce confidentiality failures. For instance, error oracle attacks depend on attackers injecting bogus messages and observing behavior. You can't have confidential message encryption without message integrity.
- yuhong 12y ago
  Still, it reminds me of Snuffle. Remember the lawsuit?
MertsA 12y ago
>but not in a meaningful way That probably isn't the case, there will always be tons of situations overlooked where you already know or have a good guess about what the plaintext of a message looks like and then you can change that section of plaintext to whatever you want, for instance, in a contrived example, lets say that there's some hypothetical messaging app that starts every ordinary message between two users with a header consisting of some fixed bytes and some predictable bytes at the beginning like an account id or something like that. I, the attacker, can replace any known plaintext I want with any other plaintext relatively easily. This might mean replacing the message header with a different one that means, my OTP is empty, resend a OTP encrypted with AES key "password1". Obviously a vulnerability won't be that simple but there is a good chance that there's something like that where an attacker can compromise our hypothetical OTP app by being able to change any plaintext he already knows. For instance, you can XOR the message text with 0x20 and you'll probably corrupt a lot of punctuation and spaces but that would invert the case of the entire message.

by utnick 12y ago

deleted 12y ago

[deleted]

Nursie 12y ago

>> Why is a mobile phone random number generator good enough to generate encryption keys, but not good enough to generate one time pads? It amounts to basically the same thing. That's the point there, what's happening in the phone is a small amount of random data is being used to generate a large amount of pseudo-random data. The security of the OTP is therefore dependent upon the PRNG and in effect you are using the PRNG as your stream-cipher. It doesn't buy you anything. >> So you would need to be in the room to eavesdrop. So the transport mechanism they choose there is a little bit less of a risk I think. With other schemes that use similar things, the exchange is of public keys. Zendo appears to use the barcode as a symmetric key, meaning that the transfer can be eavesdropped/intercepted/impersonated a bit more easily. In an asymmetric situation you could encrypt all messages with the receiver's public key and ensure only they can decrypt. >> Their 3rd point also doesn't seem to be that big enough of a deal to warrant the tone... This is more of a criticism of style, and how little they have disclosed.

falcolas 12y ago

Encryption keys don't need to be as long as one time pads. One time pads need to be large enough to encompass the size of all communications which are encrypted by them. Encryption keys need to be a couple k in size at most. For 2 and 3, basically the author is stating that the use of a one time pad is redundant at best, and potentially crippling at worst (since the capture of a copy of the OTP compromises all communications, backwards and forwards, and it would be tempting to re-use the OTP instead of constantly having to meet back up and generate a new one).

tptacek 12y ago

1. It's not that SecureRandom isn't "good enough" for an OTP. It's that it's not an OTP. It's a keyed deterministic bit generator. Its security depends on attackers not having its key. The problem isn't that SecureRandom is a devastating weakness; it's that using it for a pretend OTP creates not an OTP but instead a stream cipher based on an HMAC keystream. The irony is that the hash function underneath HMAC is far more likely to fail than AES is. But it's a theoretical observation, not a cryptanalysis. 2. It's a key exchange that can be attacked with a video recorder and, more importantly to this analysis, that depends on AES. There is no point in using a one time pad whose key is encrypted with AES; you might as well eliminate the added risks of a one time pad and just use AES. 3. Integrity failures in cryptosystems tend to produce confidentiality failures. For instance, error oracle attacks depend on attackers injecting bogus messages and observing behavior. You can't have confidential message encryption without message integrity.

yuhong 12y ago
Still, it reminds me of Snuffle. Remember the lawsuit?

MertsA 12y ago

>but not in a meaningful way That probably isn't the case, there will always be tons of situations overlooked where you already know or have a good guess about what the plaintext of a message looks like and then you can change that section of plaintext to whatever you want, for instance, in a contrived example, lets say that there's some hypothetical messaging app that starts every ordinary message between two users with a header consisting of some fixed bytes and some predictable bytes at the beginning like an account id or something like that. I, the attacker, can replace any known plaintext I want with any other plaintext relatively easily. This might mean replacing the message header with a different one that means, my OTP is empty, resend a OTP encrypted with AES key "password1". Obviously a vulnerability won't be that simple but there is a good chance that there's something like that where an attacker can compromise our hypothetical OTP app by being able to change any plaintext he already knows. For instance, you can XOR the message text with 0x20 and you'll probably corrupt a lot of punctuation and spaces but that would invert the case of the entire message.