Maybe the performance of the function GenerateRandomKey can be greatly improved

[bigradish]

Maybe using "crypto/rand" to generate the key is not efficient as mentioned in: http://stackoverflow.com/questions/12771930/what-is-the-fastest-way-to-generate-a-long-random-string-in-go

I think maybe you can adopt some points from https://github.com/dustin/randbo/blob/master/randbo.go .

Thank you very much.

[elithrar]

https://github.com/dustin/randbo/blob/master/randbo.go is not cryptographically strong at all (it uses math.rand). When generating session keys for use in cookies (or authenticating cookie values) you must ensure they are cryptographically strong to prevent someone from compromising them and modifying the values or guessing at another user’s session key.

If crypto/rand is the bottleneck on your system you likely have other scaling issues as well, and can either throw more boxes at the problem or buy a ASIC based generator ($$$).

On 14 Mar 2014, at 2:02 PM, bigradish notifications@github.com wrote:

Maybe using "crypto/rand" to generate the key is not efficient as mentioned in: http://stackoverflow.com/questions/12771930/what-is-the-fastest-way-to-generate-a-long-random-string-in-go

I think maybe you can adopt some points from https://github.com/dustin/randbo/blob/master/randbo.go .

Thank you.

—
Reply to this email directly or view it on GitHub.

[bigradish]

@elithrar Thank you for your answer. The randbo.go uses time.Now().UnixNano() to make the seed. I think that is fairly random.

[elithrar]

Using time.Now().UnixNano() is not a cryptographically strong seed. An attacker with knowledge about the time the value was generated (or control over it—such as generating new session cookies!) could potentially predict the range of values generated.

crypto/rand leverages /dev/urandom on Linux/BSD systems and a similar construct on Windows machines.

Some reading material:

• http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator
• http://en.wikipedia.org/wiki/Random_number_generator_attack
• https://news.ycombinator.com/threads?id=tptacek (any of his comments on /dev/urandom are worth reading)

It is worth being extremely careful when generating random numbers for cryptographic purposes. Apparent increases in speed should be taken with extreme caution.

Hope that helps/clarifies.

On 14 Mar 2014, at 2:41 PM, bigradish notifications@github.com wrote:

@elithrar Thank you for your answer. The randbo.go uses time.Now().UnixNano() to make the seed. I think that is fairly random.

—
Reply to this email directly or view it on GitHub.

[bigradish]

@elithrar Maybe using time.Now().Nanosecond() as the seed is better. Could you tell me how the attacker predicts the seed? Thank you very much.

[elithrar]

I explained that (at a high level) above. If the seed is "predictable" in
any way (which is precisely what a clock is!) then you have a major
vulnerability that your attacker can potentially replicate or leverage.

Also read

http://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng

and the links contained within.

On Friday, March 14, 2014, bigradish notifications@github.com wrote:

@elithrar https://github.com/elithrar Maybe using
time.Now().Nanosecond() as the seed is better. Could you tell me how the
attacker predicts the seed? Thank you very much.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-37621459
.

[kisielk]

Another example:

http://jazzy.id.au/default/2010/09/20/cracking_random_number_generators_part_1.html

Basically if you can can get two consecutive random numbers from a prng and you have some knowledge of the algorithm, then you can pretty much predict future values.

[bigradish]

@elithrar and @kisielk Yes, using nanosecond of the time as the seed seems not yet so secure. Thank you very much for your detailed explanation. :)

[bigradish]

@kisielk I have another idea: use "crypto/rand" to create a 64bits seed of "math/rand" to generate random things. This method should be secure and fast. The "crypto/rand" uses /dev/urandom, which is not so fast.
How do you think of this?
Thank you.

[kisielk]

I believe that suffers from the same problem. The problem with the
prng is that if you can get two consecutive numbers and know the
algorithm you can guess future values. It doesn't matter what the
original seed is because the RNG is effectively deterministic.

On 3/15/14, bigradish notifications@github.com wrote:

@kisielk I have another idea: use "crypto/rand" to create the seed of
"math/rand" to generate random things. This method should be secure and
fast. The "crypto/rand" uses /dev/urandom, which is not so fast.
How do you think of this?
Thank you.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

Kamil

[bigradish]

@kisielk yes, the situation is similar. Thank you. :)