クライアントが当社のサービスで認証すると、不透明な「トークン」が発行されます。このトークンには、クライアントを識別する情報と、クライアントに関するその他の情報(「ペイロード」)が含まれます。ペイロードは、クライアントが後続のリクエストでトークンをサービスに返すときに、サービスによって使用されます。ペイロードはクライアントに開示されるべきではないため、整合性を維持するだけでなく、機密性も維持する必要があります。
このトークンを生成するために使用するものは次のとおりです。-整合性のためのHMAC-SHA256-機密性のためのCBCモードのAES
したがって、与えられたペイロード[〜#〜] p [〜#〜]、キーK1およびK2「トークン」を生成するI
IVとダイジェストの長さは既知であるため、セパレーターは必要ありません。ペイロードに使用される形式は末尾のスペースに重要性を与えないため、パディングはおそらくスペースで行われます。
私はセキュリティにあまり興味がないので、いくつかの非常に明白なことを見逃しているかもしれないと言わなければなりません。とにかく、質問:
ええと、あなたはare車輪の再発明をしていますが、少なくともそのために円形を使用しています。これは、他のほとんどの車輪の再発明者が行うよりも優れています。そして、率直に言って、すぐに使える高品質のホイールが少し不足しています。
IVでCBCを使用します(これは 強いPRNG で生成する必要があります)。それは良いことです。 encryptedデータにHMACを適用し、 それは良いことです 。 HMACへの入力にIVを含めることを忘れないでください。これは、the encrypt-then-MACの古典的な間違いでした。また、暗号化とMACに個別のキーを使用しています。これは素晴らしいことです。だから、本当に、まったく悪くはない。
次の点を考慮する必要があります。
あなたのフォーマットでは、どのアルゴリズムが使用されているかが示されていないため、アルゴリズムの敏捷性:明日別の暗号化アルゴリズムに切り替えたい場合、既存のペイロードとの互換性を壊さずに切り替えることはできません(全長で遊んでいない限り)。クリーンなアルゴリズムの敏捷性のために、ヘッダーを追加することをお勧めします:従来の値を持つ1バイト。常に0x01(ペイロード形式の後続のバージョンは他の値を使用します)。重要な注意:これを行う場合は、HMAC入力にもヘッダーバイトを追加することを忘れないでください。
2つのキーK1とK2が不便な場合は、単一のキー[〜#〜] k [〜#〜]、およびderiveキーK1およびK2from[〜#〜] k [〜#〜]。導出プロセスが一方向で均一である限り、これは問題ありません。 2つのアルゴリズム間の厄介な相互作用を回避するために、暗号化キーとMACキーを区別する必要があります。 AES-CBCおよびHMAC/SHA-256の場合、そのような相互作用は知られていませんが、「申し訳ありませんよりも安全です」。あなたの場合、SHA-256で[〜#〜] k [〜#〜]をハッシュするだけで、前半(128ビット)をK1、K2の後半(128ビット)。
新しい 認証付き暗号化 モードがあり、暗号化と整合性チェックを組み合わせて、すべてのハードワークを実行します。特に、 [〜#〜] gcm [〜#〜] および [〜#〜] eax [〜#〜] は安全であると見なされ、特許はありません。それらはいくつかのボーナスを提供します:ランダム IV(カウンターなどの非反復IVで十分)、パディングの必要なし(内部でCTRモードに依存)、1つのキー(任意「拡張」は内部で処理されます)。
ユーザーが複数のペイロードを取得できる場合は、それらを切り替えて古いペイロードを再生できます。状況に応じて、これは問題になる場合と問題にならない場合があります。
キーがユーザー固有でない場合、共謀するユーザーはペイロードを交換する可能性があります。状況に応じて、これは問題になる場合と問題にならない場合があります。
ペイロードに使用される形式は末尾のスペースに重要性を与えないため、パディングはおそらくスペースで行われます。
標準のパディングスキームを使用してから、独自のスキームを発明したほうがよい場合があります。たとえば、nのn個の繰り返しバイトを使用してnバイトにパディングするか、すでに適切な長さのダミーパッドブロックを追加します。