To safely store a passwords, it is better to store them hashed using a hashing function designed to be slow like bcrypt. The goal is to trump brute force attacks.

Are there any ciphers slow enough to prevent brute force attacks? I am especially interested about SSH private key storage. Would a brute force attack work if my passphrase is as small as 8 characters?

  • 1
    You could use a slow hashing algorithm and make your encryption key / decryption key be the hash of the "key" that was provided, then use a fast encryption algorithm, same effect Aug 27, 2021 at 2:34

4 Answers 4


Most encryption algorithms are already comparatively slow and judging success is also much more difficult. When you are trying to determine the input for a hash, you know the desired output. When you are trying to crack encryption however, you don't generally know the desired plaintext, even if you do, the potential input space is generally much, much, much larger.

Each digit of a password is only worth about 7 bits of entropy, even if ideally randomly chosen. Even the low end of a standard symmetric key generally uses 128 bits of entropy. The speed of hashing wouldn't matter much if everyone used truly random 18 character passwords. Plus, the plain text you need to reach is generally unknown to the attacker and encryption algorithms generally operate a bit slower anyway since they have to do more complicated operations on a longer set of data.

So, in a sense, no, there aren't algorithms designed to specifically be slow as a design goal, but they don't need to be as the level of security provided and the normal speed of the algorithm doesn't need to be slowed to be practical. A brute force attack against a well chosen key on a 128 bit encryption algorithm with no systematic vulnerabilities would already take longer than our sun will be burning, to say nothing of 256 bit keys (which would not be done on current hardware before the heat death of the universe). Going slower simply isn't necessary.

If you were to use a key derivation function for a password derived key, that would need to be slow, but you wouldn't want to make the decryption itself slow as that would be inefficient.

As for SSH private key storage, it would depend entirely on the implementation of the key derivation function, not the speed of the encryption algorithm, but I'd suggest probably at least 10 characters if you want it to strongly resist brute forcing even for a reasonably slow key derivation (I'm not sure what SSH private key storage uses, and it may vary by client.)

  • So SSH would be good at storing password-protected private key files if it uses a slow password derivation function?
    – cbliard
    Feb 27, 2014 at 14:59
  • @cbliard - SSH is a communications protocol, not an encryption algorithm. I'm unsure what you are asking. Feb 27, 2014 at 15:05
  • Sorry, I was not clear. I meant ssh-keygen and the way it stores private keys protected with a passphrase.
    – cbliard
    Feb 27, 2014 at 15:27
  • @cbliard - as long as it is properly implemented to use a slow derivation function and a strong password is used, then protecting the random key with the derived key from the password would be just as resistent as a slow hash. You only need things to be slow when the keyspace is small enough to be exhaustible. Average usable passwords are exhaustible without adding artificial slowness to make them more resistant. That said, a single point of failure (one password revealing multiple keys) is another problem, but that's why security is about trade offs between risk and usability. Feb 27, 2014 at 15:32
  • If you want to think about it another way, a key derivation function and a hash are basically the same thing (though a derivation doesn't necessarily have to be one way). Both are simply ways to make some other value from the input password and both are only as secure as the keyspace of the password being used for them. Feb 27, 2014 at 15:35

For the most part, no. Ciphers are designed to be as fast as possible while providing a good level of security so that you can encrypt data quickly and easily. However, this property makes them bad for password encryption, hence why you have things like bcrypt that slow them down by iterating the algorithm over the password a large number of times.

Now, there was one exception I came across about a decade or so ago that was design to be slow. The author designed it that way because he didn't believe that fast algorithms were secure. While it was generally considered impractical since it would take a very long time to encrypt significant data and the design prevented it from being used in a streaming environment, it very well could be a good basis for a one way password hashing algorithm assuming the design is cryptographically secure.


Making a cipher slow is not a wise design goal. I will explain why later, but first: Bcrypt. The purpose of Bcrypt is to stretch a low entropy input to a longer output of a one way function. Bcrypt is designed with passwords in mind. Passwords typically have low entropy (<230), but if they did not Bcrypt could be replaced with a normal cryptographic hash function. One reason it is not required to slow down ciphers is because it is easy to generate high entropy keys. It is not feasible to brute force strong ciphers with large keys.

Lets compare AES-128 to hypothetical cipher BFT-256. (Named like HAL/IBM.) BFT is one million times faster than AES-128. Would it be easier to brute force the key assuming AES-128 provides 128 bits of security and BFT-256 provides 256 bits of security? No because the cipher with a larger key requires you to brute force 2128 times as many keys even though each encryption can be done 220 times faster. 2256-20 > 2128.

Finally, if someone really did want to slow down a cipher here are some examples of what they might do. They might increase the number of rounds in a block cipher. However this increases the amount of time encryption takes linearly for people with or without the key. Expanding the key space increases the amount of time taken to brute force a key exponentially while making little difference to the encryption time depending on the algorithm. Second, one might use a secret key and a counter to construct a slow cipher from Bcrypt the same way you can do so with SHA and other hash functions. However hopefully both of these solutions seem silly now.

Additionally, there is not even enough energy to increment a counter 2256 times even if all the energy produced by a supernova could be captured and ciphers take even more energy and more time than an increment operation.

  • The supernova demonstration is awesome.
    – cbliard
    Feb 28, 2014 at 8:40

Some hashing functions (presumably you meant hash, not cipher, since you're talking about password hashing) are slower than others. As an example, Bernstein's original CubeHash implementation is comparatively slow, and DJB touted its poor performance as a selling point. Nobody really bought it, though.

A lot of industry effort needs to be devoted into perfecting and securing a single cryptographic function, so the function needs to work well across the board. And, in addition to use in hashing passwords, hash functions are also used for things like file verification and on-the-fly message signing.

A slow-operating hash function is unsalvageable in cases that need high performance, but a fast-operating hash can be made slow by simply running it iteratively, as happens in PBKDF2 and similar hash-strengthening algorithms. With this in mind, a fast hash is universally more useful, and therefore more likely to be well-vetted and widely deployed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.