4 ms·

Slow security is good security. It makes brute forcing more difficult, and promotes decentralization of infrastructure (slowness adds up only for large-scale d

Slow security is good security. It makes brute forcing more difficult, and promotes decentralization of infrastructure (slowness adds up only for large-scale deployments like Google and Facebook, and we want to depend less on centralized actors, not more). If you need to choose between strength and performance, choose strength in nearly 100% of all cases. You make the job of NSA or GRU much harder, and promote offsetting security mechanisms to the edge, where they ought to be.

dsacco 9y ago
Once you've reached an appropriate security margin you shouldn't pour more resources into making it even slower. You don't typically need to choose between performance and security in a general sense, because you can achieve very good performance with very good security. Slowing down your password hashing function any further than is required is overkill, and won't improve your security.
- atemerev 9y ago
  Today's security margin is tomorrow's past news. Usually, security margins are planned against brute force according to Moore's law. This is not enough. Novel cryptographic attacks do not suddenly render the entire algorithm useless (usually); rather, they dramatically reduce its strength. And novel cryptographic attacks appear all the time even in the public space -- who knows what stays behind closed doors and clearances? If you have large enough security margin, you can escape unscathed while you upgrade your infrastructure. And if not, not.
  - dsacco 9y ago
    Sure, but even assuming Moore's Law, algorithms like SHA-2 and SHA-3 are not likely to broken within our lifetimes, if ever. For the set of hashing algorithms that are quantum-safe, you literally gain nothing in practice by making them arbitrarily stronger - they're already so strong that any increase in security margin is a negligible improvement slighter than a rounding error in computational time. But these improvements can come with a performance cost. There's generally no upside and only a downside for choosing to increase the strength beyond what's required for the sake of future proofing.
kerkeslager 9y ago
> Slow security is good security. This is simply not correct. There are a few cryptographic problems where slowness is the solution, but in most cases you want your cryptographic algorithms to be fast.
- atemerev 9y ago
  Could you please counter my arguments (brute force security against immeasurably larger computing power, resilience to novel unknown crypto attacks reducing the algorithm strength) with something more substantial than "this is simply not correct"?
  - kerkeslager 9y ago
    I could, but doing so would likely involve teaching you a good chunk of crypto 101 while you try to tell me I'm actually wrong so you can be right, which would be enjoyable for neither of us. It would be more efficient for you to just take a introductory course on cryptography from someone more qualified than me. I'm not trying to be rude here, it's just clear that you've learned about password hashing and then assumed based on that one exceptional case that slowness is how all of crypto works. It's not, and you shouldn't make claims about all of crypto if the only thing you know about crypto is that password hashing works by being slow.
aidenn0 9y ago
Slow security is bad for many reasons: 1) It means default-secure will not happen. If the NSA has to spend 10x as long to attack your security, but 1/10th as much communication is encrypted, it's a win for them (since now the simple fact that something is encrypted means someone put effort into it, which is a good signal that it will be useful). 2) Brute force attacks are typically embarrassingly parallel, and can be amenable to special purpose hardware (e.g. GPUs). An attacker with an 8 GPU system spend $10k and can attack PBKDF2 much faster than a $10k server will be authenticating people. 3) If your security relies on slowness, then people will pick less-secure defaults. If you can get an equivalent level of security per cpu-cycle, then people will pick a higher security margin (this is the non-binary version of #1). 3DES is way slower than most crypto primitives used today. I haven't seen it recommended much though.

dsacco 9y ago

Once you've reached an appropriate security margin you shouldn't pour more resources into making it even slower. You don't typically need to choose between performance and security in a general sense, because you can achieve very good performance with very good security. Slowing down your password hashing function any further than is required is overkill, and won't improve your security.

atemerev 9y ago
Today's security margin is tomorrow's past news. Usually, security margins are planned against brute force according to Moore's law. This is not enough. Novel cryptographic attacks do not suddenly render the entire algorithm useless (usually); rather, they dramatically reduce its strength. And novel cryptographic attacks appear all the time even in the public space -- who knows what stays behind closed doors and clearances? If you have large enough security margin, you can escape unscathed while you upgrade your infrastructure. And if not, not.
- dsacco 9y ago
  Sure, but even assuming Moore's Law, algorithms like SHA-2 and SHA-3 are not likely to broken within our lifetimes, if ever. For the set of hashing algorithms that are quantum-safe, you literally gain nothing in practice by making them arbitrarily stronger - they're already so strong that any increase in security margin is a negligible improvement slighter than a rounding error in computational time. But these improvements can come with a performance cost. There's generally no upside and only a downside for choosing to increase the strength beyond what's required for the sake of future proofing.

kerkeslager 9y ago

> Slow security is good security. This is simply not correct. There are a few cryptographic problems where slowness is the solution, but in most cases you want your cryptographic algorithms to be fast.

atemerev 9y ago
Could you please counter my arguments (brute force security against immeasurably larger computing power, resilience to novel unknown crypto attacks reducing the algorithm strength) with something more substantial than "this is simply not correct"?
- kerkeslager 9y ago
  I could, but doing so would likely involve teaching you a good chunk of crypto 101 while you try to tell me I'm actually wrong so you can be right, which would be enjoyable for neither of us. It would be more efficient for you to just take a introductory course on cryptography from someone more qualified than me. I'm not trying to be rude here, it's just clear that you've learned about password hashing and then assumed based on that one exceptional case that slowness is how all of crypto works. It's not, and you shouldn't make claims about all of crypto if the only thing you know about crypto is that password hashing works by being slow.

aidenn0 9y ago

Slow security is bad for many reasons: 1) It means default-secure will not happen. If the NSA has to spend 10x as long to attack your security, but 1/10th as much communication is encrypted, it's a win for them (since now the simple fact that something is encrypted means someone put effort into it, which is a good signal that it will be useful). 2) Brute force attacks are typically embarrassingly parallel, and can be amenable to special purpose hardware (e.g. GPUs). An attacker with an 8 GPU system spend $10k and can attack PBKDF2 much faster than a $10k server will be authenticating people. 3) If your security relies on slowness, then people will pick less-secure defaults. If you can get an equivalent level of security per cpu-cycle, then people will pick a higher security margin (this is the non-binary version of #1). 3DES is way slower than most crypto primitives used today. I haven't seen it recommended much though.