Tag Info

Hot answers tagged

15

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 ...


11

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 ...


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 ...


7

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 ...


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

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 ...


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 ...


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

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

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

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

The best way to generate random tokens for security purposes in PHP is using openssl_random_pseudo_bytes() to obtain some random bytes, and then bin2hex to make them printable. $token = bin2hex(openssl_random_pseudo_bytes(16)); You can safely use $token for your session identifier, CSRF tokens, etc.


1

In general, reasons to not use the random source directly as presented include: You may not require as many bits of entropy as you need bits. In this case, you can use the random bits to seed a pseudorandom number generator. This is most important when entropy is scarce (this constraint is becoming less relevant over time as dedicated hardware entropy ...


1

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 ...


1

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 ...


1

Now that other PRNGs will be used... It's worth noting that with the exception of a few niche products, Dual EC DRBG wasn't previously used by anyone. At it's inception, independent researchers pointed out that this was a horrifically inefficient algorithm which produced an output that could be poisoned by a malicious actor. But for some hefty ...


1

What you miss by switching away from Dual_EC_DBRG for a deterministic random bit generator are Bias. The actual output is biased so there is an extra layer added to debias it. (Bias is a bad thing) Inefficiency. Dual_EC_DBRG is slow compared to alternatives. There are some very specific cases where you want something to be slow, but a DBRG is not one of ...


1

If the reason the functions are insecure is because you can exhaust the seed space after seeing a very small number of values, then this approach might give the sum of the number of seed bits of security, assuming the seeds were perfectly random. If the problem is that they have a short period, if the functions have pairwise co-prime periods then the period ...



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