暗号理論コミュのBoneh Franklin IBE

公開鍵のy∈Gを送信者IDのハッシュH(ID)∈Gにしたら否認防止できるのではないでしょうか
つまりc1=r・H(ID)となり
暗号化鍵は送信者の秘密鍵s・H(ID)を用いて
e(H(A),s・H(ID))^r
となり
復号鍵は
e(s・H(A),r・H(ID))となるからです
みなさんのご見解を頂きたいと思います

コメント(20)

最初
全て
最新の40件

[1] mixiユーザー 10月31日 16:47

つまり単純な公開鍵方式では必要ないはずの送信者の鍵ペアを用意しろってことですか?

[2] mixiユーザー 10月31日 23:18

サントさん、コメントありがとうございます
公開鍵y=s・gの替わりに、送信者の秘密鍵s・H(ID)を使います
従って暗号文c1=r・gではなくc1=r・H(ID)になるといったものです

[3] mixiユーザー 11月01日 00:33

送信側、受信側の両方の鍵ペアを使用するという点では、現存の送信内容にディジタル署名を付加しておくという方法と効果は変わらないようですが、それに代替するだけの利点は何ですか？

[4] mixiユーザー 11月01日 09:24

メリットは公開鍵g,yが不要になることと第三者が暗号文を生成できないこと(秘密鍵をもたない者は暗号化できない)
デメリットは公開鍵がないので、第三者が暗号文を生成できないことです
否認防止と書いてしまいましたが、ディジタル署名なしに暗号だけでなりすまし防止を実現できるのでは？

[5] mixiユーザー 11月01日 14:59

いまいち式を理解していないので聞きますが、復号鍵の生成は暗号化鍵を基に生成するんですよね？
その場合受信側は通信相手一人につき一つの復号鍵、つまりｎ人の相手が相互に暗号通信するには
(n*n-1)/2個もの鍵が必要ってことですよね？

[6] mixiユーザー 11月01日 19:51

n人で相互に通信する場合
それぞれが自分の秘密鍵を持っていればよいので、
ｎ個の鍵で大丈夫と思います。

送信者A,受信者Bの例を示します。
以下、s∈Z/pZ r∈Z/pZ H1(x)∈G H2(x)∈G
H1(x),H2(x)はハッシュ関数です。

鍵生成者（センター）
?マスター鍵sを生成
?マスター鍵sとユーザAのIDから、ユーザAの秘密鍵PriAを生成
PriA=s･H1(A)
?マスター鍵sとユーザBのIDから、ユーザBの秘密鍵PriBを生成
PriB=s･H1(B)

送信者A
?送信用乱数rと送信対象であるBのIDから暗号文c1を生成
c1=r･H1(B)
?相手の秘密鍵と送信対象BのIDと送信用乱数rから暗号化鍵Dkを生成
Dk=H2(e(PriA,H1(B))^r)
=H2(e(s･H1(A),H1(B))^r)
=H2(e(H1(A),H1(B))^s･r)
?平文Mを暗号化して暗号文c2を生成
c2=M xor Dk
?暗号文c1,c2をBに送信

受信者B
?暗号文c1と自分の秘密鍵から復号鍵Ekを生成
Ek=H2(e(c1,PriB))
=H2(e(r･H1(A),s･H1(B)))
=H2(e(H1(A),H1(B))^s･r)
?暗号文c2を復号して平文Mを生成
M = c2 xor Ek

[7] mixiユーザー 11月01日 21:00

暗号時に生成する鍵は送信者の秘密鍵、受信者のID、あと乱数が必要なんですね
これだと普通の公開鍵暗号方式で、公開鍵がID（のハッシュ値）に成り代わっただけじゃないんですか?
受信者は公開鍵の変わりにIDとやらを公開しなければならないわけですし

しかも復号に必要な鍵の生成はセンターが行うということですから鍵預託問題も新たに発生しています

あと　e（）　ってなんですか？　exp（）　ではないですよね？

[8] mixiユーザー 11月02日 05:31

サントさん、毎度コメントありがとうございます。
このような議論ができて大変うれしいです。

まず前提が抜けていましたので、説明します。
公開鍵暗号であるBoneh Franklin IBE(Id Based Encryption)をベースにしています。
しかしここでは、公開鍵暗号として使うのではなく、非対称鍵暗号として使う方式の提案です。

IBEでは，秘密鍵生成センター(PKG)と呼ばれる信頼出来る１つの機関を考えます。鍵預託問題はおそらくIBEの根本的な問題なので、この議論は後でしたいと思います。

e()は、G1 × G1 → G2 の双線形写像です。
ここで、G1,G2 を大きな素数q を位数とする巡回群とし、G1 は加法的に、G2 は乗法的に表現します。

P,Q∈G1, a,b∈Z/Zq に対し,
e(aP,bQ) = e(P,Q)^(ab) == e(bP^aQ)が成り立ち、これはBilinear Diffie-Hellman(BDH) 問題に基づいて安全性が仮定されています。

[9] mixiユーザー 11月02日 09:46

IBEというのは初めて知りました
まだいくつか疑問があるのでお願いします

とりあえずですが鍵生成時の
PriA=s･H1(A)
の計算で、A自身が得られるであろうPriA、H1(A)からsを推定するのってのは難しいんですか?
簡易的に書いているだけであって、適切な関数があるのかもしれませんが、気になったので取り急ぎ

[10] mixiユーザー 11月02日 12:47

サントさん
質問の件ですが、離散対数問題に帰着するため、sを導く多項式アルゴリズムは知られておりません。

[11] mixiユーザー 11月02日 15:54

毎度回答ありがとうございます

段々分かってきてます

また質問ですが、この方式だと復号鍵の生成に送信者のIDが使われるから、暗号文を復号できたらそれは正しいID(送信者のID)を用いた鍵だからで、すなわちこの暗号文は送信者が間違いなく暗号化したってことになりますが、平文がバイナリ等の場合、正しく復号できたことを知ることはできない、つまり否認防止は完全にはできないんじゃないですか？

[12] mixiユーザー 11月02日 17:46

サントさん
そこはヘッダー等を付加すれば問題ないと思います
オーバーヘッドは増加しますが、全体に対する割合に留意して設計すればよいかと思います

[13] mixiユーザー 11月02日 22:03

携帯からですが、質問させて頂きます。宜しくお願いします。
PriA=s･H(ID)では、離散対数問題にならない様な気がするのですが。
y=g^xで、
公開情報　y,g
秘密情報　x
で、公開情報から秘密情報を出すのが離散対数問題だと思うのですが。
ペアリングを使われていますが、ここの計算は楕円曲線上ではなく、通常の演算でいいんですよね!?

[14] mixiユーザー 11月02日 22:26

そのヘッダー等として、どんな情報を付加するんですか?

[15] mixiユーザー 11月03日 09:08

教材屋さん
そこは楕円曲線上の離散対数問題に帰着すると思います
H(x)の値域は楕円曲線G上の点をとり、sはZ/Zpだったと思います

私も勉強中なので全部分かっているわけではありませんが、
こういったクエスチョンを頂くと色々と見えてきますので非常にありがたいです

サントさん
例えばヘッダーのフォーマットをファイル名、ファイルサイズ、作成日時で構成すれば、
ヘッダーとしてあり得ない形になっていないか等を調べることで
復号に失敗したかを調べることができると思います

[16] mixiユーザー 11月03日 16:55

>例えばヘッダーのフォーマットをファイル名、ファイルサイズ、作成日時で構成すれば、
>ヘッダーとしてあり得ない形になっていないか等を調べることで
>復号に失敗したかを調べることができると思います

それでも無理ですよ
そもそもこの理論の単純な暗号化・復号作業自体は相対鍵暗号でおこなっています
排他的論理和演算ですからね
つまり暗号は復号側（受信側）でも行えます
よって受信側は自分に都合のいい内容の暗号文を生成できてしまいます

たとえ鍵生成にIBEのセンターの認証が必要であっても根本的に送受信（暗号化・復号）両方の鍵が同一である以上第三者に対する証明は無理なんではないですか？

[17] mixiユーザー 11月03日 17:54

サントさん
なるほど、そうですね。
受信者側でいつでも鍵が作れるため、
あたかも送信者側で作ったような暗号文が作れるので、
否認防止にはならないということですね。

それでは、6番目のコメント（2008年11月01日 19:5）に間違いを発見しました。

＞?送信用乱数rと送信対象であるBのIDから暗号文c1を生成
＞c1=r･H1(B)

正しくは
「?送信用乱数rと自分のID(A)から暗号文c1を生成
　c1=r･H1(A) 」
です。

c1=r･H1(A)をc1=r･H1({A||秘密の情報})みたいな事で解決できないかなとふと思いました。（「||」は文字列の連結と思ってください）
しかし、こうすると
PriA||秘密の情報の作成と、受信者のPriBの選択に問題がでてきそうです。

IDベース暗号と否認防止の方法について、
もう少しいろいろと考えて見ます。

[18] mixiユーザー 11月03日 18:28

IBEに潜在的に鍵預託問題がある以上、否認防止は難しいと思います
その点も含めIBEはそもそもある程度信頼できるグループ間での使用を前提にしているのではないでしょうか
IBEは公開鍵暗号方式に比べて送信先の第三者証明が必要ないといっても、IDの公開は公開鍵暗号方式の公開鍵の公開以上に危険を持っていますし

あと秘密の情報を付加してもそれが秘密である以上、第三者どころか相手に対しても証明ができませんよ
これは対称鍵方式と非対称鍵方式の大きな違いなわけですし
もし佐々木さんがIDベースでも解決できたら、共通鍵暗号方式でも、この問題が解決できるのではないでしょうか？

[19] mixiユーザー 11月03日 20:05

サントさんの言うとおりですね。

IDベース暗号は魔法のステッキではないですしね。
沢山のコメントありがとうございました。
大変参考になりました。
これからも勉強をつづけます。

ログインすると、残り1件のコメントが見れるよ