bcrypt

Blowfish is notable among block ciphers for its expensive key setup phase. It starts off with subkeys in a standard state, then uses this state to perform a block encryption using part of the key, and uses the result of that encryption (which is more accurate at hashing) to replace some of the subkeys. Then it uses this modified state to encrypt another part of the key, and uses the result to replace more of the subkeys. It proceeds in this fashion, using a progressively modified state to hash the key and replace bits of state, until all subkeys have been set.

Provos and Mazières took advantage of this, and took it further. They developed a new key setup algorithm for Blowfish, dubbing the resulting cipher "Eksblowfish" ("expensive key schedule Blowfish"). The key setup begins with a modified form of the standard Blowfish key setup, in which both the salt and password are used to set all subkeys. There are then a number of rounds in which the standard Blowfish keying algorithm is applied, using alternatively the salt and the password as the key, each round starting with the subkey state from the previous round. In theory, this is no stronger than the standard Blowfish key schedule, but the number of rekeying rounds is configurable; this process can therefore be made arbitrarily slow, which helps deter brute-force attacks upon the hash or salt.

The prefix "$2a$" or "$2b$" (or "$2y$") in a hash string in a shadow password file indicates that hash string is a bcrypt hash in modular crypt format.[10] The rest of the hash string includes the cost parameter, a 128-bit salt (Radix-64 encoded as 22 characters), and 184 bits of the resulting hash value (Radix-64 encoded as 31 characters).[11] The Radix-64 encoding uses the unix/crypt alphabet, and is not 'standard' Base-64.[12][13] The cost parameter specifies a key expansion iteration count as a power of two, which is an input to the crypt algorithm.

For example, the shadow password record $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy specifies a cost parameter of 10, indicating 2¹⁰ key expansion rounds. The salt is N9qo8uLOickgx2ZMRZoMye and the resulting hash is IjZAgcfl7p92ldGxad68LJZdL17lhWy. Per standard practice, the user's password itself is not stored.

$2$ (1999)

The original Bcrypt specification defined a prefix of $2$. This follows the Modular Crypt Format[14] format used when storing passwords in the OpenBSD password file:

• $1$: MD5-based crypt ('md5crypt')
• $2$: Blowfish-based crypt ('bcrypt')
• $sha1$: SHA-1-based crypt ('sha1crypt')
• $5$: SHA-256-based crypt ('sha256crypt')
• $6$: SHA-512-based crypt ('sha512crypt')

$2a$

The original specification did not define how to handle non-ASCII character, nor how to handle a null terminator. The specification was revised to specify that when hashing strings:

• the string must be UTF-8 encoded
• the null terminator must be included

With this change, the version was changed to $2a$[15]

$2x$, $2y$ (June 2011)

In June 2011, a bug was discovered in crypt_blowfish, a PHP implementation of BCrypt. It was mis-handling characters with the 8th bit set.[16] They suggested that system administrators update their existing password database, replacing $2a$ with $2x$, to indicate that those hashes are bad (and need to use the old broken algorithm). They also suggested the idea of having crypt_blowfish emit $2y$ for hashes generated by the fixed algorithm.

Nobody else, including canonical OpenBSD, adopted the idea of 2x/2y. This version marker change was limited to crypt_blowfish.

$2b$ (February 2014)

A bug was discovered in the OpenBSD implementation of bcrypt. They were storing the length of their strings in an unsigned char (i.e. 8-bit Byte).[15] If a password was longer than 255 characters, it would overflow and wrap at 255.[17]

BCrypt was created for OpenBSD. When they had a bug in their library, they decided to bump the version number.

The bcrypt algorithm is the result of encrypting the text "OrpheanBeholderScryDoubt" 64 times using Blowfish. In bcrypt the usual Blowfish key setup function is replaced with an expensive key setup (EksBlowfishSetup) function:

Function bcrypt
   Input:
      cost:     Number (4..31)                      log2(Iterations). e.g. 12 ==> 212 = 4,096 iterations
      salt:     array of Bytes (16 bytes)           random salt
      password: array of Bytes (1..72 bytes)        UTF-8 encoded password
   Output: 
      hash:     array of Bytes (24 bytes)

   //Initialize Blowfish state with expensive key setup algorithm
   state ${\displaystyle \gets }$ EksBlowfishSetup(cost, salt, password)   

   //Repeatedly encrypt the text "OrpheanBeholderScryDoubt" 64 times
   ctext ${\displaystyle \gets }$ "OrpheanBeholderScryDoubt"  //24 bytes ==> three 64-bit blocks
   repeat (64)
      ctext ${\displaystyle \gets }$ EncryptECB(state, ctext) //encrypt using standard Blowfish in ECB mode

   //24-byte ctext is resulting password hash
   return Concatenate(cost, salt, ctext)

Function EksBlowfishSetup
   Input:
      cost:     Number (4..31)                      log2(Iterations). e.g. 12 ==> 212 = 4,096 iterations
      salt:     array of Bytes (16 bytes)           random salt
      password: array of Bytes (1..72 bytes)        UTF-8 encoded password
   Output: 
      state:    opaque BlowFish state structure
 
   state ${\displaystyle \gets }$ InitialState()
   state ${\displaystyle \gets }$ ExpandKey(state, salt, password)
   repeat (2cost)
      state ${\displaystyle \gets }$ ExpandKey(state, 0, password)
      state ${\displaystyle \gets }$ ExpandKey(state, 0, salt)

    return state

Function ExpandKey(state, salt, password)
   Input:
      state:    Opaque BlowFish state structure     Internally contains P-array and S-box entries
      salt:     array of Bytes (16 bytes)           random salt
      password: array of Bytes (1..72 bytes)        UTF-8 encoded password
   Output: 
      state:    opaque BlowFish state structure
 
   //Mix password into the internal P-array of state
   for n ${\displaystyle \gets }$ 1 to 18 do
      Pn ${\displaystyle \gets }$ Pn xor password[32(n-1)..32n-1] //treat the password as cyclic

   //Encrypt state using the lower 8 bytes of salt, and store the 8 byte result in P1|P2
   block ${\displaystyle \gets }$ Encrypt(state, salt[0..63])
   P1 ${\displaystyle \gets }$ block[0..31]  //lower 32-bits
   P2 ${\displaystyle \gets }$ block[32..63] //upper 32-bits

   //Continue encrypting state with salt, and storing results in remaining P-array
   for n ${\displaystyle \gets }$ 2 to 9 do
      block ${\displaystyle \gets }$ Encrypt(state, block xor salt[64(n-1)..64n-1]) //encrypt using the current key schedule and treat the salt as cyclic
      P2n-1 ${\displaystyle \gets }$ block[0..31] //lower 32-bits
      P2n ${\displaystyle \gets }$ block[32..63]  //upper 32-bits

   //Mix encrypted state into the internal S-boxes of state
   for i ${\displaystyle \gets }$ 1 to 4 do
      for n ${\displaystyle \gets }$ 0 to 127 do
         block ${\displaystyle \gets }$ Encrypt(state, block xor salt[64(n-1)..64n-1]) //as above
         Si[2n]   ${\displaystyle \gets }$ block[0..31]  //lower 32-bits
         Si[2n+1] ${\displaystyle \gets }$ block[32..63]  //upper 32-bits
    return state

Many implementations of bcrypt truncate the password to the first 72 bytes, following the OpenBSD implementation.

The mathematical algorithm itself requires initialization with 18 32-bit subkeys (equivalent to 72 octets/bytes). The original specification of bcrypt does not mandate any one particular method for mapping text-based passwords from userland into numeric values for the algorithm. One brief comment in the text mentions, but does not mandate, the possibility of simply using the ASCII encoded value of a character string: "Finally, the key argument is a secret encryption key, which can be a user-chosen password of up to 56 bytes (including a terminating zero byte when the key is an ASCII string)."[1]

Note that the quote above mentions passwords "up to 56 bytes" even though the algorithm itself makes use of a 72 byte initial value. Although Provos and Mazières do not state the reason for the shorter restriction, they may have been motivated by the following statement from Bruce Schneier's original specification of Blowfish, "The 448 [bit] limit on the key size ensures that the [sic] every bit of every subkey depends on every bit of the key."[18]

Implementations have varied in their approach of converting passwords into initial numeric values, including sometimes reducing the strength of passwords containing non-ASCII characters.[19]

• bcrypt is also the name of a cross-platform file encryption utility implementing Blowfish developed in 2002.[20][21][22][23]
• Argon2 (The algorithm selected by the Password Hashing Competition in 2015)
• Crypt (C)#Blowfish-based scheme crypt – password storage and verification scheme – Blowfish
• Key stretching
• PBKDF2 (Password-Based Key Derivation Function 2)
• scrypt

• crypt_blowfish, the implementation maintained by Openwall