bcrypt is a password-hashing function designed by Niels Provos and David Mazières, based on the Blowfish cipher and presented at USENIX in 1999.
[1] Besides incorporating a salt to protect against rainbow table attacks, bcrypt is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power.
[3] There are implementations of bcrypt in C, C++, C#, Embarcadero Delphi, Elixir,[4] Go,[5] Java,[6][7] JavaScript,[8] Perl, PHP, Ruby, Python, Rust,[9] Zig[10] and other languages.
Blowfish is notable among block ciphers for its expensive key setup phase.
Then it uses this modified state to encrypt another part of the key, and uses the result to replace more of the subkeys.
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 input to the bcrypt function is the password string (up to 72 bytes), a numeric cost, and a 16-byte (128-bit) salt value.
[14] 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).
In bcrypt the usual Blowfish key setup function is replaced with an expensive key setup (EksBlowfishSetup) function: The bcrypt algorithm depends heavily on its "Eksblowfish" key setup algorithm, which runs as follows: InitialState works as in the original Blowfish algorithm, populating the P-array and S-box entries with the fractional part of
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.
[26] The bcrypt algorithm involves repeatedly encrypting the 24-byte text: This generates 24 bytes of ciphertext, e.g.: The canonical OpenBSD implementation truncates this to 23 bytes:[27] It is unclear why the canonical implementation deletes 8-bits from the resulting password hash.