Let's start Scheme

2012-03-27

RFC2898(PKCS#5)斜め読み

斜め読みもしてないな、眺めただけか・・・

何が知りたかったかといえば、PBEが意味するところと、PKCS#5自体が暗号化のアルゴリズムを規定しないということ。実際そうだった。
では何を定義しているのかと言えば、(眺めただけなので違うかもしれないが)もう一つ上の層というか、より安全に暗号化する方法みたいなものと、とりあえずこいつに従っておけば中身は違っても表面上は何をしているかが統一できるといった感じのもの(だと思う)。
たとえば、派生鍵の作成手順とかその鍵を使った暗号化とかそんなの。でも派生鍵を作成する関数(KDF, Key Derivation Function)は外から渡す必要があるし、暗号化そのものを行う関数や、ハッシュ関数も外から渡す必要がある。 (もちろんMAC関数も)
嘘。KDFに関してはPBKDF1とPBKDF2がどういった関数であるけPKCS#5(RFC2898)内で定義されてた。MACも書いてある。さすがにハッシュ関数は別物だけど。

そうは言っても渡された関数に渡すパラメータとか統一できんよというために、関数が受け取るパラメータも定義してあって、その中にどのアルゴリズムを使うかを指定できるようになっている。まぁOIDでなわけだが。

問題にするところとしては、(crypto)ライブラリを書き直すもしくはてこ入れをするとして、このPKCS#5的に直すのか、とりあえずこういったものも実装しやすいように直すのかで大分方針が変わる気がする。後者かな。PKCS#5をサポートしたかったら(rfc pkcs :5)とか(pkcs :5)とか提供すればいいわけだし。ただ、派生鍵をどうするかは考えないと。こいつばっかりはアルゴリズムにどうしても依存するわけだし。(しないのか?調べないとなぁ)

どうでもいいけど、暗号関連の何かを読むと必ず「salt」って出てくるけど、塩って訳すと変だよなぁ。なんて訳すんだろう?

No comments:

Post a Comment