■暗号技術【ROUNDsurea】■

1 ：2007/05/28 〜 最終レス ：2013/10/06

前スレ
■暗号技術【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
罰としてスレタイで辱めてやる

2 ：

1乙

3 ：

ところで、暗号化後のファイルの圧縮率の悪さなら
平文（元ファイル）は2GBの0埋めで実験したんだが
おいらが試した限り一度もファイル長が縮まなかった、
そこそこの速度のある暗号があるんだが、誰か試してみてくれないか。
zip、rarはWinRARの最高圧縮モード+パスを格納しない、lzh、bhはlhaplusのデフォルトで試したんだが。

lasrmとか何とか言う奴だった気がする。最新版の評価と解析ｷﾎﾞﾝ

4 ：

それが正しい。圧縮率が悪いのは仕様です。

5 ：

エンコード後のエントロピーが偏る暗号方式なんて使い物にならないべ?

6 ：

だから低脳がスレ立てるなと一体何度言わせれば・・・

7 ：

あたりまえだ

8 ：

理想的なのは分かったが、「全く縮まない」となると
擬似乱数に使えないか？「そこそこ速度はある」らしいし。
少なくとも2GBにかけて安定している（？）乱数表の生成にはもってこいだと考えるが、どうだろう？

9 ：

ある平分を暗号化した暗号文が擬似乱数として使えるかどうか？
「使える。」が答え。
だけど、擬似乱数生成速度が暗号化速度と等しいわけで、暗号化関数を擬似乱数生成関数としてみた場合、低速。
それだったら最初から擬似乱数生成関数を使え。という話。

10 ：

!(Φ＿Φ+)
暗号技術という物はNet.に於いて使うのであれば、
「access.を知られない様に出来ないか？」という事を基に創られる物の筈です。
疑問を持たなくては為らないのが…
最も、完全な暗号を読み取れるのか？

11 ：

>>10『追加』
開発者は偉大だと思います。
それでは完全な配列を幾つ創ったのか？

12 ：

なんかよくわからんがあぼーんしておくか

13 ：

>>12
!(Φ＿Φ+)
『あぼ〜ん』を使うのですか？

14 ：

　　 {あぽ〜ん}
　　　 ζ
　 　　　!(+Φ＿Φ)つ√ζ
　 　 +⊂.　+ 〆∂ 　 {Ж}
　 　 "〆∂∂
　 　〆〆
　 .:"

15 ：

!(-＿Φ+){0000000000Ｘ=9876543210=x}
絶対に解けません。

16 ：

　 　 　 |

17 ：

>>16
!(-＿Φ+){click text all selection.をどうぞ。}

18 ：

!(-＿Φ+){ ... }
　z　y　x|

19 ：

　 　 　 |
!(-＿Φ+){確認です。}

20 ：

　 　 　 |
!(-＿Φ+){完璧です。}

21 ：

　 　 　 |xyz

22 ：

!(-＿Φ+){式の始まり。}
　 |aabcdefghijklmnopqrstuvw|xyz
zyx|wvutsrqponmlkjihgfedcbaa|

23 ：

!(-＿Φ+){ずれました。}
　 |aabcdefghijklmnopqrstuvw|xyz
zyx|wvutsrqponmlkjihgfedcbaa|

24 ：

!(-＿Φ+){ずれました。}
　 |aabcdefghijklmnopqrstuvw|xyz
zyx|wvutsrqponmlkjihgfedcbaa|

25 ：

!(-＿Φ+){ずれました。}
　 |aabcdefghijklmnopqrstuvw|xyz
zyx|wvutsrqponmlkjihgfedcbaa|

26 ：

!(Φ＿Φ+){表記は出来るのですが…}

27 ：

!(Φ＿Φ+){ 覚えたので消してしまいました。}

28 ：

!(Φ＿Φ+){忘れては為らない大切な事は…}
『どの様な暗号でも構成には配列が必ず在る』
という事ですか…
『0000000000Ｘ=9876543210=x』
にも勿論、在ります。

29 ：

!(-ｙΦ+){ fireFox！}
▽
△

30 ：

!(Φ＿Φ+){My, sory.}
通常、click.をするとtext.を選択します。
式の構成を表示しなくても何となくは分かり使えるかも知れないです。

31 ：

符号化と暗号化の本質的な違いや如何に

32 ：

符号化：たとえば、文字列を2進数表示する事
ABC→01000001 01000010 01000011
暗号化：主に符号化などをして扱いやすくなったデータを、元に戻す事が可能な手段で変更を加える事

33 ：

リードソロモン符号は暗号化ですか？

34 ：

ASCIIのテキストファイルをZIPで圧縮して
BASE64にかけたものをSMTPで送信しても
単なる多重符号化であって暗号化じゃないのだよな

35 ：

ZIPで圧縮するときにパスワード入れれば医院で内科医

36 ：

!(Φ＿Φ+)
理解する事が出来ました。
install.毎に暗号を組む事にします。

37 ：

Goppa符号は暗号化ですか？

38 ：

>>32
暗号の要件には鍵の存在が含まれると思うが

39 ：

いい加減に>>32を許してやれよ。

40 ：

どんな符号化であっても、暗号になりえるが、
誰でもその中身が見れるような情報が公になっているのであれば
その時点で暗号とは呼べない。
Winnyのキャッシュファイルも暗号とかいっているけど、
誰でもその中身を見ることが出来るので暗号ではない。

41 ：

あぁ、金庫の上に鍵が放ってあるっていう話か。

42 ：

そういえばなんで Winny はオニオンルーティングとか使わんかったんかねぇ。

43 ：

!(Φ＿Φ+)
暗号はとても大切だと同感します。
なので、個人で作成した暗号は確りとsystem.に教えてあげています。

44 ：

47滋賀暗号に関してど素人だったから。
共通鍵の扱い方とかで分かるだろ。

45 ：

!(ΦｙΦ+)
不機嫌です… かなり危険な暗号を創りました。

46 ：

どうせ作るなら「安全」な暗号創ってくれ

47 ：

安全な暗号なんてOTP暗号で十分。
鍵の受け渡しが出来ない？そんなもんはDH鍵交換で生成すればいい。

48 ：

OTPの鍵をDH鍵交換で共有すると、安全性の根拠が
情報理論的安全性から計算量理論的安全性（DH問題の難しさ）に変化しますね
実用的な長さの鍵（乱数表）を共有するために必要な通信回数／計算回数もかなり大きくなりそうです

49 ：

64bitのMに対して48bit程度のa,bを通信し、計算された値の下位32bitを用いるとか。
うん？それだとupするのに必要なdown量がup量を超えると言う不思議な現象が発生するな。

50 ：

!(ΦｙΦ+){ 【暗号】成功しました。}
999　 999　 999　 999
　 999　 999　 999　 999
999　 999　 999　 999
　 999　 999　 999　 999

51 ：

>>50『続』
!(ΦｙΦ+)
忘れていました。一瞬ですが？tty.出力されました。
組み合わせて使う事にしました。

52 ：

ちょっとスレ違いですが、ファイルを相互にやり取りする際の暗号化って
意味有るんですかね？
(パスワードキーで復号するタイプのもの)
それこそZIPでパスワードを設定した方がよほど使い勝手が良いですよ。
結局どちらもパスワードを解読されたら同じじゃないですか。
それなら圧縮されている方が、まだ良い。
(圧縮自体も暗号見たくなりますし)

53 ：

圧縮と暗号化を同列にしてるのはなぜ？

54 ：

>>53
例えば、ハックする方からすれば、暗号化されていようが圧縮されていようが、
パスワードを解析するだけだから。
もちろん技術的に異なる事はわかるが、それは内部の問題であって、
外部からはどちらも一緒なんでは？って事です。

55 ：

>>52
パスワード付きZIPは要するに圧縮＋暗号化という処理をしているだけよ
暗号化してないと思ってた？

56 ：

>>55
へー、そうなんですか。
圧縮だけだと思っていました。

57 ：

結局何が言いたかったんだろう…

58 ：

Rー

59 ：

ZIPの暗号化はパスワードがクラックされやすいから
使い物にならないって言いたかったんだと E.S.P.

60 ：

そりゃブルートフォースアタックで簡単にクラックできるようなパスワード長にするほうが悪い。
パスワードを次の英文にした時に数日でクラックできるかどうか試してみ
I am the bone of my sword. Steel is my body, and fire is my blood.

61 ：

せめて Challange Response にすべき

62 ：

>>60
それ、なんていうエミヤの詠唱？

63 ：

>>６１
馬鹿は黙ってた方がいいよ

64 ：

ファイルにパスをかけるフリーツールで完全暗号のツールはありますか？ラプラスやWinRARは(全角文字など入れて少し長めのパスを設定しておけば)現在の技術で数百年〜数千年以上は解除不能な完全暗号になるでしょうか？
(ラプラスやWinRARはバーナム暗号なのでしょうか？)よろしくお願いします。

65 ：

完全暗号の定義よろ

66 ：

>>64
ED 暗号
でググレ

67 ：

attachecase

68 ：

>>64
ラプラスやらWinRARやらは暗号化ソフトの名称だから、それだけでは何とも言えない。
「少し長め」の定義よろ

暗号化目的で使ってるならあれは共通鍵暗号だから、普通に企業とかで使う分には
内部は128bitとか256bitとかあれば十分では？
3DESはbit長の割に強度に問題あるがなー。

69 ：

個人的には、>>3が言ってたツールがお気に入り。
空間は256bitらしいが、そこそこの速度はあるし。

70 ：

OpenSSLでいいじゃん。

71 ：

「256bitAES使用で強固なセキュリティ」
とか謳う暗号化ソフトあるけど
暗号化による強度って暗号化手法もさることながら
キーの管理に寄るところの方が大きいと思うんだが
そこら辺まできちんと説明されている暗号化ソフトって少ない気がする
いくら鍵長が長かろうがユーザーが入力したパスワードから生成していたら
イタズラ防止程度にしかならない気がする…
現実的に人間が覚えられる長さ・パターンなんて限界があるし
ここら辺って暗号化ソフトを導入している企業でも理解できていないところ多いような…

72 ：

暗記できないほど複雑でメモが必要な鍵と、暗記できる鍵のどちらが
安全かは微妙な問題だな。

73 ：

メモ残し厳禁
↓
結局忘れるのでその都度リセット
↓
管理者だけ何でもあり
↓
管理者のパスワードは？
↓
毎回一緒有効期限なし暗記可能かなり単純

74 ：

そこで催眠術か何かを併用したランダムな英数字による12桁のパスワードの丸暗記ですよ

75 ：

>>73
笑えない

76 ：

admin/admin
administrator/admin
の会社を何件か知ってる

77 ：

奇遇だな
漏れも知ってるよ

78 ：

それは知らないが
system/weblogicadmin
の会社なら知ってる

79 ：

悲しいかなadministratorにパスワードなしのとろころもあるのが現実

80 ：

administrator/h16saitama
の高校を一つ知ってる。

81 ：

返信ありがとうございます
PCの知識はあまりないのですが、
>>68
「ラプラスやらWinRARは共通鍵暗号」というのはどういうことでしょうか？
全角文字(漢字なども含む)や半角英数字などを混ぜて10〜15文字のくらいのpass(メモなどせず頭の中で暗記)をつけたとしてもラプラスやWinRARなどの開発者達にはすぐに解読されてしまうということでしょうか？
普通に企業などで使うものではなく「そのようなソフトの開発者や高度な技術者など、どのような人を対象にしても」としたとき解除不能なpass(or偽造など？)を(できればフリーの)ツールで付けようと考えたら難しいのでしょうか？
(無理の場合、比較的より困難なpassの付け方、passの羅列の例＆ツールなどよかったら知りたいです。)　
《やっとネットが繋がったので(夜は使えなくなりますが‥)「共通鍵暗号」を調べたら暗号化の時と復号化のときに使うpassが同じということみたいですね‥、すみません‥。》
あとpassをかけるのが目的ならラプラスで圧縮設定3でzip非圧縮にすると圧縮の時間が短縮できるので、自分はそうしてます。そうしてもlzhは非圧縮ではなく普通に圧縮されました。
自分は1度lzh(またはzip)で(passつけるorつけないで)圧縮した後、そのファイルのファイル名を変えたりして、さらにそれをpassつきzipで圧縮すると中のファイル名も、もちろんファイル自体も人に伏せることができるので、そうしてます。
一番上のようにやはり「どのような技術を用いても少なくとも数百年以上解読不能なpassファイルを作る。
(passは自分の頭の中で暗記できるくらいの長さのものorメモなどで長いpassを保存するとしてもそのメモを他人に少なくとも今の技術で数百年以上知られないようにする保存方法がもしあれば(ないですかね笑)そうして。)」ということは難しいのでしょうか？
bitとかよくわかりません・・。

82 ：

>>71
順番は別々でも半角英語8文字　数字3文字　数字4文字の15文字を組み合わせるとして、他で質問したところラプラスは秒間で35万個ほどのパスワードが検索できるので、上の組み合わせだと5垓個ほど組み合わせがあって、50万世紀ほどかかる計算になるらしいです。
それで、この計算は完全にランダムな文字列を総当りで解読した場合なので、パスワードが意味のある単語などになっていた場合に、上記の(英語8文字)が辞書探索の1万語目で見つかったなら、3日で解読されるらしいです。
また、zipのパスワードは安全性が低く「パスワードが正しいかの判断の前に、それがパスワードの可能性があるかどうかを判定する」らしく、それでも数桁の速度アップとなるだけで、これでも50万世紀から数桁減ったところで生きているうちには解読できないらしいです。
でももし(ソフトの開発者などが)ファイル自体を調べて解析するやり方が存在していたりしたら解読されてしまいますかね‥。

自分はドライブ全体を暗号化するより個別のファイルの暗号で今の技術では何百年、何千年以上暗号を解除することができないツールのほうに興味があります。
今ある高度な暗号の技術のツールを2種類くらいつかって2重以上で複雑なpassを掛けてれば解読するのはより難しくなるでしょうか？
ファイルやフォルダにpassをかけることのできる(できればフリー)ツールで今の技術で高度なpassをかけることのできるものが知りたいです。
ラプラス、WinRAR以外にもっと高度なものは何かあるでしょうか？より解読が難しく(できれば完全暗号にでき、)暗記できるくらいのpassの組み合わせの例など知りたいです。長くてすみません‥。＆寝不足です‥。

83 ：

>>64
共通鍵暗号ってのは暗号化するときに使う鍵と復号化するときに使う鍵が
同じ物を言う。だから、パスワードをかけるのは共通鍵暗号に似ている。
WinRARの開発者は確かにRAR圧縮に関してかなりの知識を持っている事が予想されるが、
その人がその暗号を簡単に解除することが出来るのならそれは「隠すことによる秘密保持」
に該当するので、おそらくそんな事はない。
（もちろんそんな保証はないが、そんな事があればどんなパスワードでも数秒で解除する類のソフトが
出回っているだろう。）
良質なパスワードなら、乱数サイコロを百回くらい振ればいいのが作れるかと。
攻撃者が個人か団体かに因ってくる。
例えばteam2chは団結力とか凄いので(2000年以上かかる計算を2年で終わらしたとか何とか）、
パスワード長は攻撃を受ける期間とその速度・突破されたときの被害等を考慮して決める必要があると思う。
「どのような技術を用いても」という時点で、まず諦めていただきたい。
例えば。その情報を盗みたがっている人が実はピッキングが得意な泥棒で、情報が入力されているコンピュータそのものを持ち去っていくかもしれない。
例えば。その情報を盗みたがっている人が実はプロパイダの管理者で、中間者攻撃を仕掛けてくるかもしれない。
例えば。暗号化された情報を手に入れた人が実は割と新しいスーパーコンピュータの所持者で、物凄い勢いで解読を試みるかもしれない。
例えば。暗号化された情報を手に入れた人が実はこの暗号に関して天才的な頭脳の持ち主で、暗算と勘でパスワードを求めるかもしれない。

84 ：

長文のうえに「らしいです」ばかりで読む気がしない。

85 ：

だから完全暗合ってなんだよ

86 ：

じゃなくて完全暗号ってなんだよ

87 ：

どんな鍵を使っても復号できない暗号

88 ：

完全暗号って量子暗号のことか？

89 ：

バーナムかなあ。

90 ：

いやXORだろ

91 ：

第9回NSUGシンポジウム報告
www.nsug.or.jp/readme/no26/sympo98.html -キャッシュ
鍵長とその強度に関して、100MIPSのコンピュータを100台同時に動かし
たときの解読時間が示された。56ビットのDESでは1秒以内に解読可能であるの
に対し、128ビットのIDEAでは8,000億年かかる。鍵長が128ビットに満たない
共有鍵暗号を信用してはならないということなどが説明された。
　公開鍵暗号については、その代表的なものにRSA暗号があり、これは掛け算は容易であるが素因数分解は困難であるという特性を利用した初の本格的な公
開鍵暗号であるということが説明された。
　RSAの強度として100MIPSのコンピュータを同時に1億台動かした場合の解読時間も紹介され、共有鍵暗号の場合と異なり、公開鍵暗号であるRSAの場合は
1024ビット以上の鍵を使うことが強く推奨された。

3のLASRMデ検索したんですが
http://web1.nazca.co.jp/himajinn13sei/soft.html
なんかここにすごいって書いてある→http://web1.nazca.co.jp/himajinn13sei/8h.txt
WinRARとかより優れた暗号技術なんすかね‥

92 ：

暗合の安全性はそういう単純な話ではなかろう

93 ：

暗号化の技術　+　その鍵　じゃない？基本的に。
単純じゃない、とだけ言われてもよくわからんよ。

94 ：

それより今の量子コンピュータの性能が知りたい。
何年か前に15=5*3の素因数分解に成功したのは聞いたが…

95 ：

量子コンピュータなんぞができる頃には
量子暗号が普及しててあんま意味無さそう。

96 ：

ようとは暗号解読だけじゃないだろ

97 ：

単に計算量だけの話なら、長い鍵長をサポートしさえすりゃいくらでも延びるわな

98 ：

↑
97
暗記以外での鍵の保存方法は？

99 ：

>>95
量子暗号って通信でだけ使えるもので、保存では使えないぞ。
原理とかわかってて書き込んでるのか？
>>98
USBメモリとかでリアル鍵みたいに扱えばいい。

100 ：

>>99
＞USBメモリとかでリアル鍵みたいに扱えばいい。
ってどういうことでしょうか？リアル鍵‥？
フラッシュメモリはもってるのですが‥

101 ：

扉に鍵を挿すのと同じように、USBポートに(鍵ファイルの入った)USBメモリを挿すという意味じゃね？

102 ：

リアル鍵
＞家の鍵よか車の鍵とか、実際に物体として存在する鍵
＞USBメモリに暗号データを記録しておき、そのデータのUSBメモリをPCに挿してないと
＞動作しない、というような使い方を意味すると思われ
そのUSBメモリも使われたら開けられてしまうこともある＆USBメモリをなくしたり壊したりしたらもう一生開かないって感じ‥？バックアップもしたり、ですか‥。

103 ：

>>101
ありがとう

104 ：

>>102
まさにリアル鍵だね
>>97
世の中に出回ったハードウェア・ソフトウェア製品の鍵長を変更する手間がかかるよね
IPv6はもう二度とアドレス空間の拡張をしなくていいように設計したらしいけど
（計算量的な困難さに基づく）暗号技術は百年後も千年後もいたちごっこと製品更新が続くのかな

105 ：

100年後なんてまったく想像つかんわ

106 ：

とりあえず2038年を乗り切らねば

107 ：

IPがv4からv6に変わってところで暗号自体には影響ないだろ
何のためにレイヤーを分けているのかと

108 ：

暗号化って学習するの楽しいの？

109 ：

どうせ100年後の香具師らにかなり馬鹿にされるんだろうなぁ

110 ：

>>108
離散数学楽しいよ。
って友達と喋ってたら「お前ヘンだよ」って言われた。ファック。

111 ：

>>107
いや、>>104では別に「IPv6に使われている暗号技術の話」をしたいわけじゃなくて・・・

112 ：

>>110
俺、今ググるまで「離散数学」て時計演算とか曜日演算とか九去法とかで使う「剰余算」の事だと思ってたorz
>>104
千年後は知らんが、百年後くらいまでは普通に
ハッカー(防御)VSクラッカー(攻撃)の鼬ごっこだと思う。

113 ：

疑似乱数のスレが新スレに移行
疑似乱数２
http://pc11.2ch.net/test/read.cgi/tech/1192628099/

114 ：

暗号―この不可思議で魅惑的な世界って本買ってみた

115 ：

面白いのか報告頼む

116 ：

・ページ数が200以下　・紙が厚い　・文字が大きい　・図表が多い　・簡単な文章
ということでもう読み終えてしまった
（ここまで簡単に書くのにかなり苦労してる雰囲気が本全体に漂ってるがｗ
序論にも書いてあるけどこれは読み物
大学の一般教養の講義を受けてるみたいで脳味噌を回すことなくすらすら読める
内容は深入りしないけど技術の背景にあるバックボーンはわかりやすく的確に
ピックアップしてるから暗号についてプチ勉強（笑）したい人にもお勧めできる（素早く半日で読破できるし）
だがちゃんと暗号を勉強したい人は立ち読みがお勧めだ（高いし素早く半日で読破できるし）
一言でいうと楽しい読み物だな
むかし「○○のひみつシリーズ」のマンガを読んでたがあんな感じだ

117 ：

>>116
報告�d
読み物的なものが読みたいなぁと思っていたのですが少しボリュームが足りなさそうなので
今度本屋で立ち読みしてみますね

118 ：

age

119 ：

Hello Kitty used as drug lord's messenger: report
ttp://afp.google.com/article/ALeqM5ieuIvbrvmfofmOt8o0YfXzbysVuQ
麻薬王がメッセンジャーに選んだのはキティちゃん
ttp://www.afpbb.com/article/disaster-accidents-crime/crime/2362503/2721870

120 ：

暗号化ソフトは本当にファイルをユーザーが入力したキーを元に暗号化しているのか
作者は実はマスターキーを用意しているのでは
入力したキーは作者のみが知るキーで暗号化されてデータに埋め込まれているのでは

121 ：

暗号化ソフトってなに？

122 ：

ファイルフォーマットも処理様式も公開されておらず
第三者が検証できないようなツールは使わない。
という方針でいいんではない?

123 ：

科技庁はどのように選択すればよいのですか？

124 ：

なんかすごいのが見つかったみたいだけど。
ttp://www.atmarkit.co.jp/news/200804/11/cab.html

125 ：

見つかったというか、読んだ限りでは関数自体も差し替え可能な「鍵」とすることで
鍵のバリエーションが完全に無制限に ＝ 解読が完全に不可能になった、という意味かな。
むしろ 8 ギガビットの巨大な鍵でストリームが可能というのはすごいな (SSL のように
共通鍵だけというオチでなければ)。
まぁ実際はクリアアタックかけてその関数の推測から始まるんだろうけど。

126 ：

「暗号化の鍵の組み合わせ」を相手方にわからせないと意味なくない？
それはどうやって伝えるんだ？　

127 ：

読んだ限りでは公開鍵としても使えるようだから渡し方自体は今までどおりでいいでしょ。

128 ：

>>127
> 読んだ限りでは公開鍵としても使えるようだから渡し方自体は今までどおりでいいでしょ。
じゃあそこにスキができるじゃんよｗ

129 ：

?
例えば?

130 ：

相手にどの式を使ったか教えなければ複合ないんじゃないの？

131 ：

確かによくわからん…
使う関数が自由に選べちゃったら復号側が困るよなぁｗ

132 ：

おまいらこのスレに居る以上は公開鍵暗号理解してると思ってて良いんですか?

133 ：

公開鍵と秘密鍵の対は今までみたいに使われる関数がきまっているから一回手元で作るだけで良かったんだろうけど、
今回のそれはそういう事できんの？　っていう疑問でしょ。
普通に考えたら、鍵化の関数をランダムに選ばれちゃったら、公開鍵、秘密鍵の対も毎回違っちゃうんでないの？、と。
まぁ、そのＣＡＢ方式とやらで一回　ペアの鍵を作ったら、その一方の鍵でどんな関数をつかって暗号しようが関係なく、
初めに作った秘密鍵で全て復号できる！っていうなら話はわかるんだけど…　

134 ：

そんなことが果たして可能なのか

135 ：

その他もこの暗号の一部とかいってるわけだから、
公開鍵＋公開関数をセットでやりとりするとかか？
でも秘密鍵＋秘密関数をセットで保持しなきゃならないし
その関数の安全性をちゃんと図らないとだめだろうし
鍵も関数も大量の管理が必要になり面倒だろうし・・・

136 ：

俺は話半分くらいに受け取っている。
ZeoSync(100分の1圧縮)ほどの大嘘でないにしても、大したことなさそうな…
結局のところ、アルゴリズムを特定しないことによって、プロトコル名だけでは
復号の仕方が分からないというだけの話じゃないかね。

137 ：

251 名前：名無しさん＠八周年 本日のレス 投稿日：2008/04/12(土) 00:17:48 vbnqIY+x0
解読できる「確率」が定義できるような安全性のレベルを問題にする場合は、
バーナム暗号よりいい方法は存在しないことが知られている（というか学部生でも
すぐわかる）よ。記者がよくわかっていないのならいいけど、
この人の場合、前にNP問題が解けたとか言ってた前科があるからなあ。。。

138 ：

ηTペアリングの高速な実装
ttp://labs.cybozu.co.jp/blog/mitsunari/2008/03/t_1.html

139 ：

AES(Rijndael) って危ないんですか？

140 ：

どこがどう危ないと聞いたんだ？

141 ：

>>140
どこが、というのは具体的にはきいていないのですが、こんなのがありました。
http://mamono.2ch.net/test/read.cgi/newsplus/1207915608/421 (今はdat落ちです。）
>そこまでやって採用されたAES、じつは「簡単に解けてヤバいんじゃねーの？」というのは知れてる
じゃ、どんな問題があるかな、と思った次第です
で、検索してみたところ、次のような指摘はありました。
http://www.watch.impress.co.jp/internet/www/article/2002/0917/aes.htm
http://en.wikipedia.org/wiki/XSL_attack
ここで、http://cryptrec.nict.go.jp/　の http://www2.nict.go.jp/y/y213/cryptrec_publicity/c04_wat_final.pdf をみたところ、
心配する必要はないとのことですが、これは 2004 年の報告で、続報はありません。
ということで、最近の動向をご存知の方がおられたら、と考えました。
煽る意志はまったくありません。

142 ：

話をもの凄い勢いでぶった切る上に質問で本当に申し訳無いと思っているのですが
線形解読法のS_boxの近似の方法がよく分からないのですが、簡単に説明していただけますか？
論文を読んだのですが、式の意味が分からず、本当にわからなくて死にそうです

143 ：

ほしゅ
情報処理推進機構　セキュリティセンター
暗号技術に関するe-Learning教材
ttp://www.ipa.go.jp/security/fy19/development/e_Learning_Cipher/index.html
ITセキュリティ評価・認証に関するe-Learning教材
ttp://www.ipa.go.jp/security/fy19/development/e_Learning_CC/index.html

144 ：

PBKDF2による鍵派生で疑似乱数関数にHMAC-SHA1を使用した場合について
パスワードに十分なエントロピがあったとすると、
派生される鍵のパスワードに基づくエントロピの上限は
512ビット？
それとも160ビット？
もちろん長い鍵を派生した場合の話ね。
パスワードは512ビットだった場合。

145 ：

補足、PBKDF2でHMAC-SHA1を使った時点で160ビットに制限される
みたいな記述を見たことがあるんだけど、
なんか512ビットのような気がして微妙に納得いかないんだ。
詳しい人おせーて。

146 ：

誰か暗号化鍵交換（EKE: Encrypted Key Exchange）の特許について詳しい人おらん？

147 ：

特許について詳しい
って専門職すぎる

148 ：

弁理士すれにいったほうがよくね？

149 ：

>>144
SHA1が完全に破られたとしてもHMAC-SHA1は安全だと思う？
>>146
アルゴリズムには詳しいから特許に抵触する場合は抵触すると答えれると思う。

150 ：

SHA1が完全に破られたってどういう状態を言うの？
っていうか、それは>>144の疑問にどのように関わってくるのだろうか？

151 ：

どこで聞けばいいのかわからないのでここにレスさせてください。
よく雑誌などについていたりするユニークな英数字のIDがありますが、
あのIDの生成とデコードの基礎的な理論はどうやって調べればよいでしょうか？

152 ：

>>151
「よく雑誌などについていたりするユニークな英数字のID」がなんのことだかわからんので
答えようがないのだが...たとえば具体的にどういうID？

153 ：

「ASHJUDFHDJS」
のような特定桁数の英数字の組み合わせのものです。
たとえばビットキャッシュなどのプリペイド系のコードや
ネットゲームのアイテム交換コードなどもそれにあたります。
少数なら発行コードと該当する内容をデータに保存という考え方もできますが、
万単位になると管理が大変だと思うので・・・

154 ：

照会方法？
　　　　　　　　　　　　　　　　　　　　　　　サーバ  |　　　　　　　　クライアント
　　　　 +-------------------------------+--------------------
発行時|　　　　　　　　IDを生成してDBに記録  |発行されたIDを受け取る
利用時|　受け取ったIDからDBの記録を照会 |サーバへIDを照会

155 ：

ＰＫＣＳ＃１に関する事をどなたか教えて下さい。
以前、ＰＫＣＳ＃５のブロックパディング方式で暗号するプログラムを組んだ事があるのですが、ＰＫＣＳ＃１も所定サイズ（鍵長？）に満たない場合にパディングを付与したりするのですか？何バイト分付与するかで付与する値が固定で決まってはいないのでしょうか？

156 ：

The SHA-3 Zoo
ttp://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo
どのハッシュ関数が生き残るんでしょうねー

157 ：

>>156
いつのまにか公募終わってたんだな
これから一年かけてサバイバル一回戦か
参考：http://ja.wikipedia.org/wiki/AHS

158 ：

暗号前文字「acfeadda8d008302e28f0547800c3587fb7d8f15」
暗号後文字「CLJEes3f4ENLYW76WtkhojDfDGs/91tKRihLMeRLqVg=」
暗号化方式もキーも何も分からないんだけど、
解読方法って分かるかな？
無理だよな・・・
調べて分かる暗号なんて使わないよな・・・
駄目もとで書いてみた
スレ汚しスマソ

159 ：

AES Sboxのbitslice実装って使えないな
どのみちビットシャッフルはバイト単位しかないからSIMDで攪拌＋マージしたほうが効率いい

160 ：

>>158
遅レスだけど、一例だけだと分からん。
xorしてbase64しただけだったりして。

161 ：

opensslをハードウェアで処理させたいです。
opensslを使用するためのハードウェアってどこのメーカーさんが販売しているんでしょうか？

162 ：

>>161
そういうハードウェアもあるけど、さいきんのGHz級のCPUなら、ソフト
ウェア処理のほうが速いみたいよ。
ハードウェアにすると並列処理しにくくなるしね。

163 ：

CPUとハードウェアの両方でopensslを使用させることを考えています。
社員200名くらいに端末を配布しているのですが、常時サーバに接続する
端末が130程度あります。で、外部のSEさんに相談してサーバのログを調
査してもらったところopensslの暗号化処理のところがボトルネックになって
いるという報告書があがってきました。
SEさんには新しいサーバを増設するのが一番確実だといわれましたが、
PCを一つ買うと10万円以上します。が、ハードウェアなら高くても2〜3万円
程度で収まるんじゃないかと思いハードウェアを使用したいと思いました。

164 ：

数万で買えるSSLアクセラレータなんて見たことない。
というか、プログラム板の話題じゃないよね。

165 ：

>>163
使っている暗号はRSA+AESかな?
AESのハードウェアアクセラレータというと…IntelのAES-NIまだー?

166 ：

なぜハードなら２〜３万で済むと考えたのかさっぱり分からない
ボリューム品以外は高くなるのが普通じゃないか？
ＰＣの低価格に慣れすぎてないか？
googleでssl アクセラレータを検索すれば、安くても6桁するのがすぐに分かると思うが

167 ：

PCIボード型のアクセラレータと、webサーバ型のアクセラレータがあることが分かりました。
PCIボード型：20万〜
webサーバ型：100万〜
でありましたが、費用的にもサーバ室の広さ的にもPCIボード型のアクセラレータの購入を
検討します。

168 ：

A => I
K => P
X => W
Q => H
の時
C => ?

169 ：

>>167
GPUを足して以下とかはどうだろう。
まぁ"Currently is implemented AES 128 encryption only!"とのことだが。
http://math.ut.ee/~uraes/openssl-gpu/

170 ：

169は取り消し。あまり早くないのか。

171 ：

ソフトにRC5組み込んでいいの?
国内の話なんだけど。特許的に。

172 ：

ベッキー「だめだよ」

173 ：

おまいらありがとう。
俺の論文に役立ちそうだよ。

174 ：

DESの暗号化でSボックスってありますよね
これって6ビット入力で4ビット出力ですが
復号化するとき4ビットの数から6ビットに戻せなくないですか？
表の中に4ビットの数が複数含まれていますよね
どうすれば復号できるんですか？

175 ：

勘違いしてました
解決しました

176 ：

楕円暗号って焦点が分かってしまえば
解けちゃうような気が

177 ：

落とし戸が無ければふくごうできねー

178 ：

拡張子のpazを展開したいんだけど、どうやってやるんだ？
eden*のファイルなんだけど。
教えてくだしあ

179 ：

blowfish

180 ：

blowjob

181 ：

ＲＳＡの懸賞ってもう終わったの？

182 ：

ttp://www.rsa.com/rsalabs/node.asp?id=2093
ttp://www.rsa.com/rsalabs/node.asp?id=2100
no longer active だね

183 ：

なんでだ？裏で画期的なアルゴリズムが発見されちゃったのか？

184 ：

MACって通信相手の認証もしてるって説明が良くあるけど
別にサーバ認証はしてないと思うんだが

185 ：

通信相手≠サーバ

186 ：

つか
通信相手の認証≠サーバ認証
だ。

187 ：

ヴェノナ（VENONA）　　ジョン・アール・ヘインズ (著)　中西輝政 (翻訳),
http://www.amazon.co.jp/dp/4569704891
「ヴェノナ」とは、1943年にアメリカが始めたソ連の暗号傍受・解読作戦の名称である。
本書は「ヴェノナ」解読文書の元となった通信文から、ソ連のスパイ活動の全貌を暴く
画期的な一冊。
いち早くその重要性を指摘した中西輝政氏らが本邦初翻訳を試みたものである。
東西冷戦後、原著者らの努力で「ヴェノナ作戦」の成果が公表され、世界中の歴史家
に衝撃を与えた。
第二次世界大戦時の同盟国ソ連が百人単位の規模でアメリカにスパイを送り込み、
外交、軍事、産業上の機密情報をことごとく盗み出していたことが分かったからである。
当時のルーズベルト政権は、完全にソ連の工作の影響を受けていた。
そしてアメリカの軍事機密がソ連に筒抜けだった事実は、日本にとって何を意味するか。
ソ連はアメリカの原爆プロジェクト「マンハッタン計画」を事前に把握しつつ、
1945年8月6日の広島への原爆投下を見届け、
同月8日に対日戦線布告を行ったということである。
http://www.youtube.com/watch?v=7Ri2dRQnzDA
http://www.nicovideo.jp/watch/sm10436106

188 ：

> ソ連はアメリカの原爆プロジェクト「マンハッタン計画」を事前に把握しつつ、
> 1945年8月6日の広島への原爆投下を見届け、
> 同月8日に対日戦線布告を行ったということである。
暗号を勉強してる良い子のみなさんは、こういう思考に溺れないよう気をつけましょうねw

189 ：

RSAって秘密鍵と公開鍵ってあるけど
秘密鍵から公開鍵を計算することって出来るの？

190 ：

それは微妙な質問だな。
仕組み上はできない。
RSAでは秘密鍵と公開鍵は対称だから。
でも、実用上の実相ではまた話が違ったりする。

191 ：

つまり公開鍵で暗号化すると秘密鍵で解読出来るわけだけど
この逆に、公開鍵で暗号化させたものを秘密鍵を持ってる人しか見れないってことは可能なのかな？
秘密鍵を逆に公開して公開鍵を保持しとくって手もあるけど
その場合暗号強度に影響あるのかなと思って

192 ：

ん？逆になってなかった違う
秘密鍵で暗号化したものを公開鍵と一緒に配布する
みんなその公開鍵で内容を見れるけど
その暗号文を作成出来るのは秘密鍵を持ってる人だけ
みたいなことがやりたい

193 ：

それ普通の公開鍵暗号やん

194 ：

公開鍵で暗号化した物は秘密鍵で復号化できる
秘密鍵で暗号化した物は公開鍵で復号化できる
双子鍵はどちらを公開鍵とするか秘密鍵とするかは好きにできる

195 ：

>>193
その通りだ
誰でも見れるけど編集には鍵が必要みたいな文章を作る方法がないか考えてたけど
結局編集ソフトで規制掛けるしかないんだよね
だったらただのハッシュを併記しとけばいいだけだった

196 ：

保守

197 ：

サイド

198 ：

HDCPの公開鍵流出？
ttp://www.engadget.com/2010/09/14/hdcp-master-key-supposedly-released-unlocks-hdtv-copy-protect/

199 ：

こんな暗号じゃだめですか？
for(k=0;k<500000;k++){
for(j=0;j<16;j++){
for(i=0;i<32;i++){
d[i]^=GF[mlt(FG[a[j]],FG[h[i][FG[b[j]]]])];
}
}
for(i=0;i<16;i++)
a[i]^=(d[i]+c[i])%16;

for(i=16;i<31;i++)
b[i-16]^=(d[i]+c[i])%16;

200 ：

Camellia攻撃可能段数
鍵128ビット9段
鍵256ビット11段
何で256ビットの方が攻撃進んでるんだ？

201 ：

突然なんですけど
ATMをアルファベット順に７つ動かすと
HATとなるように
暗号化しても単語が
できるようなものを探してます。
できるだけ長い単語をさがしてます。
お願いします。

202 ：

宿題は自分でやりましょう

203 ：

そんなもん辞書ファイルで総当たりやれば終了じゃん。
見つかる保証はないが、そんなもんプログラムにやらせんでどうする。
自分で組めよ、屑。

204 ：

辞書にはA〜Zのアルファベットの説明が載っているはずなのぜ？
つまり・・・

205 ：

ハッシュ関数作りました。評価してみてください。
void hash(int nn){


while(k<nn){
c1.cc[0]=((c1.cc[0]+u.cc[0])&f2)^c1.cc[1];
c1.cc[1]=((c1.cc[1]+u.cc[1])&f2)^c1.cc[2];
c1.cc[2]=((c1.cc[2]+u.cc[2])&f2)^c1.cc[3];
c1.cc[3]=((c1.cc[3]+u.cc[3])&f2)^c1.cc[0];

c2.cc[0]=((c2.cc[0]+u.cc[0])&f2)^c2.cc[1];
c2.cc[1]=((c2.cc[1]+u.cc[1])&f2)^c2.cc[2];
c2.cc[2]=((c2.cc[2]+u.cc[2])&f2)^c2.cc[3];
c2.cc[3]=((c2.cc[3]+u.cc[3])&f2)^c2.cc[0];

z=(c1.dd[0]&&ff)^((c1.dd[1]&ff)>>4);
c1.dd[0]=c1.dd[0]&f; c1.dd[1]=c1.dd[1]&f;
i=c1.cc[0]%64;
c1.dd[0]^=g[i][0]; c1.dd[1]^=g[i][1];
c1.dd[0]^= z; c1.dd[1]^= ~z;
i=c2.dd[0]%64;
zz=(c2.dd[0]&&ff)^((c2.dd[1]&ff)>>4);
c2.dd[0]=c2.dd[0]&f; c2.dd[1]=c2.dd[1]&f;
c2.dd[0]^=g[i][0]; c2.dd[1]^=g[i][1];
c1=s5(c1); c2=s5(c2);
c2.dd[0]^=zz; c2.dd[1]^=~zz;
printf("%04x %04x %04x %04x %04x %04x %04x %04x\n",c1.cc[0],c1.cc[1],c1.cc[2],c1.cc[3],c2.cc[0],c2.cc[1],c2.cc[2],c2.cc[3]);
k++;
}

}

206 ：

やっぱここには屑しかいないか。

207 ：

何を分かりきったことを

208 ：

ここは投稿された歌詞やら小説やらプログラムやらの著作権を主張してた２ちゃんねるだぞ。

209 ：

投稿して1日も待てない人は、向いてないと思う

210 ：

カメリアとAESってどっちが早いの？

211 ：

前に測ったときはCamelliaの方が早かった＞OpenSSL

212 ：

GPGよりOpenSSLの方が早いのはなぜですか。

213 ：

OpenSSLで秘密鍵暗号を使うとき、コマンドラインからパスワードを
設定する方法はありますか？

214 ：

>openssl pass:hogehoge
でもこのやり方はシェルの履歴に残るぞ

215 ：

256bitハッシュ関数作ったので見てください。
ttp://sky.geocities.jp/tcshacina/hash.c

216 ：

誰かこの暗号解いてくれ(涙
27 102 8 -36 44 62 77 122 う
ヒントは-36の-はｱｰﾄとか言葉で伸ばしてる-らしい(´;ω;｀)
宜しく頼んだぜｯｯ
解説も できたら頼む。

217 ：

ストリーム暗号の周期を測定しようとしたらすごいバグが見つかった！
直して今のところ2＾32までの周期はない事がわかったのですがどの位
なら安全といえますか？

218 ：

ストリーム暗号の安全性の検証方法って
よく分かってないんじゃなかったっけ

219 ：

>>217
周期はわからないけど、とりあえずNIST検定やDIEHARDをパスすれば良いんじゃない。
ttp://csrc.nist.gov/groups/ST/toolkit/rng/index.html
ttp://www.stat.fsu.edu/pub/diehard/

220 ：

NIST検定って具体的にどんな事をするんですか？英語で書いてあってよく
わからないんですけども、出力を検査するようなソフトがあるってことですか。

221 ：

OpenSSLとかGPGって特別に秘密鍵を用意しなくても暗号化してくれる
みたいなんですけど、どうやって暗号化するカギを生成するんですか。

222 ：

>>220
乱数を検定するプログラムです。
ストリーム暗号は、いかに良い乱数でxorするかなのね。
優良だけど日本語のやつもあるので試してみては？
ttp://www.chaosware.com/ransure/ransure.html

223 ：

Ｘ　優良だけど日本語のやつもあるので試してみては？
○ 有料だけど日本語のやつもあるので試してみては？

224 ：

優良じゃないんだ

225 ：

無料のやつないですか？

226 ：

3年前、群の位数がソフィージェルマン素数になる楕円曲線を見つけた。

227 ：

http://www.cla-ri.net/pgp/pgp00.html
>公開鍵の管理方法としては２つあります。
> * 秘密鍵、公開鍵共に公的な認証局に認証してもらい、この認証局から公開鍵をもらうことにより暗号通信を行う方式
> * 秘密鍵を本人が管理し、公開鍵をお互いに交換することにより暗号通信を行う方式
ここの1つ目では秘密鍵も認証局に認証してもらうようなことが書いてありますが
秘密鍵は認証しませんよね？（誰にも知られてはマズイので）
ということは秘密鍵は自分で管理して
1．公開鍵を認証局に認証してもらい，公開鍵証明書を公開する．
２．公開鍵を通信相手と交換する
という2通りの管理方法になるということでしょうか？

228 ：

CAという認証局があってベリサインとか民間の会社がやってるサービス
なんですけど有料だと思います。PGPでは直接鍵を渡す信頼の輪という
概念で認証局を使わない方法で鍵管理が行われているようです。

229 ：

>>227
そこ書いてることむちゃくちゃじゃないか？

230 ：

ひどいね。

231 ：

どうして小説に出てくる暗号は全部解読されてしまうのですか。
解読されない限り犯人である事が証明できない方がスリルとサスペンスがあると思います。

232 ：

解かれないのなら、その暗号が元から存在しなかった場合と何もストーリーが変わらなく、物語に登場させる意味がないからでは

233 ：

高速化のため射影座標で楕円暗号の実装をしているのですが、アフィン座標の
時のように決められた位数で無限遠点になりうません。選択する座標によって
も計算結果がアフィン座標の時と違います。またアフィン変換してしまうと
高速化のメリットがなくなってしまいます。射影座標でも決められた位数を
正しく計算する方法はないのでしょうか？
理解不足ですがよろしくお願いします。
http://sky.geocities.jp/tcshacina/proj.rb

234 ：

目指してる 未来が違うｗｗｗｗｗｗｗｗ　ｂｙシャープ
http://twitter.com/udony/statuses/7396610887655426　　

235 ：

>>231
2048ビット共通鍵暗号がスーパーコンピュータなら数年で解読できる世界があったな。
素人が書くとこういうことになる。

236 ：

>>235
その世界のスーパーコンピュータは量子コンピュータなのかもしれないし
チューリングマシンですらないかもしれない

237 ：

>>236
だったらその計算能力や量子技術が他にも応用されているようすを、
きちんと描かないとな。

238 ：

暗号は基本的には誰か（通常は通信相手）には解読されないといけない物だから、
物語中で解読出来なかったら、それはそれでモヤモヤが残るね。

239 ：

量子コンピュータが暗号をサクッと解けるというのは証明されてるの？

240 ：

Shorのアルゴリズム

241 ：

ビットスライスDES(bit-slice DES, bit-sliced DES)について詳しく解説された専門書でおすすめのものがあれば教えていただけないでしょうか？
わかりやすいものであれば論文でもかまいません。
わかりにくい論文は・・・ 私は暗号の専門家じゃないのでつらいです。
ビットスライスDESをスクラッチから実装したいと考えています。

242 ：

俺の鍋敷きとして役立ってるよ
>>241の専門書は

243 ：

ちょっとご存知でしたら・・・
AESで暗号化したファイルがあるのだけど、間違って元ファイルも出してしまったのですが
これの比較でキー情報を解読する方法ってあります？
大丈夫ですよね？あったら他もピンチなのですが・・・

244 ：

ある暗号文と対応する平文を入手したときに(ry
というやつだな

245 ：

いま一番信頼されているブロック暗号アルゴリズムってなに？

246 ：

AESじゃないの？

247 ：

量子暗号についてサイエンスゼロ見た。
日本政府の最先端の研究を中国人がやってる。暗号技術だけにやばいよ。
nict　光子　中国
でぐぐれば出る。

248 ：

説明してごらん

249 ：

日本から外国人研究者を全部追い出して、
日本の国力をさらに下げたい二重スパイだろw
日本に来るようなのは、各国の最高レベルの研究者だってのに。

250 ：

そんなのやってたのか。
物理のほうだと案外量子暗号とかの話にはならないもんなんだね。

251 ：

エロ画像・動画を暗号化するビューワーを作りたいんだが
パスワードさえ長くしておけば警察にビューワーを押収されてもバレない暗号方式ってある？

252 ：

AES

253 ：

ありがとうございます
早速ＡＥＳのライブラリをゲットしました＾＾

254 ：

鍵配布をどーするつもりだよ?
おとりをどー排除するつもりだよ?
とマジレ酢。

255 ：

おとりってどういう意味かよくわからないのですが、
個人で使うものなので鍵（固定長のパスワード？）はビューワにログインの都度入力します。

256 ：

皆に得ろ画像を提供する目的じゃないんだったらなにもおしえてやらん!

257 ：

ま、個人利用なら外部に秘密鍵を漏れないように置かないとね

258 ：

4096ビットくらいの鍵を暗記すればいいんだよ

259 ：

AESは最大で256ビットの鍵しかありませんが解析されませんか？

260 ：

計算量だから、完全に無理とは言えない
警察位なら電子政府基準位なら(覚えてないです…)いいんじゃないかと

261 ：

そんな難しいことしなくても、ディフィー・ヘルマン鍵共有を使って鍵をランダムに変えれば、暗号自体はチープな RC4 くらいでいいんじゃないですか？

262 ：

>>261
>>251は、ローカルに保存してるエロファイルを暗号化したいんじゃないか？

263 ：

>>262
既存のツールでええがな

264 ：

ファイルを暗号化するツール自体はあるけど、画像を見ながらにしてファイルに暗号/複合をほどこせるビューアは無いよね
１つＡＥＳかけられるのがあったけど、.Net製で動作もおかしい
やはり自分で作ったほうが信頼できる

265 ：

詳しくないので直感です
一旦、全部暗号化して、復号をしながら閲覧で良いのでは。
処理は犠牲になるけど、ＡＥＳで実装なら出切るような

266 ：

暗号化ディスクで事足りると思うよ。
TrueCryptでggrks

267 ：

10桁アルファベット大文字小文字、数字
のパスワードを作る場合
同じ文字の「重複あり」と「重複無し」
どちらが強度があるのでしょうか？教えて下さい

268 ：

重複を許す場合
これは数学のお話だよ

269 ：

>>266
これはいいものだな
でもヘッダファイルからパスワード推測されないんだろうか？

270 ：

>>269
おまえはいろいろと足りなすぎる

271 ：

すみません＾＾；

272 ：

暗記するなら楕円曲線のほうがいいかもｗ

273 ：

>>269
つ一方向関数・ハッシュ関数・メッセージダイジェスト。
ヘッダファイルからパスワードを推測することは、多分無理だろう。

274 ：

それなら安心＾＾

275 ：

あげ

276 ：

[再放送] サイエンスＺＥＲＯ「ネット社会を守れ！究極の量子暗号」
2011年 9月17日（土）午前0:00〜午前0:30（30分）
http://cgi4.nhk.or.jp/hensei/program/p.cgi?area=001&date=2011-09-16&ch=31&eid=15977

277 ：

>>276
教えてくれてありがとう。興味深かった。
全然関係ないし亀レスだけど>>235で言ってる2048bit暗号って10^600通りくらいあるんだね。びっくり。
この数が量子コンピュータ云々で楽に解けるレベルなのか宇宙の物質の数を越えているのか知らないけど。

278 ：

openssl/evp.hを使ってDB接続用なんかのパスワードを暗号化しようと考えています
AESで暗号化したパスワードを設定ファイルに保持させようと考えていますが
saltとIV(Initialization Vector)をどのように実行ファイルに保持させるのがより安全でしょうか？
nmやstringsでバレる方法は避けたいと考えています。
先輩方の知識を貸していただけますと嬉しいです

279 ：

>>278
すいません、書き漏らしました
実行ファイル内に収めようとしているのは saltとIV に加え
暗号化keyデータもです

280 ：

あげます

281 ：

すいません、ここで良いか微妙ですが教えてください。
アプリケーションに対するデジタル署名って、
署名発行者が作ったものというのは証明出来ますか？
他人が自分の署名を付けて自分のものとして再公開されるような事って出来ますか？

282 ：

出来るか、出来ないかなら出来る

283 ：

レスthxです
manifest変更したいexeがあって、signtool使ってたんですがどうもうまくいかず。
(win7なので外部manifestもダメなんです)
理論上可能なんですね。
もう少し見てみます。

284 ：

コイン投げゲームをコミットメント・スキームを使って Java で実装したいと思ってます
Alice が表か裏かを示した暗号化したデータを鍵Aで暗号化して、Bob に渡します
その後、Bob が表か裏かを言います。その宣言の後、Alice は鍵AをBobに渡し、暗号化された表か裏かを示したデータを開きます
とはいえ、この場合、Alice は表か裏か結果を知ってから、鍵を渡すことになってしまいます
うまく鍵を調整すれば、鍵の差し替えることで、裏か表かを後追いで言い当てる、みたいなこともできますよね
これを回避するにはどうすればいいですか。
表か裏かを書いたデータと一緒に、電子署名をつければ、よさそうな気がします。（SHA256withRSA で署名すると、1024bitあるので）
しかし、私は暗号の専門家ではないのでこれでも本当に安全かわかりません
それとも、コイン投げをするのにもっとスマートな何か方法がありますか？

285 ：

>>284
お互いが内容の分かっている、ある程度の長さを持つ定型文を含めればいいんじゃないか？
「2011/10/09 15:40 分に投げたコインの向きは 表」
みたいな文章を暗号化して
「2011/10/09 15:40 分に投げたコインの向きは」 の部分は平文でも送信する

286 ：

>>284 デジタル署名（の鍵）は、そういうことができないことが求められるので、
デジタル署名を付ければ解決する。

287 ：

>>285
この場合それでも安全かもしれませんね
>>286
暗号化前のデータに対して、電子署名つけたものを、いっしょに暗号化して
Bob に送ればOKってことですね
今後、このデータを「コインの表裏」だけじゃなくて、
ランダムな乱数種とかも送れるようにしたかったんで
アドバイス助かりました

288 ：

>>283
他人の署名の偽造は通常は計算量的に不可能だよ。

289 ：

元から自己署名証明書とかなら別だが。

290 ：

>>287
署名の検証鍵はどうやって渡すつもりなの？
暗号化前のデータに単なるハッシュを付けるだけでも同じじゃないかな。

291 ：

>>290
そのとおりでした。単にSHA-256のハッシュつけて送信することにしました。

292 ：

Alice の不正行為を根本的なところで防ぐには、事前に計算できない攪拌因子を Bob が選択するのが良い
最も簡単なところで、
・最初に Bob が裏/表に対応する符号語を選択して送信 (例えば1024ビットの乱数)
次点で、
・Bob, Alice 双方で暗号化用の鍵を選択 (k1, k2)
・Bob が鍵 k1 を送信
・Alice が平文 x を選択し、暗号文 y=e_k2(e_k1(x)) を送信
といったところか

293 ：

↓メンタルポーカープロトコルの実装について質問です
http://en.wikipedia.org/wiki/Mental_poker
一言でいえばこの手順は、カードを一枚づつ暗号化して、ゲームの進行上
カードを開く権利のあるプレイヤーに鍵を渡すという方式なんですが、
これも、カードゲーム開始前に、鍵１つにき、また SHA256 などの強力なハッシュをつけて
あらかじめ公開しておかないと、またウソの鍵を渡してゲームの進行を止めることが
できてしまうのでは。ハッシュをつけないと、ウソの鍵を渡した人の、特定が不可能な
気がします。
wikipediaにはその手続きが無いのは、単に wikipedia の書き手がそこは省略したってことでしょうか。

294 ：

>>293
ありがとうございます！（俺は暗号ど素人なんで省略があったかどうかはわかりませんすみません）
実は↓スレの770,780,805でまさにwithout the use of a trusted third partyで牌を配ることが
できないか考えていたところこんなところに答えが！
ただMental Pokerの手順2や5ではDecA(EncB(EncA(x)))がちゃんとEncB(x)になるような
暗号方式を使わなければいけないけど、XORのような単純なものは使えないんですよね。
カード自体はわからなくてもカード同士の関係がわかってしまうから。
ここの具体的な暗号方式をイメージするためには俺には勉強が必要ですね。
おまいら最強の麻雀プログラムしてみろよ Part4
http://hibari.2ch.net/test/read.cgi/tech/1316008804/770

295 ：

>>294
Java なんですが私がやってみた限りは、
SecretKey initKey = KeyGenerator.getInstance("AES").generateKey();
Cipher.getInstance("AES/OFB/NoPadding")
cipher.init(Cipher.ENCRYPT_MODE, initKey , iv);
cipher.doFinal(cardData);
AES というアルゴリズムでは、A->B->C という順番で鍵をかけても
鍵さえあれば順番に関わらず元に戻ります。B->A->C でも A->C->B
でもなんでもいい

296 ：

>>295
レスありがとうございます。AESってそんなチート性能だったんですね…
つまり本当の意味でMental Pokerの手続きを理解するためにはAES(Rijndael)の数理を
理解しなければいけないと。
しかしAESなら実装には困らない（サンプルが豊富）だろうしMental Pokerの実現は思いの外
手が届きそうな気がしてきました（麻雀のためにコーディングする気はないですが）。
ちなみに俺の素人考えでは>>293の件は鍵のコミット・否認防止は必要で、
つまり著者が省略したのだろうと思っています。

297 ：

すみません>>296の「否認防止」は「拘束性確保」に置き換えてください。

298 ：

メンタルポーカープロトコルの欠点は、
一人でも回線落ち、持ってた秘密鍵を捨ててしまうと
カードの中身が復元不可能になることだな
麻雀でいうと、突然ヤマを壊して場を立ち去ることと一緒
するとまあ、チョンボ扱いになるのだろうが、しかし、
これを失点扱いにしてしまうと、周りの三人が組めば
容易に一人をチョンボ扱いとして貶めることも可能
鍵渡しても、三人揃って受け取ってないフリをすればいいだけだから
逆のウソもありうる　実際は回線落ちしたのに「鍵をちゃんと渡したが周りの三人が応答しなかった」
みたいな、言った言わない問題はありうる

299 ：

結局、審判が要ることには変わりないな
まあ、↑の不正は、ゲームの履歴がオンラインにあれば、
何度もできることじゃないから、それが多少抑止力になる
しかし、ビットコミットメントスキームで第三者に乱数種渡す方式よりは強いか

300 ：

Proof of Workと環境負荷について

301 ：

糞コテさんおいでー
手取り足取り暗号について教えるよー

302 ：

>>301
よろしくお願いいたします。
質問は次のとおりです。
今回、DH鍵交換、RSA 暗号について、少しがんばって調査しました。http://toro.2ch.net/test/read.cgi/tech/1324217575/
ここで疑問が生じました。DH鍵交換が実際の実装であまり採用されないのは、どういったわけでしょうか。(少なくとも SSL では採用されていないようです。）
たとえばAES 暗号を主に利用するとしてそれに先立って共通鍵を設定する場合の、DH鍵交換に対する、RSA 暗号の優位性はどのような点にあるのでしょうか。
バックグラウンドは次のとおりです。
RSA 暗号については、書籍 http://www.amazon.co.jp/dp/4627847610/　で、DH鍵交換については、http://saltheads.blog134.fc2.com/blog-entry-35.html を参照しました。

よろしくお願いいたします。

303 ：

数学の素養はどれくらいあるん？
整数とかどれくらい勉強したん？

304 ：

>>303
ほとんどありません。かろうじて素因数分解の一意性の証明を理解できる程度です。
お勧めの書籍があれば教えてください。
実装を目的としていますので、概念を把握できればいいと考えています。

305 ：

wikipediaで公開鍵と関連技術について調べればいいよ
あと、向こうの人達の忠告に真摯に耳を傾けなさい

306 ：

>>302
man-in-the-middle attackに弱いから

307 ：

http://toro.2ch.net/test/read.cgi/tech/1324217575/56-60
この部分の理解が重要。素のDHだと相手が正しい相手なのか攻撃者かが分からないから間違った相手にカギを渡す
可能性がある。それが>>306
基礎的な部分だから暗号を扱ってる書籍ならどれにも載ってるはずー

308 ：

正直、勉強すればいいことだから暗号の知識がないことは気にしていないが、
態度が気に食わない。自分が無知であることも自覚せず、何様のつもりなんだろうか？

309 ：

>>307
手元にあるCRYPTOGRAPHYの邦訳だとDH鍵交換の説明の直後に
STSプロトコルの説明が入っているな

310 ：

>>306-307
中間者攻撃（たとえば、ゲートウェイ等に仕掛けておきパケットの内容をすりかえる等）に弱いという問題は、DH鍵交換のみならず、RSA 暗号でも同様だと考えております。
RSA 暗号のほうが中間者攻撃に耐えうる、ということはあり得るのでしょうか。

311 ：

>>310
それはあっちであがっている通り
匿名システムでは「ない」、匿名でないシステムなら「ある」（認証を使う）

312 ：

つまり、DH であろうと、RSA であろうと、それだけでは中間者攻撃に対しては無力だ、ということですね。
では、現状では RSA が選択される理由はなになのか、言いかえると RSA の DH に対する優位性は何なんでしょうか？

313 ：

>>312
>>306-307,311とそのリンク先とかを理解して来て、手持ちの本をきちんと読めよ。書いてあるだろ
だからRSAは中間者攻撃に耐えれる仕組みを用意してるからだよ。もちろん使い方によっては攻撃に対して無防備だけどな

314 ：

>>313
公開鍵暗号は、公開鍵で暗号化、秘密鍵で復号化するものですが、RSA に限っては秘密鍵で暗号化、公開鍵で復号化することも可能、という利点があり、これにより、なりすましや改竄を回避することが可能とありました。
http://toro.2ch.net/test/read.cgi/tech/1324217575/257 にあげた e, d の定義・ed≡1(mod L), L = (p, q の関数）　からも自明ですし。）
しかし、中間者攻撃可能とは、そもそも通信の当初に使用する公開鍵が通信当事者に確実に伝達されるかどうか保障がない、ということであり、中間者攻撃を RSA 単独で回避することはできないのではないでしょうか？
いちど共通鍵の交換が成立し共通鍵暗号による通信が可能になれば、鍵が割れないかぎりなりすましや改竄は成立しませんから、RSA 公開鍵・秘密鍵の対称性はそれほどの利点にはならないと思うですが。
そういう意味では DH に対する RSA の優位性がよくわかりません。

315 ：

>>314
もう一度じっくり>>306-307,311を読んで投稿を理解しろ

316 ：

別に単に鍵交換で使うだけなら優位性はないよ。
DHは鍵交換にしか使えない、RSAは応用範囲が広い、それだけ。

317 ：

そしてその応用範囲を使って中間者攻撃にも耐えられる。それぐらい。

318 ：

>>317
RSA は鍵交換では中間者攻撃を防げないのであれば、RSA をどのようにして「応用範囲を使って中間者攻撃にも耐えられる」ようにするのでしょうか？

319 ：

>>318
上で言われているように、きちんとほかの人の投稿読んだ方がいいと思うな(´・ω・｀)
>>311にずばり書かれてるでしょ。認証。
仮に中間者攻撃をRSAなりほかの手法でも防げないのであれば、例えば通販サイト
でクレジットカードの番号入力時にSSL使ってるから安全なんて言われてないでしょ？

320 ：

みんな優しいねぇ

321 ：

ほんとそうだなｗ
完全に糞コテのお勉強スレ。しかもレベルがひどく低いｗｗｗ

322 ：

みんなというか、相手しているのは一人二人だろう

323 ：

>>319
RSA アルゴリズムに「認証」機能を実現するからくりは含まれていないと考えます。
>>316 RSAは応用範囲が広い
は理解できるのです（暗号だけでなく署名にも使えますから）。しかし、
>>313 RSAは中間者攻撃に耐えれる仕組みを用意してる
>>317 その応用範囲を使って中間者攻撃にも耐えられる
というのは不正確あるいは誤りでしょう。RSA 単独ではそれは不可能ですから。
今、DHとRSA との比較に話題を絞っているのに、両者に関係のない、あるいは両者とは別のからくりである認証を持ち出されてこられると困惑します。
>>319　きちんとほかの人の投稿読んだ方がいいと思うな
むしろ >>319 こそ >>302 の「DH と RSA との比較に絞っている」大前提を読んでいただきたい、と痛切に感じます。>>313, >>317 に至っては問題外でしょうね。

324 ：

323
そうね。君が全部正しいよ。このスレにいる君以外の人間はみんな馬鹿だから相手にしないほうがいいよ

325 ：

＞ここで疑問が生じました。DH鍵交換が実際の実装であまり採用されないのは、どういったわけでしょうか。(少なくとも SSL では採用されていないようです。）
採用されてるから。

326 ：

相変わらずトリは偉そうだな。よく相手するよ…

327 ：

どうどう巡りワロタｗｗｗ
DH使いたきゃ使っておけよ。鍵交換さえできたら安全なんだからｗｗｗ

328 ：

まとめてやるよ(^o^)丿
RSAとDiffie-Hellmanに差はない。
どちらを使用しても鍵のやりとりが終わったら安全に通信できるし、なりすましが入り込んでしまった場合には
どちらを使用しても通信内容は守られない。

329 ：

だからさー、ここはお前の勉強スレじゃないんだ
消えろ、他の奴もQZaw55cn4cを相手にするな

330 ：

>>301
暗号に詳しい人はここは読みに来ないようですね。残念です。
>>329
つ http://internet.watch.impress.co.jp/static/uocchi/2007/04/01/kentei.htm

331 ：

>>330
スルー対象の本人がこんなの貼り付けるってどういうことなの？
ここに居座るつもり？迷惑だけど
「スルー力検定」の受付がスタート
全日本通過技術検定協会が定めた「スルー力検定」ロゴ
　全日本通過技術検定協会は、物事をスルーできる力を客観的に測定する「スルー力
検定」を全国7都市で実施すると発表した。受講料は1級8,000円、2級5,000円。
　「スルー力（するーりょく）」とは、インターネット時代に必須とされる、物事をうまくやり
過ごしたり、見てみぬふりをするコミュニケーション技術。掲示板やブログ上での不快
なレスを読み飛ばすのはもちろん、上司や同僚からの仕事の依頼を何気なくかわす
など、ビジネスからプライベートまで幅広く応用できる。

332 ：

>>331
不合格ｗ

333 ：

>>331
はい。不合格。

334 ：

スルーしても糞コテがいなくならないんだもん
黙ったままでいても糞コテには意味が無い
俺を黙らせるためにスルー力検定なんてもんを貼ってやがる
暗号に詳しくてもお前の態度が気に食わない、
理解できないようだから答えないんだよ

335 ：

>>334
はい。不合格w
>>332
先をこされたか。

336 ：

コテがコテに批判的な人をスルーできないのは問題ないんだ
なんつーダブスタ

337 ：

他人にはスルー力を強要するが自分はスルーしなくていいとか
人として駄目だろう

338 ：

>>334
>暗号に詳しくてもお前の態度が気に食わない、
>理解できないようだから答えないんだよ
言うだけならかんたんだよ。詳しいというんだったら、その実力をみせてよ。
>>336-337
不合格w

339 ：

　　　〃∩ ∧＿∧
　　　⊂⌒（ 　・ω・）　　はいはい不合格不合格
　　　　 ｀ヽ_っ⌒/⌒ｃ
　　　　　　　 ⌒ ⌒

340 ：

http://en.wikipedia.org/wiki/Mental_poker#A_non-shuffling_poker_protocol
* E(c1)E(c2) = E(c1 + c2)
* collisions must be detectable, without revealing the plaintext
シャッフルしない Mental Poker Protocol というのが、意味がわからないのだが・・・
それぞれのプレイヤーが暗号化した数字を出しあって、暗号化したまま足し算して、
カードの衝突があればもう一回って、そんな器用なことできるものなのか？
中身は分からないが、衝突は発見できる、って、そんな無茶な

341 ：

できるように暗号を設計するんだよ
なんにも考えてない暗号だったら無理だろうけどさ

342 ：

あの……落とし物ですよ？
　　　　　　　　 ∧__,,∧
　　　　　　　　（´・ω・`）
　　　　　　　　(つ夢と）
　　　　　　　　 ｀ｕ―ｕ´
　あなたのすぐ後ろにありましたよ？

343 ：

和や積の準同型暗号自体なら
ElGamal暗号やPaillier暗号が昔から知られているよ
ttp://ja.wikipedia.org/wiki/%E6%BA%96%E5%90%8C%E5%9E%8B%E6%9A%97%E5%8F%B7
２つの暗号文から減算（または除算）した結果が
平文"0"（または"1"）の暗号文になっていれば
二つの暗号文の中の平文の同一性は判定できるんじゃね？
ダメかな？
>>340の参照元の論文
ttp://crypto.stanford.edu/~pgolle/papers/poker.pdf
だと，なんか分散計算でやってるみたい
３ページ目の最後の６行の理屈がどうしてもわからない・・・

344 ：

hoshu

345 ：

アンゴーで飯を食うことはできるんか

346 ：

クラウドで暗号とか言ってるけど、安全なの？
http://cloud.watch.impress.co.jp/docs/news/20120210_511289.html

347 ：

>>346
みかかごときが暗号に詳しいわけないだろ

348 ：

みかか研といえば、FEALとかE2とか、国際的に通用する（前者は攻撃法を発見されてしまったが）
暗号で知られてるぞ。
現場のバカが泥をぬったくってくれてるがw

349 ：

だれか暗号といてくれ！！
m7752902780
q5670754954
w2654637406
q5286271066
m8125522416
a1926172574
x504148223
l9676431138
g5289793839
l5799859691
n5135660909
g5241613386
k4148674163
p2895427859
i4115643171
d6373795065
----------------------
a0c2e4g6 : aaaa
a0z1c2x3 : aaaa
p65e68t2o51d27n48u38n13 : corneria
x6136494262r7484725313x185670378k2531105274x7114948063 : venom

350 ：

>>349
解いてみた。
結果は先頭に#を付けて名前欄に書いておいたｗ
これって学校の課題とか？

351 ：

>>349
解けた！
ってかこれ暗号じゃないだろ

352 ：

アウィサムブラックホールって何さ？

353 ：

てす

354 ：

a we some blackhole
？？なんだこの符号化

355 ：

awe some blackhole
だろバカ

356 ：

おー寒っ

357 ：

awesome blackhole
だろ低能

358 ：

nintendoのＷＥＢ入社試験問題だね

359 ：

>>358
マジかよ・・・
検索エンジンに引っかからないし、難易度的に学校の課題とかかと思ったら
そういうことだったのか・・・

360 ：

他者と通信する必要もなく個人で暗号化する場合って
公開鍵暗号方式って意味ある？

361 ：

基本ないと思う。
何を暗号化するかによるけど有効な場合を示せるかも知れない。

362 ：

電子「署名」だったらあるかも。
改竄される恐れがない秘密鍵を別媒体に持っていることが前提だけれど、
kernelとか好き勝手に入れ替えられると困るよね。
kernelに対して電子署名を検証できれば改竄されていないkernelって信用できる。
ううーん、、、
公開鍵「暗号」を使って『暗号化』が有効だと思える例は思いつかない。
ごめん。
うーん。
現在でも公開鍵暗号で『暗号化』するのって、
対象鍵暗号で使う「対象鍵」だもんね。
通信しないのであれば公開鍵暗号の旨味はないと思う。
電子[署名」なら考えれば良い例があるかもね。

363 ：

個人でも暗号化するPCと複合化するPCを明確に分けれるとか。

364 ：

>>360
いちいちパスワードを入力しなくてすむ。

365 ：

世界に自分ひとりしか存在しないなら、公開鍵暗号も秘密鍵暗号も無用の長物。
世界で自分以外の全てが敵なら、公開鍵暗号は無用の長物。秘密鍵暗号は有用。
世界に自分と、敵と、敵ではない誰かがいるなら、公開鍵暗号も有用。
「他者と通信する必要もなく個人で」という用途の中に家族とか友人とか
そういう緩めの第三者がいないなら、公開鍵暗号は意味ないだろうね。

366 ：

味方でも見られたら恥ずかしいデータというのがあってだな。

367 ：

>>364
いや、公開鍵暗号でも公開鍵暗号の秘密鍵を守る必要があって、
そのために公開鍵暗号の秘密鍵を対象鍵暗号で暗号化して保存してるんだよ。

368 ：

その最後の対称鍵は暗号化しなくていいんですか？

369 ：

暗号化って、通信中の解析が難しいってだけでしょ
わかってる人は、途中からやろうなんて考えないでしょう

370 ：

>>368
key = sha1(password)
decrypt(cipher, key)
みたいなことをして復号するから対象鍵(=key)暗号化しなくて大丈夫。
passwordが分からないと正しいkeyを生成できない。

371 ：

>>370
仮にそれを364が言った「いちいちパスワードを入力しなくてすむ」方法の中身だとして、
果たしてそれは秘密鍵暗号では不可能で公開鍵暗号でのみ特有な何かがあるのかな？
って言おうとしたら突っ込むべきところが違ってた。SHA-1は公開鍵暗号じゃねーよｗ
メッセージダイジェストとかハッシュ関数とかそういうカテゴリだ

372 ：

PCの盗難も考えると、最後の鍵はパスワードとして暗記するしかないと思う。
パスワードは強度を増そうと複雑にすると覚えらないし、
頻繁に変更すると忘れやすいし、ほんと困るね。

373 ：

>>371

374 ：

>>371
何を言ってるの…？

375 ：

>>371
>>371
>>371

376 ：

酔っ払って書き込んだのかな

377 ：

公開鍵暗号でゲームのデータの一部をエンコードしているよ。
データを吸い出すことは出来ても、チートデータは作りにくいはず。

378 ：

通信対戦じゃなかったら意味なくね？
対象鍵暗号でも一緒じゃん。
公開鍵暗号である意味がない。

379 ：

>>378
対象鍵暗号じゃデコードルーチンと秘密鍵をユーザーがいくらでも
覗けるから、エンコードルーチンを簡単に作れてしまう。
これでは容易に改造可能。
目的はデータ秘匿ではなく改ざん防止。

380 ：

ちなみに対称ね

381 ：

少なくともデータ比較での解析は無理で、アセンブラと暗号化の知識が必要となる。

382 ：

数学的なお話しでは、
暗号化・復号の際の非対称性をうまく利用してるって話ね。
納得。ありがとう。
crackしようかと思った場合は暗号化方法を判断しないといけないわけですが、
これは各暗号化方法に固有の定数を見つけ出して当たりを付けてるんでしょうか？
もしそうなら、定数を適当に0xff辺りでxorして守っておいた方がいいのかなー？
と思ったので聞いてみました。

383 ：

>>382
暗号化方法が何かはコードを読むしか無いよね。
自分はオリジナルの式を使ってるから、文献をそのまま当てはめても、まず見つからないし。固有の定数も無い。
クラッカーがマシンコードを読めるのは当たり前として、秘密鍵(形式も秘密)とエンコードルーチンは
自分しか知らないから、データだけの改竄はまず無理。
とは言えマシンコードそのものを変えられて、改造データを暗号化することなく読み込んで
しまうようなクラックをされたらどうにもならないげどね。
その場合はプログラムに署名してOSや認証局に頼るしかない。

384 ：

もっと凄腕だと思って質問したんだけど、
もーいーや。

385 ：

>>384
お前 ◆QZaw55cn4cか？http://toro.2ch.net/test/read.cgi/tech/1180280982/330

386 ：

いや違う

387 ：

ノートPCが盗まれたとき、ログインパスワードの強度が重要だと思うんだけど、
WindwosのNTLMv2認証って信用できるの？

388 ：

盗まれる前提ならパスワードだけで防御するのが間違ってる

389 ：

盗まれない前提ってアホかw

390 ：

NTLMv2認証の説明をざっと読んだ限りでは、ノートが盗まれたときのダメージを
左右する種類のものではないように思うんだけど。サーバからのチャレンジデータをどうこうらしいし。
WindowsならUltimateにしてBitlocker使うのが一番手っ取り早いんですかね？

391 ：

Windowsの暗号化ファイルシステムは、XPで、AES256+RSA1024。
しかし、ログインされると丸見え。

392 ：

なるほど、レスありがとうございます。。
つまりXP＋暗号化ファイルシステムのノートが盗まれた場合、
犯人のPCにノートPCから取り出したHDDを変換ケーブル等で繋いでもAES256+RSA1024が
破られない限りは大丈夫。
しかし、そのままノートをネットワークで犯人のPCで繋いでネットワークログオン(ここでNTLMv2？)が
成功するとファイルが丸見えになるということですね。それなら左右しまくりますね。

393 ：

ログインを成功させられるならネットワークいらねえよ

394 ：

いや、だからNTLMv2の安全性がどうこうの話になったんでしょ。
まあチャレンジレスポンスならヒントにはならなそうだけど。
パスワードがわかればネットワーク必要ないとかいうのは的外れ。

395 ：

ローカルログオンでもNTLMv2認証。

396 ：

NTLMv2はMD5だからもうダメだろう。

397 ：

＞まあチャレンジレスポンスならヒントにはならなそうだけど。
チャレンジレスポンスは、これを使用したネットワーク認証の通信部分は強くなるが、他の面では弱くなるぜ？
この辺分かってないやつが多いが。
チャレンジレスポンスに対応してるってことは、盗まれた場合の強度は逆に弱くなっているということ。
なぜならパスワードデータベースにソルトが使えなくなるから。

398 ：

＞パスワードがわかればネットワーク必要ないとかいうのは的外れ。
どういう意味か分からんが、盗まれたらオフラインでパスワードデータベースをクラックできる。
ネットワークは関係ないな。
で、このパスワードデータベースのクラックは、チャレンジレスポンスに対応してるせいで逆に楽になってるわけだよ、

399 ：

そこで生体認証ですよ。

400 ：

MD5ハッシュって破られてるんだっけ？

401 ：

強衝突耐性については、だいぶ弱いとわかっている

402 ：

新規に採用するのは非推奨、というあたりではないのん？
いや知らんけど

403 ：

新規に採用するのにSHA2以外はありえんだろ。暗号学的強度が必要なら。
とは言え、ひところ危惧されたほどSHA1は弱くなかったということなので、
既にあるものまでなにがなんでもSHA2にしろ、というほどでもないかな。

404 ：

使い所による。
署名のダイジェストとかに使うなら避けるべき。
パスワードハッシュとかなら別に好きにしろ。
まあパスワードハッシュなら本当はPBKDF2使うべきだが。
PBKDF2ならベースハッシュが多少弱くてもあんまり実害無い。

405 ：

一様かつ予測不能な乱数を生成したいので、メルセンヌ・ツイスタを使おうと思いました。
しかし、メルセンヌ・ツイスタは、一様な乱数を生成するものの、乱数の履歴から、
2^19937-1 のどこの地点から乱数を取ってきてるのか分かったら、次の乱数を予測
されてしまうので安全ではない、暗号学的ハッシュ関数を通す必要がある、らしいですね。
なるほどそういうものかと思って、SHA256 で切り刻むコードを書きました。
http://www.sourcepod.com/vupewt10-7054
しかし、これは安全なのですか？
ハッシュ操作してるとバレてるなら、攻撃者も同じように、メルセンヌツイスタの周期まるごと
SHA256でハッシュ化したデータを抱えて、いままでの数値の履歴から、結局、次の数値が
分かってしまうと思うのですが。
（ちなみに、本筋とは関係ないですが、単なる sfmt のコードはこれです。http://www.sourcepod.com/uhhyen53-7055 ）

406 ：

僕は素人だけど、 2^19937-1 個のハッシュ値を丸ごと抱えるってなかなかできないと思うよ

407 ：

>>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
> メルセンヌ・ツイスタは線形漸化式によって生成されるため、予測可能である
線形漸化式では暗号に使えないなら、どうすればいいんだろうか

408 ：

予測可能の意味を、たぶん取りそこなってるのかな。
MTのナイーブな実装の場合、内部ビットの個数分（19937ビット）の出力列があれば、
その後の出力列が予測可能でしょ？
たとえば線形合同法 X(n+1) = (a*X(n)+b) mod p で、X(n) の情報があれば、
X(n+1) を予測可能であるように、全体の空間に比べてごくわずかな情報から、
次の数が予測可能である、ということを、この場合に「予測可能」と言うわけ。

409 ：

生成した乱数列の羅列があればステータスを確定出来るんだろ？
ハッシュを通せば元の乱数列は不明だからステータスを確定出来ないだろ。
元の乱数が分からんと言うことは、周期分順に試していかないと、
どの部分か見つけられないって事。
全然違う。

410 ：

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

411 ：

>>408
ワタシは SFMT の内部構造は全く知らず、複雑でわからないんですが、ともかく、
内部ビットの個数分の出力さえあれば、総当りとかじゃなく、なにか逆算とかすれば、
内部ステータスが分かって、その後の出力も予測できるってことでしょうか。

コードで書いたとおり、256bit分の乱数を、sha256ダイジェスト生成API通して受け取った別物の256bitを乱数として
使えばよさそうですね。

412 ：

まあそういうこったね。
内部ビット数と同じとは限らず、周期よりずっと短いデータで内部状態を逆算できる場合も同じだね。
もっと直観的な説明でいくと、内部状態が結果列から逆算できる→予測できるってこと。
つまり一方向にしか導けない条件が必要であり、これってつまるところ暗号ハッシュと同等の性質をもつものしかダメってこと。
単なる乱数生成期で暗号ハッシュと同等の一方向性を持てるわけないよね。

413 ：

>>412
>>412

414 ：

使う側が互換する共通のアルゴリズムで使用すれば確率的に破られる運命だろ。
アルゴリズムを検証できる環境そのものが複製できちゃえばいつかは解析される。
合理的な共通規格そのものが暗号が破られる原因である。非合理で他に類似性が
なければ非常に単純であってもそれを推測することすらできない。
手品とか種がばれれば非常に簡単なのに、分からない場合は絶対に解明できな
かったりする。

415 ：

>>414
それは現代の暗号の考え方に反する。アルゴリズムを公開してもなお安全であることを追求する、のがポイントだ。
いいかえると、暗号の安全性が鍵の秘密にのみ依存するのが理想の暗号だ。

416 ：

全てのセキュリティは鍵のみに宿る。
って一言で言えないのかしら。

417 ：

そうなったのは、暗号については過去2000年ぐらいの歴史のうち、たかだか最近100年のことだからな。

418 ：

だから何？

419 ：

今世の中に存在するもので、100年以上昔に進歩が終わった技術で出来てるものなんてなかなか無いぜ。

420 ：

>>417
過去の考え方や >>414 は安全を追求していない。内部造反者等も考慮しなければならない。
>>416
ナイスですね。

421 ：

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/faq.html
> 出力列を8ワードごとに切って、ハッシュ関数で 1ワードに圧縮して使う
というようなこと書かれてはいますが、sha256 をアルゴリズムとして使うぶんには
MTが生成した乱数 256bit をハッシュ化して出力した 256bit
これを予測できない乱数として使っていいですよね
コード -> http://pastebin.com/Qjuwy7r3

422 ：

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

423 ：

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

424 ：

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

425 ：

うん。
ブルーとフォースや辞書攻撃などをオフラインで実行された場合に、圧倒的に強くできる。
パスワードハッシュにも使える、これを使うとパスワードデータベースの耐性も簡単に上げられる。
よくパスワードハッシュで、MD5やSHA1は危ないからSHA2を使わないとダメダメとか分かった風なことを言ってるのを見るが、
パスワードハッシュの用途ではSHA2使ってもそれほどは耐性は上がらないことを理解してない。
耐性を上げるにはPBKDF2を使う、これで比較にならないほど上げることが出来る。

426 ：

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

427 ：

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

428 ：

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

429 ：

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

430 ：

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

431 ：

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

432 ：

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

433 ：

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

434 ：

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

435 ：

>>434
それは確率的暗号方式
（鍵生成だけではなく、暗号化アルゴリズムも確率的アルゴリズムになっていて
たとえ同じ平文を暗号化しても毎回異なる暗号文になる）
の暗号化処理で使うランダムネスの話ですね
そういう目的で暗号化アルゴリズムへ入力する・アルゴリズム内で生成する
乱数やランダムネスをソルトと呼ぶことはあまりないと思う
てかパスワードハッシュのソルトの目的って>>472以外の何物でもないのに
バレない前提（ソルトがバレない限り安全ということ？）ってどういうこと？
>>431の読んだ参考書や解説が知りたい

436 ：

>>435のレスアンカー間違えた
472じゃなくて>>427だ
そういやずっと前に
共通鍵メッセージ認証の鍵（当然送信者と受信者以外に明かしてはいけない）を
ソルトって呼んでたブログや技術文書がどっかにあったような・・・

437 ：

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

438 ：

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

439 ：

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

440 ：

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

441 ：

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

442 ：

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

443 ：

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

444 ：

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

445 ：

ストレッチング回数なんていう、変に制約を気にしなければならない方式をわざわざ採用するメリットがない。
簡単に制約なくソルトで対応出来るのに、わざわざ制約をかけたがる意味が分からない。
ストレッチング回数なんていまでも多分10万回くらいだろう。
場合によっては幅が1万回もいかない。
それだとバースデーパラドックスで100人に一人くらいは一致する可能性が高くなる。
しかもソルトと違って途中経過も保存可能、こういうのは何らか攻撃手段を与えるきっかけになる。
こんなデメリットばかりなのにあえて使う意味が分からない。

446 ：

>多分10万回くらいだろう。
ふつう1000回ぐらいだよ。
>途中経過も保存可能
不可能だよ。どんだけ容量いるんだよ。
md5の128bitで1000回で、16000バイト。
大小英文字、数字8文字のパスワードのパターンだけで、62^8 * 16000 ≒ 3エクサバイト

実装したことない人？

447 ：

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

448 ：

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

449 ：

継続計算って何？
「なりかねない」って何。暗号理論で「なりかねない」なんて言葉、
あまり使わないと思うのが当たり前の感覚だと思うが。
>>443-444
木槌の代わりに金槌を使って痛い目に遭ったりしたことがないんだろうなw
多分、死ぬような目に遭わなきゃわからないんだろうなw
死んじゃったらわかりようもないけどw

450 ：

きちがい

451 ：

おまえ実は暗号関係素人だろ。
計算量のみに依存してる話と、何らかの問題によってその計算量が減らされる事象とは全く違う。
計算量を想定より減らされる危険があればそれは立派な弱点だよ。
それが暗号の世界だ。
じゃなきゃ例えば中間一致攻撃なんて弱点は存在しない。
実装上ありえないって、中間一致攻撃なんて実装上もっとあり得ない。
今回の話では、例えば繰り返し回数1000回程度の場合に、例えば1から1000回まで幅を持たせたら、
たまたま回数が低い場合に単純に耐性が1000分の一とかになる。
いくらなんでもこれは意味ないから例えば1000から2000回にしたとする。
ここで1000回目の値があれば、そこから1001回目の計算は1回分の計算でできる、これが継続計算できるの意味。
例えばレインボーテーブルの一種として1000回目の値を保持しておけば、
0回から1000回の計算で値が計算できる。つまり繰り返し1000回分の耐性が削られるわけだよ。
暗号の世界じゃこんなものは脆弱性以外の何物でもない。
そしてこんな不合理な方法使わなくても単純にソルトで安全に制約なく目的を達成できるんだ。
こんなバカなことをする奴はいない。

452 ：

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

453 ：

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

454 ：

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

455 ：

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

456 ：

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

457 ：

>>456
>>415

458 ：

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

459 ：

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

460 ：

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

461 ：

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

462 ：

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

463 ：

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

464 ：

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

465 ：

>>463
通信経路の暗号だと
鍵が見えたら、どうにでもなることでしょ、アルゴリズムがバレてたら
だから、通信中に鍵変えるのがあるでしょ
ファイル暗号だと鍵がわからないと手が出ないってだけ
総当たりするにしても時間がかかる

466 ：

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

467 ：

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

468 ：

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

469 ：

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

470 ：

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

471 ：

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

472 ：

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

473 ：

8文字以上のパスワードにするだけで、
そんなレインボーテーブルはこの世に存在しないから、総当りしかない。
ここで防御力を発揮するのがストレッチング。メタルスライムレベルの防御力。

474 ：

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

475 ：

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

476 ：

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

477 ：

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

478 ：

>>465
＞通信経路の暗号だと
＞鍵が見えたら、どうにでもなることでしょ、アルゴリズムがバレてたら
そのとおり。
しかし、通信を行う双方で同一の鍵を使うことが可能で、かつその鍵が第三者には明らかにならない方法が存在する。
つ「DH鍵交換」
あるいは、暗号化で使用する鍵と復号化で使用する鍵が異なり、送信側に暗号化用の鍵を渡して、自分の復号化用の鍵を秘密にしておく方法もある。
このとき秘密にしている復号化用の鍵は、暗号化用の表に公開する鍵からは簡単には計算できない仕組みになっている。
つ「RSA暗号」「公開鍵暗号」
つ「一方向関数」

479 ：

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

480 ：

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

481 ：

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

482 ：

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

483 ：

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

484 ：

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

485 ：

>>479
また論点がずれてるぜ。
それは安全性の保証じゃなくて、すでに破られているわけではないことの保証にしかならない。
現実に破られてないからOKなら、128ビットの暗号化なんて不要。
危険性の説明に実在するかどうかなんて関係ないだろうが。
実在しないのは安全性のための必要条件に過ぎない。

486 ：

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

487 ：

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

488 ：

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

489 ：

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

490 ：

実在しないかどうかは知らないもん。
お前が初めから実在するかどうかが重要ってスタンスで聞いてくるから、
実在するかどうかは関係ないって言ってんだろうが。
悔しいって笑わすな、ずっとずれたこと言い続けてんのはお前じゃねーか。
実際に実在しない保証はないが、まあおそらく総当たりのテーブルは実在しないだろう。
で、だからどうしたの？そんなことは話の本筋に関係ないといってる。

491 ：

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

492 ：

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

493 ：

話の本筋を理解できないもしくはごまかし続ける相手に説明するのは無理、時間の無駄。
どうせごまかしたり論点ずらしたりするだけなんだから。
繰り返し回数をソルトの代わりに使うことの合理性をきちんと説明してみろって。
ああ、こいつの言い分だとそもそもソルトとかテーブル対策は要らないんだったｗ
8文字以上のレインボーテーブルは存在しないのでテーブル化対策は不要です、キリっ

494 ：

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

495 ：

中間者攻撃でアウト。
特に無線LANとかだとひっかけやすい。
だから証明書とかが必要なんだな。

496 ：

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

497 ：

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

498 ：

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

499 ：

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

500 ：

>>497
OK

501 ：

しかし、英数字パスワードだと、1文字辺りって6ビット程度だよな。
記号入れても7ビットはいかないが。
8文字だと48ビット程度か。
ビット数だけならDESより余裕で弱いんだな。
まあそれ以前にパスワードのエントロピーなんて乱数よりずっと低いが。
48ビットだと組み合わせ数は256Tか。
計算途中を再開するためには全情報が要るが、
単なるテーブルなら先頭の例えば64ビット分だけでも十分かもしれん。
とすれば8バイト×256Tで、2Pバイトか。
暗号関連の、ホントに現実的じゃない安全想定に比べたら、
余裕で実現可能なレベルだな。

502 ：

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

503 ：

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

504 ：

瓶詰演算
これら楕円曲線上の点の上に、次のような演算を定義すると、群になる。
すなわち、(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 ：

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

506 ：

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

507 ：

>>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 ：

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

509 ：

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

510 ：

cbc modeの話だと仮定します。
IVは暗号化前に生成しておいて、
復号時にも同じ値をIVとして使用します。
通常IVは暗号化しません。
また、Keyは対称鍵暗号で使う対称鍵のことと仮定しますが、
Keyのみを公開鍵暗号で暗号化して、
暗号化対象の実体は対称鍵(Key)で暗号化します。

511 ：

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

512 ：

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

513 ：

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

514 ：

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

515 ：

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

516 ：

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

517 ：

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

518 ：

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

519 ：

事実、現実が不適切な運用だらけなのに、
それを前提にしないシステムは欠陥ありというべきであろう。
最低限、EFSを使用する場合には、ログインパスワードのセキュリティポリシーを
強制的に厳しくするべきだね、MSは。

520 ：

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

521 ：

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

522 ：

>>521
暗号文とハッシュ値、ハッシュの秘密鍵と復号鍵の格納場所がどこで
どんな経路を通じて誰が一貫性（完全性ともいう）チェックと復号をするのかによって
いろいろ変わるのかもしれないけど、一般的にはEncrypt-then-Macといって
（１）最初に暗号化する
（２）次にその暗号文のキー付きハッシュをとる
という順番になる
もとのデータを利用したいときは
（１）まず暗号文の完全性をチェックする。エラーを検出したらそこで終了
（２）暗号文を復号する
という手順になる
この順番にすることで、勝手なデータを復号処理に入力して、その出力結果を観測して
暗号の安全性を破る攻撃（選択暗号文攻撃）を防ぐことができる
あるいは最初から秘匿とメッセージ認証の機能をあわせもつ
認証付き暗号（認証子付き暗号ともいう）を使うという手もある

523 ：

そこらへんの暗号化や署名したデータのフォーマットを各自が考えると相互運用性や
可搬性が低くなるから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 ：

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 ：

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

526 ：

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

527 ：

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

528 ：

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

529 ：

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

530 ：

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

531 ：

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

532 ：

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

533 ：

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

534 ：

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

535 ：

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

536 ：

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

537 ：

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

538 ：

2ch_prog20004140935082220001
のSHA256ハッシュを取ると
00000000015FBAE7DCBE0642BE86EAD87962183AF994884DD2159188B90EF494
で0のビットが先頭に39個続く
2ch_progから始まる文字列でこれより長く0のビットが続くの探してみて

539 ：

【IT】マイクロソフトが発見！中国製PCに出荷時からウィルス「中国製のパソコンや情報端末の購入には、慎重になったほうがいい」★２
http://uni.2ch.net/test/read.cgi/newsplus/1347879086/
＊＊＊＊＊＊＊＊＊＊＊＊
可能性としてありうる。
１、中国製パソコンの画像データには以下の実行
プログラムソースがふくまれてる。
２、有事の際には中国当局からネットで全世界の
パソコンに指示を出し、機能停止が可能。
３、夜間定期的に送受信メールやテキストファイル、PDFの中身を
自動的にスキャンして、中国に対する不利益な動きに対し
自動的に中国当局に警報メールを発信する。もちろんIPアドレスから
そのPCの位置情報、個人情報のすべて。
４、上記を検出、ソース表示をしようとする動きに対し、フリーズ、暴走する機能内蔵
技術的にはすぐにでも可能。
というかすでに中国出荷の全PCやBIOS
のレベルでインスコ済みの可能性がある。
　
＊＊＊＊＊＊***************

540 ：

保守

541 ：

不正防止とコスト
市場はどっちを選択するんだろうなぁ

542 ：

誰かがコストを選択して痛い目に遭ってから、不正防止を選択します。
顕在せぬ危険性について、株主が理解することは不可能でしょ。
どっかの株価大暴落がないと駄目だろうね。

543 ：

なんでITだと、「こんなこともあろうかと」が無いんでしょうかね

544 ：

>>543
物理的な「こんなこともあろうかと」は認知しやすく
論理的な「こんなこともあろうかと」は認知しにくい
ってのが大きいんじゃなかろうか。
「分かった気になれない」「シッタカデキナイ」
かな？
なんか地味なんだよね。
MySQLとかでミラーリングしてて上手く決まっても、
発動したことはログに残っているだけだし。
パフォーマンスが悪くなっていても、何とか耐えれちゃう。
俺が復活の呪文唱えればそれで平常運転になる。
だからといって、「俺が救った、俺がすごい」なんて言いにくいし。
障害報告で軽微な影響となるだけだし。
2匹ともRば理解できるだろうけど、
そんなことならないように俺がいるわけだし。
ITとずれてしまうけど、知的業務繋がりということで、
暗号学なら、差分解読法の顛末が「こんなこともあろうかと」になるんじゃない？
有効な攻撃方法を誰かが見つけるだろうと考えて、DESを設計した。
「差分解読法を他の誰かが見つけることもあろうかと・・・」
でも、知ってて黙ってたってのだから、違いはするか。

545 ：

ここの皆さんはやはり凄腕客家ーなんですかね・・

546 ：

えっ？

547 ：

ROUNDsurea
ってことは
surea
が何番かってことなのか

548 ：

WinRARでパスつき(AES)ファイルを作成したりしていますが、フリーで使えるツールの中ではAESは1番強度の高い暗号アルゴリズムでいいのかな。
71のレスを読むと、AESアルゴリズムを使っていても他の部分で脆弱性があれば、解析されやすくなるということだと思いますが、AESのツールの中でそういうのを少しでも判別する方法があるか調べてみたい。

549 ：

また、強度を少しでも強くするためのパスワードのつけ方について、
解析方法を「数字のみ」「英数字」など選択せずに、全数探索で「1,2,3‥」として、
1文字目を存在するすべての文字を照合してから2文字目にいくとして、
「abc123」と「,.;:^|」は同じ6文字で強度はあまり変わらないのかな。
全角文字でパスワードをつけた場合のことも調べる必要あるし、長いパスワードをつけても何文字目かまでしか認識されていないツールがあるというのも見ました。

550 ：

今のスーパーコンピュータなどを使っても解析に数年から数百年以上かかるくらいの強度を、今のフリーのツールでも実現できていてほしい。
「パスワード 解析にかかる時間」でぐぐってあとで見てみます。

551 ：

できました！ありがとう。

552 ：

ブロック暗号化って暗号データと元データがあると解析されやすいらしいけど
HDDを暗号化するとしてHDDの後半とかには大抵ゼロうめされた領域があるじゃない？
ってことは元データをゼロ決め打ちして解析することってできちゃうんじゃないの？
そこんとこどうなの？

553 ：

元データがあるなら解析しなくて済む罠

554 ：

>>552
LBAをCTRにするとか。

555 ：

なるほど、わからん

556 ：

まったくの素人だがとあるソフトの暗号通信解析してたらちょっと感動した
まず クライアント内で最初から持ってる鍵 で GetTickCountで取得した時間と最初の鍵を織り交ぜた復号用の鍵 を生成して
その鍵を 最初の鍵 で暗号化して鯖に送ってそれの返答でサーバーから 別の鍵 が送られてきてその鍵を 前回の復号用の鍵 で復号して
復号した鍵 から 新たな復号用のカギ を生成して 前回送られてきた鍵 をそのまま 最初の鍵 で暗号化してサーバーに送って鍵を確定させて
帰ってきたデータを 復号用のカギ で復号してそのあと前回サーバーに送った確定した鍵を元に 暗号用のカギ を生成して
それ以降は一定時間毎にサーバーから新たな鍵が送られてきて元の鍵を混ぜ合わせて更新するという流れだった。
大体のソフトの通信も似た感じなんだろうけど、最初から通信監視してないとまず復号できないし、すごいなーって素で思っちゃったよ

557 ：

要はCBC

558 ：

初歩的な質問ですみません。
完全に自作のアルゴリズムではなくPHPやPerlで標準のハッシュ・文字列関数等のみで
「入力と出力の対が知られても変換の法則の推測は難しい」関数を作ることはできるでしょうか？
文字列A(人間が覚える必要はない。例えば128ビット)を入力して、
その後ある認証を行い成功したら、Aを元にした文字列Bを返すプログラムを作りたいのですが、
攻撃者が認証を繰り返しAとBのペアを例えば1万通り入手したら、そこから変換の法則を推測し、
以後認証プログラムを使わなくても自前でAからBを得られるようになってしまうでしょうか？

559 ：

yes
yes

攻撃者（）がAからBを得られたところでどうでもいい

560 ：

すみません。質問が悪かったようです。
(あと業務で使うものではないので絶対に破られてはならないものではないです)
Web上でPerlで動いているプログラムXに特殊な方式の認証機能を追加したいのですが、
この認証方式のフリーのプログラムがPHP版しか見つからず、Perlで作り直す余裕もないため、
XはユーザーにチャレンジAを発行＆セッションに保存→ユーザーは認証プログラムにまずAを入力
→さらにある認証をし、成功したらレスポンスBを出力→ユーザーはXにBを入力
という方法を考えました。
暗号アルゴリズムも詳しくないので、定数リテラルでソルトを与える・入力の部分文字列からソルトを生成・
複数回ハッシュを計算など、単純な関数だけの組み合わせで法則が推測困難な物は作れるのかと思いまして。
法則が推測されると認証しなくてもチャレンジからレスポンスが生成できるので、システムが成り立ちません。

561 ：

>>558 の質問の答えが yes yes だったとしても
チャレンジからレスポンスが生成できなくしてしまえばいい

562 ：

captchaのことかな

563 ：

>>562
はい。
>>559>>561
まずyes yesというのは、何重にも組み合わせることでより時間がかかるようにはできるが、
いくら難しくしても結局は現実的な時間内で解析可能、ということでしょうか。
そして、チャレンジからレスポンスが生成できなくしてしまえばいい
というのは、バレたら(もしくは一定時間ごとに)新しい法則に変えてしまえばいいということでしょうか。

564 ：

そうじゃなくて関数自体は解析されてもレスポンスを作れなければ良いんです
言い換えると認証確認時に鯖側でチャレンジからレスポンスを作るのが間違ってる

565 ：

>>564
そもそもチャレンジというものを使わず、ユーザーには最初に認証プログラムにアクセスするようにさせ、
認証成功時は時刻同期OTPのような方法か、または認証プログラムからXに裏側でBを送るかし、
ユーザーがXに入力したBの値を検証するようにすれば、チャレンジがわからないからレスポンスもわからない？
あ・・・そもそもレスポンスすらいらず、成功時認証PがXにGETなりして「認証成功」ってセッション作らせて、
Xが発行したセッションIDをユーザーに通知して、ユーザーはそれを持ってXにアクセスすればいいのか・・・？

566 ：

チャレンジレスポンスの仕組みは利用するよ

567 ：

解析されてもレスポンスが作れないって意味が分かってないだろうから具体的に教えてあげれば？
言わんとしてることがよく分からないから俺は教えてやれないが。

568 ：

webサーバーが乗っ取られて（覗かれて）も、大丈夫なようなnetwork構成にするとか

569 ：

馬鹿には無理

570 ：

AESキャッシュ攻撃のアルゴリズムが詳しく載っている論文知らないですか？
プログラムだとベストです

571 ：

そういうスレじゃねーからw

572 ：

スパムメールの脅威
http://music.geocities.jp/jphope21/0203/35/234_1.html
暗号解読をクリアする方法の問題点にあった。
( http://music.geocities.jp/jphope21/0103/38/265.html )

573 ：

>>570
https://www.google.co.jp/search?q=AES%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E6%94%BB%E6%92%83
で結構でてきているようだよ，あとAES/Rijndael は選定当初よりいろいろいわれていたね

574 ：2013/10/06

>>573
ありがとうございます