Potential Insecure Randomness

[louwersj]

os.urandom() is used for generating random values for cryptographic purposes. While it is secure for most cases, the code does not specify or validate its use for cryptographic integrity.

Use secrets Module for Secure Randomness. Python's secrets module is specifically designed for cryptographic operations and provides a straightforward, secure way to generate random values. Replace os.urandom with secrets.token_bytes or similar secure functions from the secrets module.

import secrets

pstamp = secrets.token_bytes(256 // 8)  # Securely generate random bytes

https://github.com/markqvist/LXMF/blob/cec903a4dcc878f14f8cd8be6a9abc54868cbea6/LXMF/LXStamper.py#L108

[louwersj]

wrong place

[markqvist]

From markqvist/LXMF#24:

Thanks for chiming in, but I think you have misunderstood the scope and purpose of this particular piece of code.

The LXStamper module simply needs access to a fast entropy source to generate a stream of random values that can be hashed together with the stamp workblock to search for, and ultimately come up with, a valid stamp for the message.

Closing, as this is not an issue, and the system is functioning as intended and designed.

If you disagree, you are welcome to provide argumentation as to why os.urandom() is insufficient here.

[louwersj]

I do not disagree with you. I just tried to aim for a more "pure" (if that is the right word in this context) randomness.

[faragher]

This is longwinded and a bit philosophical. I don't blame you if you skip it.

Metaphor: Alice has a husband and three children. She takes the family grocery shopping, works in town, and was thinking about starting a project that needs 4x8 sheets of plywood. She goes to the car dealership and sees three cars: a two seat electric vehicle which is very efficient and inexpensive, a sedan that seats five and can carry groceries, but no large cargo, and a full-bed pickup with a king size cab that seats five.

The electric car would be great in town, but fails every other requirement.

The sedan fills every requirement except potential future projects that aren't even a certainty.

The pickup is uncomfortable, drinks fuel, doesn't fit in a parking space, and won't be hauling any appreciable cargo 99.9% of the time.

If Alice can only purchase one vehicle, it should be the sedan. The money saved in day to day operations will surpass the cost of renting a pickup for discrete projects. As the kids go to college or more projects emerge, the situation can be re-evaluated; just make sure the garage is big enough for any reasonable option.

On the other hand, if Alice has the electric car, the sedan, and a two-seater pickup in the garage, then the proper option can always be taken without the overhead of a one-size-fits-all solution. The pickup is even more efficient since it doesn't have to fill multiple roles.

Practical:

Cryptographic randomness is required for security purposes. However, there are situations where the number doesn't matter, so long as it's different. In this case any psudorandom number will do since you're not fighting at attacker, you're fighting the Birthday Problem. For an operation that needs to run frequently and isn't security-centric (and in fact will be hashed anyway, making it computationally intensive to reverse engineer anyway) then the most efficient "random enough" method is better suited.

A larger issue is that there is no way to make a non-cryptographically secure source into a cryptographically secure source. Random numbers can only be generated by random events, and that requires an entropy source. There are plenty of ways to generate this entropy, some better than others, but the entropy they generate is finite. While this is a theoretical problem at these scales, there's the possibility that using a secure entropy source too often will deplete it, either causing a lag as more entropy is acquired, or entirely un-random numbers to be generated.

So, basically, it's slower and depletes a finite resource if you use cryptographically secure systems for all purposes. Even if you pull from a system-generated random source that's secure, it can still run out of entropy. I'd assume this is a well-considered issue on POSIX systems, so if you require high standards of randomness, feed atmospheric noise into your entropy source and just let Linux do its thing. Unless Python uses XOR randomness instead of the system source, which I really can't imagine.

[louwersj]

"In this case any psudorandom number will do..."

Ok.

[markqvist]

In case you missed @faragher's point, using secrets.token_bytes(256 // 8) would be a much worse solution in this particular case, as it would actively exhaust high-quality entropy sources on the system much more rapidly than is at all required.

It would simply be a very, very silly implementation.