3 ms·

bcrypt is a hashing algorithm for securely hashing passwords, this is something you want to be slow, yes. However, the discussion in the link is about encrypti

by merijnv 14y ago

bcrypt is a hashing algorithm for securely hashing passwords, this is something you want to be slow, yes. However, the discussion in the link is about encryption, which you want to be fast. A popular webserver serving HTTPS to thousands of clients can't afford a 10x overhead on the speed of encryption.

VLM 14y ago
Encryption and decryption speeds need not be symmetric. Salted passwords are a stereotypical example... Lets say my password is "password" and I salt it with a random 8 bit value to make rainbow tables 256 times longer than unsalted. I can encrypt the salted password in one round. However on the decrypt side a salty password is going to have to average 128 rounds before a match and a worst case failure / non-match means you have to run ALL 256 rounds just to make sure. Obviously we're talking salty passwords not secure web traffic, but the point is off the shelf systems have existed for decades where the decrypt system is orders of magnitude more expensive than the encrypt system. Implementing an algo with those characteristics for web traffic "superficially seems feasible" although the details are fuzzy. As an example of a rough guess, 16 bits of salt would scale pretty well for "thousands of clients" if the server and client are more or less similar performance level (which within an order of magnitude or two is probably about right). Simple salt is the wrong algo for this job, but...
finnw 14y ago
bcrypt is actually a cipher, like standard blowfish but with a much more expensive key expansion function. When you call the bcrypt "hash function", what it is really doing is performing this key expansion then using the resulting key to encrypt a constant string. GP is right - you can use bcrypt as a regular cipher, and the extended key schedule will make brute-forcing harder. It is inefficient and unnecessary though - a 384-bit key will not be attacked by brute force anyway, and blowfish's small block size of 64 bits can be problematic (you need to change the key quite frequently to prevent active attacks.)
Dylan16807 14y ago
Actually I think 10x cpu for encryption is perfectly feasible on modern hardware. 100x perhaps not.

by merijnv 14y ago

VLM 14y ago

Encryption and decryption speeds need not be symmetric. Salted passwords are a stereotypical example... Lets say my password is "password" and I salt it with a random 8 bit value to make rainbow tables 256 times longer than unsalted. I can encrypt the salted password in one round. However on the decrypt side a salty password is going to have to average 128 rounds before a match and a worst case failure / non-match means you have to run ALL 256 rounds just to make sure. Obviously we're talking salty passwords not secure web traffic, but the point is off the shelf systems have existed for decades where the decrypt system is orders of magnitude more expensive than the encrypt system. Implementing an algo with those characteristics for web traffic "superficially seems feasible" although the details are fuzzy. As an example of a rough guess, 16 bits of salt would scale pretty well for "thousands of clients" if the server and client are more or less similar performance level (which within an order of magnitude or two is probably about right). Simple salt is the wrong algo for this job, but...

finnw 14y ago

bcrypt is actually a cipher, like standard blowfish but with a much more expensive key expansion function. When you call the bcrypt "hash function", what it is really doing is performing this key expansion then using the resulting key to encrypt a constant string. GP is right - you can use bcrypt as a regular cipher, and the extended key schedule will make brute-forcing harder. It is inefficient and unnecessary though - a 384-bit key will not be attacked by brute force anyway, and blowfish's small block size of 64 bits can be problematic (you need to change the key quite frequently to prevent active attacks.)

Dylan16807 14y ago

Actually I think 10x cpu for encryption is perfectly feasible on modern hardware. 100x perhaps not.