Reputation
Top tag
Next privilege 250 Rep.
View close votes
Badges
9
Impact
~612 people reached

Apr
16
comment Is it possible to brute-force a hash algorithm of 32 bits
Is this about a real-world system? If so, which one? I'd like to avoid it like the plague.
Apr
16
comment Is it possible to brute-force a hash algorithm of 32 bits
True, Maarten. I took the question to be about "finding a password that matches the hash", but I see how it could equally well be interpreted as "finding the password the user selected". However, with a 32-bit hash, I think it stands to reason that the latter is not possible to do with any reasonable degree of certainty, at least if the passwords were reasonably well chosen; there are just going to be too many candidate passwords that match the hash output.
Apr
16
comment Is it possible to brute-force a hash algorithm of 32 bits
Even if we posit only 5 bits/character of entropy in the passwords (roughly equivalent to random single-case alphabetic passwords), 32 bits output hash seems to only allow for 6-7 character passwords before you start seeing collisions. Wouldn't that be the set you need to hash to have a high likelihood of finding a collision, if the hash (aside from outputting only 32 bits) at least has a uniform output distribution? Approaching that even as a brute force attack on a modern PC should be trivial.
Apr
13
comment Brute force knowing a part of the password
Lesson learned should be "keep backups". RAID is not a backup. There's a gazillion other possible ways for things to go awry with the data storage that won't be helped by this approach at all, and using full-disk encryption has a tendency to exacerbate the resultant problems.
Apr
13
comment Is there an AES identity key?
@abligh Sounds like a reasonable answer to the question.
Apr
13
comment Why is the permutation in AES (and other ciphers) not random?
@kasperd Yep, that would cover it. Thanks for the link.
Apr
12
comment Why is the permutation in AES (and other ciphers) not random?
Wasn't there also some discussion of that the original IBM-selected DES S-boxes were vulnerable to differential cryptanalysis, but the revised ones weren't? (If this is better asked as a separate question, ping me and I'll post it...)
Apr
5
suggested rejected edit on Is there something wrong with my decryption using key=9, mod 26?
Nov
6
comment How to decrypt RSA cipher text?
What is the size of the RSA modulus?
Oct
19
comment Design for file transfers to a new party
@CodesInChaos /dev/urandom can produce insecure randomness in an entropy-starvation situation. This is documented at least on Linux (man 4 random dated 2010-08-29). If you want to be certain that the randomness corresponds to available entropy (within system estimations) then read from /dev/random and be aware that the read may block for potentially a long time.
Sep
1
awarded  Autobiographer
Jun
5
awarded  Critic
Jun
4
revised How do we know a cryptographic primitive won't fail suddenly?
Copy-editing
Jun
4
suggested approved edit on How do we know a cryptographic primitive won't fail suddenly?
Jun
4
comment What makes SHA-2 and SHA-3 have security levels half their output hash length?
@yyyyyyy Sounds to me like the beginnings of a decent answer.
Jun
4
comment What makes SHA-2 and SHA-3 have security levels half their output hash length?
@user3491648 Well, that makes some modicum of sense, I suppose. But birthday attacks do have some fairly specific requirements (specifically that the attacker is able to control both inputs) which aren't really generally applicable, right? So how does that justify boiling down the entire "security level" of the hash function to half the hash length? Now, don't get me wrong; I recognize that birthday attacks are valid in some situations (and I should have thought of that) but they aren't always useful.
Jun
4
asked What makes SHA-2 and SHA-3 have security levels half their output hash length?
Jun
4
awarded  Organizer
Jun
4
revised How do we know a cryptographic primitive won't fail suddenly?
Better title, some copy-editing
Jun
4
suggested approved edit on How do we know a cryptographic primitive won't fail suddenly?