■暗号技術【ROUNDsurea】■

1 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 00:49:42 ] 前スレ ■暗号技術【ROUND2】■ pc11.2ch.net/test/read.cgi/tech/1088530204/ 擬似乱数 pc11.2ch.net/test/read.cgi/tech/1146071975/ 暗号数学について語ろう。ROUND 3 science6.2ch.net/test/read.cgi/math/1170938965/ 素数判定は「決定的」多項式時間で可能 science6.2ch.net/test/read.cgi/math/1028813059/ 【疑似】乱数をつくる【本物】 science6.2ch.net/test/read.cgi/denki/1074867250/ ＲＳＡ暗号　解読　助けてください！！ pc11.2ch.net/test/read.cgi/sec/1026903337/ お前らって本当に自分じゃ何もしないよな。 前スレ>>990->>994 罰としてスレタイで辱めてやる 416 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/04(水) 03:18:50.66 ] 全てのセキュリティは鍵のみに宿る。 って一言で言えないのかしら。 417 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/04(水) 06:12:49.46 ] そうなったのは、暗号については過去2000年ぐらいの歴史のうち、たかだか最近100年のことだからな。 418 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/04(水) 11:13:56.70 ] だから何？ 419 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/04(水) 12:04:24.71 ] 今世の中に存在するもので、100年以上昔に進歩が終わった技術で出来てるものなんてなかなか無いぜ。 420 名前： ◆QZaw55cn4c mailto:sage [2012/04/04(水) 12:13:38.36 ] >>417 過去の考え方や >>414 は安全を追求していない。内部造反者等も考慮しなければならない。 >>416 ナイスですね。 421 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/04(水) 12:23:59.15 ] www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/faq.html > 出力列を8ワードごとに切って、ハッシュ関数で 1ワードに圧縮して使う というようなこと書かれてはいますが、sha256 をアルゴリズムとして使うぶんには MTが生成した乱数 256bit をハッシュ化して出力した 256bit これを予測できない乱数として使っていいですよね コード -> pastebin.com/Qjuwy7r3 422 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/04(水) 13:08:33.86 ] 念のために元乱数列を多めにしといた方がベターだとは思うけど、悪くはないでしょ。 あと用途によってはストレッチングも検討。 423 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/04(水) 14:25:33.89 ] 別に圧縮は必要ない。 なんとなく、暗号ハッシュ自体の目的のイメージから、なんとなく圧縮って言ってしまっただけに見える。 まあどっちでも別に問題はない。 424 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/08(日) 17:41:48.19 ] PKCS#5って何のメリットがあるの？ これ使えばパスワードクラックに対して強くなるの？ 425 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/08(日) 21:19:51.19 ] うん。 ブルーとフォースや辞書攻撃などをオフラインで実行された場合に、圧倒的に強くできる。 パスワードハッシュにも使える、これを使うとパスワードデータベースの耐性も簡単に上げられる。 よくパスワードハッシュで、MD5やSHA1は危ないからSHA2を使わないとダメダメとか分かった風なことを言ってるのを見るが、 パスワードハッシュの用途ではSHA2使ってもそれほどは耐性は上がらないことを理解してない。 耐性を上げるにはPBKDF2を使う、これで比較にならないほど上げることが出来る。 426 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/08(日) 23:45:33.20 ] 計算回数増やせば強くなるが、saltは飾りです。 427 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/09(月) 00:19:22.84 ] saltはテーブル化を防げればそれで十分役に立ってる。 428 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/09(月) 19:45:50.80 ] ていうか、それ単に最初からストレッチングを前提に設計されてんじゃん。 比較対象としてなんか違う。 429 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/09(月) 22:45:58.07 ] そりゃ耐パスワードクラックにはストレッチングこそ必要って話なんだから。 何が違うのかようわからん。 430 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/09(月) 22:49:02.23 ] おかしいのは、パスワードハッシュの耐性とか、やたらうるさくこだわりながら、 単にハッシュを一回かけるだけとかで、やたら気にしてるのはハッシュ関数の種類だけ みたいなの。 突っ込みたくもなるわ。 431 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/10(火) 20:27:41.23 ] saltの意義はいくら調べても分かりません。 どの説明もバレない前提の説明ばかり。 しかし、実装レベルの説明ではバレてもいいみたいこと書いてる。 432 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/10(火) 20:38:34.17 ] > バレない前提の説明 それが原理的に考えておかしい。 あらかじめ時間をかけて、大量にハッシュ値を計算しておく、という攻撃への対策として、 塩を混ぜてからハッシュ値を計算することで、情報を知ってからハッシュ値を計算しなければ ならなくする、というのが目的なんだから、塩の秘匿（ないし公開）は、ハッシュ値の秘匿（ないし公開）と 同じ扱いでよい。 433 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/10(火) 20:49:27.42 ] そういう理由なら反復回数の秘匿でハッシュ値の秘匿も達成されるじゃん。 434 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 05:33:30.00 ] saltはランダム値を使ってこそ意味がある。 平文aを1というsaltで暗号文bをつくり、bと1を送る。 しかし、また同じ平文aを送りたいとき、bと1を送れば、 盗聴されてる場合は解読はされてないが、同じ平文を送ったことがバレる。 しかし、平文aを2というsaltで暗号文cを作れば、同じ文を送ったかどうかはバレない。 435 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 09:40:48.58 ] >>434 それは確率的暗号方式 （鍵生成だけではなく、暗号化アルゴリズムも確率的アルゴリズムになっていて たとえ同じ平文を暗号化しても毎回異なる暗号文になる） の暗号化処理で使うランダムネスの話ですね そういう目的で暗号化アルゴリズムへ入力する・アルゴリズム内で生成する 乱数やランダムネスをソルトと呼ぶことはあまりないと思う てかパスワードハッシュのソルトの目的って>>472以外の何物でもないのに バレない前提（ソルトがバレない限り安全ということ？）ってどういうこと？ >>431の読んだ参考書や解説が知りたい 436 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 09:47:17.77 ] >>435のレスアンカー間違えた 472じゃなくて>>427だ そういやずっと前に 共通鍵メッセージ認証の鍵（当然送信者と受信者以外に明かしてはいけない）を ソルトって呼んでたブログや技術文書がどっかにあったような・・・ 437 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 11:35:24.53 ] >>435 暗号化処理で暗号化毎に使うランダム値もまあソルトって言う気がするけどな。 パスワードハッシュやパスワードベースの暗号化の場合とは目的は違ったりしても。 438 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 15:01:25.17 ] ストレッチングでテーブル化は防げるんだからsaltは不必要でしょ。 439 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 15:05:02.47 ] ストレッチングは計算量をかせぐ目的のものであって、あらかじめ計算されてしまう、 という問題への対策ではない。 440 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 15:18:06.14 ] 不必要である、なくてもいいという反論になってないな。 残ってるのは、歴史的理由でしょう。 元々 鍵+塩　で後から ストレッチングが追加されただけ。 441 名前：営利利用に関するLR審議中＠詳細は自治スレへ [2012/04/11(水) 16:19:57.11 ] >>437 そうなの？ 暗号理論の論文ではまず見ないから知らんかった 実装ではそういうもんなのか >>438 反復回数ってどれぐらいの幅をもたせられるもんなのかね あと>>439にもあるけど、ユーザーごとに異なるソルトを使わずに反復回数だけを変化させた場合 流出したパスワードハッシュに何回かハッシュ値をかけて 全部のパスワードのハッシュ関数反復適用回数を、たとえば10万回に揃えれば 一度計算した「反復回数10万回のハッシュ値」が全部のパスワードとの比較に利用できるから やっぱり反復回数を変えただけじゃソルトの代わりにはならないんじゃないかな 442 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 16:32:44.92 ] >>440 目的が違う、という結論に対して、同じもんなんだから要らない、という 論理が生き残れると思える発想がわからないな。 443 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 17:14:39.81 ] 昔、ワープロ派とPC派がいてだな。 ワープロ派は目的が違うからとずっと言っていた。 444 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 17:33:20.29 ] 今、ケータイ派とスマフォ派がいてだな。 ケータイ派は目的が違うと言っている。 445 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 17:40:27.20 ] ストレッチング回数なんていう、変に制約を気にしなければならない方式をわざわざ採用するメリットがない。 簡単に制約なくソルトで対応出来るのに、わざわざ制約をかけたがる意味が分からない。 ストレッチング回数なんていまでも多分10万回くらいだろう。 場合によっては幅が1万回もいかない。 それだとバースデーパラドックスで100人に一人くらいは一致する可能性が高くなる。 しかもソルトと違って途中経過も保存可能、こういうのは何らか攻撃手段を与えるきっかけになる。 こんなデメリットばかりなのにあえて使う意味が分からない。 446 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 18:06:50.54 ] >多分10万回くらいだろう。 ふつう1000回ぐらいだよ。 >途中経過も保存可能 不可能だよ。どんだけ容量いるんだよ。 md5の128bitで1000回で、16000バイト。 大小英文字、数字8文字のパスワードのパターンだけで、62^8 * 16000 ≒ 3エクサバイト 実装したことない人？ 447 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 18:10:25.12 ] そういうこと言ってんじゃないの。 継続計算できるって性質そのものが何らかの弱点を作り出すきっかけになりかねないって言ってんの。 暗号関連の経験あるなら、こういうのはできる限り避けるのは当たり前の感覚だろがよ。 448 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 18:24:06.15 ] だから実装上ありえないって言ってるの。総当りも実装上は継続計算。 暗号化、複合化が公開されてる暗号化手法で継続計算できない暗号手法なんて存在しない。 どの手法も常にコンピュータの計算力のリスクに晒されてる。 449 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 20:01:43.16 ] 継続計算って何？ 「なりかねない」って何。暗号理論で「なりかねない」なんて言葉、 あまり使わないと思うのが当たり前の感覚だと思うが。 >>443-444 木槌の代わりに金槌を使って痛い目に遭ったりしたことがないんだろうなw 多分、死ぬような目に遭わなきゃわからないんだろうなw 死んじゃったらわかりようもないけどw 450 名前：営利利用に関するLR審議中＠詳細は自治スレへ mailto:sage [2012/04/11(水) 20:09:42.25 ] きちがい 451 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 21:18:59.05 ] おまえ実は暗号関係素人だろ。 計算量のみに依存してる話と、何らかの問題によってその計算量が減らされる事象とは全く違う。 計算量を想定より減らされる危険があればそれは立派な弱点だよ。 それが暗号の世界だ。 じゃなきゃ例えば中間一致攻撃なんて弱点は存在しない。 実装上ありえないって、中間一致攻撃なんて実装上もっとあり得ない。 今回の話では、例えば繰り返し回数1000回程度の場合に、例えば1から1000回まで幅を持たせたら、 たまたま回数が低い場合に単純に耐性が1000分の一とかになる。 いくらなんでもこれは意味ないから例えば1000から2000回にしたとする。 ここで1000回目の値があれば、そこから1001回目の計算は1回分の計算でできる、これが継続計算できるの意味。 例えばレインボーテーブルの一種として1000回目の値を保持しておけば、 0回から1000回の計算で値が計算できる。つまり繰り返し1000回分の耐性が削られるわけだよ。 暗号の世界じゃこんなものは脆弱性以外の何物でもない。 そしてこんな不合理な方法使わなくても単純にソルトで安全に制約なく目的を達成できるんだ。 こんなバカなことをする奴はいない。 452 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 21:22:02.64 ] そもそも現在不可能なこと以上を気にする必要ないなら、 128ビット暗号化とか無駄なものを作るやつは実装経験のないバカなのか？ 今の暗号の仕組みなんて今現実じゃ実装不可能なレベルの耐性を考慮してるものばかりだよ。 453 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 21:23:25.00 ] MD5やSHA1の脆弱性だって現実実装上、やぶれる環境なんて存在しない。 じゃあこれを気にするのは実装したことがないバカなのか？ 笑わすなっつうの。 454 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 21:27:55.19 ] >>453 ネゴかかるところから送信受信の全データ捕獲すれば、解けないことはないでしょ リアルタイムに解析ってのは無理かもしれんけど 455 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 21:32:47.27 ] >>454 一応、今言ってんのは単純にMD5自体を破る話な。 パスワードとか関係なく、あくまで暗号関連の脆弱性話の例として出しただけ。 456 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 21:35:44.87 ] アルゴリズムわかってるのを暗号というのはどうなんかね？ ネタバレしたら手品にならんような 457 名前： ◆QZaw55cn4c mailto:sage [2012/04/11(水) 21:44:26.35 ] >>456 >>415 458 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 22:02:48.07 ] >>457 机上の空論？ 別に考えることを否定してるわけじゃないよ 459 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 22:28:54.27 ] 実際、無線LANが実際突破されちゃったからねぇ。 タダでインターネットができるツールって堂々とクラックツールを路上販売してるんだもの。 WEP限定だけど。 460 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 22:40:55.85 ] 暗号化するってことは簡単な暗号解読ぐらいできないと意味無いでしょう 461 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 22:57:07.20 ] >>451 ストレッチングはバカが考えたということ？ 462 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:02:52.51 ] >>451 たった10^-3じゃなぁ。 レインボーテーブルも結局、HDDの容量の壁にごっつんこだな。 463 名前： ◆QZaw55cn4c mailto:sage [2012/04/11(水) 23:06:36.20 ] >>458 暗号を解読する方法があったとしても、途方もない計算資源が必要で事実上解読できない、 たとえ暗号のアルゴリズムを公開したとしても、鍵さえ秘密であれば、実用上問題ない、 という考え方もあると思う。 実際に使用するときには、暗号化の方法を秘密にしてもなんら差し支えないし、そうするのが普通だろう。 しかし、仮に内部通報者がいて、暗号化の方法を暴露する、あるいは暗号化のプログラムそのものを暴露する、ということがあっても、鍵さえ暴露されなければ問題なし、という方がより安全だろう。 現代の暗号は、そういうシチュエーションも考慮して暗号アルゴリズムを追求していると考えている。 464 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:17:01.79 ] >>462 はいはいもう消えろよ。 465 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:18:36.23 ] >>463 通信経路の暗号だと 鍵が見えたら、どうにでもなることでしょ、アルゴリズムがバレてたら だから、通信中に鍵変えるのがあるでしょ ファイル暗号だと鍵がわからないと手が出ないってだけ 総当たりするにしても時間がかかる 466 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:19:26.51 ] >>464 ほう。大小英数字8文字のレインボーテーブルがこの世に存在するのか？ 容量はいくらだ？ 467 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:20:56.93 ] 10^3だからわざわざデメリットばかりの方法使うって？ あほだな。 だいたい元の状態から比較したら、10^3じゃなくてストレッチングの意味がなくなるんだぜ。 レインボーテーブルはHDD容量でぶつかるって？ だったら最初からソルトとかテーブル化を防ぐ処置なんていらないんだよ。 なのになんでそれを防ぐようにしてるんだ？ まあそもそもテーブルだってそうあたりじゃなくて辞書をい使うんだがな普通は。 ソルトが10^3ってのも少なすぎて笑うけどな。 468 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:22:19.40 ] はい今度はレインボーテーブル対策は無意味とね。 くすくす、次は何を言い出してくれるのかな。 469 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:23:01.52 ] >>466 誰がそんなこと言ったんだよきちがい。 470 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:23:27.14 ] >>466 これ以上無知をさらす前に消えろよ。 471 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:25:13.76 ] だいぶ前にexcelの暗号化ファイルのパスワード解析した人がいたなあ 472 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:27:03.68 ] WindowsのNTLMv2だったかなんかはレインボウテーブル実在したよな確か。 あれはソルト使ってねーからな。 チャレンジレスポンスに対応するためやむを得ないんだが。 473 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:28:02.23 ] 8文字以上のパスワードにするだけで、 そんなレインボーテーブルはこの世に存在しないから、総当りしかない。 ここで防御力を発揮するのがストレッチング。メタルスライムレベルの防御力。 474 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:29:25.00 ] >>470 無知はおまえだ。存在しないものは存在しない。 あるなら、どのハッシュのものでもいいからURL張れ。 475 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:33:23.37 ] だから辞書と組み合わせるんだっつの。 本当にあほだなお前。 476 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:34:51.85 ] あとそもそも実在するかどうかなんて関係ないんだよ。 暗号にかかわるならそんなことは常識で理解できるだろ。 実在実在見当はずれなこと言ってるのはお前だけ。 477 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:37:07.19 ] 8文字長のレインボーテーブル出せで、なんで辞書の組み合わせテーブルなんだよw テーブル劣化しすぎwwww 478 名前： ◆QZaw55cn4c mailto:sage [2012/04/11(水) 23:37:18.90 ] >>465 ＞通信経路の暗号だと ＞鍵が見えたら、どうにでもなることでしょ、アルゴリズムがバレてたら そのとおり。 しかし、通信を行う双方で同一の鍵を使うことが可能で、かつその鍵が第三者には明らかにならない方法が存在する。 つ「DH鍵交換」 あるいは、暗号化で使用する鍵と復号化で使用する鍵が異なり、送信側に暗号化用の鍵を渡して、自分の復号化用の鍵を秘密にしておく方法もある。 このとき秘密にしている復号化用の鍵は、暗号化用の表に公開する鍵からは簡単には計算できない仕組みになっている。 つ「RSA暗号」「公開鍵暗号」 つ「一方向関数」 479 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:42:25.12 ] >>476 実在しないことが前提で今の暗号化の強度は成り立ってます。 実在したとなればそれは破られたと同義です。DESがいい例。 480 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:43:01.39 ] >>478 片側しか見えんとでも思ってるの、今のnet環境？ その手のやつは、ある程度時間経つと鍵変えてるような気がするけど 481 名前： ◆QZaw55cn4c mailto:sage [2012/04/11(水) 23:47:22.17 ] >>480 ＞片側しか見えんとでも思ってるの、今のnet環境？ kwsk ＞ある程度時間経つと鍵変えてるような気がする 素数を使用するタイプの公開暗号系では、確率的ではあるが素数判定方法があるので、お手軽に素数を算出してはそれを暗号に使用している。 お手軽に算出する程度のものだから、頻繁に鍵＝鍵に使用する素数を変える必要があるのだろう。 482 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:47:53.00 ] >>477 なんで勝手にお前が出した条件にあうものを応えなきゃならないんだよ基地外かお前は。 お前が言ったテーブルが実在するかなんて誰も問題にしてないんだよ。 っていうか誰も実在するなんて言ってない。 馬鹿かよ。 お前が言ったテーブルがなければそんで安全なのか？ 論点ずらしまくってんじゃねーよこの基地外。 それで済むなら暗号技術なんてどうでもいいもんばっかなんだよ。 お前はひとりで繰り返し回数をソルトの代わりに使うバカシステムでも作ってろよ。 まともな人間が見たら指摘されるだろうけどな。 483 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:48:10.70 ] >>478 見えるのは途中の経路にぶら下がったところだからね 末端の人には見えないから安全ってだけでしょ 484 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:49:01.56 ] まさか>>415-416の話に賛成できない人がいるとは思わなかった。 Security through Obscurityと言われたりもするっけ。byだっけ。 >>415-416の考え方を「知らなかった」ならわかるけどそれに反論するとか どんなチャレンジャーだよ。 485 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:50:07.59 ] >>479 また論点がずれてるぜ。 それは安全性の保証じゃなくて、すでに破られているわけではないことの保証にしかならない。 現実に破られてないからOKなら、128ビットの暗号化なんて不要。 危険性の説明に実在するかどうかなんて関係ないだろうが。 実在しないのは安全性のための必要条件に過ぎない。 486 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:51:41.65 ] >>482 じゃあ、単純に実在しないよと言えばいいのに、 なんで「これ以上無知をさらす前に消えろよ。」なんだよw キミの感情を複合化してやるよ。 くやしいんですね。わかりますw 487 名前： ◆QZaw55cn4c mailto:sage [2012/04/11(水) 23:51:43.34 ] >>483 残念だがその意見は違うだろう。 公開暗号系を使用すれば、途中の経路で通信内容が全部傍受されたとしても、暗号を解読することは事実上不可能だ。 末端でみえようとみえまいと、あるいは途中の経路でみえようみえまいと、プロバイダがすべての通信のログを取得しようと、安全性には全然関係ない。 むしろ Windows のログオンパスワードの脆弱さといったら、お話にならないくらいだ。 488 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:51:56.04 ] ああ、>>479は人違いで逆の意味でいったのかな、だったら勘違いすまんね。 489 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:53:47.07 ] IPSecは糞と言いたいんだな。 490 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:55:30.35 ] 実在しないかどうかは知らないもん。 お前が初めから実在するかどうかが重要ってスタンスで聞いてくるから、 実在するかどうかは関係ないって言ってんだろうが。 悔しいって笑わすな、ずっとずれたこと言い続けてんのはお前じゃねーか。 実際に実在しない保証はないが、まあおそらく総当たりのテーブルは実在しないだろう。 で、だからどうしたの？そんなことは話の本筋に関係ないといってる。 491 名前： ◆QZaw55cn4c mailto:sage [2012/04/11(水) 23:56:00.33 ] >>484 最初に暗号に触れる人には、理解に一定の困難が伴う考え方だと思う。「チャレンジャー」も理解を促進するひとつの方法だろう。 ただ理解しているものはそれに丁寧に回答する義務はあるかもしれない。 492 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:58:06.14 ] ＞キミの感情を複合化してやるよ。 噴いた。 493 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 00:02:25.62 ] 話の本筋を理解できないもしくはごまかし続ける相手に説明するのは無理、時間の無駄。 どうせごまかしたり論点ずらしたりするだけなんだから。 繰り返し回数をソルトの代わりに使うことの合理性をきちんと説明してみろって。 ああ、こいつの言い分だとそもそもソルトとかテーブル対策は要らないんだったｗ 8文字以上のレインボーテーブルは存在しないのでテーブル化対策は不要です、キリっ 494 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 00:09:35.68 ] >>487 流れてるパケットの量が半端じゃないからね ピンポイントでやろうってのがいないだけなんじゃねえの？ 495 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 00:11:14.65 ] 中間者攻撃でアウト。 特に無線LANとかだとひっかけやすい。 だから証明書とかが必要なんだな。 496 名前：484 mailto:sage [2012/04/12(木) 00:12:58.03 ] >>491 確かに暗号の話を教える/教わるとき最初の山が公開鍵暗号あたりで、その次が Security through Obscurity(がダメという話)かもしれませんね。順番は逆かも？ とはいえ俺は理解はしてるけど他人を理解させられるレベルではないので えらそうなことは言えませんね。 497 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 00:15:05.53 ] レインボーテーブルの弱点はsaltと長パスワードでOK？ 498 名前： ◆QZaw55cn4c mailto:sage [2012/04/12(木) 00:26:39.87 ] >>496 なに、理解はらせん状に行きつ戻りつ進んでいくものだし、他人に説明することは自分の理解の深化にも寄与すると期待している。 ここは匿名の場であるし、遠慮なく自分の考えの述べるのはお互いにとっても最終的に利益になると思う。 お考えをうかがいたい。 499 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 00:43:26.82 ] C++のAES256の枯れたライブラリってある？ 500 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 08:54:02.73 ] >>497 OK 501 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 09:06:07.92 ] しかし、英数字パスワードだと、1文字辺りって6ビット程度だよな。 記号入れても7ビットはいかないが。 8文字だと48ビット程度か。 ビット数だけならDESより余裕で弱いんだな。 まあそれ以前にパスワードのエントロピーなんて乱数よりずっと低いが。 48ビットだと組み合わせ数は256Tか。 計算途中を再開するためには全情報が要るが、 単なるテーブルなら先頭の例えば64ビット分だけでも十分かもしれん。 とすれば8バイト×256Tで、2Pバイトか。 暗号関連の、ホントに現実的じゃない安全想定に比べたら、 余裕で実現可能なレベルだな。 502 名前：デフォルトの名無しさん mailto:sage [2012/04/13(金) 04:47:14.97 ] Ciphertext stealingって1ブロック以下のときはどうやってパディングするの？ 503 名前：デフォルトの名無しさん mailto:sage [2012/04/16(月) 08:36:16.49 ] 楕円曲線暗号の掛け算について分からないので教えて下さい。 ｈttp://deztec.jp/x/05/faireal/23-index.html このページ中で「同意された点8に75を掛けると点26になる」 という部分なのですが、点8に75を掛けてみても点26に出来ません。 どの値にどのように掛ければ良いのか、教えて頂けると幸いです。 504 名前：デフォルトの名無しさん mailto:sage [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になる相手の数）のこと。 505 名前：503 mailto:sage [2012/04/16(月) 10:50:04.28 ] >>504 回答有難う御座います。 まだ試してないので、ちゃんと理解出来たのか怪しいですが もう少し頑張ってみます。 506 名前：504 mailto:sage [2012/04/16(月) 14:45:35.89 ] >>505 >>503で貼り付けているsite内を検索してごらん 507 名前：デフォルトの名無しさん mailto:sage [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 メッセージ認証と鍵ラッピングは知ってたけど 認証子付き暗号化とかディスク暗号化なんてのもあるのか 508 名前：503 mailto:sage [2012/04/16(月) 20:42:26.64 ] >>506 追加のアドバイス、有難う御座います。 ちゃんと理解する為には色々と検索しなければならなさそうですがｗ、 今考えている方法を試して駄目だったら検索もやってみます。 509 名前：デフォルトの名無しさん mailto:sage [2012/04/18(水) 18:17:06.76 ] 共通鍵暗号におけるIV(initial value?)というのは、 解読時までKeyと一緒に覚えておく必要があるのでしょうか？ もしそうなら、公開鍵暗号と一緒に用いる場合、 Keyと一緒に暗号化しておくべきでしょうか？ 510 名前：デフォルトの名無しさん mailto:sage [2012/04/18(水) 18:40:15.18 ] cbc modeの話だと仮定します。 IVは暗号化前に生成しておいて、 復号時にも同じ値をIVとして使用します。 通常IVは暗号化しません。 また、Keyは対称鍵暗号で使う対称鍵のことと仮定しますが、 Keyのみを公開鍵暗号で暗号化して、 暗号化対象の実体は対称鍵(Key)で暗号化します。 511 名前：デフォルトの名無しさん mailto:sage [2012/04/18(水) 19:22:56.39 ] 情報が不足していてすみませんでした まさに対称鍵暗号のCBCやCTRを想定していました 回答ありがとうございました 512 名前：デフォルトの名無しさん mailto:sage [2012/04/24(火) 18:42:15.56 ] コンテンツ暗号化するときは毎回コンテンツごとにコンテンツ暗号化キーをランダムに生成。 で、コンテンツ自体を暗号化(だいたい対称暗号で)。で、コンテンツ暗号化キー自体を 自分の何からしの鍵(キー暗号化キー)で暗号化して、その暗号化されたキー暗号化キーと暗号化されたコンテンツをセットに する。キー暗号化キーをどうするかは用件しだいで、>>510のように、公開鍵暗号で暗号化したり、 パスワードベースにするならPBKDF2などのキー導出関数を使って、導出させる。 513 名前：デフォルトの名無しさん mailto:sage [2012/04/24(火) 18:46:06.85 ] まぁ、暗号化だけじゃ、機密性しか提供できないから、一貫性チェックのために、 暗号化する前に、コンテンツのハッシュを求めて、コンテンツとハッシュをあわせたものを 暗号化するなどして、復号化時に、コンテンツの一貫性をチェックできるようになる。 Windowsの暗号化ファイルシステム(EFS)をだいたい同じ。EFSは使用するとEFS用の 自己署名された証明書とその公開・非公開鍵ペアをつくって、その非公開鍵が キー暗号化キーになるイメージ。 514 名前：デフォルトの名無しさん mailto:sage [2012/04/24(火) 18:55:04.74 ] コンテンツ暗号化キーを暗号化するときに、１つのキー暗号化キーで暗号化するのでは なく複数のキー暗号化キーを使って、暗号化されたコンテンツ＋複数それぞれのキー暗号化キー で暗号化されたコンテンツ暗号化キーをセットにしておけば、１つのキー暗号化キーを 忘れても他ので復号化できるので安心。EFSに回復エージェントって仕組みがあるけど まさしくそれ。 515 名前：デフォルトの名無しさん mailto:sage [2012/04/24(火) 19:43:56.51 ] 暗号化ファイルシステムがハックされたら、終わり 516 名前：デフォルトの名無しさん mailto:sage [2012/04/25(水) 05:49:50.07 ] 「ハックされたら」の一言で計算量理論もなにもかもをふっとばせるバカはお気楽でいいな 517 名前：デフォルトの名無しさん mailto:sage [2012/04/25(水) 06:20:04.43 ] Windowsの暗号化ファイルシステム(AES256+(ECC256 or RSA2048))はザル。 ログインパスワードさえ突破しさえすれば丸見え。大半は辞書攻撃で突破可能。 518 名前：デフォルトの名無しさん mailto:sage [2012/04/25(水) 07:23:33.81 ] 鍵の不適切な運用を前提に議論するとか、最強の論理体系ですねw 519 名前：デフォルトの名無しさん mailto:sage [2012/04/25(水) 07:31:34.85 ] 事実、現実が不適切な運用だらけなのに、 それを前提にしないシステムは欠陥ありというべきであろう。 最低限、EFSを使用する場合には、ログインパスワードのセキュリティポリシーを 強制的に厳しくするべきだね、MSは。 520 名前：デフォルトの名無しさん mailto:sage [2012/04/25(水) 17:04:02.53 ] 個人用の場合、忘れたもしくは自分が死んだらおしまいの、パスワードベースでいいんだけど、 EFSは証明書に基づく公開・非公開鍵要求するからふざけるなって感じ。 BitLockerでいいよ。 521 名前：デフォルトの名無しさん mailto:sage [2012/04/26(木) 02:50:46.22 ] コンテンツのハッシュをとってから暗号化するのと、 暗号化してからキー付ハッシュをとるのとどっちがいい」？ 522 名前：デフォルトの名無しさん mailto:sage [2012/04/26(木) 04:18:20.27 ] >>521 暗号文とハッシュ値、ハッシュの秘密鍵と復号鍵の格納場所がどこで どんな経路を通じて誰が一貫性（完全性ともいう）チェックと復号をするのかによって いろいろ変わるのかもしれないけど、一般的にはEncrypt-then-Macといって （１）最初に暗号化する （２）次にその暗号文のキー付きハッシュをとる という順番になる もとのデータを利用したいときは （１）まず暗号文の完全性をチェックする。エラーを検出したらそこで終了 （２）暗号文を復号する という手順になる この順番にすることで、勝手なデータを復号処理に入力して、その出力結果を観測して 暗号の安全性を破る攻撃（選択暗号文攻撃）を防ぐことができる あるいは最初から秘匿とメッセージ認証の機能をあわせもつ 認証付き暗号（認証子付き暗号ともいう）を使うという手もある 523 名前：デフォルトの名無しさん mailto:sage [2012/04/26(木) 11:42:17.37 ] そこらへんの暗号化や署名したデータのフォーマットを各自が考えると相互運用性や 可搬性が低くなるからCMS(Cryptography Message Syntax)ってものがある。RFC3852読むといいよ。 CMSのデータはネストできる構造になってるんだが、そこで、Digested-Dataようはハッシュしたデータの 項みると、 Typically, the digested-data content type is used to provide content integrity, and the result generally becomes an input to the enveloped-data content type. となってて、一般的にハッシュしたデータはEnvelped-Data(要は暗号化)の入力になるとは書いてある。 524 名前：デフォルトの名無しさん mailto:sage [2012/04/26(木) 11:47:45.07 ] Win8でWindows APIにCNG DPAPIってデータを保護するAPIが追加されるらしいんだけど、それが CMS使ってて、その構造をttp://msdn.microsoft.com/en-us/library/windows/desktop/hh706817%28v=vs.85%29.aspx でみると、一番外側が図で類推する限り、Enveloped-Dataになってて、それで、 >>513では、ハッシュを先にするべきなのかなとハッシュを先に書いた。 525 名前：デフォルトの名無しさん mailto:sage [2012/04/26(木) 11:54:55.18 ] >>522はtools.ietf.org/html/rfc5083のAuthenticated Enveloped Dataかね。 526 名前：デフォルトの名無しさん mailto:sage [2012/04/26(木) 12:29:28.11 ] まぁ、RFC3852(5652),RFC3370,RFC5754,RFC3565を気合入れて読みながら、Windowsの CryptoAPIのCMSを操作する関数をここ2週間いじくりまくって身に付けた程度の知識だから、 Secruity Condisderationsとかそこまでは手回ってなく、詳しくはわからんけど、 選択する暗号アルゴリズムやハッシュアルゴリズムを強度が高いものにして、 後は鍵管理をしっかりしとけば、ハッシュした後、暗号化しとけばとりあえず 問題ないとは思うけどな。自分だけ復号化できればいいんだったら。わざわざ、 メッセージ認証する必要ねぇとは思う。 527 名前：デフォルトの名無しさん mailto:sage [2012/05/11(金) 13:32:46.81 ] OpenSSLのRAND_bytes()を使おうと思うのですが、 RAND_add()は、常駐してエントロピーを収集するようなプログラムが使うもので、 ユーザープログラムは、RAND_bytes()を呼び出すだけで済むという認識で正しいでしょうか？ 528 名前：デフォルトの名無しさん mailto:sage [2012/05/11(金) 15:01:32.57 ] RAND_add()は、RAND_seed()とほぼ同じ関数だよ。 乱数の乱数性を強化する際に使う関数。 >>527はRAND_bytes()を呼び出すだけという認識でいいよ。 529 名前：デフォルトの名無しさん mailto:sage [2012/05/11(金) 16:37:59.92 ] 毎回種蒔くのは面倒だと思っていたので、すっきりしました 回答ありがとうございました 530 名前：デフォルトの名無しさん mailto:sage [2012/06/05(火) 18:30:28.73 ] CIPHERUNICORN-A、Hierocrypt-3、SC2000の ソースコード探してるのですけど 在りかを知ってる方がいれば教えて頂きたいです。 …できれば言語がCだと有難いです。 531 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 20:56:26.20 ] Hierocrypt-3はあった ci.nii.ac.jp/naid/10016220863 532 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 09:10:40.65 ] >>531 ありがとうございます！ 非常に助かりました。 533 名前：デフォルトの名無しさん [2012/06/15(金) 13:43:33.76 ] これからはCDのコピー禁止フラグのような軽いプロテクトも流行るんじゃないかな。 534 名前：デフォルトの名無しさん mailto:sage [2012/06/15(金) 13:47:20.86 ] 何も重いプロテクトをかけるだけがいいことでは無い。 プロテクトを外す行為が違法ならあえて軽いプロテクトにして、外した者を どんどん逮捕したらいい。 535 名前：デフォルトの名無しさん mailto:sage [2012/06/15(金) 14:15:25.05 ] フラグ1個でも技術的保護手段っていうの？ 536 名前：デフォルトの名無しさん mailto:sage [2012/06/15(金) 14:17:14.63 ] 要はコピー禁止の意志がファイルに付いていると認められるということ。 537 名前：デフォルトの名無しさん mailto:sage [2012/06/17(日) 13:24:12.69 ] >>534 違法行為で暗号を解読した証拠は裁判所で証拠にならないので 犯罪に使われた解読後の結果が証拠になるなら、他者の所有物の解読は 違法ではないという判断になるんじゃない？ 538 名前：デフォルトの名無しさん [2012/09/17(月) 09:35:08.91 ] 2ch_prog20004140935082220001 のSHA256ハッシュを取ると 00000000015FBAE7DCBE0642BE86EAD87962183AF994884DD2159188B90EF494 で0のビットが先頭に39個続く 2ch_progから始まる文字列でこれより長く0のビットが続くの探してみて 539 名前：デフォルトの名無しさん [2012/09/18(火) 21:01:37.05 ] 【IT】マイクロソフトが発見！中国製PCに出荷時からウィルス「中国製のパソコンや情報端末の購入には、慎重になったほうがいい」★２ uni.2ch.net/test/read.cgi/newsplus/1347879086/ ＊＊＊＊＊＊＊＊＊＊＊＊ 可能性としてありうる。 １、中国製パソコンの画像データには以下の実行 プログラムソースがふくまれてる。 ２、有事の際には中国当局からネットで全世界の パソコンに指示を出し、機能停止が可能。 ３、夜間定期的に送受信メールやテキストファイル、PDFの中身を 自動的にスキャンして、中国に対する不利益な動きに対し 自動的に中国当局に警報メールを発信する。もちろんIPアドレスから そのPCの位置情報、個人情報のすべて。 ４、上記を検出、ソース表示をしようとする動きに対し、フリーズ、暴走する機能内蔵 技術的にはすぐにでも可能。 というかすでに中国出荷の全PCやBIOS のレベルでインスコ済みの可能性がある。 　 ＊＊＊＊＊＊*************** 540 名前：デフォルトの名無しさん [2012/10/10(水) 21:46:53.81 ] 保守 541 名前：デフォルトの名無しさん [2012/11/06(火) 14:51:31.15 ] 不正防止とコスト 市場はどっちを選択するんだろうなぁ 542 名前：デフォルトの名無しさん mailto:sage [2012/11/06(火) 15:19:32.37 ] 誰かがコストを選択して痛い目に遭ってから、不正防止を選択します。 顕在せぬ危険性について、株主が理解することは不可能でしょ。 どっかの株価大暴落がないと駄目だろうね。

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef