Generate SecureRandom bytes with an ideal size

Question

I want to generate a random bytes using SecureRandom and encode it as base64 to be pass in a URL parameter.

My requirements is: it must atleast hard to predict or brute force, but also short enough not to consume too much memory.

I came up with this code where I put 8 bytes. Is it enough?

SecureRandom rand = new SecureRandom();
byte[] randomBytes = new byte[8];
rand.nextBytes(randomBytes);

Base64 base64 = new Base64();
String result = base64.encodeBase64URLSafeString(randomBytes);

Also, I am planning to append at least a timestamp to make it more unique. UUID is not my option since its too big. Maybe a portion of timestamp, would the be a good idea?

This "hard to predict and not too long" seems a known combination. Did you notice (or maybe even ask...) similar questions recently? Anyway, please define "not too long" and "hard to predict" quantitatively. I.e. how long is allowed? What is the maximum probability to guess? — Yunnosch, Jul 12 '23 at 10:31
Note that "include a timestamp" was among the first desings of UUID in its history. You might be on the same track.... — Yunnosch, Jul 12 '23 at 10:32
"I put 8 bytes. Is it enough?" I think that you are asking the wrong audience. Without context and quantitative requirements it is next to impossible to answer. — Yunnosch, Jul 12 '23 at 10:33
@Yunnosch this is the context: `it must atleast hard to predict or brute force, but also short enough not to consume too much memory.` — Repins Star, Jul 12 '23 at 11:02
Ok, I take that as "I cannot add details, I cannot specify clear values and I refuse to rephrase". Also I note that you do not comment on whether or not the similar question was also by you, which I now assume; which is relevant, because that question might actually contain more info than this one and I would like to review your reactions to the feedbacks you got there... Note by the way that improving older questions with the help of feedback is a better bet on the long term, for getting helpful answers here. — Yunnosch, Jul 12 '23 at 11:05

Stephen C · Answer 1 · 2023-07-12T13:25:34.527

Your primary question is "are 8 random bytes enough" to mitigate brute force attack. It depends.

It depends on:

What probability of a successful attack is acceptable to you.
How many IDs have been issued. (I am assuming that a brute-force guess of any valid ID is sufficient.)
How many brute-force attempts can be performed per second.
How long you would anticipate that an attacker would persist in their brute-force attacks.

Given values for the above, you can calculate whether 8 bytes == 2⁶⁴ possible IDs is large enough. It is relatively simple math. (Look up how to solve the "birthday paradox" problem.)

Also, I am planning to append at least a timestamp to make it more unique. Maybe a portion of timestamp, would the be a good idea?

That's a bad idea. If the attacker knows that you are using a timestamp or portion of a timestamp in your IDs, they can potentially use that information to reduce the number of guesses they need to make.

N random bits will be more secure than M (< N) random bits and N - M bits of timestamp information.

Generate SecureRandom bytes with an ideal size

1 Answers1