emboss

4 ms·

1.
by emboss 11y ago
General-purpose hash functions should be as efficient as possible. That's why they shouldn't be used for password hashing directly. There are special hash functions (slow, memory-intensive, hard to parallelize) for storing passwor
2.
OpenSSL PRNG is not (really) fork-safe(martinbosslet.de)
1 points by emboss 13y ago|0 comments
3.
E-Mail Made in Germany - Really?(martinbosslet.de)
1 points by emboss 13y ago|0 comments
4.
We need to sign Ruby gems! But how?(emboss.github.com)
1 points by emboss 14y ago|0 comments
5.
by emboss 14y ago
Hmm, that's an interesting idea. Although I could imagine that this approach ultimately leads to something like Universal Hashing. For example, if the functions you would use in your example are not randomized in some way, an attacker could
6.
by emboss 14y ago
Thank you! I hope we (or others) can manage to break some more hashes to raise the awareness of this problem! See also this nice example for btrfs: http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/
7.
Breaking Murmur: Hash-flooding DoS Reloaded(emboss.github.com)
6 points by emboss 14y ago|4 comments
8.
by emboss 14y ago
If OpenSSL::Random isn't working (because OpenSSL is not installed for example) there is also SecureRandom in the stdlib. It tries to do the right thing in any situation: Use OpenSSL:Random if available, otherwise it will fall back to what'
9.
by emboss 14y ago
You're welcome - and thank you!
10.
Krypt - the Next Level of Ruby Cryptography(emboss.github.com)
10 points by emboss 14y ago|2 comments
11.
Units Digit of a Power: A Constant-Time Algorithm Using a Little Number Theory(emboss.github.com)
3 points by emboss 14y ago|0 comments
12.
by emboss 14y ago
Implementations: C: https://github.com/floodyberry/siphash Go: https://github.com/dchest/siphash C: https://github.com/emboss/siphash-c Ruby: https://github.com/emboss/siphash-ruby Java: https://github.com/emboss/siphash-ja
13.
SipHash - A solution for hashDoS and short message MACs(131002.net)
6 points by emboss 14y ago|1 comments
14.
by emboss 14y ago
Since it was standardized by ITU, it's still used in newer telecom protocols, and it's pervasively used throughout higher level cryptography-related protocols/standards, CAdES is one of the more recent ones and gaining acceptance in the EU.
15.
by emboss 14y ago
I find their attitude worrying - how can something be overstated if it's essentially possible for anyone to take down servers as easy as that? It's possible, so it must be fixed, that's what basically any text book on security tries to conv
16.
by emboss 14y ago
Minor nitpicking: > unlike in Java, you can also call a class method on an instance It's possible in Java, too. It's just considered bad practice. Still, a very nice read!
17.
by emboss 14y ago
Maybe the question is asked from the wrong perspective - it's not that designers of cryptographic hash functions ask themselves "Hmm, so how fast/slow do we want this thing to be?". They go the other way round and set a "security parameter"
18.
by emboss 15y ago
While we agree on the fact that using either of the three can't be a bad thing, I'd like to give my opinion on why I favor PBKDF2 over bcrypt, and probably even over scrypt, although I admit the "memory-hardness" of the latter makes it supe