1

UnixOSのカスタムビルドがあります。

私の仕事：OSにIPSecを追加する。

私はフェーズIに取り組んでおり、最初の2つのパケットの送信を完了しました。

私が今やろうとしているのは、識別ペイロードを作成することです。キーイングマテリアル（SKEYID、SKEYID_d、SKEYID_a、SKEYID_e、およびIV作成）について説明しているRFC 2409 （付録B）を読んでいます。

現在、認証にSHA-1を使用しているため、HMAC-SHA1を使用しており、暗号化アルゴリズムはAES-256です。本当の問題は、RFCがPRFに関して何をすべきかについて十分に明確ではないということです。それは言う：

「ネゴシエートされたPRFを使用するには、このドキュメントで採用されているPRFフィードバックメカニズムのために、PRF出力を拡張する必要がある場合があります。」

SHA-1を使用していますが、PRFをネゴシエートしないという意味ですか？

私の意見では、AESは拡張（256ビットの固定長）を必要とする唯一のアルゴリズムです。したがって、SKEYID_eのみを拡張する必要がありますか？

信頼できるものの、より明確な情報源を知っている場合は、RFCにリンクを投稿してください。

4

2 に答える 2

1

IETF RFCは、多くの場合、十分に明確ではありません。ただし、これらは相互運用性を説明することのみを目的として作成されているため、コードを探索するかテストするためのリファレンス実装を見つけることがほぼ不可欠です。確かに2409は特に注意します：

著者は、このハイブリッドプロトコルの独立した実装と相互運用性テストを奨励しています。

別の実装を見つけることが本当に必要なことです。他の誰かのソースを見つけることはさらに良いです。それができない場合は、参考文献を読んでください。一部の企業によって作成されたRFCの中には、「市場での優位性」を構築するために適合実装を作成するために必要な情報を意図的に難読化または単に非表示にするものがあると言われています。2049年を理解するための王道はありません。

于 2010-03-23T15:43:17.873 に答える
1

RFC2409のみに基づいてPRFをネゴシエートすることはできないため、心配する必要はありません。3つのキーTriple-DES、AES-192、およびAES-256はすべて、付録Bのキー拡張アルゴリズムを必要とします。多くの実装にこれらがあるため、相互運用性のテストはそれほど難しくありません。

于 2010-03-24T14:07:16.823 に答える