Take the 2-minute tour ×

I am working on a app for windows phone and need a 1MB random pool of byte to use as key for one time pad encryptions. I plan to first make a byte array and fill it with bytes generated by the built in RNGCryptoServiceProvider (app is made in c#). And use information from sources like accelerometer, camera, microphone and touch. Then i bitwise xor this information with each of the pool bits.

Is this a secure approach or is there a better/safer way?

share|improve this question
It's not a onetimepad if it's pseudo-random. You're just constructing an annoying to use stream cipher. –  CodesInChaos Jul 23 '12 at 20:51
What would you do with the encypted bytes? Someone would need to decrypt them, and that someone needs your one time pad. So how are you going to send that to the receiver? Maybe you'll need to ecnrypt it. Seriously: this solution is as secure as the key is. –  Kris Vandermotten Jul 23 '12 at 20:52
@SLaks Only if you're really careful with massaging it into a uniform bitstream and you carefully estimate the entropy. That's a difficult task. I for one wouldn't feel up to it without studying related papers for several days. –  CodesInChaos Jul 23 '12 at 20:58
Sort of strange question... If you do have reasons not to trust RNGCryptoServiceProvider than you are expected to understand these reasons and have very good knowledge of random number generation for security purposes... Otherwise why do you think your "improvements" would make random distribution any better? –  Alexei Levenkov Jul 23 '12 at 21:00
show 9 more comments

1 Answer

Ok, so we seem to have several comments addressing part 1, is this secure. Now on to question 2, is there a better safer way?

There are three pieces in this puzzle: Key generation, key distribution, and encryption.

I strongly suggest sticking to tried and true methods of key distribution and encryption, but adding entropy to the key generation from sampled input devices can only help.

The trick there is that you want to accumulate and "whiten" that entropy into the key using a hash function. For example, you could collect data from all the entropy sources you mentioned, hash them with SHA-256 to pack all that entropy into a manageable space and randomize it, then XOR with the RNGCryptoServiceProvider data as you suggested before.

Now the wild entropy you added has made a true RNG out of your PRNG.

As you collect more entropy, hash the original hash with the new data so that the old entropy gets mushed up with the new. This way, you will eventually accumulate a full hash length worth of entropy.

Figuring out how long it takes to reach that state is harder, though.

share|improve this answer
Thanks for the answer, some of you may find this offensive and think that dont listen to the advice given to me but thats not true i try to learn as much as posible but i would just like to get a better explanation of some of the statements in the comments above.so here it comes. As you sad its three important parts of this puzzle. Key generation, key distribution and encryption. If i use a key generation like the one you suggested and key distribution aint no problem in my application why sould i use aes as the above comments suggested and not a otp. –  Hampus Andersson Jul 24 '12 at 17:59
For OTP, you have to somehow securely get a pad as long or longer than the plaintext to the receiver. This isn't any easier than transmitting the plaintext securely in the first place, it just allows you to schedule when the secret part happens. Furthermore, the whole pad needs to be random - pure entropy, which is very demanding on your RNG. AES, RC4, etc allow you to transmit a small key in secret that can be used for a large amount of data. Public key techniques allow you to exchange or create these keys publicly. ...all of which depend on an RNG which would benefit from more entropy. –  tbroberg Jul 25 '12 at 3:37
add comment

Your Answer


