ID ベースの暗号化とオープンソース

Question

最近、ID ベースの暗号化 (IBE) という新しいアイデアのように思える概念に出会いました。しかし、暗号化コミュニティでそれを解読する方法を見つけようとしている人があまりいないことに私は気づきませんでした。私が間違っている？

同様に、私は、ブラックハット集団が攻撃できるオープンソース実装を実際に配布できない限り、メリットがないのではないかと考えています。

このアプローチを使用したコミュニティ全体の経験と、アプリケーションに組み込んで配布することがどれほど簡単かを理解したいと思いますか?

（編集：ここにあります ウィキペディアの記事 ID ベースの暗号化に基づいて。)

Answer 1

何を聞きたいのかよくわからないので、いくつか考えて答えてみます。暖かくなったら教えてください

まず、「ID ベースの暗号化」は実際には暗号化スキームではなく、キー管理スキームです。パブリック/プライベート (技術的には「非対称」) 暗号化には、2 つのキーがあります。そのうちの 1 つは暗号化に使用され、もう 1 つは復号化に使用されます。これらには、一方を知っていても、もう一方を構築するのが指数関数的に困難である (または指数関数的に難しいと考えられている) という特別な特性があります。したがって、たとえば、秘密鍵を使用してあなたへの手紙を暗号化できます。私は自分の公開鍵を公開します。公開鍵を使用して手紙を復号化できれば、本当に手紙を送ったのが私であるという確信が得られます。これはデジタル署名スキームの中核となる考え方です。

問題は、これらのキーを生成して管理する方法が必要であることですが、スキームの保護は秘密キーの保護と同じくらい優れているため、それが困難であることが判明しました。これを行うにはいくつかの方法があります。

ID ベースの暗号化はこれを簡素化しようとします。 キー管理 既知の公開情報から秘密鍵を構築する特別なアルゴリズムを提案することで、この問題を解決します。メールアドレスを言います。秘密側を理解するのが難しい方法でこれを行うには、知っている他の秘密に基づいて秘密キーを構築する信頼できるエンティティが必要です。したがって、あなたの電子メール アドレスを知っている誰かと通信を確立する必要があります。信頼できるプロバイダーにアクセスして、秘密キーの生成を依頼します。あなたが通信したい相手は、あなたが使用しているプロバイダーを知っており、 マスター公開鍵 そのプロバイダーから。

これで、送信先の相手は、プロバイダーからのマスター キー情報以外は何も知らなくても、あなたの ID から公開側を生成できるようになります。キーが方向に送信されることはありません。

つまり、次のようになります。アリスは、暗号化された電子メールをボブに送信したいと考えています。二人ともプロバイダーのトムを信頼しています。

• アリスは電子メール アドレス「alice@example.com」を使用してトムにリクエストを送信し、秘密鍵を返します。 P. 。対応する公開鍵があります p, 、 しかし トムはそれを誰にも送りません。
• ボブはトムにリクエストを送信し、トムの マスター公開鍵 メートル.
• アリスはメッセージ「x」を秘密鍵で暗号化し、{"x"} を与えます。P. 。(その表記は単なる「メッセージ "x" "ラップ" またはキーによる暗号化」です P.) 次に、アリスはそのメッセージをボブに送信します。
• ボンはアリスの電子メール アドレスとトムのマスター キーに関する知識を利用します。 メートル, 、そして計算します。 p=f("alice@example.com", メートル）。ここで、復号化 decrypt({"x")P, p) を適用すると、アリスのメッセージが出力されます。

これらのスキームの特徴は、いくつかの主要な管理問題を簡素化することですが、それはほんのわずかであるということです。それでもキーを生成する必要があり、さらに悪いことに、 本当に トムを信じてください、彼はすべてを知っているからです。彼はあなたの秘密キーを生成し、それを使って暗号化して、どんなメッセージもあなたから送信されたように見せることができます。これが意味するのは、固有のキー エスクロー スキームを作成するということです。あなたの秘密鍵が見つかる可能性があります。

これはある意味では良いことです。鍵の紛失の問題にも対応します。しかし、人々が暗号化を使用したいと思うほとんどの理由は、それが悪いことです。今、誰かがトムを召喚するか、彼を殴り、あなたの個人情報を入手することができます。

その結果、ID ベースの暗号化だけでは気の利いたアイデアですが、それほど多くの市場を獲得できませんでした。

Answer 2

チャーリーは、右のトラックにですが、私はいくつかの他の点を強調したいです。 （私のコメントは、チャーリーの答えの以前の、短いバージョンに基づいて書かれていた。）IBE暗号化へのアプローチよりも鍵管理方式であり、および鍵管理へのアプローチは、敷物の下で重要な問題を掃引します。誰もが電子申請では、どうか、ネット上または物理的な世界に身元を確認するには本当に良い解決策を持っていないため、基盤としてのアイデンティティを使用しようとすると、問題をはらんでいます。あなたは、彼らがに依存しているアイデンティティを強調したら、アイデンティティに良い解決策がなければ、これらのIBEスキームは、自分の顔の上に落ちています。

私は本当にスケールしないと、あなたが本当にそれを気にしたときに実際のセキュリティを提供していない、「プロバイダを信頼する」委譲についての技術的な詳細を見てきましたIBEシステムのほとんどを。プロバイダの努力ネットワーク上のアイデンティティを確立するために、その後、皆のための暗号化キーを保持している、信頼できる第三者として機能します。信頼できる第三者機関に依存することは多くの既知の弱点を持っています。

現代暗号はすべて第三者に頼る必要がないようにする方法を探しについてです。信頼のウェブは、主な欠点は、それがエンドユーザーに鍵の管理を離れ、鍵の管理が高価であるということである、1つのアプローチです。証明書発行者に頼ることの別のアプローチであるが、そこには、発行者が信頼できるサードパーティがあることは明らかです。数年前に、すべてのブラウザが信頼できる主要な課題の一つは、バストを行って、それが明確にそのスキームの弱点は、証明書チェーンのルートにあることを作り、明らかに信頼できなかったプレイヤーが破産の外に買いましたます。

Answer 3

アイデンティティベースの暗号化は、オープンソースプロジェクトで、特に自由のように単に無料ではないようなものはなく、ビールのように自由をやってのけるすることは困難です。前述したように、システム全体は、キーを発行する信頼できる第三者機関に依存しています。これは、それが購入し、維持するために高価であり、ハードとソフトの両方のために、インフラストラクチャをとります。さらに、それはキー発行をやっている党に責任の多くを置きます。システムを使用する人は、物事がうまくいかない（と彼らがする）際に発行者が責任を取ることを期待しています。責任のこの種は安くはない、と取るためのオープンソースプロジェクトのために、多くの場合、実行不可能である。

Answer 4

何か特別な計画を考えていますか？「ID ベースの暗号化」は非常に広範な用語です。

しかしいずれにせよ、暗号自体はそれほど特別なものではないため、あまり注目されていないのかもしれません。暗号化キーには何ビットのエントロピーが存在するかなど、暗号化の一般原則が引き続き適用されます。同じキーが実質的に無期限に使用される場合、衝突攻撃や、大量の平文/暗号文に基づくその他の攻撃のリスクは何ですか?

Answer 5

それをを試してみてください。善と簡単な解決策ます。