■暗号技術【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/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でいいよ。

**デフォルトの名無しさん** · 2012/04/26(木) 02:50:46.22

コンテンツのハッシュをとってから暗号化するのと、
暗号化してからキー付ハッシュをとるのとどっちがいい」？

**デフォルトの名無しさん** · 2012/04/26(木) 04:18:20.27

>>521
暗号文とハッシュ値、ハッシュの秘密鍵と復号鍵の格納場所がどこで
どんな経路を通じて誰が一貫性（完全性ともいう）チェックと復号をするのかによって
いろいろ変わるのかもしれないけど、一般的にはEncrypt-then-Macといって

（１）最初に暗号化する
（２）次にその暗号文のキー付きハッシュをとる

という順番になる

もとのデータを利用したいときは

（１）まず暗号文の完全性をチェックする。エラーを検出したらそこで終了
（２）暗号文を復号する

という手順になる

この順番にすることで、勝手なデータを復号処理に入力して、その出力結果を観測して
暗号の安全性を破る攻撃（選択暗号文攻撃）を防ぐことができる

あるいは最初から秘匿とメッセージ認証の機能をあわせもつ
認証付き暗号（認証子付き暗号ともいう）を使うという手もある

**デフォルトの名無しさん** · 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(要は暗号化)の入力になるとは書いてある。

**デフォルトの名無しさん** · 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では、ハッシュを先にするべきなのかなとハッシュを先に書いた。

**デフォルトの名無しさん** · 2012/04/26(木) 11:54:55.18

>>522はhttp://tools.ietf.org/html/rfc5083のAuthenticated Enveloped Dataかね。

**デフォルトの名無しさん** · 2012/04/26(木) 12:29:28.11

まぁ、RFC3852(5652),RFC3370,RFC5754,RFC3565を気合入れて読みながら、Windowsの
CryptoAPIのCMSを操作する関数をここ2週間いじくりまくって身に付けた程度の知識だから、
Secruity Condisderationsとかそこまでは手回ってなく、詳しくはわからんけど、
選択する暗号アルゴリズムやハッシュアルゴリズムを強度が高いものにして、
後は鍵管理をしっかりしとけば、ハッシュした後、暗号化しとけばとりあえず
問題ないとは思うけどな。自分だけ復号化できればいいんだったら。わざわざ、
メッセージ認証する必要ねぇとは思う。

**デフォルトの名無しさん** · 2012/05/11(金) 13:32:46.81

OpenSSLのRAND_bytes()を使おうと思うのですが、
RAND_add()は、常駐してエントロピーを収集するようなプログラムが使うもので、
ユーザープログラムは、RAND_bytes()を呼び出すだけで済むという認識で正しいでしょうか？

**デフォルトの名無しさん** · 2012/05/11(金) 15:01:32.57

RAND_add()は、RAND_seed()とほぼ同じ関数だよ。
乱数の乱数性を強化する際に使う関数。
>>527はRAND_bytes()を呼び出すだけという認識でいいよ。

**デフォルトの名無しさん** · 2012/05/11(金) 16:37:59.92

毎回種蒔くのは面倒だと思っていたので、すっきりしました
回答ありがとうございました

**デフォルトの名無しさん** · 2012/06/05(火) 18:30:28.73

CIPHERUNICORN-A、Hierocrypt-3、SC2000の
ソースコード探してるのですけど
在りかを知ってる方がいれば教えて頂きたいです。

…できれば言語がCだと有難いです。

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

Hierocrypt-3はあった
http://ci.nii.ac.jp/naid/10016220863

**デフォルトの名無しさん** · 2012/06/07(木) 09:10:40.65

>>531
ありがとうございます！
非常に助かりました。

**デフォルトの名無しさん** · 2012/06/15(金) 13:43:33.76

これからはCDのコピー禁止フラグのような軽いプロテクトも流行るんじゃないかな。

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

何も重いプロテクトをかけるだけがいいことでは無い。
プロテクトを外す行為が違法ならあえて軽いプロテクトにして、外した者を
どんどん逮捕したらいい。

**デフォルトの名無しさん** · 2012/06/15(金) 14:15:25.05

フラグ1個でも技術的保護手段っていうの？

**デフォルトの名無しさん** · 2012/06/15(金) 14:17:14.63

要はコピー禁止の意志がファイルに付いていると認められるということ。

**デフォルトの名無しさん** · 2012/06/17(日) 13:24:12.69

>>534
違法行為で暗号を解読した証拠は裁判所で証拠にならないので
犯罪に使われた解読後の結果が証拠になるなら、他者の所有物の解読は
違法ではないという判断になるんじゃない？

**デフォルトの名無しさん** · 2012/09/17(月) 09:35:08.91

2ch_prog20004140935082220001

のSHA256ハッシュを取ると
00000000015FBAE7DCBE0642BE86EAD87962183AF994884DD2159188B90EF494
で0のビットが先頭に39個続く

2ch_progから始まる文字列でこれより長く0のビットが続くの探してみて

**デフォルトの名無しさん** · 2012/09/18(火) 21:01:37.05

【IT】マイクロソフトが発見！中国製PCに出荷時からウィルス「中国製のパソコンや情報端末の購入には、慎重になったほうがいい」★２
http://uni.2ch.net/test/read.cgi/newsplus/1347879086/

＊＊＊＊＊＊＊＊＊＊＊＊
可能性としてありうる。

１、中国製パソコンの画像データには以下の実行
プログラムソースがふくまれてる。

２、有事の際には中国当局からネットで全世界の
パソコンに指示を出し、機能停止が可能。

３、夜間定期的に送受信メールやテキストファイル、PDFの中身を
自動的にスキャンして、中国に対する不利益な動きに対し
自動的に中国当局に警報メールを発信する。もちろんIPアドレスから
そのPCの位置情報、個人情報のすべて。

４、上記を検出、ソース表示をしようとする動きに対し、フリーズ、暴走する機能内蔵

技術的にはすぐにでも可能。
というかすでに中国出荷の全PCやBIOS
のレベルでインスコ済みの可能性がある。
　
＊＊＊＊＊＊***************

**デフォルトの名無しさん** · 2012/10/10(水) 21:46:53.81

保守