■暗号技術【ROUNDsurea】■

**デフォルトの名無しさん** · 2007/05/28(月) 00:49:42

前スレ
■暗号技術【ROUND2】■
http://pc11.2ch.net/test/read.cgi/tech/1088530204/

擬似乱数
http://pc11.2ch.net/test/read.cgi/tech/1146071975/
暗号数学について語ろう。ROUND 3
http://science6.2ch.net/test/read.cgi/math/1170938965/
素数判定は「決定的」多項式時間で可能
http://science6.2ch.net/test/read.cgi/math/1028813059/
【疑似】乱数をつくる【本物】
http://science6.2ch.net/test/read.cgi/denki/1074867250/
ＲＳＡ暗号　解読　助けてください！！
http://pc11.2ch.net/test/read.cgi/sec/1026903337/

お前らって本当に自分じゃ何もしないよな。
前スレ>>990->>994
罰としてスレタイで辱めてやる

2012/04/04(水) 12:23:59.15

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/faq.html
> 出力列を8ワードごとに切って、ハッシュ関数で 1ワードに圧縮して使う

というようなこと書かれてはいますが、sha256 をアルゴリズムとして使うぶんには
MTが生成した乱数 256bit をハッシュ化して出力した 256bit
これを予測できない乱数として使っていいですよね

コード -> http://pastebin.com/Qjuwy7r3

2012/04/04(水) 13:08:33.86

念のために元乱数列を多めにしといた方がベターだとは思うけど、悪くはないでしょ。
あと用途によってはストレッチングも検討。

2012/04/04(水) 14:25:33.89

別に圧縮は必要ない。
なんとなく、暗号ハッシュ自体の目的のイメージから、なんとなく圧縮って言ってしまっただけに見える。
まあどっちでも別に問題はない。

2012/04/08(日) 17:41:48.19

PKCS#5って何のメリットがあるの？
これ使えばパスワードクラックに対して強くなるの？

2012/04/08(日) 21:19:51.19

うん。
ブルーとフォースや辞書攻撃などをオフラインで実行された場合に、圧倒的に強くできる。
パスワードハッシュにも使える、これを使うとパスワードデータベースの耐性も簡単に上げられる。

よくパスワードハッシュで、MD5やSHA1は危ないからSHA2を使わないとダメダメとか分かった風なことを言ってるのを見るが、
パスワードハッシュの用途ではSHA2使ってもそれほどは耐性は上がらないことを理解してない。
耐性を上げるにはPBKDF2を使う、これで比較にならないほど上げることが出来る。

2012/04/08(日) 23:45:33.20

計算回数増やせば強くなるが、saltは飾りです。

2012/04/09(月) 00:19:22.84

saltはテーブル化を防げればそれで十分役に立ってる。

2012/04/09(月) 19:45:50.80

ていうか、それ単に最初からストレッチングを前提に設計されてんじゃん。
比較対象としてなんか違う。

2012/04/09(月) 22:45:58.07

そりゃ耐パスワードクラックにはストレッチングこそ必要って話なんだから。
何が違うのかようわからん。

2012/04/09(月) 22:49:02.23

おかしいのは、パスワードハッシュの耐性とか、やたらうるさくこだわりながら、
単にハッシュを一回かけるだけとかで、やたら気にしてるのはハッシュ関数の種類だけ
みたいなの。
突っ込みたくもなるわ。

2012/04/10(火) 20:27:41.23

saltの意義はいくら調べても分かりません。
どの説明もバレない前提の説明ばかり。
しかし、実装レベルの説明ではバレてもいいみたいこと書いてる。

2012/04/10(火) 20:38:34.17

> バレない前提の説明

それが原理的に考えておかしい。

あらかじめ時間をかけて、大量にハッシュ値を計算しておく、という攻撃への対策として、
塩を混ぜてからハッシュ値を計算することで、情報を知ってからハッシュ値を計算しなければ
ならなくする、というのが目的なんだから、塩の秘匿（ないし公開）は、ハッシュ値の秘匿（ないし公開）と
同じ扱いでよい。

2012/04/10(火) 20:49:27.42

そういう理由なら反復回数の秘匿でハッシュ値の秘匿も達成されるじゃん。

2012/04/11(水) 05:33:30.00

saltはランダム値を使ってこそ意味がある。
平文aを1というsaltで暗号文bをつくり、bと1を送る。
しかし、また同じ平文aを送りたいとき、bと1を送れば、
盗聴されてる場合は解読はされてないが、同じ平文を送ったことがバレる。
しかし、平文aを2というsaltで暗号文cを作れば、同じ文を送ったかどうかはバレない。

2012/04/11(水) 09:40:48.58

>>434
それは確率的暗号方式
（鍵生成だけではなく、暗号化アルゴリズムも確率的アルゴリズムになっていて
たとえ同じ平文を暗号化しても毎回異なる暗号文になる）
の暗号化処理で使うランダムネスの話ですね

そういう目的で暗号化アルゴリズムへ入力する・アルゴリズム内で生成する
乱数やランダムネスをソルトと呼ぶことはあまりないと思う

てかパスワードハッシュのソルトの目的って>>472以外の何物でもないのに
バレない前提（ソルトがバレない限り安全ということ？）ってどういうこと？
>>431の読んだ参考書や解説が知りたい

2012/04/11(水) 09:47:17.77

>>435のレスアンカー間違えた
472じゃなくて>>427だ

そういやずっと前に
共通鍵メッセージ認証の鍵（当然送信者と受信者以外に明かしてはいけない）を
ソルトって呼んでたブログや技術文書がどっかにあったような・・・

2012/04/11(水) 11:35:24.53

>>435
暗号化処理で暗号化毎に使うランダム値もまあソルトって言う気がするけどな。
パスワードハッシュやパスワードベースの暗号化の場合とは目的は違ったりしても。

2012/04/11(水) 15:01:25.17

ストレッチングでテーブル化は防げるんだからsaltは不必要でしょ。

2012/04/11(水) 15:05:02.47

ストレッチングは計算量をかせぐ目的のものであって、あらかじめ計算されてしまう、
という問題への対策ではない。

2012/04/11(水) 15:18:06.14

不必要である、なくてもいいという反論になってないな。
残ってるのは、歴史的理由でしょう。
元々鍵+塩　で後からストレッチングが追加されただけ。

2012/04/11(水) 16:19:57.11

>>437
そうなの？
暗号理論の論文ではまず見ないから知らんかった
実装ではそういうもんなのか

>>438
反復回数ってどれぐらいの幅をもたせられるもんなのかね
あと>>439にもあるけど、ユーザーごとに異なるソルトを使わずに反復回数だけを変化させた場合
流出したパスワードハッシュに何回かハッシュ値をかけて
全部のパスワードのハッシュ関数反復適用回数を、たとえば10万回に揃えれば
一度計算した「反復回数10万回のハッシュ値」が全部のパスワードとの比較に利用できるから
やっぱり反復回数を変えただけじゃソルトの代わりにはならないんじゃないかな

2012/04/11(水) 16:32:44.92

>>440 目的が違う、という結論に対して、同じもんなんだから要らない、という
論理が生き残れると思える発想がわからないな。

2012/04/11(水) 17:14:39.81

昔、ワープロ派とPC派がいてだな。
ワープロ派は目的が違うからとずっと言っていた。

2012/04/11(水) 17:33:20.29

今、ケータイ派とスマフォ派がいてだな。
ケータイ派は目的が違うと言っている。

2012/04/11(水) 17:40:27.20

ストレッチング回数なんていう、変に制約を気にしなければならない方式をわざわざ採用するメリットがない。
簡単に制約なくソルトで対応出来るのに、わざわざ制約をかけたがる意味が分からない。

ストレッチング回数なんていまでも多分10万回くらいだろう。
場合によっては幅が1万回もいかない。
それだとバースデーパラドックスで100人に一人くらいは一致する可能性が高くなる。

しかもソルトと違って途中経過も保存可能、こういうのは何らか攻撃手段を与えるきっかけになる。

こんなデメリットばかりなのにあえて使う意味が分からない。

2012/04/11(水) 18:06:50.54

>多分10万回くらいだろう。

ふつう1000回ぐらいだよ。

>途中経過も保存可能

不可能だよ。どんだけ容量いるんだよ。
md5の128bitで1000回で、16000バイト。
大小英文字、数字8文字のパスワードのパターンだけで、62^8 * 16000 ≒ 3エクサバイト

実装したことない人？

2012/04/11(水) 18:10:25.12

そういうこと言ってんじゃないの。
継続計算できるって性質そのものが何らかの弱点を作り出すきっかけになりかねないって言ってんの。
暗号関連の経験あるなら、こういうのはできる限り避けるのは当たり前の感覚だろがよ。

2012/04/11(水) 18:24:06.15

だから実装上ありえないって言ってるの。総当りも実装上は継続計算。
暗号化、複合化が公開されてる暗号化手法で継続計算できない暗号手法なんて存在しない。
どの手法も常にコンピュータの計算力のリスクに晒されてる。

2012/04/11(水) 20:01:43.16

継続計算って何？

「なりかねない」って何。暗号理論で「なりかねない」なんて言葉、
あまり使わないと思うのが当たり前の感覚だと思うが。

>>443-444
木槌の代わりに金槌を使って痛い目に遭ったりしたことがないんだろうなw
多分、死ぬような目に遭わなきゃわからないんだろうなw
死んじゃったらわかりようもないけどw

2012/04/11(水) 20:09:42.25

きちがい

**デフォルトの名無しさん** · 2012/04/11(水) 21:18:59.05

おまえ実は暗号関係素人だろ。
計算量のみに依存してる話と、何らかの問題によってその計算量が減らされる事象とは全く違う。
計算量を想定より減らされる危険があればそれは立派な弱点だよ。
それが暗号の世界だ。
じゃなきゃ例えば中間一致攻撃なんて弱点は存在しない。
実装上ありえないって、中間一致攻撃なんて実装上もっとあり得ない。

今回の話では、例えば繰り返し回数1000回程度の場合に、例えば1から1000回まで幅を持たせたら、
たまたま回数が低い場合に単純に耐性が1000分の一とかになる。
いくらなんでもこれは意味ないから例えば1000から2000回にしたとする。
ここで1000回目の値があれば、そこから1001回目の計算は1回分の計算でできる、これが継続計算できるの意味。
例えばレインボーテーブルの一種として1000回目の値を保持しておけば、
0回から1000回の計算で値が計算できる。つまり繰り返し1000回分の耐性が削られるわけだよ。
暗号の世界じゃこんなものは脆弱性以外の何物でもない。
そしてこんな不合理な方法使わなくても単純にソルトで安全に制約なく目的を達成できるんだ。

こんなバカなことをする奴はいない。

**デフォルトの名無しさん** · 2012/04/11(水) 21:22:02.64

そもそも現在不可能なこと以上を気にする必要ないなら、
128ビット暗号化とか無駄なものを作るやつは実装経験のないバカなのか？
今の暗号の仕組みなんて今現実じゃ実装不可能なレベルの耐性を考慮してるものばかりだよ。

**デフォルトの名無しさん** · 2012/04/11(水) 21:23:25.00

MD5やSHA1の脆弱性だって現実実装上、やぶれる環境なんて存在しない。
じゃあこれを気にするのは実装したことがないバカなのか？
笑わすなっつうの。

**デフォルトの名無しさん** · 2012/04/11(水) 21:27:55.19

>>453
ネゴかかるところから送信受信の全データ捕獲すれば、解けないことはないでしょ
リアルタイムに解析ってのは無理かもしれんけど

**デフォルトの名無しさん** · 2012/04/11(水) 21:32:47.27

>>454
一応、今言ってんのは単純にMD5自体を破る話な。
パスワードとか関係なく、あくまで暗号関連の脆弱性話の例として出しただけ。

**デフォルトの名無しさん** · 2012/04/11(水) 21:35:44.87

アルゴリズムわかってるのを暗号というのはどうなんかね？
ネタバレしたら手品にならんような

◆QZaw55cn4c · 2012/04/11(水) 21:44:26.35

>>456
>>415

**デフォルトの名無しさん** · 2012/04/11(水) 22:02:48.07

>>457
机上の空論？
別に考えることを否定してるわけじゃないよ

**デフォルトの名無しさん** · 2012/04/11(水) 22:28:54.27

実際、無線LANが実際突破されちゃったからねぇ。
タダでインターネットができるツールって堂々とクラックツールを路上販売してるんだもの。
WEP限定だけど。

**デフォルトの名無しさん** · 2012/04/11(水) 22:40:55.85

暗号化するってことは簡単な暗号解読ぐらいできないと意味無いでしょう

**デフォルトの名無しさん** · 2012/04/11(水) 22:57:07.20

>>451
ストレッチングはバカが考えたということ？

**デフォルトの名無しさん** · 2012/04/11(水) 23:02:52.51

>>451
たった10^-3じゃなぁ。
レインボーテーブルも結局、HDDの容量の壁にごっつんこだな。

◆QZaw55cn4c · 2012/04/11(水) 23:06:36.20

>>458
暗号を解読する方法があったとしても、途方もない計算資源が必要で事実上解読できない、
たとえ暗号のアルゴリズムを公開したとしても、鍵さえ秘密であれば、実用上問題ない、
という考え方もあると思う。

実際に使用するときには、暗号化の方法を秘密にしてもなんら差し支えないし、そうするのが普通だろう。
しかし、仮に内部通報者がいて、暗号化の方法を暴露する、あるいは暗号化のプログラムそのものを暴露する、ということがあっても、鍵さえ暴露されなければ問題なし、という方がより安全だろう。
現代の暗号は、そういうシチュエーションも考慮して暗号アルゴリズムを追求していると考えている。

**デフォルトの名無しさん** · 2012/04/11(水) 23:17:01.79

>>462
はいはいもう消えろよ。

**デフォルトの名無しさん** · 2012/04/11(水) 23:18:36.23

>>463
通信経路の暗号だと
鍵が見えたら、どうにでもなることでしょ、アルゴリズムがバレてたら

だから、通信中に鍵変えるのがあるでしょ

ファイル暗号だと鍵がわからないと手が出ないってだけ
総当たりするにしても時間がかかる

**デフォルトの名無しさん** · 2012/04/11(水) 23:19:26.51

>>464
ほう。大小英数字8文字のレインボーテーブルがこの世に存在するのか？
容量はいくらだ？

**デフォルトの名無しさん** · 2012/04/11(水) 23:20:56.93

10^3だからわざわざデメリットばかりの方法使うって？
あほだな。
だいたい元の状態から比較したら、10^3じゃなくてストレッチングの意味がなくなるんだぜ。
レインボーテーブルはHDD容量でぶつかるって？
だったら最初からソルトとかテーブル化を防ぐ処置なんていらないんだよ。
なのになんでそれを防ぐようにしてるんだ？
まあそもそもテーブルだってそうあたりじゃなくて辞書をい使うんだがな普通は。
ソルトが10^3ってのも少なすぎて笑うけどな。

**デフォルトの名無しさん** · 2012/04/11(水) 23:22:19.40

はい今度はレインボーテーブル対策は無意味とね。
くすくす、次は何を言い出してくれるのかな。

**デフォルトの名無しさん** · 2012/04/11(水) 23:23:01.52

>>466
誰がそんなこと言ったんだよきちがい。

**デフォルトの名無しさん** · 2012/04/11(水) 23:23:27.14

>>466
これ以上無知をさらす前に消えろよ。

**デフォルトの名無しさん** · 2012/04/11(水) 23:25:13.76

だいぶ前にexcelの暗号化ファイルのパスワード解析した人がいたなあ

**デフォルトの名無しさん** · 2012/04/11(水) 23:27:03.68

WindowsのNTLMv2だったかなんかはレインボウテーブル実在したよな確か。
あれはソルト使ってねーからな。
チャレンジレスポンスに対応するためやむを得ないんだが。

**デフォルトの名無しさん** · 2012/04/11(水) 23:28:02.23

8文字以上のパスワードにするだけで、
そんなレインボーテーブルはこの世に存在しないから、総当りしかない。

ここで防御力を発揮するのがストレッチング。メタルスライムレベルの防御力。

**デフォルトの名無しさん** · 2012/04/11(水) 23:29:25.00

>>470
無知はおまえだ。存在しないものは存在しない。
あるなら、どのハッシュのものでもいいからURL張れ。

**デフォルトの名無しさん** · 2012/04/11(水) 23:33:23.37

だから辞書と組み合わせるんだっつの。
本当にあほだなお前。

**デフォルトの名無しさん** · 2012/04/11(水) 23:34:51.85

あとそもそも実在するかどうかなんて関係ないんだよ。
暗号にかかわるならそんなことは常識で理解できるだろ。
実在実在見当はずれなこと言ってるのはお前だけ。

**デフォルトの名無しさん** · 2012/04/11(水) 23:37:07.19

8文字長のレインボーテーブル出せで、なんで辞書の組み合わせテーブルなんだよw
テーブル劣化しすぎwwww

◆QZaw55cn4c · 2012/04/11(水) 23:37:18.90

>>465
＞通信経路の暗号だと
＞鍵が見えたら、どうにでもなることでしょ、アルゴリズムがバレてたら
そのとおり。
しかし、通信を行う双方で同一の鍵を使うことが可能で、かつその鍵が第三者には明らかにならない方法が存在する。

つ「DH鍵交換」

あるいは、暗号化で使用する鍵と復号化で使用する鍵が異なり、送信側に暗号化用の鍵を渡して、自分の復号化用の鍵を秘密にしておく方法もある。
このとき秘密にしている復号化用の鍵は、暗号化用の表に公開する鍵からは簡単には計算できない仕組みになっている。

つ「RSA暗号」「公開鍵暗号」
つ「一方向関数」

**デフォルトの名無しさん** · 2012/04/11(水) 23:42:25.12

>>476
実在しないことが前提で今の暗号化の強度は成り立ってます。
実在したとなればそれは破られたと同義です。DESがいい例。

**デフォルトの名無しさん** · 2012/04/11(水) 23:43:01.39

>>478
片側しか見えんとでも思ってるの、今のnet環境？
その手のやつは、ある程度時間経つと鍵変えてるような気がするけど

◆QZaw55cn4c · 2012/04/11(水) 23:47:22.17

>>480
＞片側しか見えんとでも思ってるの、今のnet環境？
kwsk

＞ある程度時間経つと鍵変えてるような気がする
素数を使用するタイプの公開暗号系では、確率的ではあるが素数判定方法があるので、お手軽に素数を算出してはそれを暗号に使用している。
お手軽に算出する程度のものだから、頻繁に鍵＝鍵に使用する素数を変える必要があるのだろう。

**デフォルトの名無しさん** · 2012/04/11(水) 23:47:53.00

>>477
なんで勝手にお前が出した条件にあうものを応えなきゃならないんだよ基地外かお前は。
お前が言ったテーブルが実在するかなんて誰も問題にしてないんだよ。
っていうか誰も実在するなんて言ってない。
馬鹿かよ。
お前が言ったテーブルがなければそんで安全なのか？
論点ずらしまくってんじゃねーよこの基地外。
それで済むなら暗号技術なんてどうでもいいもんばっかなんだよ。
お前はひとりで繰り返し回数をソルトの代わりに使うバカシステムでも作ってろよ。
まともな人間が見たら指摘されるだろうけどな。

**デフォルトの名無しさん** · 2012/04/11(水) 23:48:10.70

>>478
見えるのは途中の経路にぶら下がったところだからね
末端の人には見えないから安全ってだけでしょ

**デフォルトの名無しさん** · 2012/04/11(水) 23:49:01.56

まさか>>415-416の話に賛成できない人がいるとは思わなかった。
Security through Obscurityと言われたりもするっけ。byだっけ。
>>415-416の考え方を「知らなかった」ならわかるけどそれに反論するとか
どんなチャレンジャーだよ。

**デフォルトの名無しさん** · 2012/04/11(水) 23:50:07.59

>>479
また論点がずれてるぜ。
それは安全性の保証じゃなくて、すでに破られているわけではないことの保証にしかならない。

現実に破られてないからOKなら、128ビットの暗号化なんて不要。
危険性の説明に実在するかどうかなんて関係ないだろうが。
実在しないのは安全性のための必要条件に過ぎない。

**デフォルトの名無しさん** · 2012/04/11(水) 23:51:41.65

>>482
じゃあ、単純に実在しないよと言えばいいのに、
なんで「これ以上無知をさらす前に消えろよ。」なんだよw
キミの感情を複合化してやるよ。

くやしいんですね。わかりますw

◆QZaw55cn4c · 2012/04/11(水) 23:51:43.34

>>483
残念だがその意見は違うだろう。
公開暗号系を使用すれば、途中の経路で通信内容が全部傍受されたとしても、暗号を解読することは事実上不可能だ。
末端でみえようとみえまいと、あるいは途中の経路でみえようみえまいと、プロバイダがすべての通信のログを取得しようと、安全性には全然関係ない。

むしろ Windows のログオンパスワードの脆弱さといったら、お話にならないくらいだ。

**デフォルトの名無しさん** · 2012/04/11(水) 23:51:56.04

ああ、>>479は人違いで逆の意味でいったのかな、だったら勘違いすまんね。

**デフォルトの名無しさん** · 2012/04/11(水) 23:53:47.07

IPSecは糞と言いたいんだな。

**デフォルトの名無しさん** · 2012/04/11(水) 23:55:30.35

実在しないかどうかは知らないもん。
お前が初めから実在するかどうかが重要ってスタンスで聞いてくるから、
実在するかどうかは関係ないって言ってんだろうが。
悔しいって笑わすな、ずっとずれたこと言い続けてんのはお前じゃねーか。

実際に実在しない保証はないが、まあおそらく総当たりのテーブルは実在しないだろう。
で、だからどうしたの？そんなことは話の本筋に関係ないといってる。

◆QZaw55cn4c · 2012/04/11(水) 23:56:00.33

>>484
最初に暗号に触れる人には、理解に一定の困難が伴う考え方だと思う。「チャレンジャー」も理解を促進するひとつの方法だろう。
ただ理解しているものはそれに丁寧に回答する義務はあるかもしれない。

**デフォルトの名無しさん** · 2012/04/11(水) 23:58:06.14

＞キミの感情を複合化してやるよ。
噴いた。

**デフォルトの名無しさん** · 2012/04/12(木) 00:02:25.62

話の本筋を理解できないもしくはごまかし続ける相手に説明するのは無理、時間の無駄。
どうせごまかしたり論点ずらしたりするだけなんだから。

繰り返し回数をソルトの代わりに使うことの合理性をきちんと説明してみろって。
ああ、こいつの言い分だとそもそもソルトとかテーブル対策は要らないんだったｗ

8文字以上のレインボーテーブルは存在しないのでテーブル化対策は不要です、キリっ

**デフォルトの名無しさん** · 2012/04/12(木) 00:09:35.68

>>487
流れてるパケットの量が半端じゃないからね
ピンポイントでやろうってのがいないだけなんじゃねえの？

**デフォルトの名無しさん** · 2012/04/12(木) 00:11:14.65

中間者攻撃でアウト。
特に無線LANとかだとひっかけやすい。

だから証明書とかが必要なんだな。

**484** · 2012/04/12(木) 00:12:58.03

>>491
確かに暗号の話を教える/教わるとき最初の山が公開鍵暗号あたりで、その次が
Security through Obscurity(がダメという話)かもしれませんね。順番は逆かも？
とはいえ俺は理解はしてるけど他人を理解させられるレベルではないので
えらそうなことは言えませんね。

**デフォルトの名無しさん** · 2012/04/12(木) 00:15:05.53

レインボーテーブルの弱点はsaltと長パスワードでOK？

◆QZaw55cn4c · 2012/04/12(木) 00:26:39.87

>>496
なに、理解はらせん状に行きつ戻りつ進んでいくものだし、他人に説明することは自分の理解の深化にも寄与すると期待している。
ここは匿名の場であるし、遠慮なく自分の考えの述べるのはお互いにとっても最終的に利益になると思う。

お考えをうかがいたい。

**デフォルトの名無しさん** · 2012/04/12(木) 00:43:26.82

C++のAES256の枯れたライブラリってある？

**デフォルトの名無しさん** · 2012/04/12(木) 08:54:02.73

>>497
OK

**デフォルトの名無しさん** · 2012/04/12(木) 09:06:07.92

しかし、英数字パスワードだと、1文字辺りって6ビット程度だよな。
記号入れても7ビットはいかないが。

8文字だと48ビット程度か。
ビット数だけならDESより余裕で弱いんだな。
まあそれ以前にパスワードのエントロピーなんて乱数よりずっと低いが。

48ビットだと組み合わせ数は256Tか。
計算途中を再開するためには全情報が要るが、
単なるテーブルなら先頭の例えば64ビット分だけでも十分かもしれん。
とすれば8バイト×256Tで、2Pバイトか。

暗号関連の、ホントに現実的じゃない安全想定に比べたら、
余裕で実現可能なレベルだな。

**デフォルトの名無しさん** · 2012/04/13(金) 04:47:14.97

Ciphertext stealingって1ブロック以下のときはどうやってパディングするの？

**デフォルトの名無しさん** · 2012/04/16(月) 08:36:16.49

楕円曲線暗号の掛け算について分からないので教えて下さい。
ｈttp://deztec.jp/x/05/faireal/23-index.html
このページ中で「同意された点8に75を掛けると点26になる」
という部分なのですが、点8に75を掛けてみても点26に出来ません。
どの値にどのように掛ければ良いのか、教えて頂けると幸いです。

**デフォルトの名無しさん** · 2012/04/16(月) 09:02:54.18

瓶詰演算

これら楕円曲線上の点の上に、次のような演算を定義すると、群になる。
すなわち、(x1, y1) という点と、 (x2, y2) という点の「和」 (x3, y3) を、次の
ように約束する。

x3 = λ2 - x1 - x2
y3 = λ(x1 - x3) - y1

λとは何者か？というと、異なる点を足す場合、つまり一般の場合には

λ = (y2 - y1) × (x2 - x1)-1

とする。同じ点を足す場合、これでは分母分子ともゼロになってしまうが、そ
の場合には、

λ = ( 3x12 + a ) × 2y1-1

とする。 a とは楕円曲線の1次の係数で、①では2である。さらに、x1 = x2 で
y1 = -y2 というケースがある。その場合、足し算の結果は「無限遠点」とする。
「無限遠点」自身は、この演算に関してゼロとして機能する。ここで-1乗という
のは逆数（ℤ7上でかけると1になる相手の数）のこと。

**503** · 2012/04/16(月) 10:50:04.28

>>504
回答有難う御座います。
まだ試してないので、ちゃんと理解出来たのか怪しいですが
もう少し頑張ってみます。

**504** · 2012/04/16(月) 14:45:35.89

>>505
>>503で貼り付けているsite内を検索してごらん

**デフォルトの名無しさん** · 2012/04/16(月) 16:15:02.73

>>502
CTSなんてブロック暗号利用モードがあるんだ
知らなかった

全くの思い付きだけど、最初から1ブロックしか暗号化しないってことは
共通鍵暗号で単純に1つのメッセージを暗号化するときと同じだから
PKCS#5 Paddingとかでメッセージの長さを1ブロック分にして
それを暗号化するのではないかと予想

てか秘匿とメッセージ認証以外にもいろんなモードの規格が準備されてるんだね

ttp://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html
ttp://www.cryptrec.go.jp/estimation/techrep_id2011.pdf

メッセージ認証と鍵ラッピングは知ってたけど
認証子付き暗号化とかディスク暗号化なんてのもあるのか

**503** · 2012/04/16(月) 20:42:26.64

>>506
追加のアドバイス、有難う御座います。
ちゃんと理解する為には色々と検索しなければならなさそうですがｗ、
今考えている方法を試して駄目だったら検索もやってみます。

**デフォルトの名無しさん** · 2012/04/18(水) 18:17:06.76

共通鍵暗号におけるIV(initial value?)というのは、
解読時までKeyと一緒に覚えておく必要があるのでしょうか？
もしそうなら、公開鍵暗号と一緒に用いる場合、
Keyと一緒に暗号化しておくべきでしょうか？

**デフォルトの名無しさん** · 2012/04/18(水) 18:40:15.18

cbc modeの話だと仮定します。

IVは暗号化前に生成しておいて、
復号時にも同じ値をIVとして使用します。
通常IVは暗号化しません。

また、Keyは対称鍵暗号で使う対称鍵のことと仮定しますが、
Keyのみを公開鍵暗号で暗号化して、
暗号化対象の実体は対称鍵(Key)で暗号化します。

**デフォルトの名無しさん** · 2012/04/18(水) 19:22:56.39

情報が不足していてすみませんでした
まさに対称鍵暗号のCBCやCTRを想定していました
回答ありがとうございました

**デフォルトの名無しさん** · 2012/04/24(火) 18:42:15.56

コンテンツ暗号化するときは毎回コンテンツごとにコンテンツ暗号化キーをランダムに生成。
で、コンテンツ自体を暗号化(だいたい対称暗号で)。で、コンテンツ暗号化キー自体を
自分の何からしの鍵(キー暗号化キー)で暗号化して、その暗号化されたキー暗号化キーと暗号化されたコンテンツをセットに
する。キー暗号化キーをどうするかは用件しだいで、>>510のように、公開鍵暗号で暗号化したり、
パスワードベースにするならPBKDF2などのキー導出関数を使って、導出させる。

**デフォルトの名無しさん** · 2012/04/24(火) 18:46:06.85

まぁ、暗号化だけじゃ、機密性しか提供できないから、一貫性チェックのために、
暗号化する前に、コンテンツのハッシュを求めて、コンテンツとハッシュをあわせたものを
暗号化するなどして、復号化時に、コンテンツの一貫性をチェックできるようになる。
Windowsの暗号化ファイルシステム(EFS)をだいたい同じ。EFSは使用するとEFS用の
自己署名された証明書とその公開・非公開鍵ペアをつくって、その非公開鍵が
キー暗号化キーになるイメージ。

**デフォルトの名無しさん** · 2012/04/24(火) 18:55:04.74

コンテンツ暗号化キーを暗号化するときに、１つのキー暗号化キーで暗号化するのでは
なく複数のキー暗号化キーを使って、暗号化されたコンテンツ＋複数それぞれのキー暗号化キー
で暗号化されたコンテンツ暗号化キーをセットにしておけば、１つのキー暗号化キーを
忘れても他ので復号化できるので安心。EFSに回復エージェントって仕組みがあるけど
まさしくそれ。

**デフォルトの名無しさん** · 2012/04/24(火) 19:43:56.51

暗号化ファイルシステムがハックされたら、終わり

**デフォルトの名無しさん** · 2012/04/25(水) 05:49:50.07

「ハックされたら」の一言で計算量理論もなにもかもをふっとばせるバカはお気楽でいいな

**デフォルトの名無しさん** · 2012/04/25(水) 06:20:04.43

Windowsの暗号化ファイルシステム(AES256+(ECC256 or RSA2048))はザル。
ログインパスワードさえ突破しさえすれば丸見え。大半は辞書攻撃で突破可能。

**デフォルトの名無しさん** · 2012/04/25(水) 07:23:33.81

鍵の不適切な運用を前提に議論するとか、最強の論理体系ですねw

**デフォルトの名無しさん** · 2012/04/25(水) 07:31:34.85

事実、現実が不適切な運用だらけなのに、
それを前提にしないシステムは欠陥ありというべきであろう。

最低限、EFSを使用する場合には、ログインパスワードのセキュリティポリシーを
強制的に厳しくするべきだね、MSは。

**デフォルトの名無しさん** · 2012/04/25(水) 17:04:02.53

個人用の場合、忘れたもしくは自分が死んだらおしまいの、パスワードベースでいいんだけど、
EFSは証明書に基づく公開・非公開鍵要求するからふざけるなって感じ。
BitLockerでいいよ。