Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

In reading about the One-time pad it appears to need truly random key for the pad. Since true random values are not practical to generate this presents a problem (thus making One-time pad less practical). If instead I use the operating system provided CSPRNG to generate the key, is that any better than using AES in GCM mode?

Update: Just to be clear, a One-time pad cannot be done with a CSPRNG.

share|improve this question
    
... did you have another question? –  Thomas Sep 24 '12 at 13:01
    
@Thomas No, I just wanted to clarify my question based on the answers. –  Jim McKeeth Sep 24 '12 at 16:01

4 Answers 4

It's much more secure to use AES (or some other well-understood cipher) in a well-described mode than to go construct some random number generator and pretend that it's a one-time pad. It's better not to lie to yourself.

If you use AES in counter mode, you're effectively using AES as a PRNG and then that as a pad, since you XOR the AES onto the plaintext. It's also well-understood.

GCM is a bit tetchy, there are plenty of ways to get it wrong. But nonetheless, yes, you're better off using GCM (which is a derivative of the basic counter mode) than where you're going.

share|improve this answer

Thats a Pseudo-One-Time Pad. A good CSPRNG need have only one attribute. Its output must be unpredictable to an attacker. And thats it. If it is truly unpredictable, then it must be random (otherwise it could be predicted). Note that many PRNG are completely predictable - for some simple schemes given a few bytes of output, the rest can be 100% predicted. However the seed value for the CSPRNG must have at least 128-bits of entropy. So you still need some truly random bits to get started!

Another and probably better alternative is to use a Blum-Blum-Shub generator. Now the unpredictability of the output is anchored to the known hard problem of integer factorisation.

share|improve this answer
    
Even for Blum-Blum-Shub you need some entropy to start with (otherwise $p$ and $q$ are already known to the attacker). And BBS is slow compared to most other secure stream ciphers or block ciphers. –  Paŭlo Ebermann Sep 21 '12 at 21:39

First of all, a terminology nit: please don't say "a One-time-pad generated by a CSPRNG"; a one-time pad must, by definition, be generated randomly, and an important part of its security proof is that it was generated randomly (and so an attacker cannot disqualify any potential pad, even if that attacker had infinite computational resources). Exclusive-or'ing a CSPRNG output with the plaintext to form the ciphertext is a stream cipher; while it is a perfectly usable primitive, it isn't the primitive known as OTP.

In addition, if we use a stream cipher, we usually don't generate the entire key stream on one side, and send that to the other. Instead, we usually send the key (initial CSPRNG state) from one side to the other; that drastically reduces the amount of keying material that needs to be sent, and is no less secure.

Now, with those nits done, the answer to your question (which is more secure, GCM or a secure stream cipher) depends on what you mean by "secure".

If by "secure", you mean privacy (that is, an evesdropper cannot obtain any information of the encrypted message), well both GCM and secure stream ciphers are perfectly secure against real potential adversaries; on this score, they are even.

If by "secure", you mean integrity (that is, someone in the middle that can intercept messages, and inject modified versions cannot fool the receiver into accepting a message that the sender did not send), well, classic stream ciphers run into a problem. That's because stream ciphers are malleable; specifically, an attacker can flip a bit in the ciphertext; on decryption, the corresponding plaintext bit will be flipped (and thus an attacker who guesses what the plaintext is can modify the ciphertext so that it decrypts to whatever he wants). This doesn't work with GCM; if the attacker modifies the ciphertext in any way, the integrity check within GCM will fail, and so the receiver will reject the message. Yes, this means that an active attacker can cause messages to be rejected; an active attacker can do that in any case.

Now, there are standard constructions (such as a MAC) on top of the standard stream cipher apparatus which also provides integrity protection. So, if we ask CRPRNG+MAC vs GCM, well, there isn't a great deal of difference from a security standpoint (but there may be practical differences, such as "what happens if a message gets lost; do you need to handle that case?").

share|improve this answer

If you use a CSPRNG to generate the pad, you're not using a one-time-pad anymore by definition since the pad is no longer random, so the question as stated is incorrect with respect to terminology.

The advantage of using stream ciphers is that you no longer have the key distribution problem the OTP has, since your key is now only a few dozen bits long, and the key reuse problem is also negated, if addressed properly - perhaps with a KDF. Sure, you lose the attractive theoretical security properties, but what good is a cryptographic algorithm if you can't actually use it effectively in real life? Let's just say stream ciphers are an imperfect solution for an imperfect world.

Now, you suggest using the OS-provided CSPRNG to generate the pad - the issue with this approach is that it is essentially an OTP, but with all the disadvantages and no security proof, which is self-defeating:

  • Key reuse: you are only exclusive-or'ing the pad with your plaintext, same as an OTP, so you must change the key after each message (and therefore send it to your recipient every new message).
  • Key distribution: any decent CSPRNG cannot be replayed (it uses external entropy sources), so you'd need to send the complete pad to your recipient rather than just a seed, just as in an OTP.

On the other hand, AES in any streaming mode will work much better: your key is just 128-bit to 256-bit long, so you can distribute it fairly conveniently, and you can reuse your key for many messages using initialization vectors (so you probably only need to share the key once - unless, it gets compromised)


Do not forget to include a MAC if using a stream cipher - or even, if you must, an OTP - or use an authentication mode like GCM - the one-time-pad might provide perfect secrecy, but it gives you absolutely no guarantee on integrity, anyone can intercept your ciphertext and flip bits here and there, possibly altering the intended message to their advantage if the format is somewhat known. Without a message authentication code, you have no way of knowing if the ciphertext was changed, and you are screwed.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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