CODEWITHSUNDEEP
mysqlsqlsecurityencryptioncryptography
Nick
Nick

Reputation: 1629

Does RAND() has low entropy to generate salts?

I have to encrypt several data in my DB (no password) I would use a salt to prevent rainbow attack. I'm generating a salt like that:

mysalt = UNHEX(SHA2(RAND(),512))

is RAND() (mysql function) an enough source of entropy? I should have all my salts value different each other, but if my PRNG has too much collision isn't the case. Does it depend from number of records in DB? If it is the case what is the limit with RAND()? Which could be a good alternative technique if that above isn't good? Finally is that good to salt passwords too?

Upvotes: 2

Views: 207

Answers (1)

gusto2
gusto2

Reputation: 12085

I have to encrypt several data in my DB (no password) I would use a salt to prevent rainbow attack.

As already commented, you should use proper terminology to make sure we're talking about the same thing. Based on the comments let's assume you're generating an IV (initialization vector) for a block mode (cbc, cfb or ofb). The IV is enabling the safe key reuse. Nothing to do with rainbow tables.

mysalt = UNHEX(SHA2(RAND(),512))

RAND() generates a float between 0 and 1. Your function effectively uses the float as a string, so proper notation would be sha2(convert(RAND(),CHAR),128), AES is using 128 bit IV anyway. No reason to generate more.

is RAND() (mysql function) an enough source of entropy?

Depends on the modes used. Some modes (CTR, CFB) the IV is required to be unique (event a simple counter is good enough), for the CBC and OFB mode the IV needs to be "unpredictable" (stronger term than random).

I am unable to find source state of the RAND() function and then I am unable to guarantee it cannot be brute-forced (it can be done in case of timestamp-based source for NLFSR PRNG). I'm not really willing to dig into the mysql source code (as far I recall mysql uses the OS rand function, so it will depend on the underlying system, I may be wrong here). So RAND() can be safe to generate the IV for CBC, under assumptions that the initial state is random enough. Seems no-one here is able to confirm nor deny this assumption. Using RANDOM_BYTES() it is guaranteed to use a cryptographically secure random source.

Does it depend from number of records in DB?
If it is the case what is the limit with RAND()?

You need a unique combination of the key-iv. The more records you have the higher probability of the value collision. And here we come again with with the initial RAND state size which is system-depended, though in the comment someone claims it's 4 bytes. That's really not too much.

Which could be a good alternative technique if that above isn't good?
Finally is that good to salt passwords too?

As already commented, RANDOM_BYTES are using the random generator from the SSL library, which is required to be cryptographically feasible.

Upvotes: 1

Related Questions