1
$\begingroup$

Edits: added then removed additional cases that on reflection seem like a bad idea. In fact, this whole line of thought seems like a complicated way to get a bigger nonce, which might be better accomplished with something like XSalsa20 which was designed for that. I will accept the "just use the right tool" answer, but if anyone has anything further to contribute please do.

To prevent possible stream cipher key repetition given unreliable storage, provided only that your RNG works and at the cost of some bytes per connection, start the connection with a random cipher key that is not stored on disk and is used to encrypt the rest of the stream (i.e. as the key for your stream cipher, which might be AES-256-CTR, ChaCha20, or a Keccak based stream cipher).

Questions (assume we have a MAC and any reply will encrypt with that random key and a different, previously agreed, nonce):

  1. Suppose you use a simple shared secret XORed with this random key to encrypt it and have a reliable random number generator. An attacker can then easily get random key 1 XOR random key 2 and encrypted streams 1 and 2, but it seems like this shouldn't help. Are there any specific properties that a stream cipher would need to have or not have for this to be exploitable?

  2. If that doesn't work or you don't trust that your RNG doesn't have some characteristic that might be exploitable with that system, add a random nonce sent before the key and use the shared secret to encrypt the random key (via the stream cipher) with that nonce. Now are there any considerations that would make this system exploitable beyond the need for your RNG to generate a good key each connection?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
1
$\begingroup$

I'll answer per related question:

  1. It seems like you are trying to describe a scheme that relies on a One Time Pad (OTP). To use an OTP it is required that your scheme complies to the security requirements of a one time pad. If it does, it will be provably secure (except for the leaking of time and length related data).

  2. Now you are trying to create a slow, untested stream cipher out of your OTP scheme, because you do not comply to the OTP requirements. You are better off choosing a well known, fast stream cipher instead.

So choose a fast stream cipher and try and create a good key management scheme around it; you haven't described how you distribute your session keys.

Improve this answer
$\endgroup$
2
  • $\begingroup$ As it is very tricky to prove that a RNG is secure, the chances of proving your real life OTP is secure is small to non-existent. Use a stream cipher. $\endgroup$
    – Maarten Bodewes ♦
    Nov 3, 2013 at 11:52
  • $\begingroup$ 1) Thanks, it took me a while to figure out what you were talking about but I see that protection of the shared secret in #1 is like OTP. 2) I was assuming for #2 that the secret key to be used for the rest of the session is encrypted using your stream cipher (with the random nonce sent). For specifics if that makes it easier, let's say the stream cipher could be AES-256-CTR, ChaCha20, or a Keccak based stream cipher. I will edit for clairty. 3) For the purpose of these questions I was assuming that there is one shared key ever, which seems like it should work. I'll add a 3rd case too. $\endgroup$
    – joveian
    Nov 3, 2013 at 23:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.