Score:2

Crypto

How less secure were those random bytes?

Nowhere man

8/29/23, 2:07 PM

In our Python codebase, some random bytes were generated that we wanted to be cryptographically secure. Previously, the code was:

capability = "".join(secrets.choice(string.digits) for i in range(33))

I've changed it to:

capability = secrets.token_bytes(16)

By my estimation, the first version chose 33 times between 10 digits and so had 33*log₂(10)=110bits of entropy, while the second has 128bits of entropy. Is this calculation correct?

0 + 0

random-number-generator

poncho

8/29/23, 2:24 PM

"How less secure were those random bytes"; it also depends on what you did with those bytes. For example, if you used them as an AES-128 key, well, that means that you most likely used only the first 16 bytes of the first example, which is *significantly* worse than "110 bits security"

Maarten Bodewes

8/29/23, 2:43 PM

I agree with Poncho. I don't see anything wrong with your calculations, but it then depends on how the digits are used (and considering the method for generating them, that may be any good or bad way). Once thing is also that if this is considered a number that you might end up with a few leading zeros, which may be removed before the value is used. It again depends on the code thereafter if that has a significant impact or not.

Maarten Bodewes

8/29/23, 2:47 PM

Beware of the Duck-typing used in Python. Having a String consisting of digits or bytes is rather different. I don't like using strings for binary values; if I'd design an API I would just accept [`bytes` or `bytearray`](https://www.w3resource.com/python/python-bytes.php) for Python 3

Nowhere man

9/3/23, 3:54 PM

We use the whole thing to make an unguessable URL (wiith base64).

Score:3

Crypto

JAAAY

8/29/23, 4:28 PM

Your math are correct, theoretically. Indeed, using printable digits to store randomness is a trade-off between storage and readability. However, since you are talking about cryptographic security, I want to mention something.

When considering randomness there are two things you should keep in mind : unpredictability and uniformity.

Not your case but, if you are using python built-ins like random, you have uniformity but not unpredictability, because it uses a PRNG. So, speaking cryptographic wise according to Kerchoff's laws, you get 0 entropy.
If you are using secrets. It uses (in Linux for exmaple) /dev/urandom which is generally considered cryptographically secure *, except in some cases (e.g. while booting) you get an estimated amount of entropy (you can't actually measure it) that you hope it is a little bit less than your theoretical one.

* There is/was an ongoing debate on whether to use /dev/urandom or /dev/random. You can read more here and you can also check SAI Peregrinus' comment bellow.

0 + 0

Paul Uszak

9/3/23, 5:31 AM

Err, what do you mean _"using printable digits to store randomness is a trade-off between storage and readability"_? Are you concerned with storage capacity?

SAI Peregrinus

9/5/23, 1:42 AM

That "ongoing debate" hasn't been a debate for some time now. Current Linux kernels have *no* difference in behavior between /dev/random and /dev/urandom. They block at boot until the pool is seeded, then don't block afterwards.