■暗号技術【ROUNDsurea】■

>>193
その通りだ

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

保守

サイド

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

こんな暗号じゃだめですか？

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;

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

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

できるだけ長い単語をさがしてます。
お願いします。

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

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

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

ハッシュ関数作りました。評価してみてください。

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++;
}

}

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

何を分かりきったことを

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

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

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

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

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

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

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

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

誰かこの暗号解いてくれ(涙

27 102 8 -36 44 62 77 122 う

ヒントは-36の-はｱｰﾄとか言葉で伸ばしてる-らしい(´;ω;｀)

宜しく頼んだぜｯｯ

解説も できたら頼む。

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

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

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

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

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

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

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

優良じゃないんだ

無料のやつないですか？

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

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

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

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

ひどいね。

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

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

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

http://sky.geocities.jp/tcshacina/proj.rb

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

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

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

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

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

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

Shorのアルゴリズム

ビットスライスDES(bit-slice DES, bit-sliced DES)について詳しく解説された専門書でおすすめのものがあれば教えていただけないでしょうか？
わかりやすいものであれば論文でもかまいません。

わかりにくい論文は・・・ 私は暗号の専門家じゃないのでつらいです。

ビットスライスDESをスクラッチから実装したいと考えています。

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

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

ある暗号文と対応する平文を入手したときに(ry

というやつだな

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

AESじゃないの？

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

説明してごらん

日本から外国人研究者を全部追い出して、
日本の国力をさらに下げたい二重スパイだろw

日本に来るようなのは、各国の最高レベルの研究者だってのに。

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

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

AES

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

鍵配布をどーするつもりだよ?
おとりをどー排除するつもりだよ?

とマジレ酢。

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

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

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

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

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

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

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

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

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

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

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

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

10桁アルファベット大文字小文字、数字
のパスワードを作る場合

同じ文字の「重複あり」と「重複無し」

どちらが強度があるのでしょうか？教えて下さい

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

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

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

すみません＾＾；

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

>>269
つ一方向関数・ハッシュ関数・メッセージダイジェスト。

ヘッダファイルからパスワードを推測することは、多分無理だろう。

それなら安心＾＾

あげ

[再放送] サイエンスＺＥＲＯ「ネット社会を守れ！究極の量子暗号」
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

>>276
教えてくれてありがとう。興味深かった。

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

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

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

あげます

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

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

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

理論上可能なんですね。
もう少し見てみます。

コイン投げゲームをコミットメント・スキームを使って Java で実装したいと思ってます

Alice が表か裏かを示した暗号化したデータを鍵Aで暗号化して、Bob に渡します
その後、Bob が表か裏かを言います。その宣言の後、Alice は鍵AをBobに渡し、暗号化された表か裏かを示したデータを開きます

とはいえ、この場合、Alice は表か裏か結果を知ってから、鍵を渡すことになってしまいます
うまく鍵を調整すれば、鍵の差し替えることで、裏か表かを後追いで言い当てる、みたいなこともできますよね

これを回避するにはどうすればいいですか。

表か裏かを書いたデータと一緒に、電子署名をつければ、よさそうな気がします。（SHA256withRSA で署名すると、1024bitあるので）
しかし、私は暗号の専門家ではないのでこれでも本当に安全かわかりません

それとも、コイン投げをするのにもっとスマートな何か方法がありますか？

>>284
お互いが内容の分かっている、ある程度の長さを持つ定型文を含めればいいんじゃないか？

「2011/10/09 15:40 分に投げたコインの向きは 表」

みたいな文章を暗号化して

「2011/10/09 15:40 分に投げたコインの向きは」 の部分は平文でも送信する

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

>>285
この場合それでも安全かもしれませんね

>>286
暗号化前のデータに対して、電子署名つけたものを、いっしょに暗号化して
Bob に送ればOKってことですね

今後、このデータを「コインの表裏」だけじゃなくて、
ランダムな乱数種とかも送れるようにしたかったんで
アドバイス助かりました

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

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

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

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

Alice の不正行為を根本的なところで防ぐには、事前に計算できない攪拌因子を Bob が選択するのが良い
最も簡単なところで、

・最初に Bob が裏/表に対応する符号語を選択して送信 (例えば1024ビットの乱数)

次点で、

・Bob, Alice 双方で暗号化用の鍵を選択 (k1, k2)
・Bob が鍵 k1 を送信
・Alice が平文 x を選択し、暗号文 y=e_k2(e_k1(x)) を送信

といったところか

↓メンタルポーカープロトコルの実装について質問です
http://en.wikipedia.org/wiki/Mental_poker

一言でいえばこの手順は、カードを一枚づつ暗号化して、ゲームの進行上
カードを開く権利のあるプレイヤーに鍵を渡すという方式なんですが、

これも、カードゲーム開始前に、鍵１つにき、また SHA256 などの強力なハッシュをつけて
あらかじめ公開しておかないと、またウソの鍵を渡してゲームの進行を止めることが
できてしまうのでは。ハッシュをつけないと、ウソの鍵を渡した人の、特定が不可能な
気がします。

wikipediaにはその手続きが無いのは、単に wikipedia の書き手がそこは省略したってことでしょうか。

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

>>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
でもなんでもいい

>>295
レスありがとうございます。AESってそんなチート性能だったんですね…
つまり本当の意味でMental Pokerの手続きを理解するためにはAES(Rijndael)の数理を
理解しなければいけないと。
しかしAESなら実装には困らない（サンプルが豊富）だろうしMental Pokerの実現は思いの外
手が届きそうな気がしてきました（麻雀のためにコーディングする気はないですが）。

ちなみに俺の素人考えでは>>293の件は鍵のコミット・否認防止は必要で、
つまり著者が省略したのだろうと思っています。

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

メンタルポーカープロトコルの欠点は、
一人でも回線落ち、持ってた秘密鍵を捨ててしまうと
カードの中身が復元不可能になることだな

麻雀でいうと、突然ヤマを壊して場を立ち去ることと一緒

するとまあ、チョンボ扱いになるのだろうが、しかし、
これを失点扱いにしてしまうと、周りの三人が組めば
容易に一人をチョンボ扱いとして貶めることも可能

鍵渡しても、三人揃って受け取ってないフリをすればいいだけだから
逆のウソもありうる　実際は回線落ちしたのに「鍵をちゃんと渡したが周りの三人が応答しなかった」
みたいな、言った言わない問題はありうる

結局、審判が要ることには変わりないな
まあ、↑の不正は、ゲームの履歴がオンラインにあれば、
何度もできることじゃないから、それが多少抑止力になる

しかし、ビットコミットメントスキームで第三者に乱数種渡す方式よりは強いか

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

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

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

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

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

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

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

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

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

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

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

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

>>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 の優位性がよくわかりません。

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

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

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

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

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

みんな優しいねぇ

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

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

>>319
RSA アルゴリズムに「認証」機能を実現するからくりは含まれていないと考えます。

>>316 RSAは応用範囲が広い
は理解できるのです（暗号だけでなく署名にも使えますから）。しかし、

>>313 RSAは中間者攻撃に耐えれる仕組みを用意してる
>>317 その応用範囲を使って中間者攻撃にも耐えられる

というのは不正確あるいは誤りでしょう。RSA 単独ではそれは不可能ですから。
今、DHとRSA との比較に話題を絞っているのに、両者に関係のない、あるいは両者とは別のからくりである認証を持ち出されてこられると困惑します。

>>319　きちんとほかの人の投稿読んだ方がいいと思うな

むしろ >>319 こそ >>302 の「DH と RSA との比較に絞っている」大前提を読んでいただきたい、と痛切に感じます。>>313, >>317 に至っては問題外でしょうね。

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

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

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

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

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

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

>>301
暗号に詳しい人はここは読みに来ないようですね。残念です。

>>329
つ http://internet.watch.impress.co.jp/static/uocchi/2007/04/01/kentei.htm

>>330
スルー対象の本人がこんなの貼り付けるってどういうことなの？
ここに居座るつもり？迷惑だけど

「スルー力検定」の受付がスタート
全日本通過技術検定協会が定めた「スルー力検定」ロゴ

　全日本通過技術検定協会は、物事をスルーできる力を客観的に測定する「スルー力
検定」を全国7都市で実施すると発表した。受講料は1級8,000円、2級5,000円。

　「スルー力（するーりょく）」とは、インターネット時代に必須とされる、物事をうまくやり
過ごしたり、見てみぬふりをするコミュニケーション技術。掲示板やブログ上での不快
なレスを読み飛ばすのはもちろん、上司や同僚からの仕事の依頼を何気なくかわす
など、ビジネスからプライベートまで幅広く応用できる。

>>331
不合格ｗ

>>331
はい。不合格。

スルーしても糞コテがいなくならないんだもん
黙ったままでいても糞コテには意味が無い
俺を黙らせるためにスルー力検定なんてもんを貼ってやがる

暗号に詳しくてもお前の態度が気に食わない、
理解できないようだから答えないんだよ

>>334
はい。不合格w

>>332
先をこされたか。

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

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

>>334
>暗号に詳しくてもお前の態度が気に食わない、
>理解できないようだから答えないんだよ

言うだけならかんたんだよ。詳しいというんだったら、その実力をみせてよ。

>>336-337
不合格w

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

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 というのが、意味がわからないのだが・・・

それぞれのプレイヤーが暗号化した数字を出しあって、暗号化したまま足し算して、
カードの衝突があればもう一回って、そんな器用なことできるものなのか？
中身は分からないが、衝突は発見できる、って、そんな無茶な

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

あの……落とし物ですよ？

　　　　　　　　 ∧__,,∧
　　　　　　　　（´・ω・`）
　　　　　　　　(つ夢と）
　　　　　　　　 ｀ｕ―ｕ´

　あなたのすぐ後ろにありましたよ？

和や積の準同型暗号自体なら
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
だと，なんか分散計算でやってるみたい
３ページ目の最後の６行の理屈がどうしてもわからない・・・

hoshu

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

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

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

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

現場のバカが泥をぬったくってくれてるがw

だれか暗号といてくれ！！

m7752902780
q5670754954
w2654637406
q5286271066
m8125522416
a1926172574
x504148223
l9676431138
g5289793839
l5799859691
n5135660909
g5241613386
k4148674163
p2895427859
i4115643171
d6373795065

----------------------
a0c2e4g6 : aaaa
a0z1c2x3 : aaaa
p65e68t2o51d27n48u38n13 : corneria
x6136494262r7484725313x185670378k2531105274x7114948063 : venom

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

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

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

てす

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

awe some blackhole
だろバカ

おー寒っ

awesome blackhole
だろ低能

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

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

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

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

電子「署名」だったらあるかも。
改竄される恐れがない秘密鍵を別媒体に持っていることが前提だけれど、
kernelとか好き勝手に入れ替えられると困るよね。
kernelに対して電子署名を検証できれば改竄されていないkernelって信用できる。

ううーん、、、
公開鍵「暗号」を使って『暗号化』が有効だと思える例は思いつかない。
ごめん。

うーん。
現在でも公開鍵暗号で『暗号化』するのって、
対象鍵暗号で使う「対象鍵」だもんね。
通信しないのであれば公開鍵暗号の旨味はないと思う。

電子[署名」なら考えれば良い例があるかもね。

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

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

世界に自分ひとりしか存在しないなら、公開鍵暗号も秘密鍵暗号も無用の長物。
世界で自分以外の全てが敵なら、公開鍵暗号は無用の長物。秘密鍵暗号は有用。
世界に自分と、敵と、敵ではない誰かがいるなら、公開鍵暗号も有用。

「他者と通信する必要もなく個人で」という用途の中に家族とか友人とか
そういう緩めの第三者がいないなら、公開鍵暗号は意味ないだろうね。

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

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

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

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

>>368
key = sha1(password)
decrypt(cipher, key)

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

>>370
仮にそれを364が言った「いちいちパスワードを入力しなくてすむ」方法の中身だとして、
果たしてそれは秘密鍵暗号では不可能で公開鍵暗号でのみ特有な何かがあるのかな？

って言おうとしたら突っ込むべきところが違ってた。SHA-1は公開鍵暗号じゃねーよｗ
メッセージダイジェストとかハッシュ関数とかそういうカテゴリだ

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

>>371

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

>>371
>>371
>>371

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

公開鍵暗号でゲームのデータの一部をエンコードしているよ。

データを吸い出すことは出来ても、チートデータは作りにくいはず。

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

>>378
対象鍵暗号じゃデコードルーチンと秘密鍵をユーザーがいくらでも
覗けるから、エンコードルーチンを簡単に作れてしまう。

これでは容易に改造可能。
目的はデータ秘匿ではなく改ざん防止。

ちなみに対称ね

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

数学的なお話しでは、
暗号化・復号の際の非対称性をうまく利用してるって話ね。
納得。ありがとう。

crackしようかと思った場合は暗号化方法を判断しないといけないわけですが、
これは各暗号化方法に固有の定数を見つけ出して当たりを付けてるんでしょうか？
もしそうなら、定数を適当に0xff辺りでxorして守っておいた方がいいのかなー？
と思ったので聞いてみました。

>>382
暗号化方法が何かはコードを読むしか無いよね。
自分はオリジナルの式を使ってるから、文献をそのまま当てはめても、まず見つからないし。固有の定数も無い。

クラッカーがマシンコードを読めるのは当たり前として、秘密鍵(形式も秘密)とエンコードルーチンは
自分しか知らないから、データだけの改竄はまず無理。

とは言えマシンコードそのものを変えられて、改造データを暗号化することなく読み込んで
しまうようなクラックをされたらどうにもならないげどね。
その場合はプログラムに署名してOSや認証局に頼るしかない。

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

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

いや違う

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

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

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

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

WindowsならUltimateにしてBitlocker使うのが一番手っ取り早いんですかね？

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

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

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

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

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

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

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

＞パスワードがわかればネットワーク必要ないとかいうのは的外れ。

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

そこで生体認証ですよ。

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

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

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

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

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

一様かつ予測不能な乱数を生成したいので、メルセンヌ・ツイスタを使おうと思いました。

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

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

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

（ちなみに、本筋とは関係ないですが、単なる sfmt のコードはこれです。http://www.sourcepod.com/uhhyen53-7055 ）

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

>>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
> メルセンヌ・ツイスタは線形漸化式によって生成されるため、予測可能である

線形漸化式では暗号に使えないなら、どうすればいいんだろうか

予測可能の意味を、たぶん取りそこなってるのかな。

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

たとえば線形合同法 X(n+1) = (a*X(n)+b) mod p で、X(n) の情報があれば、
X(n+1) を予測可能であるように、全体の空間に比べてごくわずかな情報から、
次の数が予測可能である、ということを、この場合に「予測可能」と言うわけ。

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

全然違う。

極端に言うと例えば、

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

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


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

まあそういうこったね。

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

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

>>412
>>412

使う側が互換する共通のアルゴリズムで使用すれば確率的に破られる運命だろ。
アルゴリズムを検証できる環境そのものが複製できちゃえばいつかは解析される。

合理的な共通規格そのものが暗号が破られる原因である。非合理で他に類似性が
なければ非常に単純であってもそれを推測することすらできない。
手品とか種がばれれば非常に簡単なのに、分からない場合は絶対に解明できな
かったりする。

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

全てのセキュリティは鍵のみに宿る。

って一言で言えないのかしら。

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

だから何？

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

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

>>416
ナイスですね。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> バレない前提の説明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ふつう1000回ぐらいだよ。

>途中経過も保存可能

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


実装したことない人？

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

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

継続計算って何？

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

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

きちがい

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

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

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

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

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

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

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

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

>>456
>>415

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つ「DH鍵交換」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

お考えをうかがいたい。

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

>>497
OK

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

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

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

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

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

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

瓶詰演算

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

という順番になる

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

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

という手順になる

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

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

そこらへんの暗号化や署名したデータのフォーマットを各自が考えると相互運用性や
可搬性が低くなるから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(要は暗号化)の入力になるとは書いてある。

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では、ハッシュを先にするべきなのかなとハッシュを先に書いた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2ch_prog20004140935082220001

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

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

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

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

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

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

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

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

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

保守

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

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

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

>>543
物理的な「こんなこともあろうかと」は認知しやすく
論理的な「こんなこともあろうかと」は認知しにくい

ってのが大きいんじゃなかろうか。
「分かった気になれない」「シッタカデキナイ」
かな？

なんか地味なんだよね。
MySQLとかでミラーリングしてて上手く決まっても、
発動したことはログに残っているだけだし。
パフォーマンスが悪くなっていても、何とか耐えれちゃう。
俺が復活の呪文唱えればそれで平常運転になる。
だからといって、「俺が救った、俺がすごい」なんて言いにくいし。
障害報告で軽微な影響となるだけだし。

2匹とも死ねば理解できるだろうけど、
そんなことならないように俺がいるわけだし。

ITとずれてしまうけど、知的業務繋がりということで、
暗号学なら、差分解読法の顛末が「こんなこともあろうかと」になるんじゃない？
有効な攻撃方法を誰かが見つけるだろうと考えて、DESを設計した。
「差分解読法を他の誰かが見つけることもあろうかと・・・」

でも、知ってて黙ってたってのだから、違いはするか。

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

えっ？

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

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

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

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

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

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

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

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

なるほど、わからん

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

大体のソフトの通信も似た感じなんだろうけど、最初から通信監視してないとまず復号できないし、すごいなーって素で思っちゃったよ

要はCBC

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

yes
yes


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

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

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

captchaのことかな

>>562
はい。

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

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

>>564
そもそもチャレンジというものを使わず、ユーザーには最初に認証プログラムにアクセスするようにさせ、
認証成功時は時刻同期OTPのような方法か、または認証プログラムからXに裏側でBを送るかし、
ユーザーがXに入力したBの値を検証するようにすれば、チャレンジがわからないからレスポンスもわからない？

あ・・・そもそもレスポンスすらいらず、成功時認証PがXにGETなりして「認証成功」ってセッション作らせて、
Xが発行したセッションIDをユーザーに通知して、ユーザーはそれを持ってXにアクセスすればいいのか・・・？

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

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

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

馬鹿には無理

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

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

スパムメールの脅威

http://music.geocities.jp/jphope21/0203/35/234_1.html

暗号解読をクリアする方法の問題点にあった。

( http://music.geocities.jp/jphope21/0103/38/265.html )

>>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 は選定当初よりいろいろいわれていたね

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

格子暗号が気になる

暗号解読助けてください！
N＝27

公開暗号鍵（1517,137)
よってexponentkは360

137d≡1(mod360)
　
　　　〜
　　　〜
1＝137・113-360・43

d=113

秘密鍵dを用いて暗号文BNGBYQBY_BZ_AK_BQDBTBBNW
最後尾の三文字BNWには1・27^2+13・27+22=1102が対応しています。
これを27進展開すると125=4・27+17になるのでerが得られます

dの値は僕が計算した結果113となりました。


BNW
N進表示(1,13,22)
N進展開(1102)

1102^d≡125(mod1517)

ABCD〜〜〜〜〜〜〜〜X Y Z _
0123 23 24 25 26

です。
途中計算含め教えてください

N＝27

公開暗号鍵（1517,137)
よってexponentkは360

137d≡1(mod360)
　
　　　〜
　　　〜
1＝137・113-360・43

d=113

ここまではよいのさ
ここまではな

宿題丸投げスレってなかったっけ

鍵が分っていても暗号化した当事者の同意、許可なしに暗号を解除することは違法です。

>>578
キチガイが気にならなければここがhttp://toro.2ch.net/test/read.cgi/tech/1313183984/

>http://anago.2ch.net/test/read.cgi/scienceplus/1395148087/
>　日本電信電話（NTT）は3月17日、世界最大規模となる、100万
>ビット規模の量子コンピュータの実現に向けた新手法を確立したことを発表した。
おまえら、ＰＣの時代がおわるぞ。
もう暗号とか一瞬で解読されちゃうから、進入し放題だ

それはRSA暗号＝因数分解問題のことじゃないか？
離散対数問題＝DH鍵交換とその同類はまだまだ大丈夫じゃないかったのか？

離散対数問題も多項式時間になりあやういみたいだね、なにか別の方法はないか？

ECDLP

opensslまたきた

http://ccsinjection.lepidum.co.jp/ja.html

ttps://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/

このサイトで解説しているMS-CHAP V2だけど
DES用の三つの鍵のうち、ひとつは2^16の解析で済むよ
残りの二つは2^56だけどひとつのループ内でチェックを二回するだけだから
一回分の時間と大差ないよ、と書いているように思えるんだけど

だったら

三つ目の鍵が2^56であっても
ひとつのループ内でチェックを三回するだけだから
一回分の時間と大差ないよ、になりませんかね？

なんか矛盾しているように思えるんだけどなぁ
勘違いしてたら指摘して。

どの途、2^56回のループで済むって話だろ。

そもそもDESが56ビット鍵なのが問題なわけで
1個の鍵が16ビット相当になることなんて問題なくね？って話。
理解不足ならごめん。

S/Keyで教えて下さい。
ログイン回数が0になると
seedの再生成が必要ですが
この処理はサーバが暗黙的に行いますか？
再度ログインしてユーザーが行いますか？

Cookieを使わずにユーザーを追跡する仕組みが普及しつつある
http://it.slashdot.jp/story/14/07/22/0613210/

Jane Styleは大丈夫？ 助けが必要かな？