問題タブ [public-key-encryption]

私はコードを使ったチュートリアルを求めているのではなく、調査を行おうとしていますが、正しい質問をしていることを確認したいと考えています。

• .NET ですぐに使用できる暗号化の最適な形式は何ですか?
• 公開鍵/秘密鍵、これらをどこに安全に保管すればよいですか?
• これを適切に行うには、どのようなツールが必要ですか?

AESCryptoServiceProvider から始めて、渡した文字列を暗号化しました。満足しました。2回呼び出すと同じ値になることをテストしました。その後、何の形式のキーも提供していないことに気付き、アプリの 2 回目の実行で異なる結果が得られました。それで、私は読み始め、RSA公開/秘密鍵などを見ました。そして、私が行っている読みで正しい道を進んでいることを確認したいだけです。そこにはたくさんの例がありますが、これらのキーをどこに置くか、どこから取得するかについて言及しているものはほとんどありません.

以下のコードに記載されているように、メッセージを暗号化および復号化しようとしています。基本的に、公開鍵でメッセージを暗号化し、その暗号化されたメッセージをバイト配列から文字列に変換したいと思います。そして、この文字列を元のテキストに復号化します。これが両方の方法です。ここでは暗号化は正常に機能しますが、復号化は失敗します（エラーは「データはゼロで始まる必要があります」です）。暗号化されたバイト配列を文字列に変換するため、これが原因だと思います。

どうすればこれを解決できますか？（暗号化されたバイト配列を文字列として使用し、復号化に使用したい）他のアプローチはありますか（公開鍵と秘密鍵を使用）

BouncyCastleAPIがJavaの非対称暗号化に適しているかどうかを知りたいです。

現在、私はJavaのJCEAPIを使用してこれを行っています。非対称暗号化にBouncyCastleAPIを使用した場合、何か利点はありますか？

Wall-O-Textの受信について、あらかじめお詫び申し上げます。これは（少なくとも私にとっては）かなり複雑な問題であり、私はかなりのことを考えてきました。私の質問を読んだり、このGitHub GistでRubyのテスト実装（非常に急いで構築され、データベースにバックアップされておらず、おそらく非常に醜い）を見ることができます。

序章

次の要件を持つWebベースのパスワード管理システム（SSL経由！:)を作成する必要があると想像してください。

1. 個々のユーザーは、独自のパスフレーズを使用してシステムにサインインします。
2. このパスフレーズは、ユーザーがシステムを効果的に使用できるようにするために十分なものである必要があります（たとえば、スマートフォンなどから）。つまり、キーファイルを保持する必要はありません。
3. ユーザーは、任意の長さのデータをシステム（「エントリ」）に保存できます。
4. エントリは、暗号化されたエントリを読み取るのに十分な情報がデータベースまたはアプリケーションだけにないように、データベースで暗号化されます。
5. ユーザーは、他のユーザーがエントリの内容を読み取れるように、システムの他のユーザーとエントリを「共有」できる必要があります。

私は暗号化の専門家ではありません。しばらく考えてみたところ、次のことが思い浮かびました。 私の質問は：この実装は安全ですか？私は何かが足りないのですか？もしそうなら、上記の仕様は実装可能ですか？それともこれはやり過ぎですか？

データベース

データベースは次のように設定されます。

基本的なユースケース

システムの2人のユーザー、アリスとボブを想像してみましょう。

ボブはサイトにサインアップします：

• ボブはパスワードを入力します。このパスワードはサーバーに送信されます（ただし、保存されません）。
• サーバーはランダムなソルトを生成し、それをsaltフィールドに保存します。
• サーバーは、ボブのパスワードとソルトのSHA-256ハッシュを生成します。
• サーバーはRSAキーペアを生成します。公開鍵は、フィールドにプレーンテキストとして保存されpub_keyます。秘密鍵は、ボブのパスワードとソルトから生成されたハッシュを鍵として使用してAES-256を介して暗号化され、enc_priv_keyフィールドに保存されます。
• サーバーは、ボブのパスワードとソルトをキーとして使用して、ボブの秘密キーのハッシュベースのメッセージ認証コードを生成し、これをpriv_key_hmacフィールドに格納します。

ボブはシステムにエントリを保存します：

• ボブは、パスワードとともにエントリとして保存するデータを入力します。このデータはサーバーに送信されます。
• サーバーは、AES-256暗号化のキーとして使用されるキーを生成します。
• サーバーはこのキーを使用してデータを暗号化し、結果をenc_dataフィールドに保存します。
• サーバーは、生成されたキーを使用してデータのハッシュベースのメッセージ認証コードを生成し、これをdata_hmacフィールドに格納します。
• データの暗号化に使用される対称鍵は、ボブの公開鍵で暗号化され、enc_sym_keyフィールドに保存されます。
• サーバーはBobの秘密鍵を使用して、対称鍵の署名を生成します。

ボブは保存されたエントリを取得します。

• ボブは自分のパスワードと取得するエントリのIDを入力します。
• サーバーは、ボブのパスワードとソルトのSHA-256ハッシュを生成します。
• ボブの暗号化された秘密鍵は、ハッシュを使用したAES-256暗号化によって復号化されます。
• サーバーは、でHMACをチェックすることにより、ボブの暗号化された秘密鍵が改ざんされていないことを確認しpriv_key_hmacます。
• サーバーは、enc_sym_keyボブの秘密鍵を使用して、フィールドに格納されている対称鍵を復号化します。
• sym_key_signサーバーは、ボブの公開鍵を使用して署名を検証することにより、暗号化された対称鍵が改ざんされていないことを検証します。
• サーバーは、対称鍵を使用してデータを復号化します。
• サーバーは、フィールドに格納されているHMACを検証することにより、暗号化されたデータが改ざんされていないことを検証しdata_hmacます。
• サーバーは復号化されたデータをボブに返します。

ボブはアリスとエントリを共有します：

• ボブは、アリスが自分が所有するエントリにアクセスできるようにしたいと考えています。彼は自分のパスワードと共有するエントリのIDを入力します。
• エントリのデータは、「ボブが保存したエントリを取得する」の方法を使用して復号化されます。
• 次の例外を除いて、「ボブがシステムにエントリを格納する」と同じ方法で、アリスの新しいエントリが作成されます。
  1. エントリparent_entryはボブのエントリに設定されます。
  2. 対称鍵の署名は、ボブの秘密鍵を使用して計算されます（アリスの秘密鍵はボブが使用できないため）。
  3. アリスがこの新しいエントリにアクセスすると、null以外が存在する parent_entryと、システムはボブの公開鍵を使用して署名を検証します（彼の秘密鍵が署名の作成に使用されたため）。

ボブは共有エントリのデータを変更します：

• ボブは、アリスと共有したエントリのデータを変更することにしました。ボブは、変更するエントリIDとそれに含める必要のある新しいデータを示します。
• 「ボブはシステムにエントリを保存します」で作成されたデータを上書きします。
• parent_entryシステムは、変更されたばかりのエントリと等しいすべてのエントリを検索し、それぞれについて、「ボブはアリスとエントリを共有します」で作成されたデータを上書きします。

分析

利点：

• データを復号化するために必要な秘密鍵はユーザーのパスワードで暗号化され、そのパスワード（およびそのハッシュ）はに保存されないため、データを所有するユーザーのパスワードなしでデータベースからデータを復号化することはできません。データベース。
• ユーザーがパスワードを変更したい場合は、暗号化された秘密鍵のみを再生成する必要があります（古いパスワード/ハッシュで秘密鍵を復号化してから、新しいパスワード/ハッシュで再暗号化します）。
• 共有エントリは実際の個別のレコードとしてデータベースに保存されるため、複数のユーザー/ユーザーグループ間でキーを共有する必要はありません。

短所/問題（私が考えることができる）：

• 共有エントリが変更された場合、システムはすべての子エントリを再暗号化する必要があります。多数のユーザーがデータを共有している場合、これは計算コストが高くなる可能性があります。
• 共有エントリは、署名の検証のために親ユーザーの公開鍵に依存します。ユーザーが削除された場合、またはユーザーのキーが変更された場合、署名は無効になります。

はじめに繰り返します：私の質問は：この実装は安全ですか？私は何かが足りないのですか？もしそうなら、上記の仕様は実装可能ですか？それともこれはやり過ぎですか？

これだけ長く突き出してくれてありがとう。あなたの意見に興味があります！私は正しい方向に進んでいますか、それとも完全なモロンですか？あなたが決める！:)

AはメールにRSA暗号化を使用しています。Bは、Aへの暗号化された電子メールを見つけます。c= m ^ emodn彼はプレーンテキストを知りたいと思っています。Bは、Aが自分の電子メールに返信するときに、返信するメッセージのテキストを常に返信に含めることを知っています。

Aは、最大でlog nの長さのビット文字列であり、Znにマッピングできるメッセージのみを受信するとします。

また、Bがcを自分の電子メールとしてAに送信して返信を期待することはできないが、Aはc以外の電子メールメッセージに応答するとします。

Bは、c、e、n、およびZnからのランダムな値のみを使用してmをどのように学習できますか？

公開鍵を使用してサーバーをセットアップし、秘密鍵をputtyに追加すると、サーバーに正しく接続できるようになります。しかし、ページェントを使用すると機能しません。私の調査によると、ページェントが実行されているイベントログは次のようになります。

....
ページェントが実行されています。キーを要求しています。
PageantにはX個のSSH-2キーがあります
Pageantキー＃0を試して
います...。

ただし、私のイベントログは次のようになります

...
ページェントが実行されています。キーを要求しています。
..。

ページェントがパテの重要な要求に応答していないようです。これで助けていただければ幸いです。

ありがとう

サイトの URL へのアクセスを制限し、クライアント アプリケーションのみがこれらの URL にアクセスできるようにする方法を教えてください。URL をリクエストするための REST API を入れていますが、AWS S3 のように公開鍵/秘密鍵を使用できると考えていました。私の理解では、転送中にデータを保護するために SSL 証明書が必要です。

これは正しいアプローチのように思えますか? また、サーバー側でキーを生成する方法もわかりません。Railsとphpの両方でコーディングしています。

2 パーティの公開鍵暗号化は .net フレームワークで非常にうまくレイアウトされていますが、n パーティになることは私にとって大きな懸念事項です。たとえば、2 パーティの video-conf を保護します。コミュニケーションは非常に簡単です。

1) 各当事者は、セッション固有の RSA キー ペアを生成し、信頼できる機関 (つまり、信頼できるサーバー) によって署名された公開キーを取得します。2) 各関係者はこれを使用して鍵を交換しECDiffieHellmanCng、これで接続は本物で安全になります (Vista/W7 を使用していると考えてください)。

鍵交換アルゴリズムは 2 つの公開鍵のみから共有秘密を導出するように設計されているため (特に .NET と BouncyCastle を使用)、この通信に 3 番目の参加者を追加しても機能しません。そこで問題は、信頼性が高く (つまり、中間者攻撃に耐性があり)、安全な (つまり、盗聴から安全な) n パーティの公開鍵暗号化スキーマをどのように実装するかということです。

編集: 現在のアイデアは以下のとおりです。NBusy.Communicatorライブラリの一部として最も人気のあるものを実装します。

• 一方のパーティがフェデレーション サーバーとして機能する、2 パーティの通信スキームを使用します。
• 二者通信を開始し、一方の当事者が第三者を認証し、秘密/対称キーを共有できるようにします。
• Multi-Party Key Agreement スキームを使用します。

Edit2：ここで説明したものと同様の「n-Party Diffie Hellman」アルゴリズムを使用しますが、いくつかの変更があります：http://www.codeproject.com/KB/cs/diffy_helman.aspx

ウィキペディア（およびその他の情報源）によると、非対称暗号化は常に次のように機能します。

• パーティAには公開鍵と秘密鍵があります
• パーティBはAの公開鍵を使用して暗号化します
• パーティAは秘密鍵を使用してデータを復号化します

ただし、パーティAが自分のデータを暗号化できるようにしたくはなく、データを復号化できるようにしたいだけです。非対称ロジックを使用すると、次のようになります。

• パーティAには秘密鍵があります
• パーティBには秘密鍵（パーティAの公開鍵）があります
• パーティBは秘密鍵で暗号化します
• パーティAは秘密鍵を使用してデータを復号化します

これをある種のライセンス生成/チェックに使用します。クライアントはライセンスを生成しない場合がありますが、ライセンスファイルはクライアント側で読み取り可能である必要があります。

これはまだ非対称暗号化ですか、それとも別の方法を検討する必要がありますか？

ウェブサイトを構築しており、支払い方法は Google Checkout と Paypal になります。支払いを処理するための安全な Google/Paypal サイトにユーザーをリダイレクトするリンク/ボタンがあります。これは、サイトに SSL 証明書をインストールするための年間 150 ドルの追加費用と複雑さが必要ないことを意味します。

ただし、ユーザーがログインしているときにユーザーのパスワードを暗号化したいので、ネットワーク上にいる場合、FireSheep などを実行している悪意のある人物がサーバーに送信されているユーザーの実際のパスワードを読み取ることができません。サイトの残りの部分は、機密データではなく、おそらくユーザー エクスペリエンスが大幅に低下するため、暗号化は必要ありません。

私の考えでは、これは公開鍵暗号で実装できると思います。プロセスが次のようになるとしましょう。

1. 公開鍵は JavaScript 外部ファイルにあり、秘密鍵はサーバー上の PHP にあります
2. ユーザーはフォームにユーザー名とパスワードを入力し、送信をクリックします
3. JavaScript が実行されてパスワードが暗号化され、テキスト フィールドに保存されます。
4. フォームがサーバーに送信され、パスワードが PHP で復号化されます
5. PHP のプレーン テキスト パスワードはソルト化およびハッシュ化され、データベース内のハッシュと比較されます。
6. 登録/パスワード変更機能についても同様のプロセスが考えられます。

RSAのようなものがうまくいくと思います。しかし、それを行うために動作する JavaScript ライブラリをネットで探しましたが、利用可能な PHP ライブラリと互換性があるものはないようです。いずれにしても、JavaScript および PHP と互換性のある一連のキーを生成する必要があります。

これに対する実際の実用的な解決策を知っている人はいますか? そうでない場合は、作成してからオープンソースにしましょう。残念ながら、暗号化/復号化コードの記述は非常に複雑であるため、既存のライブラリが何を行っているのか、それらを変更して機能させる方法を正確には知りません。私はすでにセッション固定/ハイジャックに対する保護を持っているので、それには興味がありません。Webサーバーに到達する前にデータを暗号化することに興味があります.

注: スタンドアローンの Javascript または PHP 暗号化ライブラリへのリンクを大量に投稿しないでください。既に Google でそれらを見つけました。それは実際には役に立ちません。私が必要としているのは、JavaScript 暗号化と PHP 復号化のコードであり、実際に調和して連携して、上記で概説した意図した結果を生成します。

また、「SSL を使用するだけ」などのコメントの投稿を控えていただければ幸いです。ベストプラクティスでなくても、この正確な問題の解決策が実際に欲しいのですが、それでも興味深いでしょう。

どうもありがとう！