■暗号技術【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/03/24(土) 23:03:49.37
ノートPCが盗まれたとき、ログインパスワードの強度が重要だと思うんだけど、
WindwosのNTLMv2認証って信用できるの？
2012/03/24(土) 23:12:51.13
盗まれる前提ならパスワードだけで防御するのが間違ってる
2012/03/24(土) 23:18:08.70
盗まれない前提ってアホかw
2012/03/25(日) 01:19:01.76
NTLMv2認証の説明をざっと読んだ限りでは、ノートが盗まれたときのダメージを
左右する種類のものではないように思うんだけど。サーバからのチャレンジデータをどうこうらしいし。

WindowsならUltimateにしてBitlocker使うのが一番手っ取り早いんですかね？
2012/03/25(日) 08:21:37.54
Windowsの暗号化ファイルシステムは、XPで、AES256+RSA1024。
しかし、ログインされると丸見え。
2012/03/25(日) 09:23:48.32
なるほど、レスありがとうございます。。
つまりXP＋暗号化ファイルシステムのノートが盗まれた場合、
犯人のPCにノートPCから取り出したHDDを変換ケーブル等で繋いでもAES256+RSA1024が
破られない限りは大丈夫。
しかし、そのままノートをネットワークで犯人のPCで繋いでネットワークログオン(ここでNTLMv2？)が
成功するとファイルが丸見えになるということですね。それなら左右しまくりますね。
2012/03/25(日) 13:45:34.73
ログインを成功させられるならネットワークいらねえよ
2012/03/25(日) 14:34:56.77
いや、だからNTLMv2の安全性がどうこうの話になったんでしょ。
まあチャレンジレスポンスならヒントにはならなそうだけど。
パスワードがわかればネットワーク必要ないとかいうのは的外れ。
2012/03/25(日) 17:40:07.97
ローカルログオンでもNTLMv2認証。
2012/03/26(月) 21:47:22.06
NTLMv2はMD5だからもうダメだろう。
2012/03/28(水) 23:41:27.37
＞まあチャレンジレスポンスならヒントにはならなそうだけど。
チャレンジレスポンスは、これを使用したネットワーク認証の通信部分は強くなるが、他の面では弱くなるぜ？
この辺分かってないやつが多いが。
チャレンジレスポンスに対応してるってことは、盗まれた場合の強度は逆に弱くなっているということ。
なぜならパスワードデータベースにソルトが使えなくなるから。
2012/03/28(水) 23:45:45.71
＞パスワードがわかればネットワーク必要ないとかいうのは的外れ。

どういう意味か分からんが、盗まれたらオフラインでパスワードデータベースをクラックできる。
ネットワークは関係ないな。
で、このパスワードデータベースのクラックは、チャレンジレスポンスに対応してるせいで逆に楽になってるわけだよ、
2012/03/28(水) 23:59:55.79
そこで生体認証ですよ。
2012/03/29(木) 14:31:30.65
MD5ハッシュって破られてるんだっけ？
2012/03/29(木) 19:24:25.04
強衝突耐性については、だいぶ弱いとわかっている
2012/04/03(火) 00:18:29.10
新規に採用するのは非推奨、というあたりではないのん？
いや知らんけど
2012/04/03(火) 08:02:20.07
新規に採用するのにSHA2以外はありえんだろ。暗号学的強度が必要なら。
とは言え、ひところ危惧されたほどSHA1は弱くなかったということなので、
既にあるものまでなにがなんでもSHA2にしろ、というほどでもないかな。
2012/04/03(火) 11:40:54.97
使い所による。
署名のダイジェストとかに使うなら避けるべき。
パスワードハッシュとかなら別に好きにしろ。
まあパスワードハッシュなら本当はPBKDF2使うべきだが。
PBKDF2ならベースハッシュが多少弱くてもあんまり実害無い。
405営利利用に関するLR審議中＠詳細は自治スレへ
垢版 |
2012/04/03(火) 15:48:13.58
一様かつ予測不能な乱数を生成したいので、メルセンヌ・ツイスタを使おうと思いました。

しかし、メルセンヌ・ツイスタは、一様な乱数を生成するものの、乱数の履歴から、
2^19937-1 のどこの地点から乱数を取ってきてるのか分かったら、次の乱数を予測
されてしまうので安全ではない、暗号学的ハッシュ関数を通す必要がある、らしいですね。

なるほどそういうものかと思って、SHA256 で切り刻むコードを書きました。
http://www.sourcepod.com/vupewt10-7054

しかし、これは安全なのですか？
ハッシュ操作してるとバレてるなら、攻撃者も同じように、メルセンヌツイスタの周期まるごと
SHA256でハッシュ化したデータを抱えて、いままでの数値の履歴から、結局、次の数値が
分かってしまうと思うのですが。

（ちなみに、本筋とは関係ないですが、単なる sfmt のコードはこれです。http://www.sourcepod.com/uhhyen53-7055 ）
2012/04/03(火) 15:57:27.78
僕は素人だけど、 2^19937-1 個のハッシュ値を丸ごと抱えるってなかなかできないと思うよ
407営利利用に関するLR審議中＠詳細は自治スレへ
垢版 |
2012/04/03(火) 16:39:49.02
>>405
しかし、それなら、同じ理由で素の 2^19937-1 の値使うことには問題なさそうに見えます

http://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%AB%E3%82%BB%E3%83%B3%E3%83%8C%E3%83%BB%E3%83%84%E3%82%A4%E3%82%B9%E3%82%BF
> メルセンヌ・ツイスタは線形漸化式によって生成されるため、予測可能である

線形漸化式では暗号に使えないなら、どうすればいいんだろうか
2012/04/03(火) 19:02:41.11
予測可能の意味を、たぶん取りそこなってるのかな。

MTのナイーブな実装の場合、内部ビットの個数分（19937ビット）の出力列があれば、
その後の出力列が予測可能でしょ？

たとえば線形合同法 X(n+1) = (a*X(n)+b) mod p で、X(n) の情報があれば、
X(n+1) を予測可能であるように、全体の空間に比べてごくわずかな情報から、
次の数が予測可能である、ということを、この場合に「予測可能」と言うわけ。
2012/04/03(火) 19:14:41.71
生成した乱数列の羅列があればステータスを確定出来るんだろ？
ハッシュを通せば元の乱数列は不明だからステータスを確定出来ないだろ。
元の乱数が分からんと言うことは、周期分順に試していかないと、
どの部分か見つけられないって事。

全然違う。
2012/04/03(火) 19:21:35.46
極端に言うと例えば、

1から順の整数列が有るとする。
この整数列のあるところから開始する。
例えば123456789123456789だったとする。
当たり前だが予測できる。
ハッシュを取ってみる。
もう予測出来ないだろ。
元の値が123456789123456789だってことが分からないから。
これを調べるには、例えば1から順に全部ハッシュを取っていって、同じになるまで探さなきゃいけない。

411営利利用に関するLR審議中＠詳細は自治スレへ
垢版 |
2012/04/03(火) 20:05:37.02
>>408
ワタシは SFMT の内部構造は全く知らず、複雑でわからないんですが、ともかく、
内部ビットの個数分の出力さえあれば、総当りとかじゃなく、なにか逆算とかすれば、
内部ステータスが分かって、その後の出力も予測できるってことでしょうか。


コードで書いたとおり、256bit分の乱数を、sha256ダイジェスト生成API通して受け取った別物の256bitを乱数として
使えばよさそうですね。
2012/04/03(火) 21:38:07.61
まあそういうこったね。

内部ビット数と同じとは限らず、周期よりずっと短いデータで内部状態を逆算できる場合も同じだね。

もっと直観的な説明でいくと、内部状態が結果列から逆算できる→予測できるってこと。
つまり一方向にしか導けない条件が必要であり、これってつまるところ暗号ハッシュと同等の性質をもつものしかダメってこと。
単なる乱数生成期で暗号ハッシュと同等の一方向性を持てるわけないよね。
2012/04/03(火) 23:59:11.83
>>412
>>412
2012/04/04(水) 01:48:22.01
使う側が互換する共通のアルゴリズムで使用すれば確率的に破られる運命だろ。
アルゴリズムを検証できる環境そのものが複製できちゃえばいつかは解析される。

合理的な共通規格そのものが暗号が破られる原因である。非合理で他に類似性が
なければ非常に単純であってもそれを推測することすらできない。
手品とか種がばれれば非常に簡単なのに、分からない場合は絶対に解明できな
かったりする。
2012/04/04(水) 01:54:44.62
>>414
それは現代の暗号の考え方に反する。アルゴリズムを公開してもなお安全であることを追求する、のがポイントだ。
いいかえると、暗号の安全性が鍵の秘密にのみ依存するのが理想の暗号だ。
2012/04/04(水) 03:18:50.66
全てのセキュリティは鍵のみに宿る。

って一言で言えないのかしら。
2012/04/04(水) 06:12:49.46
そうなったのは、暗号については過去2000年ぐらいの歴史のうち、たかだか最近100年のことだからな。
2012/04/04(水) 11:13:56.70
だから何？
2012/04/04(水) 12:04:24.71
今世の中に存在するもので、100年以上昔に進歩が終わった技術で出来てるものなんてなかなか無いぜ。
2012/04/04(水) 12:13:38.36
>>417
過去の考え方や >>414 は安全を追求していない。内部造反者等も考慮しなければならない。

>>416
ナイスですね。
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
不必要である、なくてもいいという反論になってないな。
残ってるのは、歴史的理由でしょう。
元々 鍵+塩　で後から ストレッチングが追加されただけ。
441営利利用に関するLR審議中＠詳細は自治スレへ
垢版 |
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
アルゴリズムわかってるのを暗号というのはどうなんかね？
ネタバレしたら手品にならんような
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の容量の壁にごっつんこだな。
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
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環境？
その手のやつは、ある程度時間経つと鍵変えてるような気がするけど
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
2012/04/11(水) 23:51:43.34
>>483
残念だがその意見は違うだろう。
公開暗号系を使用すれば、途中の経路で通信内容が全部傍受されたとしても、暗号を解読することは事実上不可能だ。
末端でみえようとみえまいと、あるいは途中の経路でみえようみえまいと、プロバイダがすべての通信のログを取得しようと、安全性には全然関係ない。

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

■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況