問題タブ [hmac]

機密性と認証の両方を保証するメッセージの構成要素として、AES256 CBC + HMAC SHA-256 を使用することを考えています。

特に、次のシナリオを検討してください。

• Alice は Bob に属する公開鍵を所有しています (鍵交換とアルゴリズムはこの質問の範囲外です)。Alice は、Bob と共有されている識別キー K を持っており、これを使用して自分自身を識別することができます。鍵 K を知っているのは Alice と Bob だけです。
• Alice は、Bob の公開鍵を使用して (nonce || K) を暗号化します。
• Bob はパケットを復号化し、K と nonce を取得しました。
• Bob は SHA-256 と SHA256(K || nonce) を使用して、256 ビットの K(e) を生成します。
• Bob は SHA-256 と SHA256(K || nonce + 1) を使用して、256 ビットの K(s) を生成します。

ここで、ボブがアリスに送信したいすべてのパケットに対して、ボブは次のことを実行します。

• 新しいランダムな 128 ビット IV を作成する
• IV と K(e) をキーとして使用してメッセージを暗号化します。
• K(s) をキーとし、(IV || 暗号化されたメッセージ) をデータとする SHA-256 HMAC を作成します。
• 最後に (IV || HMAC || 暗号文) を Alice に送信します

Alice も K(e) と K(s) を計算し、Bob からデータを受信するときに次の手順に従います。

• メッセージを IV、暗号文、および HMAC に分割します。
• K(s)、IV、および暗号文を使用して HMAC を計算します。
• HMAC と送信された HMAC を比較します。これが一致する場合、Alice はこのメッセージが Bob によって送信されたメッセージとして認証されたと見なし、そうでない場合は破棄されます。
• Alice は K(e) を使用してメッセージを復号化します。

このプロトコルは、ボブ以外の誰もアリスが公開鍵を使用して暗号化して送信した暗号化されたメッセージを読むことができないと仮定して、アリスがボブからのメッセージのみを復号化することを保証しますか?

つまり、この方法で作成されたメッセージは、機密性と認証の両方を保証しますか?

注: プロトコルで Bob が複数のメッセージを送信する必要がある場合、リプレイ アタックを回避するために、このスキームを少し変更する必要があります。

PS AES-GCM/CCM を認識していますが、このスキームは、ほとんどの暗号化パッケージに含まれる基本的な AES、SHA、および HMAC アルゴリズムで機能します。このソリューションも遅くなる可能性がありますが、それも問題の範囲外です。

S3 スタイルの認証を使用する RESTful APIでは、API クライアントは HMAC-SHA1 を使用して秘密鍵でリクエストに署名するため、秘密鍵がネットワーク経由で送信されることはありません。次に、サーバーは、クライアントの秘密鍵を使用して署名プロセス自体を繰り返し、その結果をクライアントから送信された署名と比較することにより、クライアントを認証します。

これはすべて良いことですが、サーバーがクライアントの共有シークレットの平文にアクセスする必要があることを意味します。これは、ユーザーのパスワードをデータベース内に平文で保存することに対するあらゆるアドバイスに反するものです。パスワードのソルトハッシュのみを保存することは、私が知る限りオプションではありません。クライアントの署名を検証できないためです。

私の API は RESTful であるため、ステートレスであるべきであることを強調しておく必要があります。他の API 呼び出しの前にログイン手順を実行することは避けたいと考えています。

オプションのソリューションの 1 つは、対称キー アルゴリズムを使用してすべてのユーザー パスワードを暗号化することです。ただし、サーバーはその暗号化のキーを、ソース コード内など、簡単にアクセスできる場所に保存する必要があります。これは何もないよりはましですが、最適な解決策ではありません (@Rook が回答で述べたように、CWE-257 に違反しています)。

ソリューションの別の方向性は、非対称署名に関する何かかもしれませんが、それを HMAC に適用する方法がわかりません。また、この件に関する記事も見つかりません。

ここで明らかな何かが欠けていますか？多くの立派なプロバイダーがこの種の認証スキームを実装しています。それらすべてが共通のセキュリティ原則に違反しているわけではありませんよね? そうでない場合、共有できるベスト プラクティスはありますか?

パスワードハッシュに関するこの優れた回答を読んで、それを実装する方法を知りたい:

邪悪なノミは次のように書いています。

ユーザーごとに nonce を生成します。これだけで虹のテーブルは打ち負かされます。これは、範囲に応じて生成されるハッシュの数を拡張する乱数です。

ユーザーのパスワードのほかに、データベースに一意のトークンを保存しますか?

元の投稿のコード例:

このコードでパスワードを確認するにはどうすればよいですか? 説明させてください：

ユーザーがパスワードを送信すると、メールアドレスとハッシュ化されたパスワードが一致する既存のデータベース行を確認するために、そのハッシュを生成する必要があります。ユーザーについて何も知らないときに、この行を選択するにはどうすればよい$nonceですか? 何か不足していますか？メールアドレスだけでユーザーを選択し、後でパスワードハッシュを確認する必要があるのでしょうか?

ところで、このハッシュ方法をお勧めしますか?

Amazon の SimpleDB 用のモジュールを作成しています。HMAC-SHA アルゴリズムを使用して REST 要求に署名する必要があります。（詳細はこちら）

この署名をコンピューター化する機能があると言われましたが、ドキュメントで見つけることができません。関数は何と呼ばれ、その引数はどのように見えますか?

暗号を多用するアプリケーションを作成しています。ほとんどのネットワーク化されたアプリケーションと同様に、私のものはデータをさまざまな種類のメッセージ (インスタント メッセージ、ファイル チャンク、ビデオ フレームなど) に分割し、改ざん防止と正しい発信元の両方について、それぞれの信頼性をチェックする必要があります。これまでのところ、ECDH を使用して、AES で既に使用している共有シークレットをネゴシエートできます。もちろん、同じ共有シークレットを後で使用できます。

私の質問は次のとおりです。この場合、ECDH によって HMAC で確立された共有秘密を単に使用するのではなく、各メッセージに署名するために ECDSA を使用することに追加の利点はありますか?

以下で M と言う場合、暗号化されたメッセージまたは平文のいずれかを意味します。それは問題ではありません。以下のエラーを修正してください。

ECDSA (または DSA) では、通常M、安全なハッシュ アルゴリズム (私は現在 SHA-2 の 1 つを使用しています) を使用してメッセージ ( ) をハッシュし、署名者の秘密鍵を使用してH(M)暗号化することを理解しています。H(M)これによりR、S整数 (署名) が生成されます。次に、M、R、および S が、送信者の公開鍵を既に所有している受信者に送信されます。 が計算され、 と を使用しH'(M)て署名が検証されます。BouncyCastle は、これを実装するものを提供します。RSECDSASigner

HMAC では、私が持っている共有シークレットが必要です。次に:
HMAC(K, M) := H( f2(K) || H(f1(K) || M) ) (訂正していただきありがとうございます、Paŭlo Ebermann。詳細については、彼の回答を参照してください。)

では、DH/ECDH が共有シークレットを安全にネゴシエートすることを考えると、HMAC を使用してはいけない理由はありますか?

関連: なぜNSAは、MAC ではなく DSA の標準アルゴリズムを指定するのですか? SHA-2 + AES にできるという理由だけで？

ここでは速度が重要です。現在作成しているこの 1 つのプロトコルで、現在のテキスト メッセージだけでなく、近い将来、大きなファイルやビデオ フレームもサポートするようにしたいからです。したがって、私は HMAC を使用することを好みますが、上記の目標を確実に達成できるようにしたいと考えています。

ご協力いただきありがとうございます！

hmac sha256 暗号化を使用してサーバーにログインしようとしていますが、php で動作するコードを持っていますが、iphone で動作させることができず、同じ入力 php を指定すると、iphone の hmac が php コードに異なる出力を生成していることを追跡しましたコードは

Objective-Cコードは

署名されたAPIリクエストを認証するために、 AmazonAWSサンプルと同様のコードを使用することを計画しています。したがって、ユーザーは次のようになります。

$digestリクエストURIにパラメータとしてアタッチします。サーバー側は同じアルゴリズムを使用してクライアントURIからダイジェストを作成し、それをクライアントから送信された値と比較します。

私が見つけられないのは、HMACSHA256ダイジェストを生成するときに使用する正しい長さのSecretKeyを生成するためのPerlサポートです。

私のAmazonAWSアカウントでは、40ASCII文字のbase64エンコード文字列が提供されています。

クライアント用の適切な秘密鍵を生成するにはどうすればよいですか？

Data::UUID Perl モジュールを使用して、HMAC_SHA256 アルゴリズムで使用する 256 ビットの対称キーを生成することを検討しています。各呼び出しで 128 ビットの一意の文字列が得られるはずなので、次のようなことを考えています。

use Data::UUID;

my $ug = new Data::UUID;

my $uuid1 = $ug->to_hexstring($ug->create());

my $uuid2 = $ug->to_hexstring($ug->create());

my $256_bit_key = $uuid1 . $uuid2;

この鍵は暗号的に強力ですか?

サードパーティのサービスに渡されるユーザーIDに署名するためにhmacsha1を使用しています。すべてのユーザーに同じシークレットが使用され、ソルトはユーザーごとに一意です。

hmacは短い文字列に対して機能しますか？userid：timestampは、たとえば12：1304985212のようになります。ソルトとシークレットの順序は重要ですか？（ソルト+シークレットvsシークレット+ソルト）共有シークレットの長さは何で、ソルトの長さは何でしょうか？同じシークレットを使用して、サーバーとリモートサービス間のメッセージにも署名できますか、それとも別のシークレットを生成する方がよいですか？

ありがとう

以下の仕様を使用して、Android で oauth_signature を作成する必要があります。OAuth 経由でリソースにアクセスするための署名を作成する際にボイラー プレート コードを処理するライブラリを探しています。

1. 3 つのリクエスト要素の連結で構成される署名「ベース文字列」を作成します。

   • HTTP リクエスト メソッド。
   • リクエストの送信先のベース URL。この URL にはクエリ パラメータを含めないでください。Google サービスへの呼び出しに署名する場合、関連する手順については、OAuth 仕様のセクション 9.1.2 を参照してください。
   • リクエスト内のパラメーターの正規化された文字列 (oauth_signature パラメーターを除く)。これには、リクエスト ヘッダーまたは本文で送信されるパラメータと、リクエスト URL に追加されるクエリ パラメータが含まれます。文字列を正規化するには、辞書式のバイト値順序を使用してパラメーターを並べ替えます。この文字列の正規化の詳細については、OAuth 仕様のセクション 9.1.1 を参照してください。

2. 次のいずれかのシーケンスを使用して oauth_signature を生成します。

   • アプリケーションが登録されていて、HMAC-SHA1 を使用している場合は、登録時に生成された OAuth の「コンシューマー シークレット」値を使用します。この値は、ドメインの登録ページに表示されます。