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

Question

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).

Answer 1

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.

Answer 2

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.