Tag Info

Hot answers tagged

16

Short answer: To prevent brute forcing the CSRF token. Let's take a trivial example: let's say your token is a single digit, accepting values from 0 to 9. Now sure, an attacker cannot read this value from the cookie or header, but she does not have to - she can just have the attack send 10 CSRF requests, one with each possible value. One of them will be ...


15

Reading bytes from a device can be troublesome (you have to account for syscall specificities, e.g. interrupted system calls) and can potentially be inefficient if reading many small chunks (a syscall has a non-negligible overhead). A custom software PRNG, seeded with bytes from /dev/urandom, gives more control over performance. (Also, there might be a bit ...


13

Entropy is required in the following sense: if a PRNG has only n bits of entropy, then this means that it has (conceptually) only 2n possible internal states, and thus could be broken through brutal enumeration of these 2n states, provided that n is low enough for such a brute force attack to be feasible. Then things become complex, because the "entropy ...


10

If you're asking why openssl rand or RAND_bytes() do not simply regurgitate /dev/random or /dev/urandom, it's because their function is to serve only as a PRNG, and they do exactly that: The rand command outputs num pseudo-random bytes after seeding the random number generator once. A correctly compiled and operating OpenSSL will read 32 bytes from ...


8

If the PRNG is cryptographically strong, then, by definition, its output cannot be distinguished from random bytes. That's the thought experiment by which a PRNG is supposed to be tested: two black boxes are given to the attacker, one implementing the PRNG, the other producing really random bytes (that one contains a gnome who throws dice real quick). The ...


7

A PRNG can be insecure for several reasons, but one of them is using as seed some data which can have only a limited number of distinct values. For instance, if you use the current time as seed, then that value is known to the attacker, or at least potentially known with a not-so-hard effort: even if you have an internal clock with microsecond precision, and ...


7

Hashing the output of a RNG is typically a component of making a cryptographically secure RNG, but it's not magic. It can't make a crappy RNG suddenly secure. A key component in a cryptographically secure RNG is absolute unpredictability. If you can predict the output, then you can use that prediction as part of your attack. Running the output through a ...


6

Unfortunately the previous answers given to this question, are not only wrong, but also quite dangerous. While it is certainly true that digital signatures usually involve hash functions, which by its nature are inherently deterministic, you should note that digital signatures are more than just a simple hash. They involve public key cryptography, which is ...


5

Hashing has no effect at all in increasing the security of a PRNG like rand(). In fact, if the output of the PRNG is larger than the output of the hashing function, it will decrease its security. sha(rand()) is, basically, security by obscurity. You're assuming that by making the PRNG output appear more random it will make it more secure, which is ...


4

Signing with RSA in OpenPGP is deterministic and thus does not require a source for randomness as you described correctly. Hashing the data to be signed is deterministic as long not padded with a random seed (see @Karol Babioch's answer for details why one might want to do so), signing the hash also is. Detailed discussion of the parts involved: RSA ...


3

If we take a look at the man page for random we get the following: The random number generator gathers environmental noise from device drivers and other sources into an entropy pool. The generator also keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created. At the bottom we see: ...


3

Combining the best of both answers: The token length needs to be proportional to the number of victims and the number of requests per victim. If an attacker convinces X victims to navigate to his page (by way of spam or phishing attacks) and each such page attempts Y different tokens then you need to protect yourself against 2x*y attacks. For example, if ...


3

It doesn't It just has to be pseudo random. CSRF is not compatible with brute force attacks. Consider the attack vector: Malicious user crafts a special email or web page with HTML that posts to the site of interest User is logged on to the site of interest, and the session ID is passed passively (it's a cookie) User is tricked into clicking the link in ...


3

A PRNG which lacks reseeding, prediction resistance, or whatever these people mean by "continuous testing", is not a PRNG. Not in cryptographic terms. Conversely, a good PRNG, like HMAC_DRBG, will be as good as Dual_EC_DRBG, actually better since Dual_EC_DRBG exhibits measurable biases, and is awfully slow. The only good point of Dual_EC_DRBG is the ...


3

This certification is typically done through FIPS certification. The list of labs certified by NIST to perform FIPS certifications is here


2

(Note: I am not a cryptographer, I might be completely off-based with this answer. :P) I would take anything Sam Curry said with a bucket of salt. He has proven that he knows absolutely nothing about cryptopgrahy. Here is the full quote. The length of time that Dual_EC_DRBG takes can be seen as a virtue: it also slows down an attacker trying to guess ...


2

Technically, you improve the security a little, but to no useful end. Random numbers usually come from a pseudo-random number generator (PRNG) that is itself seeded with a random value. The purpose of the PRNG is to stretch the original seed to produce a very long output. Random numbers are usually invoked for two reasons: To create random-looking data ...


2

Part 1 No this is not secure, it would not be Semantically Secure (because Random() isn't secure) I would argue that it wouldn't be secure because a hash function reduces the entropy of its input. In other words a hash function usually has less than a 1:1 mapping of results to input, and it has a greater chance of colliding with prior inputs than the raw ...


2

I accept this statement as true: Therefore if I have an AES-256 cipher and I know the key was generated using SHA-1 PRNG I only have to test 2^165 possible combinations, not 2^256. However, I question the assumption derived from it: This would appear to significantly weaken the cipher. It is not now, nor will it ever be physically possible to test 2^165 ...


2

The key should be the same size as the hash output. In your case you are using SHA-256 so you should use a 256-bit key (which equals 32-bytes that you mention). The HMAC algorithm is really quite flexible, so you could use a key of any size. However, if you only use a 128-bit key then there is no point using a 256-bit hash; you might as well use a 128-bit ...


2

Python provides the function os.urandom() to read bytes from the OS CSPRNG mentioned by Stephen Touset above. For the more appealing random module API, it also provides the class random.SystemRandom() that uses the same source. There's no reason to do anything more complicated. I already heard of ideas like reading allocated memory (if it was just ...


2

This depends on the platform. As a general case, you should consider using the OpenSSL bindings to use OpenSSL's RAND_* API. Do make sure to seed it correctly. Not reading the OpenSSL documentation will cause a security compromise on virtually all operating systems due to improper RNG seed. Even “big ones” have been bitten by this. On Unix-like operating ...


2

This certainly looks like premature optimization. A fast CSPRNG on a modern Intel CPU will output between 500 MB and 2 GB per second. Even if you have a quite random game which requires 100 random bytes per second per player (I can't think of a typical casino game anywhere near that) a single core will be able to generate random numbers for ten million ...


2

The purpose of salting when hashing passwords is to prevent identical passwords from resulting in the same hash values. If your passwords all are, as you say, long and generated by a CSPRNG, then you will not have identical passwords in your database for different users; they will all be unique, and salting adds nothing to the security of these ...


2

The check is to ensure that skew doesn't occur. If your random number generator has a range of 0 to 9, and you simply take a straight modulus, you'll end up with the following outputs: 0 % 6 = 0 1 % 6 = 1 2 % 6 = 2 3 % 6 = 3 4 % 6 = 4 5 % 6 = 5 6 % 6 = 0 7 % 6 = 1 8 % 6 = 2 9 % 6 = 3 This leads to the values 4 and 5 being less common than 0, 1, 2, or 4. ...


2

dev/random is not even remotely the same as NIST SP 800-90A DRGB. If you want to claim compliance to NIST SP 800-90A DRGB then hire a test lab to test your DRBG and submit the results to NIST's Cryptographic Algorithm Validation Program (http://csrc.nist.gov/groups/STM/cavp/index.html) and then it will end up on this list: ...


2

What should be the size of the seed that I initialize a CSPRNG with? Seed Length and other requirements for approved block cipher algorithms are summarized here: How often should I reseed it? The seed is secure as long as it remains unknown to the attacker. I think I can not explain better than this answer. CSPNRG entropy is calculated using ...


2

What matters is entropy. What makes a PRNG cryptographically secure is the inability of attackers to predict the next bytes. Precisely, there are three "security levels" that define the security, in the following model: The attacker is given s bits of consecutive output from the PRNG. The attacker's computing abilities are limited to 2k elementary ...


1

Come to think of it, you could implement an engine with a weak RNG and insert it into OpenSSL using: ENGINE_set_default(e, ENGINE_METHOD_RAND); That should make sure that the random number generator is used. Of course it may be a good idea to ignore any seed information given to the random RNG by the OpenSSL. This has the obvious disadvantage that it may ...


1

Although there are no guarantees, there are mathematical safety-measures against poor keys due to inappropriate random number generators. You could for example try some nice software tools to test the statistical entropy that your generator puts out: Dieharder TestU01 These tools come with a large number of statistical tests, but as RFC 4086 states: ...



Only top voted, non community-wiki answers of a minimum length are eligible