# Stream cipher vs OTP, with /dev/urandom and secure key exchange

My application will work in an office setting where a user can directly and securely collect a long One Time Pad. For example, it may be 16Gb on a USB drive. This would fill me with joy except that the OTP will be generated from /dev/urandom and therefore is not 'truly random'.

I understand that /dev/urandom is acceptable for most cryptographic uses, but my OTP would no longer be information-theoretically secure.

In this circumstance, should I continue down the OTP path, or use a stream cipher instead? Are there other factors to consider? (Note: I believe the staff can store their OTP securely).

• Well, a possibility in this situation is to borrow, buy or build a TRNG and then joy joy feelings will return. Is that a factor? – Paul Uszak Jan 21 at 13:00

Are there other factors to consider? (Note: I believe the staff can store their OTP securely).

The obvious issues are authentication of data and storage of keys. I will presume the data being encrypted is personal to each staff member, and is not to be transmitted between staff.

You note that staff can store their OTP securely, on USB drives. What happens if they get lost? If the storage used for keys cannot be lost and is secure, you could just store the data there.

I think you have to question how secure a physical piece of storage can actually be. It's certainly never close to being secure against unlimited physical power in a manner analogous to information-theoretic security.

Data authentication would need to be carefully implemented in order to not affect the security of the scheme, and would require using pad data. Per Wikipedia:

Universal hashing provides a way to authenticate messages up to an arbitrary security bound (i.e., for any $$p > 0$$, a large enough hash ensures that even a computationally unbounded attacker's likelihood of successful forgery is less than $$p$$)

Per the helpful user Poncho:

you can do data authentication with an OTP (and preserve the informational security properties); for example, using an epsilon almost-universal hash function (with OTP providing both the UH keys and xoring the hash output)

Not using data authentication would mean that the data could be tampered with so it seems unlikely that this would be the case.

• And perhaps that /dev/urandom $\ne$ OTP? A common theme on this site. – Paul Uszak Jan 21 at 13:04
• @PaulUszak yeah sorry, I've edited, I was responding re: other factors. – Modal Nest Jan 21 at 13:06
• Actually, you can do data authentication with an OTP (and preserve the informational security properties); for example, using an epsilon almost-universal hash function (with OTP providing both the UH keys and xoring the hash output) – poncho Jan 21 at 13:07
• @ModalNest: obviously, if the ciphertext is $n$ bits larger than the plaintext (e.g. the tag is $n$ bits and there is no other ciphertext expansion), the attacker can generate a forgery with probability at least $2^{-n}$. However, it leaks no information about the plaintext, and that $2^{-n}$ bound on the forgery probability is achievable (even against computationally unbounded adversaries) – poncho Jan 21 at 13:14
• @DatsunBing A nonce wouldn't be pre-shared. I also assumed that staff don't send data to each other. There are ways to implement a stream cipher (depending on actual requirements) that would be far superior to the OTP I think. For me, implementing a OTP is similar to asking users to change passwords every hour. It might be more secure on paper, but in the real-world it becomes a burden on security. – Modal Nest Jan 22 at 10:53

On recent Linux kernels, the output of /dev/urandom comes from the stream cipher ChaCha20. This output should never be used "as is" to encrypt data because OTP (and any stream cipher) is maleable. You must use an authenticated encryption schema, such as XChaCha20+poly1305.

Also, you must properly deal with key distribution and protection. How do you ensure that a one copy of an OTP is not tempered with so that the encrypted message is not read differently by the recipient? (The recipient can be the sender at a later date.) How do you ensure the USB key is not stollen, copied, then returned? I just stated 2 of the most obvious possible threats here, but many more exist.

I'm sorry, but your implementation of OTP is just poor man's cryptography, even if you used a true RNG. Far less secure in practice than a well design cryptographic protocol, despite your best intentions.

To solve your original question, you should do a proper rigorous risk assessment, to identify what you want to protect, against who, with what means, and at what cost (time, money, skill, resources, etc). Only then you will be able not properly design your security requirements and not overlook issues that could be exploited to bring you harm.

Also do not forget that your solution will be used by real humans who tend to naturally go the easy way: they will try to bypass any cumbersome security measure, even if they are put in place to protect them. A 16 Gb OTP on a USB key looks really cumbersome to me.

• I noticed you failed to take into account the very good advices of the accepted answer of your previous question, here: crypto.stackexchange.com/a/75334/41219 Authentication is not an option. – A. Hersean Jan 21 at 14:34
• For the downvoter(s): please explain why the downvotes. Without any explanation that's not very useful. I'd gladly accept any criticism to improve my answer. – A. Hersean Jan 21 at 14:37