アイデンティティベースの暗号化とオープンソース

Question

私は最近、アイデアベースの暗号化（IBE）の考え方に賛成しました。しかし、私はそれを打破する方法を見つけようとしている暗号学のコミュニティの多くに気づいていません。私が間違っている？

同様に、私は、ブラックホールの群衆が攻撃できるオープンソースの実装を実際に配布できない限り、メリットがない可能性があると私は信じていますか？

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

（編集：ここWikipedia articleは、IDベースの暗号化にあります）

Answer 1

私はあなたが尋ねようとしていることは明確ではないので、私はいくつかのことを作り上げて答えようと思います。私が暖かくなったら教えてください

最初に、「IDベースの暗号化」は、キー管理スキームほどの暗号化スキームではありません。公開/非公開、または技術的に "非対称"な暗号化には、2つの鍵があります。そのうちの1つは、暗号化に使用され、1つは解読され、他のものを構築するには指数関数的に難しい（または指数関数的に難しいと考えられる）特殊な性質があります。だから、私は私の秘密鍵を使ってあなたに手紙を暗号化することができます。私は自分の公開鍵を公開する。公開鍵を使って手紙を解読することができれば、本当にそれを送った者であるという保証があります。これはデジタル署名方式の中核的なアイデアです。

問題は、これらの鍵を生成および管理する方法が必要であり、秘密鍵の保護と同じくらいスキームが良いため、難しいことが分かります。これを行うにはいくつかの方法があります。

IDベースの暗号化では、既知の公開情報（秘密鍵を構成する秘密鍵：電子メールアドレスなど）を構成する特別なアルゴリズムを提案することで、このkey management問題を簡素化しようとします。プライベートサイドを把握することが難しいようにこれを行うには、彼らが知っている他の秘密に基づいてプライベートキーを構築する信頼できるエンティティを持つ必要があります。あなたのメールアドレスを知っている人とあなたのコミュニケーションを確立する。信頼できるプロバイダにアクセスして、秘密鍵の生成を要求します。通信する相手は、使用しているプロバイダーを知っていて、マスター公開鍵をそのプロバイダーから取得します。

あなたが送信したい人は、プロバイダーからのいくつかのマスターキー情報以外のことを知らずにIDからパブリックサイドを生成できます。キーは決して方向を伝えません。

つまり、次のようになります。アリスは暗号化されたボブに電子メールを送信します。彼らはどちらもプロバイダーを信頼しています。

• アリスは自分のメールアドレス「alice @ example」でトムにリクエストを送信します。COM」、とは、対応する公開鍵Pがあります。秘密鍵Pを取り戻すが、トムは誰にもそれを送信しません。
• ボブはトムにリクエストを送信し、トムのマスター公衆を取得しますキーメートル。
• アリスは、{「X」}をPを与え、自分の秘密鍵を用いて彼女のメッセージ「X」を暗号化する。（つまり表記は単に「メッセージ 『X』 『ラップ』またはキーPと暗号化されています。）アリスはそのメッセージをボブに送信します。
• ボンはアリスの電子メールアドレスとトムのマスターキーmの知識を使用して計算します。 p = f（ "alice@example.com"、m）。今度は彼は解読解読（{"x"）P、p}を適用し、poofはアリスのメッセージになります。

これらのスキームの主な点は、いくつかの重要な管理上の問題を簡素化することです。あなたはまだ鍵を生成する必要があります。さらに悪いことに、は本当にです。Tomはすべてを知っているから、自分の秘密鍵を生成して暗号化することができます。これが意味するのは、固有のキーエスクロースキームを作成するということです。秘密鍵を見つけることができます。

これはいくつかの点で優れています。キーの紛失の問題を処理します。しかし、ほとんどの理由から、人々は暗号化を使いたいと思うので、それは悪いことです。誰かがトムを召喚したり、ただ殴ったりしてプライベートデータを入手することができます。

その結果、IDベースの暗号化だけでは気の利いたアイデアはありますが、市場はあまりありません。

Answer 2

あなたは心を持っている特定の方式はありますか？ 「アイデンティティベースの暗号化」はかなり広義です。

しかし、いずれにしても、それはそれ自体特別な暗号ではないので、あまり注目されていない可能性があります。暗号化キーには何ビットのエントロピーが存在するかなど、暗号の一般原則は適用されますか？本質的に無期限に同じ鍵が使用される場合、平文/暗号文を大量に持つことに基づいて、衝突攻撃やその他の攻撃のリスクは何か？

Answer 3

チャーリーは正しいトラックですが、私はいくつかの点を強調したいと思います。 IBEは、暗号化アプローチよりも鍵管理スキームであり、鍵管理に対するアプローチは、その敷物の下で重要な問題を掃除します。アイデンティティを基盤にしようとすると、ネット上であろうと物理的な世界であろうと、電子アプリケーションでアイデンティティを検証するための本当に良い解決策を誰も持っていないので、問題があります。アイデンティティへの良い解決策がなければ、これらのIBEスキームは、あなたが依存しているアイデンティティを強調すると、直面します。

ほとんどのIBEシステムは、技術的な詳細を見たことがありますが、実際にそれを気にかけていると、実際のセキュリティを提供していない、「信頼するプロバイダー」に本当に譲渡されました。プロバイダはネットワーク上でアイデンティティを確立しようと努力し、次にすべての人のために暗号鍵を保持している信頼できる第三者として行動します。信頼できる第三者に依拠することには、多くの既知の弱点があります。

現代の暗号化はすべて、第三者に頼る必要がない方法を探し出すことです。 Web of trustは1つのアプローチですが、主な欠点はエンドユーザーに重要な管理を委ね、キー管理は高価です。証明書の発行者に依拠することも別のアプローチですが、発行者が信頼できる第三者であることは明らかです。数年前、すべてのブラウザが信頼する主要な問題の1つは、明らかに信頼できないプレイヤーによって倒産され、破産から買収されたため、そのスキームの弱点は証明書チェーンの根源にあることが明らかになりました。

Answer 4

オープンソースプロジェクトでは、アイデンティティベースの暗号化は難しいでしょう。特に自由のような自由ではなく、ビールのような自由です。前述したように、システム全体は信頼できる第三者に依頼して鍵を発行する。ハードウェアとソフトウェアの両方で、購入と保守に高価なインフラストラクチャが必要です。さらに、鍵発行を行っている当事者に多くの責任を課しています。システムを使用する人は、問題が起こったときに発行者が責任を負うことを期待します。この種の責任は安価ではなく、オープンソースプロジェクトが引き継ぐことはしばしば不可能です。

Answer 5

お試しit良いと簡単な解決策。