アカウント名:
パスワード:
一定のアルゴリズムで暗号化したデータに対して、暗号のまま四則演算やビット演算が行える技術ですね。数学的には平文と等価だけれども入力も出力も暗号のままで、処理している中間データや返却値を覗いても解読できず、サービス運営者や作業者は知る必要がない情報を知らずに済むというやつ。
ただ、どの方式も計算量が膨大で実用にならないまま何十年も経過していたような。
ゼロ知識証明と関連があるのかなちょっと似てそうな素人の印象
なるほどわからん。どうやってデバッグするんだろう...
# 組み込みでopenssl、期待通り動かないときのデバッグがしんどいんだよね...
処理プログラムの形式的証明で……みたいな理想論に理想論を重ねた世界に入っていきそう。
ルーチンがおかしいのか中身がおかしいのかわからんな。開発中は中身がわかってるモックデータ使うのだろうけど、本番環境などで予期していないデータがきておかしなことになってたとしても再現させられないのでは。
ネーミングが最高に良い
思うにDBテーブル構造を社外に晒した時点でもうダメwカラム一個にまとめてレコードにも状態シフト入れるくらいじゃないと全文検索どころか操作更新もままならないクソ仕様秘密にしたい深さ線引の問題なんだろうけど
>思うにDBテーブル構造を社外に晒した時点でもうダメw
そこら辺は、分析サービス用のレコード形式に、参加者が合わせればいいだけではないでしょうか。
最近のCPUには、コードやデータを暗号化したまま処理できる機能があるものが多い平文はCPUダイ内でのみ存在し、CPUダイの外では暗号化されたものしか存在しないDRAM上でももちろん暗号化されてる
そういった命令群を使えば(実装にバグやバックドアがなければ)、比較的容易にそういったことが可能では?
CPUで暗号化解除したら「暗号化したまま処理」してないからw大体、研究とサービス設計の区別もついてないし…w
f()が暗号化する関数とすれば、f(x+y)=f(x)+f(y)とかf(xy)=f(x)f(y)ってことでいいんだよね?もともとの代数構造を保存してしまう暗号化って、「ぐちゃぐちゃ度」が低くなって、そこが弱点になりがちなんじゃないのか?という疑問がわくけど、どうなんだろ?
ノー。f(x+y)=g(f(x),f(y))が正しい。安全性を落とさずに、足し算や掛け算以外のいろんなのに対してfやgを上手く作ってる。
言い方悪かった。f(x+1y)=f(x)+2f(y), +1 がもとの代数系の和で+2が暗号化した代数系の和。この和の計算は実際には複雑なものになっても、交換性とか、和の持っている性質は満たしているということでいいのかな?暗号強度への影響はどうなんだろ?
準同型暗号はCCA安全性を満たしません。攻撃者は、暗号文 f(x) を直接復号できなくても、代わりに f(x)+f(1) を復号して x+1 を求め、次に x=(x+1)-1 として、平文を求められてしまうからです。(準同型性のために f(x)+f(1) の復号結果が x+1 と等しくなってしまうのです. また、公開鍵暗号なので攻撃者は 1 の暗号文 f(1) を容易に計算できます。)(なぜ攻撃者は f(x)+f(1) を復号できるのか? これは、CCA安全性の定義では、そういう強い攻撃者を想定するからです。)
では、CCA安全性を満たさないと実用上どういう問題があるのか? ...すみません、私は専門家でないのでそこは分かりません。
RSAがf(xy)=f(x)f(y)満たしますねさて、弱点でしょうか
寡聞にてまったく存じませんでしたが、なんか、公開鍵暗号方式のときと同じ様に、意味はわかるが、実現可能?、そんなの不可能では?って感じの「夢の技術」ですね。
理屈の上では、暗号アルゴリズムと暗号鍵(あと平文)から、暗号化データ、「だけじゃなく」、暗号型加算プロシージャ、暗号型減算プロシージャ、比較、等々の暗号型プロシージャを生成すれば、できるって発想なんだろうけど。 比較プロシージャ( ==, 0x01, 0x02 ) #=> False そうなるよな 暗号型比較プロシージャ( ==, 0x01, 0x02 ) #=
追記 掛け算で例えたほうが、おもしろいかも。
算術プロシージャ( ✕, 0x01, 0x02) #=> 0x02 1✕2は2暗号型算術プロシージャ( ✕, 0x01, 0x02) #=> 0x20 1✕2は20倍やぞ!
AIと相性が良い部分があるのはわかるんだけど、時間データとかの時系列をどう担保するんだろう
そんなこともないみたいですよ。だいたいスクリプト言語での処理と同じくらいのスピードらしい。https://www.jstage.jst.go.jp/article/essfr/12/1/12_12/_article/-char/ja [jst.go.jp]
うーん。十分に遅い。
復号化、計算、暗号化、中間処理のデータの後始末の手間と比較しないと
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
秘密計算とは (スコア:5, 参考になる)
一定のアルゴリズムで暗号化したデータに対して、暗号のまま四則演算やビット演算が行える技術ですね。数学的には平文と等価だけれども入力も出力も暗号のままで、処理している中間データや返却値を覗いても解読できず、サービス運営者や作業者は知る必要がない情報を知らずに済むというやつ。
ただ、どの方式も計算量が膨大で実用にならないまま何十年も経過していたような。
Re: (スコア:0)
ゼロ知識証明と関連があるのかな
ちょっと似てそうな素人の印象
Re: (スコア:0)
なるほどわからん。どうやってデバッグするんだろう...
# 組み込みでopenssl、期待通り動かないときのデバッグがしんどいんだよね...
Re:秘密計算とは (スコア:2)
処理プログラムの形式的証明で……みたいな理想論に理想論を重ねた世界に入っていきそう。
Re: (スコア:0)
ルーチンがおかしいのか中身がおかしいのかわからんな。
開発中は中身がわかってるモックデータ使うのだろうけど、本番環境などで予期していないデータがきておかしなことになってたとしても再現させられないのでは。
Re: (スコア:0)
ネーミングが最高に良い
Re: (スコア:0)
思うにDBテーブル構造を社外に晒した時点でもうダメw
カラム一個にまとめてレコードにも状態シフト入れるくらいじゃないと
全文検索どころか操作更新もままならないクソ仕様
秘密にしたい深さ線引の問題なんだろうけど
Re: (スコア:0)
>思うにDBテーブル構造を社外に晒した時点でもうダメw
そこら辺は、分析サービス用のレコード形式に、参加者が合わせればいいだけではないでしょうか。
Re: (スコア:0)
最近のCPUには、コードやデータを暗号化したまま処理できる機能があるものが多い
平文はCPUダイ内でのみ存在し、CPUダイの外では暗号化されたものしか存在しない
DRAM上でももちろん暗号化されてる
そういった命令群を使えば(実装にバグやバックドアがなければ)、
比較的容易にそういったことが可能では?
Re: (スコア:0)
CPUで暗号化解除したら「暗号化したまま処理」してないからw
大体、研究とサービス設計の区別もついてないし…w
Re: (スコア:0)
f()が暗号化する関数とすれば、f(x+y)=f(x)+f(y)とかf(xy)=f(x)f(y)ってことでいいんだよね?もともとの代数構造を保存してしまう暗号化って、「ぐちゃぐちゃ度」が低くなって、そこが弱点になりがちなんじゃないのか?という疑問がわくけど、どうなんだろ?
Re:秘密計算とは (スコア:1)
ノー。f(x+y)=g(f(x),f(y))が正しい。安全性を落とさずに、足し算や掛け算以外のいろんなのに対してfやgを上手く作ってる。
Re: (スコア:0)
言い方悪かった。f(x+1y)=f(x)+2f(y), +1 がもとの代数系の和で+2が暗号化した代数系の和。この和の計算は実際には複雑なものになっても、交換性とか、和の持っている性質は満たしているということでいいのかな?暗号強度への影響はどうなんだろ?
Re: (スコア:0)
準同型暗号はCCA安全性を満たしません。
攻撃者は、暗号文 f(x) を直接復号できなくても、代わりに f(x)+f(1) を復号して x+1 を求め、次に x=(x+1)-1 として、平文を求められてしまうからです。
(準同型性のために f(x)+f(1) の復号結果が x+1 と等しくなってしまうのです. また、公開鍵暗号なので攻撃者は 1 の暗号文 f(1) を容易に計算できます。)
(なぜ攻撃者は f(x)+f(1) を復号できるのか? これは、CCA安全性の定義では、そういう強い攻撃者を想定するからです。)
では、CCA安全性を満たさないと実用上どういう問題があるのか? ...すみません、私は専門家でないのでそこは分かりません。
Re: (スコア:0)
RSAがf(xy)=f(x)f(y)満たしますね
さて、弱点でしょうか
Re: (スコア:0)
寡聞にてまったく存じませんでしたが、
なんか、公開鍵暗号方式のときと同じ様に、意味はわかるが、実現可能?、そんなの不可能では?って感じの「夢の技術」ですね。
理屈の上では、暗号アルゴリズムと暗号鍵(あと平文)から、暗号化データ、「だけじゃなく」、暗号型加算プロシージャ、暗号型減算プロシージャ、比較、等々の暗号型プロシージャを生成すれば、できるって発想なんだろうけど。
比較プロシージャ( ==, 0x01, 0x02 ) #=> False そうなるよな
暗号型比較プロシージャ( ==, 0x01, 0x02 ) #=
Re: (スコア:0)
追記 掛け算で例えたほうが、おもしろいかも。
算術プロシージャ( ✕, 0x01, 0x02) #=> 0x02 1✕2は2
暗号型算術プロシージャ( ✕, 0x01, 0x02) #=> 0x20 1✕2は20倍やぞ!
Re: (スコア:0)
AIと相性が良い部分があるのはわかるんだけど、時間データとかの時系列をどう担保するんだろう
Re: (スコア:0)
そんなこともないみたいですよ。だいたいスクリプト言語での処理と同じくらいのスピードらしい。
https://www.jstage.jst.go.jp/article/essfr/12/1/12_12/_article/-char/ja [jst.go.jp]
Re: (スコア:0)
うーん。十分に遅い。
Re: (スコア:0)
復号化、計算、暗号化、中間処理のデータの後始末の手間と比較しないと