問題タブ [public-key-encryption]

一方は他方よりも安全ですか?

64 ビットの公開鍵と秘密鍵のペアを生成する必要がありますが、標準のアルゴリズムが見つかりません。

データがデバイスにプリロードされている特定のデバイスから誰でも読み取ることができるデータを作成する必要がある状況がありますが、誰もが独自のデバイスを作成して独自のデータを入力できるようにすることはできません同じフォーマット。

これは少しクレイジーに聞こえるかもしれませんが、正当な理由があります。

公開鍵暗号方式を使用してデータを公開鍵で暗号化することを計画していましたが、データを読み取りたい人には秘密鍵を公開しました。

ただし、RSACryptoServiceProvider とその仕組みを調べたところ、秘密鍵を使用して公開鍵を作成できるため、秘密鍵を公開することはできないようです。

誰かがその疑いを確認したり、どうすればこれを機能させることができるかについてのヒントを教えてくれませんか!

どうもありがとう。

クライアントが私のサーバーにライセンスを要求し、ライセンスを持つことが許可されている場合はライセンスを送信するときに、ライセンス システムを作成しています。

現在のシステムでは、単一の秘密鍵を使用してライセンスを暗号化し、ライセンスの復号化に使用するクライアント アプリケーションに公開鍵を埋め込んでいます。できます！

サーバー上で公開鍵を使用して暗号化し、秘密鍵をクライアントに配布する必要があると言う人もいます。Web を検索したところ、秘密鍵を使用して暗号化する場合もあれば、公開鍵を使用して暗号化する場合もあります。

この場合、どうすればいいですか？

プロダクトキーを生成して検証する必要があり、公開/秘密キーシステムの使用を検討しています。

に基づいてプロダクトキーを生成します

• クライアント名（可変長の文字列の場合もあります）
• 6桁のシリアル番号。

プロダクトキーが扱いやすい長さ（16文字程度）であるとよいでしょう

ベースでそれらを暗号化してから、復号化/検証システムを分散させる必要があります。私たちのシステムはマネージコード（.NET）で記述されているため、暗号化システムを配布するのではなく、復号化のみを配布します。公開秘密鍵が必要です。これを行うには良い方法のようです。保持している1つの鍵で暗号化し、復号化/検証に必要なもう1つの鍵を配布します。

上記の要件でこれを行うための適切なメカニズムは何ですか？

注：著作権侵害を止めることではありません。これは、初心者ユーザーが不要な/使用を許可されていないコンポーネントをインストールする可能性を減らすためです。

Here are my constants

I have made two public / private keys like this:

I am decrypting like this:

This works with small amounts of data, when when the data becomes larger such as 263 bytes if fails with an IllegalBlockSizeException. I thinks this is because the data is greater than 256 bytes but that is just an guess and I have no idea of how to fix it.

What am I doing wrong?

I changed it to use the update method, but still have the same problem:

I am trying to implement digital signatures by the way. The client has the public key and the server has the private key.

私は病院で働いており、保険がその義務を支払った後、サービスが提供される前に、サービスに対する患者の総経済的責任を見積もる方法を開発しました. 多くの患者が見積もりを求めており、私は患者の要求に応じてそれらの結果を電子メールで送信する安全な方法を見つけたいと考えていました.

生成された見積もりからすべての患者情報を削除することを検討しているため、セキュリティ上の懸念はありませんが、電子メールを暗号化して送信し、患者の電子メール クライアントが電子メールを復号化できるようにする方法を見つけたいと考えています。

セキュリティ証明書の使用方法がわかりませんが、証明書のインターネット向けホスティングへのアクセスを許可するには、企業の面倒な手続きを踏まなければならないにもかかわらず、セキュリティ証明書が最善の選択肢かもしれません。電子メール以外のすべてのアプリケーションは病院です。サイドのみ。

また、生成されたレターから PDF を作成し、PDF を暗号化して、ソーシャルの最後の 4 つ、または見積もり生成プロセス中に共有されたその他の個人情報をパスワードとして割り当てることも検討しています。

公開鍵暗号について私が読んだ説明では、2 つの非常に大きな素数を掛け合わせることで大きな数が得られると言われています。大きな素数の積を因数分解することは、ほとんど不可能なほど時間がかかるため、安全です。

これは、レインボー テーブルで簡単に解決できる問題のようです。使用される素数のおおよそのサイズが分かっていて、それらが 2 つあることがわかっている場合は、すぐにレインボー テーブルを作成できます。それは非常に大きなテーブルになりますが、それは実行でき、タスクはハードウェア全体で並列化できます。

レインボー テーブルが、大きな素数の乗算に基づいて公開鍵暗号を打ち負かす効果的な方法ではないのはなぜですか?

免責事項: 明らかに、何万人ものクレイジーでスマートなセキュリティ意識の高い人々が、私が午後に考えたことを何十年も見逃していたわけではありません。単純化された素人の説明を読んでいたため（例：2つ以上の数字が使用されている場合）、これを誤解していると思いますが、知識のギャップがどこにあるかを知るにはまだ十分に知りません.

編集: 「レインボー テーブル」がルックアップ テーブルで事前に計算されたハッシュを使用することに関連していることは知っていますが、上記はレインボー テーブル攻撃のように聞こえるため、ここではこの用語を使用しています。

編集 2:回答で述べたように、すべての素数だけを保存する方法はなく、すべての積を保存する方法はありません。

• このサイトによると、512 ビットの素数は、((2^511) * 1) / (512 log(2)) = 4.35 × 10 ¹⁵¹ほど多く存在します。
• 太陽の質量は 2 × 10 ³⁰ kg または 2 × 10 ³³ g
• これは、太陽 1 グラムあたり2.17 × 10 ^{124個の素数です。}
• 数量 キロバイトに収まる 512 ビットの数値: 1 kb = 1024 バイト = 8192 ビット / 512 = 16
• これは 1 テラバイトに収まります: 16*1024*1024*1024 = 1.72 × 10 ¹⁰
• ペタバイト: 16*1024*1024*1024*1024 = 1.72 × 10 ¹³
  
• エクサバイト: 16*1024*1024*1024*1024*1024 = 1.72 × 10 ¹⁶

1 エクサバイトが 1 グラムの重さであったとしても、これらすべての数値を太陽の質量のハード ドライブに収めるのに必要な2.17 × 10 ^{124にはほど遠いです。}

公開鍵を使用して 100KB のファイルを暗号化する必要があります。公開鍵を使用して大きなファイルを直接暗号化することは実用的ではなく、対称鍵を使用してファイルを暗号化し、次に公開鍵を使用してこの対称鍵を暗号化することが推奨される方法であると主張するいくつかの投稿を読んでいます。単純な解決策は、大きなファイルをバラバラに分割し、同じ公開鍵を使用してそれぞれを暗号化することです。私の質問は、この解決策が間違っているかどうか、またその理由は何ですか?

最初の注意：これは個人的ないじくり回しプロジェクトのためだけのものです。私はここでエンタープライズセキュリティを書いているのではありません。もしそうなら、私は自分のスキームを書こうとするよりもよく知っているでしょう。:-D

編集：上記の点を強調するために、これを「iKnowThisWouldBeABadIdeaInRealLife」でタグ付けしようとしましたが、25文字を超えていたためSOは受け入れませんでした。私はそれが商用グレードではないことを知っていることに注意してください！

HTTP経由でユーザーを認証する方法が必要です（この場合はHTTPSを使用できません）。私は、相手が本当に彼らが言っている人であるということを知る必要があります（ある程度の自信を持って）。ユーザーが正当であると確信したら、クライアントとサーバー間のコンテンツがプレーンテキストとして送信されるかどうかは気にしません。

私が見ている問題は、パスワードをプレーンテキストとして送信せずにクライアントからサーバーに送信しようとすることです。一部のGoogle検索で見栄えの良いライブラリが見つかったため、JavaScriptで公開鍵暗号を試すことを考えました。

これが私が考えているスキームです：

（ AとA'がそれぞれ秘密鍵と公開鍵を表すと仮定します。また、 enc（text、key）とdec（cyphertext、key）が暗号化/復号化機能を表します）

これに見られる弱点の1つは、交換を聞いていたBAD GUYが、Aを持っていないのに、既知の暗号文/平文の組み合わせを持っていることです。これは、暗号クラスから覚えているBADIDEAです。塩漬けでこれをなんとか軽減できると思いますか？

だからここに私の[2]の質問があります：

1. これは「良い」スキームですか？（この最初の交換に続くものが平文であるかどうかは気にしないことを忘れないでください-私はここで最初の身元を確認しようとしているだけです）
2. 上記の「既知の平文/暗号文のペア」の弱点を回避するための最良の方法は何でしょうか？塩漬け？

ありがとう！

編集： すべての議論に感謝します！明確にするために：

• 私は、サーバーが彼らの言うとおりの人物であることをクライアントに保証することについて心配していません。反対のみ（サーバーにクライアントが彼らの言うとおりの人物であることを保証する）
• 私はMITM攻撃について知っています。このスキームは、それらから保護することを目的としたものではありません。
• 私はこれに対する解決策がすでにたくさんあることを知っています。これは純粋に私にとっての学習演習です！私は車輪の再発明やより良いネズミ捕りを作ろうとはしていません。これはただの楽しみです！

• このスキームに対する私の思考プロセスは次のとおりです。（公開キーと秘密キーを適切に使用していないことはわかっていますが、しばらくお待ちください）

  • ボブはアリスに近づき、「ねえ、私はボブです」と言います。

  • アリスは、「わかりました。ボブの「秘密鍵」を知っています。本当にボブの場合は、暗号化したばかりのこの秘密メッセージ（ボブの秘密鍵を使用）を取得して、復号化してください。」

  • ボブは正しいメッセージで返信し、アリスは幸せです。