I've stumbled (jobwise) over a system where small messages (512 Bytes or less) are encrypted and decrypted using a simple XOR using a OTP. That OTP is created using a seed based on the individual user passwords and a simple PRNG.

I'm currently seeing the following problem: Alice always keeps her password absolutely secret and it is never shared or transmitted. But the crypto-message may be intercepted by Eve, who may be smart enough to detect the pattern used to XOR the message (as the PRNG functionality is widely used as simple C-lib rand() functionality and therefore publicly available).

My counter-argument is that it may be speedy, but because the seed is generated using a simple byte-addition (which results in a seed between 0 and 255), Eve has pretty good chances to quickly find the used seed and thereby the PRNG offset... which will allow her to decrypt the complete crypto-message(s) within 256 trail-and-error approaches.

Personally, I am about to advise them to use an acknowledged crypto-scheme (like AES) and make them drop their weak and insecure OTP-based crypto thing.

For as long as I can remember, I have been reading and have been told that an OTP may be regarded to be theoretically secure — but for that, the OTPs must be absolutely and truly random. From my point of view, a PRNG (cryptographically secure or not) does not seem to be a secure way to generate an OTP for crypto-purposes (using simple XOR).

But this got me thinking — maybe I am missing something in the big sea of crypto-schemes, functions, and implementations.

To avoid I'm missing something, I would embrace any feedback on the question:

Do any (non-hardware) RNGs exist which could be used (or securely abused) to create an OTP for crypto purposes?

I believe the word eek sums up the collective thoughts of all cryptographers reading about their "encryption".
–
ReidAug 26 '13 at 17:06

I have to go to class at the moment, but I'll just leave an extremely relevant link in lieu of writing a proper answer: stream cipher
–
ReidAug 26 '13 at 17:14

1

@Reid Yep, eek sums it perfectly! Mind you they are pretty active in the IT security business. When I saw what they call a "secure implementation" for the first time, I actually had trouble deciding between "laughing out loud" and "giving up on humanity". ;) Thanks for the link to WikiPedia. The stream-cypher RNGs are pretty stream-related, so I don't think they should use that - especially when looking at the table called "Comparison Of Stream Ciphers" and their known attacks.
–
e-sushiAug 26 '13 at 17:39

@Reid On the other hand, the "Trivia" about combiner-type algorithms raised my personal interest. Practically forgot about that term (how could I?), but thanks to you I now have another search term I can throw at search engines to dive in deeper. Thanks!
–
e-sushiAug 26 '13 at 17:48

1 Answer
1

The system you describe is not a one-time pad, it is a stream cipher, and a bad one for that.

A one time pad has real (truly) random bits in the XOR pad, which are never reused for two messages. "Their" cipher has a pseudorandom pad (with non-crypto PRNG), and if I understand right, even the same one for each message.

Even a real random one-time-pad is vulnerable if the same key is used twice (or more often) for different messages (or the same message, if you don't want the attacker to know that it is the same message).

Even if you use a good stream cipher (or PRNG), and use different "passwords" (i.e. keys) for each message (or use a stream cipher with an IV input, and use different IVs for each message), you don't get the perfect security guarantees of an one-time pad – it can be brute-forced, with effort depending on the key size.

For a system to have the security guarantees of an OTP, you need key entropy of at least as much as the message length.

If you have such keying material, but not in a form suitable for direct use as a key (e.g. not equi-distributed, like a really really long passphrase), you might be able to pre-process it using some crypto functions like a hash functions, to transform it into a form usable for an OTP key. Though the transformation algorithm must be studied to make sure that enough entropy stays – for your OTP you need your $n$-bit output to have $n$ bits of entropy, which is not that easy using hash functions with internal state size $< n$.

Actually, most hardware PRNGs work that way – they measure some data and use it as entropy input to a crypto-PRNG.

[+1] OK, so I'm not missing something — thanks for confirming. (On a sidenote: I know it's weird to write "they", but I would like to keep the company name out of public. After all, fixing some of their fails and flaws will pay my rent next month. ;) Hope you understand.)
–
e-sushiAug 26 '13 at 18:04