問題タブ [diffie-hellman]

キー交換に Diffie Hellman を使用しAES、キーでデータを暗号化しようとしています。Android に適した作業サンプルを提供してくれる人はいますか?

重複の可能性:
SSL 鍵交換暗号化技術

SSL/TLS の暗号スイートの一部は DH として、一部は EDH として言及されています。エフェメラル Diffie Hellman (EDH または DHE) と Diffie Hellman の違いは何ですか?

Diffie-Hellman Elliptic Curves に FIPS 186-3 推奨曲線を使用しています。RFC 5915 によると、秘密鍵の最大長を決定しようとしています。

上限 (log2(n)/8) 、n は曲線の次数

P-256 曲線の場合、コードで見ているものに対応する最大長 32 を取得します (符号なし表現を想定)。ただし、P-521 曲線の場合、最大長は 65 ですが、コードで長さ 66 の秘密鍵を取得しています。P-521 曲線からの 66 バイトの秘密鍵の例を次に示します。

5367794175793176027889969828113014603157344894208126643379049713388781962338446363455749219733919077469072043715066195336337088038146192289964998476049182286

16 進数:

01 90 59 2F 64 1C 73 AB F8 57 C4 F0 F2 A3 17 DD 5E 5F 64 B1 3C 61 15 8F E2 AC 34 DD 3F FC 6F 9B F1 38 9B 66 0F 27 34 60 75 E3 32 B0 BFE2 80 DF 9F 2A AC FF 82 BE 36 00 77 7A 92 B1 CB F7 7F 98 6E 4E

この公開鍵は (先頭の 0x04 バイトなしで):

01 F0 64 36 14 25 89 F8 7E 0D 5F 0E F9 26 36 D7 5C 4A 45 D7 9C 86 BD F8 C5 B9 A7 AA C4 C2 EB 56 52 DD BD BE E1 A0 5B DD A1 1F D8 79 D8 BA 2A 18 68 56 C0 D7 0A 4D D6 2B AB BD 8E D9 33 7F B1 FF E5 18 00 B2 06 21 D9 DA C1 BA A2 E7 43 69 06 FF 03 2F 05 FC 0E 44 74 A1 A3 3B 2E 7E B1 68 01 B2 7F B9 94 EB 8C C7 47 D7 02 A5 46 4E 88 32 59 DD 27 DE 72 C2 6D 8D B4 3B D0 45 67 31 AF 8E 1C 30 87 42 38 9F

66 バイト長の秘密鍵を取得できる理由を知っている人はいますか? FIPS 186-3 ドキュメントによると、P-521 曲線の順序は次のとおりです。

n = 6864797660130609714981900799081393217269435300143305409394463459185543183397655394245057746333217197532963996371363321113864768612440380340372808892707005449

これにより、天井 (log2(n)/8) = 65 が得られます。

よろしく、 -Martin Lansler

ECDH 鍵交換を必要とするプロジェクトに取り組んでいます。MITM 攻撃から保護する方法を理解しようとしています。公開鍵に署名し、公開鍵の転送と共に署名を送信して、鍵が改ざんされていないことを確認できますが、MITM 攻撃が同じことを行うのを止めることはできません。鍵交換が第三者によって何らかの方法で検証されなければならないことは理解していますが、誰かが MITM 攻撃を行うことができると仮定して、第三者がどのように解決策になり得るのかを理解するのに苦労しています。なぜ彼らは第三者検証でも MITM を行うことができなかったのでしょうか? 両方の当事者が何らかの事前情報を得ることなく、考えられるすべての MITM 攻撃を完全に排除する確実な方法はありますか?

現在開発中の金融取引サービスを提供するAndroidアプリケーションとTLSサーバー間の通信を「保護」しました。

セキュリティクレデンシャルは、Androidapkに含まれているBKSキーストアに保存されます。キーストアのパスワードは、アプリケーションソースにプレーンテキストで表示されます。

keyStore.load(is, "passwd".toCharArray());

誰かがアプリをリバースエンジニアリングした場合、他のユーザーになりすましてサービスのセキュリティを危険にさらす可能性があるのではないかと心配しています。

私の実装に欠陥があるかどうか、他の誰かがこの懸念を持っているかどうか、そしてこの可能性を防ぐための最良の方法は何であるか疑問に思いました。

私は現在、鍵交換にDiffie-Hellmanを使用するプロトコルに取り組んでいます。aes-128暗号化部分と128ビットDH公開鍵で構成されるパケットを受信します。

プロトコルの最後のステップで、aesキーがネットワーク内の別のピアに送信されます。このaesキーは、128ビットの強力な秘密キーを使用して暗号で暗号化する必要があります。

私はBlowfishを使用する予定です（別の暗号にすることもできますが、問題には関係ありません）

ここで、aes-keyを暗号化するために、たとえばblowfishを使用して、SecretKeySpec（javax.cryptoのものを使用しています）というクラスで暗号化用の秘密鍵を作成する必要があります。このクラスは、コンストラクターでbyteArrayを使用してsecretKeyを作成します。

DHの共有キーは128ビットのBigIntegerです。これで、共有キーをbyteArrayとして解釈できるようになりました（16バイトで128ビットが得られます[数値は8ビットデータのフレームとして解釈されます]）

だから私の質問は、私の鍵は本当にどれくらい強いのかということです。

byteArrayの入力として数値のみを使用するため、影響はありますか（これにより、キースペースが制限されますか？）

そうではないと思いますが、100％確信はありません。たぶん誰かが数学をして、私が正しいか間違っているかを証明することができます。

共有キーのキーサイズが間違っている場合、暗号化のために最終的に128ビットのSecretKeyに到達するための心の一部を与えてくれますか？

ECDHシークレットアグリーメントの構造を調べて数日を過ごしましたが、成功しませんでした。MSDNで、NCryptSecretAgreement関数が、秘密の合意値を表すハンドルを受け取るNCRYPT_SECRET_HANDLE変数へのポインターを設定していることがわかりました。私はWinAPIにまったく慣れていないので、ドキュメントを読む以外に何もできません。

WindowsベースのデスクトップアプリとWebアプリの間でキーを交換する必要があります。私が知る必要があるのは、CNGのKDFが秘密合意値をどのように正確に使用するか（私の場合はハッシュ）です。SHA-256アルゴリズムをKDFとして使用し、秘密合意のXとYをハッシュしようとしていますが、結果がCNGで計算されたものと一致しません。何か案は？

ありがとうございました。

2 つのソフトウェア コンポーネント (Alice と Bob) 間で Diffie-Hellman 鍵交換を実行するために、bouncycastle を使用したいと考えています。Alice と Bob は、同じ CA から発行された独自のキー ペアを持っています。ただし、Alice は Java になり、Bob は C# になります。

各言語で交換を実行する方法の例を検索して見つけました。しかし、私が見つけた例には2つの問題があります:

1. 例は、サンプル コードの同じブロックで Alice と Bob 間の交換を実装することで単純化しすぎています。SSL ストリームを介して実際に中間値 (g^a mod p と g^b mod p) を交換する必要がある場合、Alice と Bob がどのように見えるかを理解するのに苦労しています。
2. 例は、常に同じ言語で記述されたソフトウェア コンポーネント用です。Diffie-Hellman 鍵交換ライブラリは、中間値を生成するためにいくつかの内部定数を使用することがよくあることを他の場所で読みました。DH がどのように機能するかについての私の知識に基づいて、どのような種類の定数が必要になるかはわかりませんが、私は専門家ではありません。

これら 2 つの問題に基づいて、2 つの質問があります。

1. 両側のコードを別々に示すコード例を知っている人はいますか?
2. java コンポーネントと .net コンポーネントの両方に bouncycastle API を使用する場合、コンポーネントが同じ秘密対称鍵に同意できない理由を誰か知っていますか?

私はPythonでRC4とDHキー交換を実装しようとしています。問題は、Python long/intをキー交換からRC4実装に必要なバイト配列に変換する方法がわからないことです。longを必要な長さのバイト配列に変換する簡単な方法はありますか？

更新：私が扱っている数値は768ビットの符号なし整数であることを忘れてしまいました。

これは、別の質問からすべての回避策を見つける前と同じように、ここでの最初の質問です。

質問は非常に短いです: iOS 用の Diffie-Hellman 実装があるかどうか知っている人はいますか? つまり...アイデアは、2つのデバイス（1つはiOSで、もう1つはJava Webサービス）間で秘密鍵を共有することであり、最良のアイデアはその方法であるべきだと思います。

そうでない場合、誰かが私に別のオプションを提案できますか?

私は高度な開発者ではないため、このためのフレームワークを確認しようとしています。

よろしくお願いします！