bcrypt(ビー・クリプト)はNiels ProvosとDavid Mazièresによって設計された1999年にUSENIXにて公開された、Blowfish暗号を基盤としたパスワードハッシュ化関数である。レインボーテーブル攻撃に対抗するためにソルトを組み込んでいる以外に、bcryptは適応的な特性を備えている。計算能力が増えたとしてもブルートフォース攻撃に耐えられるように、繰り返し回数を増やして速度を落とせるようになっている。

bcryptはOpenBSDのデフォルトのパスワードハッシュアルゴリズムとして利用されているほか、SUSE LinuxなどのLinuxディストリビューションを含む他のシステムでも利用されている。

bcryptはC、C++、C#、Go、Java、JavaScript、Elixir、Perl、PHP、Python、Ruby、その他の言語による実装がある。

## 背景

Blowfishはブロック暗号の中では鍵のセットアップフェーズのコストが高いことで知られている。Blowfishは標準状態はいくつかのサブキーで開始される。その後、鍵の一部を使ってブロック暗号化を行い、この暗号化(正確にはハッシュ)の結果を使ってサブキーのいくつかを置換する。その後は変更された状態を使って鍵の残りの部分の暗号化を行い、その結果を使ってより多くのサブキーを置換する。この方法を繰り返し、段階的に状態を変更しつつ鍵のハッシュ化とビットの状態の置き換えを行い、最終的にすべてのサブキーを設定していく。

ProvosとMazièresはこの方法を取り入れ、さらに発展させた。彼らはBlowfishのための新しい鍵セットアップアルゴリズムを開発し、その成果物の暗号に"Eksblowfish" ("expensive key schedule Blowfish")という名前をつけた。このアルゴリズムでは標準のBlowfishの鍵セットアップから変更され、すべてのサブキーの設定において、ソルトとパスワードの両方を利用する。その後は、ソルトとパスワードを交互に鍵として使い、標準のBlowfishの鍵作成アルゴリズムを複数ラウンド数適用していく。ラウンドのたびに、以前の適用結果をサブキーの状態として計算を行う。理論的にはBlowfishの鍵スケジュールほど強くはないが、鍵作成のラウンド数が変更可能であるため、任意でこのプロセスの計算量を増やして遅くすることが可能であり、ハッシュやソルトに対するブルートフォース攻撃に対抗できる。

## 説明

bcryptによってハッシュ化された文字列は"$2a$"や"$2b$" (あるいは "$2y$")という接頭辞を持つ。この接頭辞はハッシュ化する際に用いたアルゴリズムによって異なり、前述の接頭辞の場合はshadowパスワードファイルがModular Crypt Formatと呼ばれる形式で記述されており、bcryptハッシュであることを示す。ハッシュ文字列の残りの部分にはコストパラメータ、128ビットのソルト(Radix-64エンコードされて22文字になっている)、184ビットの結果のハッシュ値 (Radix-64エンコードされて31文字になっている)が含まれる.
。Radix-64はunix/cryptアルファベットを利用するもので、標準のBase-64とは異なる。コストパラメータはキー拡張の反復回数を設定するもので、2のべき乗の数となっていて、暗号アルゴリズムの入力値となっている。

`$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy` というshodowパスワードのレコードを例にとると、コストパラメータは10で、キー拡張のラウンド数は2になる。ソルトは`N9qo8uLOickgx2ZMRZoMye`であり、結果のハッシュは `IjZAgcfl7p92ldGxad68LJZdL17lhWy`となっている。一般的なパスワード管理のプラクティス通り、ユーザーのパスワードそのものが格納されることはない。

## バージョン履歴

オリジナルの仕様では接頭辞が `$2$`であると定義されていた。これはOpenBSDのpasswordファイルにパスワードを格納するために使われるModular Crypt Formatフォーマットにしたがっている:

- `$1$`: MD5ベースの暗号('md5crypt')
- `$2$`: Blowfishベースの暗号 ('bcrypt')
- `$sha1$`: SHA-1ベースの暗号 ('sha1crypt')
- `$5$`: SHA-256ベースの暗号 ('sha256crypt')
- `$6$`: SHA-512ベースの暗号 ('sha512crypt')

オリジナルの仕様ではASCII以外の文字やnull終端をどのように扱うべきかの定義がなかった。このバージョンの仕様では文字列のハッシュ化について定義され改訂された:

- 文字列はUTF-8エンコードされる
- null終端がふくまれなければならない

これらの変更により、バージョンが`$2a$`に変更された。

2011年6月に、BCryptのPHP実装であるcrypt\_blowfishの中でバグが発見された。8ビット文字列の扱いを間違っていたのが原因であった。システムの管理者は既存のパスワードデータベースを開き、`$2a$`を`$2x$`に更新することで、既存の間違ったハッシュアルゴリズムを明示的に使い続けていることを示すことを提案した。それ以外にも、修正されたアルゴリズムで生成されたハッシュ値で示すために、crypt\_blowfishが接頭辞として`$2y$` を出力するアイディアを提案した。

標準的なOpenBSDを含むどのディストリビューションも2x/2yのアイディアを採用しなかった。このバージョンマーカーの変更はcrypt\_blowfish.に限定された。

バグがOpenBSDのbcrypt実装で発見された。これは8ビットのバイトであるunsigned charに長さを格納をしていたのが原因である。パスワード長として255文字を越えると、オーバーフローして長さが255に丸められてしまった。

BCryptはOpenBSDのために作られた。OpenBSDのライブラリでバグが発見された時はバージョン番号が更新されることが決定される。

## アルゴリズム

bcryptのアルゴリズムは"OrpheanBeholderScryDoubt" というアルゴリズムをBlowfishを用いて64回暗号化した文字列を作成する。bcryptでは通常のBlowfishの鍵セットアップ関数をコストが高価な(expensive key setup)EksBlowfishSetup関数に置き換えている:

### Expensive key setup

アルゴリズムは、次のロジックを持つ鍵セットアップアルゴリズムの"Eksblowfish"に強く依存している:

InitialStateはオリジナルのBlowfishアルゴリズムと同じように動作する。P配列とS-boxに $\pi$の16進数の少数点数部分を設定したものである。

### Expand key

ExpandKey関数は次のような処理を行う:

`ExpandKey(state, 0, key)` は通常のBlowfishのkey scheduleと同じため、すべてゼロのソルト値とのXORをとるのは意味がない。`ExpandKey(state, 0, salt)`も同様だが、ソルトを128ビットの鍵として扱っている。

## ユーザー入力

多くのbcrypt実装はパスワードを最初の72バイトだけ切り出して利用する実装になっている。

算術アルゴリズムが18個の32ビットサブキー(72オクテット/バイトと同じ)に初期化することを要求しているからである。bcryptのオリジナル仕様 はユーザーランドのテキストベースのパスワードをこのアルゴルズムの数値とどのようにマッピングするべきかを強制するものはなかった。テキストで書かれた短いコメントで文字列のASCIIエンコードされた文字をシンプルに利用する可能性があると書かれているが、強制するものではない: 「最後に、key引数は秘密暗号鍵であり、ユーザーが選んだ56バイトまでのパスワードである可能性がある(文字列がASCII文字列の場合はゼロのバイトの終端も含む)」

アルゴリズムは初期値として72バイトの入力を扱うが、上記に引用文が「56バイトまで」のパスワードに言及している点は注目に値する。ProvosもMazièresも制約を短くした理由については表明していないが、ブルース・シュナイアーによるBlowfishのオリジナルの仕様を見て決定した可能性がある: 「鍵サイズの448ビット制限によりすべてのサブキーのすべてのビットは、鍵のすべてのビットに依存していることが保証される」

パスワードを初期の数値の値に変換する方法は実装によって異なる可能性があるため、非ASCII文字を含んだパスワードの強度が低下する可能性がある。