meta user
network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 9 months |
| seen | Apr 24 at 3:58 | |
| stats | profile views | 34 |
|
Aug 16 |
answered | Why does PBKDF2 xor the iterations of the hash function together? |
|
Aug 16 |
awarded | Citizen Patrol |
|
Aug 14 |
awarded | Enlightened |
|
Aug 14 |
awarded | Nice Answer |
|
Aug 11 |
comment |
How should I calculate the entropy of a password? @this.josh If you expect the attacker to expect you to use some positions more than others, yes. Whether or not that's a good expectation is an interesting discussion. There is said to be a government agency using a password restriction of "if there is only one letter or special character, it should not be either the first or last character". I wrote a blog post a while back on this extendedsubset.com/?p=18 |
|
Aug 11 |
comment |
How should I calculate the entropy of a password? Perhaps you could put it like this: entropy exists from the perspective of some party. To the user who knows their password, the password has zero entropy. But usually the party we're discussing the entropy is some hypothetical attacker. If you were to show him the password one symbol at a time, how much new information (in units of bits) would he learn as he sees each one arrive in turn? So the entropy is about the generation of the password insofar as we expect the attacker to know the method, but not the values, of that generation process. |
|
Aug 11 |
comment |
Properties of PRNG / Hashes So I was right that NIST wouldn't like "a1 = hash(seed), a2 = hash(seed + a1), ...", their approved method is somewhat more complex and does involve counters. I was wrong thinking that NIST wouldn't like a recursive SHA-1 PRNG at 160*2^80 bits output, AFAICT they don't allow anything to output more than 2^67 bits! |
|
Aug 11 |
comment |
Properties of PRNG / Hashes Sorry for the confusion, let me try again: For a given seed, the PRNG we're discussing recursively evaluates a hash function on its own output. When this recursion count approaches the Collision Resistance of the function, it risks colliding with one of its previous outputs. So our expectation for such a PRNG is that its cycle length will have an upper bound determined by the HF's CR. Looking at NIST SP 800-90, Hash_DRBG uses both counters and recursive HF application, and still places very conservative limits on the allowed output (< 2^48 reqs even for SHA-512) |
|
Aug 10 |
comment |
How can I improve a password generation scheme based on a shared secret and URL? As a point of reference, this guy golubev.com/hashgpu.htm is doing 5.8e9 MD5s per second on an off-the-shelf CPU+GPU box. That might translate into 1.8e9 SHA-1s per second. Better pick a strong password! |
|
Aug 9 |
comment |
Properties of PRNG / Hashes Agreed, 2^80 output blocks under the same key is not worth losing sleep over. But why would you even do it that way when the CTR-mode PRNG is no more expensive? On NIST, I read them saying (in their 2007 request for SHA-3 candidate submissions): "The 160-bit hash value produced by SHA–1 is becoming too small to use for digital signatures, therefore, a 160-bit replacement hash algorithm is not contemplated." This suggests to me that they would frown upon "only" 2^80 collion resistance in a new design. They even commissioned a function with a 512-bit output size too. |
|
Aug 7 |
comment |
Why isn't the alternating step generator used more often? My Google searches turned up a related patent web hit, but the linked web page didn't have 'Gunther' in it. It was in Google's result summary though. I had to view source in order to find it! |
|
Aug 7 |
revised |
Why isn't the alternating step generator used more often? minor exposition |
|
Aug 7 |
answered | Why isn't the alternating step generator used more often? |
|
Aug 7 |
revised |
Properties of PRNG / Hashes Some claims not holding up under scrutiny and withdrawn |
|
Aug 7 |
comment |
Properties of PRNG / Hashes OK, I'll buy that about the cycle length. |
|
Aug 6 |
answered | Where do I securely store the key for a system where the source is visible? |
|
Aug 6 |
comment |
Properties of PRNG / Hashes They certainly don't impose the memory overhead of a Mersenne Twister. |
|
Aug 6 |
comment |
Is the logic for how the enigma machine worked documented somewhere? Perhaps this is what you want: homepages.tesco.net/~andycarlson/enigma/simulating_enigma.html "A recurring theme in my Inbox is people asking for the enigma wheel wiring so that they can write their own simulator. To save repetition, this web page contains the information you will need if you want to build yourself a simulator." |
|
Aug 6 |
comment |
Properties of PRNG / Hashes @D.W. Well I didn't mean to say that 2^80 was an imminent security problem - but there are certainly many users who wouldn't accept it in a new design either, e.g., NIST. Also -- I didn't believe that paper either. So I tested it with exhaustive and Monte Carlo analysis on much smaller (and likely much more ideal) random functions. My results suggested that, if anything, the effect was understated a bit. Here's some links to the ensuing discussion (including some source): bit.ly/oOe8tX bit.ly/rn3my3 My feeling about 2^64 wasn't based on the analytic collisions...just 160/2.5. |
|
Aug 6 |
awarded | Commentator |
