【研究】Tracing malicious proxies in proxy Re-Encryption (Libert, Vergnaud) [Pairing '08]

Proxy encryptionの新しい方式の話．
Aさん向けの暗号文でも，Aさんのproxyサーバを通すと別の人でも復号できるような方式がProxy encryption．


今回は，CPA安全であるものの，tracability付きを実現．
traceabilityは，proxyでmallicious（Aが許可していない相手が復号できるようにRe-encryptする）なものが存在した場合，どれがmalliciousであるのか追跡可能という意味．


すばらしいことに，敵が
i　方式に従ってユニークなidをmallicious proxyに与える
ii　方式に従ったKeygenをしてくれる
場合にのみ，Traceabilityが言える．


non-blackboxとは言え，この条件って妥当なのだろうか？
論文中ではGeneric group modelで妥当であるという話をしているらしいが…本当？

【研究】Security and Composition of Cryptographic Protocols: A Tutorial (R.Canetti)

追記していく

UCの概念を直感的に学んでみましょうよ、という論文（配布資料と言った方が正しい？）
時折証明を織り交ぜつつ、しかし大体は概念の説明。
まずは簡単にtwo-partyでnon-reactiveなプロトコルがstand-aloneで実行されている場合を考えましょう、次にmulti-party・reactiveに拡張しましょう、non-concurrentに対してcomposableな形にしましょう、concurrentな結合にも安全にしましょう…


正直言って理解できてない気がする。




motivation:
大きいプロトコルの安全性をモジュールの安全性に帰着させたい。
この性質、この性質…とやっていくと色々矛盾が生じる。
→まず安全性の定式化としてtrusted party paradigmを使ってみたらどうか？
「プロトコル\pi（実際に動かすプロトコル）に対して\cal Aを使って攻撃して得られる情報」\approx「理想機能\cal F（理想機能なので必要以上の情報は漏れない）に対して\cal S（自分の机の上みたいなもの）を使って攻撃して得られる情報」




multi-party,reactive,uncomposable:
ごく少数のITIから構成（ぶっちゃけinitial ITI\cal Eだけいい）。
identity tapeの導入・invocation命令の追加により、ITIを増やしていく。その際ユニークなIDを付与する。
→数え上げがいらず、unbounded number ITIsも可能

【研究】Attribute-based Encryption with Partially Hidden Ciphertext Policies (西出,米山,太田) [ISEC'07]

Attribute-Based：暗号文を、特定の属性（attribute）を持つ参加者が復号できる方式。


これまでいくつか見たものは、
ユーザーの秘密鍵に復号することのできる属性（access policy）を埋め込んでいた。
ゆえに、例えば部門A向けの暗号文と部門B向けの暗号文を復号するためには、ユーザが2つの秘密鍵を持つ必要があった（tree構造を使えば少しは改善するだろうが）。


今回は秘密鍵にユーザ自身の属性を、暗号文に復号することのできる属性を埋め込んだ。
ゆえに1ユーザに1鍵で、暗号化するときに「こいつらにだけ復号させよう」とかできるようになった。
普通はこういう発想になると思うんだが。


方式自体の発想は、
特定の属性の復号条件を１，０，＊（どちらでもいい）とする。
例えば参加者のある属性が１だったとすると、鍵に「１で復号できるもの」と「＊で復号できるもの」を渡す。
…くらい？ｗ
非常にナチュラルな発想だと思います。
ゆえに、工夫するところが多そうな気も。というか、冗長性が大きすぎる気がするのだが、どうにかして少なくはできないのだろうか？

【研究】A Framework for Efficient and Composable Oblivious Transfer (Peikert,Vaikuntanathan,Waters) [CRYPTO'08]

UC安全（adaptiveではない、つまりadversatyはadaptiveにcorruptすることはない）なOTをCRSモデルで構成。
UC安全であり、round optimalであり、computationが（比較的）少ないというところがcryptoに通った理由なのだろうか？
これまでUC安全なOTはtwo-partyしかないから非効率だった、てことかな。


方式自体はCRSにtrapdoorを埋め込むのは普通。
dual-mode cryptosystem（以下dm）というOTのabstractionを定義している。
まぁぶっちゃけそのままOTだが…ｗ


UC安全なtwo-party protocolだから、simulaterSは色々相反することができる必要がある。
・senderがcorruptされたら、A（Z）が作った暗号文は両方ともdecryptできる。
・receiverがcorruptされたら、A（Z）は復号できないメッセージ情報を失う。


dmは、crsの確率分布が2種類存在して、
それを証明の際に上手く使い分けてreceiverかsenderのどちらかにunconditionalな安全性を保証している。
dmはDDH、QR、lattice関係の3つのassumptionから構成できる、と。


なんでしょね、今回のポイントは。
両方ともcomputationalでいいならadaptive Aに対しても安全性言えそうな気がするんですが。


あと毎回疑問に思うんだが、今回のF_otを例にとると、
記述ではまずsenderが（x_0、x_1）を送って、その後receiverが（b∈{0,1}）を送りx_bを得る。
この順番で記述されているんだが、それだとどうしても証明に納得がいかない。
先にreceiverがbを決めてもいいんではないかい？
ていうか、今回のとかまさにそうだし。receiverはbを決めてpkを作成し、senderに送るわけだから。
だからF_otの記述はおかしいと思うのだが、さすがにcryptoにacceptされたペーパーと俺の頭脳では分が悪すぎるｗ
誰か教えてくれないかなぁ。

【研究】One the Generic Construction of Identity Based Signatures with Additional Properties (Galindo, Herranz, Kiltz) [ASIACRYPTO'06]

PKI Sig + PKI Sig　→　ID Sigという結果がbellare et.al. EURO'04だったわけだが、それを
+ PKI Blind Sig　→　ID Blind Sig,
+ PKI Proxy Sig　→　ID Proxy Sig…が今回の成果？

発想をIDBlindSigを例に簡単に記述すると、
IDとPKIの違いであるExtractの部分をどうにかしなくてはならない。
なぜなら、ここがちゃんとした入力であることが保障されれば、
後はvalidな入力でPKIBlindSigを走らせることができるから（IDBlindSigのblindnessとPKIBlindSigのblindnessが等価になる）

そのために、IDSigのExtractで返すsk[ID]の中にBlindSigの鍵を「PKISigで署名して」送る。ポイント。
ゆえにvalidな値でプロトコルが走ることが保障されると。
こんな感じかな。

【サーバ】apacheのインストール

なぜか必要になったapacheのインストール。

aptitude install apache2-mpm-prefork

apache2-mpm-workerはphpの実装がなんかややこしいらしいのでこっちで。
workerの方が、1つのプロセス上で多くのリクエストに応えることができる→プロセスが少なくてすむらしい。
ということは、サーバ上に多量のアクセスがあることが見込まれる場合は、workerの本領発揮といったところだろう。
とはいえ自宅で細々とやるサーバにそんなアクセスはあるわけないので…


apache2-defaultのhtmlが変わっていた。
昔の、「あなたの予想に反して〜」ではなく、シンプルに「It works!」と出てきた。
確かにこんなんで十分だよねぇｗ


依然使っていた…違うな、ちょっと作成してみたhtmlファイルを/var/www/に移動。
次に/etc/apache2/apache2.confをいじる。


        Options FollowSymLinks MultiViews    # Indexesを削除してディレクトリが表示されないようにする
        AllowOverride None
        Order allow,deny
        allow from all
        # This directive allows us to have apache2's default start page
        # in /apache2-default/, but still have / go to the right place
#       RedirectMatch ^/$ /apache2-default/   # 自動的にデフォルトのhtmlに飛ばないようにする


残りの設定は、大元のapache2.confはいじらず、conf.d/localというファイルを作ってそこに書く。
conf.dディレクトリは実行時にincludeされる。

【サーバ】nptdの設定　sysv-rc-confの導入

9時間ずれてるとかネタだろう。

aptitude install ntp-simple

デフォルトでntpサーバはpool.ntp.orgとなっている。
これは、いくつかのntpサーバからランダムに選ばれるようになっている。
しかしネットワーク的に遠いサーバが選ばれるのもアレだし、プロバイダでntpサーバあるみたいだからそれを使ってみる。
/etc/ntpd.confにてserver行を追加すればいいだけだが。




sysv-rc-confをインストール。
起動時に自動実行されるスクリプトの管理が超簡単にできる。
いちいちrc内をいじっていた昔の俺は一体…

aptitude install sysv-rc-conf