11/02/10 09:21:59
>>236
だったらその計算能力や量子技術が他にも応用されているようすを、
きちんと描かないとな。
238:デフォルトの名無しさん
11/02/10 20:04:12
暗号は基本的には誰か（通常は通信相手）には解読されないといけない物だから、
物語中で解読出来なかったら、それはそれでモヤモヤが残るね。
239:デフォルトの名無しさん
11/02/12 01:37:55
量子コンピュータが暗号をサクッと解けるというのは証明されてるの？
240:デフォルトの名無しさん
11/02/12 08:22:23
Shorのアルゴリズム
241:デフォルトの名無しさん
11/03/03 23:36:23.39
ビットスライスDES(bit-slice DES, bit-sliced DES)について詳しく解説された専門書でおすすめのものがあれば教えていただけないでしょうか？
わかりやすいものであれば論文でもかまいません。
わかりにくい論文は・・・ 私は暗号の専門家じゃないのでつらいです。
ビットスライスDESをスクラッチから実装したいと考えています。
242:デフォルトの名無しさん
11/03/04 00:48:35.68
俺の鍋敷きとして役立ってるよ
>>241の専門書は
243:デフォルトの名無しさん
11/03/24 00:45:15.49
ちょっとご存知でしたら・・・
AESで暗号化したファイルがあるのだけど、間違って元ファイルも出してしまったのですが
これの比較でキー情報を解読する方法ってあります？
大丈夫ですよね？あったら他もピンチなのですが・・・
244:デフォルトの名無しさん
11/03/24 02:18:32.31
ある暗号文と対応する平文を入手したときに(ry
というやつだな
245:デフォルトの名無しさん
11/05/29 20:55:55.12
いま一番信頼されているブロック暗号アルゴリズムってなに？
246:デフォルトの名無しさん
11/05/30 06:53:58.53
AESじゃないの？
247:デフォルトの名無しさん
11/07/02 19:41:22.76
量子暗号についてサイエンスゼロ見た。
日本政府の最先端の研究を中国人がやってる。暗号技術だけにやばいよ。
nict 光子 中国
でぐぐれば出る。
248:デフォルトの名無しさん
11/07/03 09:11:13.60
説明してごらん
249:デフォルトの名無しさん
11/07/03 09:26:46.87
日本から外国人研究者を全部追い出して、
日本の国力をさらに下げたい二重スパイだろw
日本に来るようなのは、各国の最高レベルの研究者だってのに。
250:デフォルトの名無しさん
11/07/03 09:27:20.18
そんなのやってたのか。
物理のほうだと案外量子暗号とかの話にはならないもんなんだね。
251:デフォルトの名無しさん
11/07/19 09:30:48.61
エロ画像・動画を暗号化するビューワーを作りたいんだが
パスワードさえ長くしておけば警察にビューワーを押収されてもバレない暗号方式ってある？
252:デフォルトの名無しさん
11/07/19 17:06:19.29
AES
253:デフォルトの名無しさん
11/07/19 17:24:49.42
ありがとうございます
早速ＡＥＳのライブラリをゲットしました＾＾
254:デフォルトの名無しさん
11/07/19 19:29:14.19
鍵配布をどーするつもりだよ?
おとりをどー排除するつもりだよ?
とマジレ酢。
255:デフォルトの名無しさん
11/07/19 19:34:29.13
おとりってどういう意味かよくわからないのですが、
個人で使うものなので鍵（固定長のパスワード？）はビューワにログインの都度入力します。
256:デフォルトの名無しさん
11/07/19 19:37:30.13
皆に得ろ画像を提供する目的じゃないんだったらなにもおしえてやらん!
257:デフォルトの名無しさん
11/07/19 20:56:25.66
ま、個人利用なら外部に秘密鍵を漏れないように置かないとね
258:デフォルトの名無しさん
11/07/19 21:30:40.13
4096ビットくらいの鍵を暗記すればいいんだよ
259:デフォルトの名無しさん
11/07/19 22:20:27.12
AESは最大で256ビットの鍵しかありませんが解析されませんか？
260:デフォルトの名無しさん
11/07/19 22:42:37.05
計算量だから、完全に無理とは言えない
警察位なら電子政府基準位なら(覚えてないです…)いいんじゃないかと
261:デフォルトの名無しさん
11/07/19 23:23:01.87
そんな難しいことしなくても、ディフィー・ヘルマン鍵共有を使って鍵をランダムに変えれば、暗号自体はチープな RC4 くらいでいいんじゃないですか？
262:デフォルトの名無しさん
11/07/20 17:10:41.09
>>261
>>251は、ローカルに保存してるエロファイルを暗号化したいんじゃないか？
263: 忍法帖【Lv=12,xxxPT】
11/07/20 17:41:54.17
>>262
既存のツールでええがな
264:デフォルトの名無しさん
11/07/20 21:42:52.52
ファイルを暗号化するツール自体はあるけど、画像を見ながらにしてファイルに暗号/複合をほどこせるビューアは無いよね
１つＡＥＳかけられるのがあったけど、.Net製で動作もおかしい
やはり自分で作ったほうが信頼できる
265:デフォルトの名無しさん
11/07/20 22:46:03.84
詳しくないので直感です
一旦、全部暗号化して、復号をしながら閲覧で良いのでは。
処理は犠牲になるけど、ＡＥＳで実装なら出切るような
266:デフォルトの名無しさん
11/07/21 01:27:48.43
暗号化ディスクで事足りると思うよ。
TrueCryptでggrks
267:デフォルトの名無しさん
11/07/21 22:03:49.51
10桁アルファベット大文字小文字、数字
のパスワードを作る場合
同じ文字の「重複あり」と「重複無し」
どちらが強度があるのでしょうか？教えて下さい
268:デフォルトの名無しさん
11/07/21 23:15:55.42
重複を許す場合
これは数学のお話だよ
269:デフォルトの名無しさん
11/07/27 17:10:54.97
>>266
これはいいものだな
でもヘッダファイルからパスワード推測されないんだろうか？
270:デフォルトの名無しさん
11/07/27 17:26:13.24
>>269
おまえはいろいろと足りなすぎる
271:デフォルトの名無しさん
11/07/27 17:33:32.37
すみません＾＾；
272:デフォルトの名無しさん
11/07/27 19:40:22.69
暗記するなら楕円曲線のほうがいいかもｗ
273:デフォルトの名無しさん
11/07/27 20:21:40.21
>>269
つ一方向関数・ハッシュ関数・メッセージダイジェスト。
ヘッダファイルからパスワードを推測することは、多分無理だろう。
274:デフォルトの名無しさん
11/08/02 14:33:24.75
それなら安心＾＾
275: 忍法帖【Lv=2,xxxP】
11/08/27 14:24:54.66
あげ
276:デフォルトの名無しさん
11/09/16 10:03:34.30
[再放送] サイエンスＺＥＲＯ「ネット社会を守れ！究極の量子暗号」
2011年 9月17日（土）午前0:00～午前0:30（30分）
URLﾘﾝｸ(cgi4.nhk.or.jp)
277: 忍法帖【Lv=40,xxxPT】
11/09/17 00:33:32.92
>>276
教えてくれてありがとう。興味深かった。
全然関係ないし亀レスだけど>>235で言ってる2048bit暗号って10^600通りくらいあるんだね。びっくり。
この数が量子コンピュータ云々で楽に解けるレベルなのか宇宙の物質の数を越えているのか知らないけど。
278:デフォルトの名無しさん
11/09/17 08:52:00.16
openssl/evp.hを使ってDB接続用なんかのパスワードを暗号化しようと考えています
AESで暗号化したパスワードを設定ファイルに保持させようと考えていますが
saltとIV(Initialization Vector)をどのように実行ファイルに保持させるのがより安全でしょうか？
nmやstringsでバレる方法は避けたいと考えています。
先輩方の知識を貸していただけますと嬉しいです
279:デフォルトの名無しさん
11/09/17 08:55:51.69
>>278
すいません、書き漏らしました
実行ファイル内に収めようとしているのは saltとIV に加え
暗号化keyデータもです
280:デフォルトの名無しさん
11/09/17 10:15:41.71
あげます
281:デフォルトの名無しさん
11/09/17 21:36:47.84
すいません、ここで良いか微妙ですが教えてください。
アプリケーションに対するデジタル署名って、
署名発行者が作ったものというのは証明出来ますか？
他人が自分の署名を付けて自分のものとして再公開されるような事って出来ますか？
282:デフォルトの名無しさん
11/09/17 22:27:57.12
出来るか、出来ないかなら出来る
283:デフォルトの名無しさん
11/09/17 22:52:57.98
レスthxです
manifest変更したいexeがあって、signtool使ってたんですがどうもうまくいかず。
(win7なので外部manifestもダメなんです)
理論上可能なんですね。
もう少し見てみます。
284:デフォルトの名無しさん
11/10/09 15:11:41.86
コイン投げゲームをコミットメント・スキームを使って Java で実装したいと思ってます
Alice が表か裏かを示した暗号化したデータを鍵Aで暗号化して、Bob に渡します
その後、Bob が表か裏かを言います。その宣言の後、Alice は鍵AをBobに渡し、暗号化された表か裏かを示したデータを開きます
とはいえ、この場合、Alice は表か裏か結果を知ってから、鍵を渡すことになってしまいます
うまく鍵を調整すれば、鍵の差し替えることで、裏か表かを後追いで言い当てる、みたいなこともできますよね
これを回避するにはどうすればいいですか。
表か裏かを書いたデータと一緒に、電子署名をつければ、よさそうな気がします。（SHA256withRSA で署名すると、1024bitあるので）
しかし、私は暗号の専門家ではないのでこれでも本当に安全かわかりません
それとも、コイン投げをするのにもっとスマートな何か方法がありますか？
285:デフォルトの名無しさん
11/10/09 15:42:41.77
>>284
お互いが内容の分かっている、ある程度の長さを持つ定型文を含めればいいんじゃないか？
「2011/10/09 15:40 分に投げたコインの向きは 表」
みたいな文章を暗号化して
「2011/10/09 15:40 分に投げたコインの向きは」 の部分は平文でも送信する
286:デフォルトの名無しさん
11/10/09 15:54:22.04
>>284 デジタル署名（の鍵）は、そういうことができないことが求められるので、
デジタル署名を付ければ解決する。
287:デフォルトの名無しさん
11/10/09 18:15:25.88
>>285
この場合それでも安全かもしれませんね
>>286
暗号化前のデータに対して、電子署名つけたものを、いっしょに暗号化して
Bob に送ればOKってことですね
今後、このデータを「コインの表裏」だけじゃなくて、
ランダムな乱数種とかも送れるようにしたかったんで
アドバイス助かりました
288:デフォルトの名無しさん
11/10/10 11:11:14.25
>>283
他人の署名の偽造は通常は計算量的に不可能だよ。
289:デフォルトの名無しさん
11/10/10 11:12:16.57
元から自己署名証明書とかなら別だが。
290:デフォルトの名無しさん
11/10/10 11:45:03.30
>>287
署名の検証鍵はどうやって渡すつもりなの？
暗号化前のデータに単なるハッシュを付けるだけでも同じじゃないかな。
291:デフォルトの名無しさん
11/10/10 13:31:41.77
>>290
そのとおりでした。単にSHA-256のハッシュつけて送信することにしました。
292:デフォルトの名無しさん
11/10/10 14:33:11.63
Alice の不正行為を根本的なところで防ぐには、事前に計算できない攪拌因子を Bob が選択するのが良い
最も簡単なところで、
・最初に Bob が裏/表に対応する符号語を選択して送信 (例えば1024ビットの乱数)
次点で、
・Bob, Alice 双方で暗号化用の鍵を選択 (k1, k2)
・Bob が鍵 k1 を送信
・Alice が平文 x を選択し、暗号文 y=e_k2(e_k1(x)) を送信
といったところか
293:デフォルトの名無しさん
11/10/12 13:14:34.22
↓メンタルポーカープロトコルの実装について質問です
URLﾘﾝｸ(en.wikipedia.org)
一言でいえばこの手順は、カードを一枚づつ暗号化して、ゲームの進行上
カードを開く権利のあるプレイヤーに鍵を渡すという方式なんですが、
これも、カードゲーム開始前に、鍵１つにき、また SHA256 などの強力なハッシュをつけて
あらかじめ公開しておかないと、またウソの鍵を渡してゲームの進行を止めることが
できてしまうのでは。ハッシュをつけないと、ウソの鍵を渡した人の、特定が不可能な
気がします。
wikipediaにはその手続きが無いのは、単に wikipedia の書き手がそこは省略したってことでしょうか。
294:デフォルトの名無しさん
11/10/12 20:46:00.82
>>293
ありがとうございます！（俺は暗号ど素人なんで省略があったかどうかはわかりませんすみません）
実は↓スレの770,780,805でまさにwithout the use of a trusted third partyで牌を配ることが
できないか考えていたところこんなところに答えが！
ただMental Pokerの手順2や5ではDecA(EncB(EncA(x)))がちゃんとEncB(x)になるような
暗号方式を使わなければいけないけど、XORのような単純なものは使えないんですよね。
カード自体はわからなくてもカード同士の関係がわかってしまうから。
ここの具体的な暗号方式をイメージするためには俺には勉強が必要ですね。
おまいら最強の麻雀プログラムしてみろよ Part4
ｽﾚﾘﾝｸ(tech板:770番)
295:デフォルトの名無しさん
11/10/12 23:07:34.29
>>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:294
11/10/12 23:47:47.97
>>295
レスありがとうございます。AESってそんなチート性能だったんですね…
つまり本当の意味でMental Pokerの手続きを理解するためにはAES(Rijndael)の数理を
理解しなければいけないと。
しかしAESなら実装には困らない（サンプルが豊富）だろうしMental Pokerの実現は思いの外
手が届きそうな気がしてきました（麻雀のためにコーディングする気はないですが）。
ちなみに俺の素人考えでは>>293の件は鍵のコミット・否認防止は必要で、
つまり著者が省略したのだろうと思っています。
297:294
11/10/12 23:51:41.57
すみません>>296の「否認防止」は「拘束性確保」に置き換えてください。
298:デフォルトの名無しさん
11/10/14 10:31:22.51
メンタルポーカープロトコルの欠点は、
一人でも回線落ち、持ってた秘密鍵を捨ててしまうと
カードの中身が復元不可能になることだな
麻雀でいうと、突然ヤマを壊して場を立ち去ることと一緒
するとまあ、チョンボ扱いになるのだろうが、しかし、
これを失点扱いにしてしまうと、周りの三人が組めば
容易に一人をチョンボ扱いとして貶めることも可能
鍵渡しても、三人揃って受け取ってないフリをすればいいだけだから
逆のウソもありうる 実際は回線落ちしたのに「鍵をちゃんと渡したが周りの三人が応答しなかった」
みたいな、言った言わない問題はありうる
299:デフォルトの名無しさん
11/10/14 10:50:04.57
結局、審判が要ることには変わりないな
まあ、↑の不正は、ゲームの履歴がオンラインにあれば、
何度もできることじゃないから、それが多少抑止力になる
しかし、ビットコミットメントスキームで第三者に乱数種渡す方式よりは強いか
300:デフォルトの名無しさん
11/12/16 05:15:37.28
Proof of Workと環境負荷について
301:デフォルトの名無しさん
11/12/25 11:49:20.85
糞コテさんおいでー
手取り足取り暗号について教えるよー
302: ◆QZaw55cn4c
11/12/25 12:23:30.64
>>301
よろしくお願いいたします。
質問は次のとおりです。
今回、DH鍵交換、RSA 暗号について、少しがんばって調査しました。ｽﾚﾘﾝｸ(tech板)
ここで疑問が生じました。DH鍵交換が実際の実装であまり採用されないのは、どういったわけでしょうか。(少なくとも SSL では採用されていないようです。）
たとえばAES 暗号を主に利用するとしてそれに先立って共通鍵を設定する場合の、DH鍵交換に対する、RSA 暗号の優位性はどのような点にあるのでしょうか。
バックグラウンドは次のとおりです。
RSA 暗号については、書籍 URLﾘﾝｸ(www.amazon.co.jp) で、DH鍵交換については、URLﾘﾝｸ(saltheads.blog134.fc2.com) を参照しました。
よろしくお願いいたします。
303:デフォルトの名無しさん
11/12/25 12:40:52.75
数学の素養はどれくらいあるん？
整数とかどれくらい勉強したん？
304: ◆QZaw55cn4c
11/12/25 12:52:53.38
>>303
ほとんどありません。かろうじて素因数分解の一意性の証明を理解できる程度です。
お勧めの書籍があれば教えてください。
実装を目的としていますので、概念を把握できればいいと考えています。
305:デフォルトの名無しさん
11/12/25 12:59:15.68
wikipediaで公開鍵と関連技術について調べればいいよ
あと、向こうの人達の忠告に真摯に耳を傾けなさい
306:デフォルトの名無しさん
11/12/25 13:09:47.39
>>302
man-in-the-middle attackに弱いから
307:デフォルトの名無しさん
11/12/25 15:41:04.54
ｽﾚﾘﾝｸ(tech板:56-60番)
この部分の理解が重要。素のDHだと相手が正しい相手なのか攻撃者かが分からないから間違った相手にカギを渡す
可能性がある。それが>>306
基礎的な部分だから暗号を扱ってる書籍ならどれにも載ってるはずー
308:デフォルトの名無しさん
11/12/25 15:48:18.45
正直、勉強すればいいことだから暗号の知識がないことは気にしていないが、
態度が気に食わない。自分が無知であることも自覚せず、何様のつもりなんだろうか？
309:デフォルトの名無しさん
11/12/25 16:13:24.82
>>307
手元にあるCRYPTOGRAPHYの邦訳だとDH鍵交換の説明の直後に
STSプロトコルの説明が入っているな
310: ◆QZaw55cn4c
11/12/25 22:02:30.10
>>306-307
中間者攻撃（たとえば、ゲートウェイ等に仕掛けておきパケットの内容をすりかえる等）に弱いという問題は、DH鍵交換のみならず、RSA 暗号でも同様だと考えております。
RSA 暗号のほうが中間者攻撃に耐えうる、ということはあり得るのでしょうか。
311:デフォルトの名無しさん
11/12/25 22:10:17.08
>>310
それはあっちであがっている通り
匿名システムでは「ない」、匿名でないシステムなら「ある」（認証を使う）
312: ◆QZaw55cn4c
11/12/27 05:02:57.50
つまり、DH であろうと、RSA であろうと、それだけでは中間者攻撃に対しては無力だ、ということですね。
では、現状では RSA が選択される理由はなになのか、言いかえると RSA の DH に対する優位性は何なんでしょうか？
313:デフォルトの名無しさん
11/12/27 05:53:03.50
>>312
>>306-307,311とそのリンク先とかを理解して来て、手持ちの本をきちんと読めよ。書いてあるだろ
だからRSAは中間者攻撃に耐えれる仕組みを用意してるからだよ。もちろん使い方によっては攻撃に対して無防備だけどな
314: ◆QZaw55cn4c
11/12/27 20:45:08.25
>>313
公開鍵暗号は、公開鍵で暗号化、秘密鍵で復号化するものですが、RSA に限っては秘密鍵で暗号化、公開鍵で復号化することも可能、という利点があり、これにより、なりすましや改竄を回避することが可能とありました。
ｽﾚﾘﾝｸ(tech板:257番) にあげた e, d の定義・ed≡1(mod L), L = (p, q の関数） からも自明ですし。）
しかし、中間者攻撃可能とは、そもそも通信の当初に使用する公開鍵が通信当事者に確実に伝達されるかどうか保障がない、ということであり、中間者攻撃を RSA 単独で回避することはできないのではないでしょうか？
いちど共通鍵の交換が成立し共通鍵暗号による通信が可能になれば、鍵が割れないかぎりなりすましや改竄は成立しませんから、RSA 公開鍵・秘密鍵の対称性はそれほどの利点にはならないと思うですが。
そういう意味では DH に対する RSA の優位性がよくわかりません。
315:デフォルトの名無しさん
11/12/27 20:50:54.87
>>314
もう一度じっくり>>306-307,311を読んで投稿を理解しろ
316:デフォルトの名無しさん
11/12/27 23:25:39.78
別に単に鍵交換で使うだけなら優位性はないよ。
DHは鍵交換にしか使えない、RSAは応用範囲が広い、それだけ。
317:デフォルトの名無しさん
11/12/27 23:56:02.91
そしてその応用範囲を使って中間者攻撃にも耐えられる。それぐらい。
318: ◆QZaw55cn4c
11/12/28 07:49:10.45
>>317
RSA は鍵交換では中間者攻撃を防げないのであれば、RSA をどのようにして「応用範囲を使って中間者攻撃にも耐えられる」ようにするのでしょうか？
319:デフォルトの名無しさん
11/12/28 10:57:24.05
>>318
上で言われているように、きちんとほかの人の投稿読んだ方がいいと思うな(´・ω・｀)
>>311にずばり書かれてるでしょ。認証。
仮に中間者攻撃をRSAなりほかの手法でも防げないのであれば、例えば通販サイト
でクレジットカードの番号入力時にSSL使ってるから安全なんて言われてないでしょ？
320:デフォルトの名無しさん
11/12/28 11:25:51.27
みんな優しいねぇ
321:デフォルトの名無しさん
11/12/28 11:28:44.16
ほんとそうだなｗ
完全に糞コテのお勉強スレ。しかもレベルがひどく低いｗｗｗ
322:デフォルトの名無しさん
11/12/28 12:05:06.45
みんなというか、相手しているのは一人二人だろう
323: ◆QZaw55cn4c
11/12/28 22:16:11.79
>>319
RSA アルゴリズムに「認証」機能を実現するからくりは含まれていないと考えます。
>>316 RSAは応用範囲が広い
は理解できるのです（暗号だけでなく署名にも使えますから）。しかし、
>>313 RSAは中間者攻撃に耐えれる仕組みを用意してる
>>317 その応用範囲を使って中間者攻撃にも耐えられる
というのは不正確あるいは誤りでしょう。RSA 単独ではそれは不可能ですから。
今、DHとRSA との比較に話題を絞っているのに、両者に関係のない、あるいは両者とは別のからくりである認証を持ち出されてこられると困惑します。
>>319 きちんとほかの人の投稿読んだ方がいいと思うな
むしろ >>319 こそ >>302 の「DH と RSA との比較に絞っている」大前提を読んでいただきたい、と痛切に感じます。>>313, >>317 に至っては問題外でしょうね。
324:デフォルトの名無しさん
11/12/28 22:49:16.31
323
そうね。君が全部正しいよ。このスレにいる君以外の人間はみんな馬鹿だから相手にしないほうがいいよ
325:デフォルトの名無しさん
11/12/29 00:05:14.33
＞ここで疑問が生じました。DH鍵交換が実際の実装であまり採用されないのは、どういったわけでしょうか。(少なくとも SSL では採用されていないようです。）
採用されてるから。
326:デフォルトの名無しさん
11/12/29 00:43:22.68
相変わらずトリは偉そうだな。よく相手するよ…
327:デフォルトの名無しさん
11/12/29 00:52:42.62
どうどう巡りワロタｗｗｗ
DH使いたきゃ使っておけよ。鍵交換さえできたら安全なんだからｗｗｗ
328:デフォルトの名無しさん
11/12/29 02:16:20.45
まとめてやるよ(^o^)丿
RSAとDiffie-Hellmanに差はない。
どちらを使用しても鍵のやりとりが終わったら安全に通信できるし、なりすましが入り込んでしまった場合には
どちらを使用しても通信内容は守られない。
329:デフォルトの名無しさん
11/12/29 08:49:39.12
だからさー、ここはお前の勉強スレじゃないんだ
消えろ、他の奴もQZaw55cn4cを相手にするな
330: ◆QZaw55cn4c
11/12/30 15:53:17.64
>>301
暗号に詳しい人はここは読みに来ないようですね。残念です。
>>329
つ URLﾘﾝｸ(internet.watch.impress.co.jp)
331:デフォルトの名無しさん
11/12/30 17:20:18.01
>>330
スルー対象の本人がこんなの貼り付けるってどういうことなの？
ここに居座るつもり？迷惑だけど
「スルー力検定」の受付がスタート
全日本通過技術検定協会が定めた「スルー力検定」ロゴ
全日本通過技術検定協会は、物事をスルーできる力を客観的に測定する「スルー力
検定」を全国7都市で実施すると発表した。受講料は1級8,000円、2級5,000円。
「スルー力（するーりょく）」とは、インターネット時代に必須とされる、物事をうまくやり
過ごしたり、見てみぬふりをするコミュニケーション技術。掲示板やブログ上での不快
なレスを読み飛ばすのはもちろん、上司や同僚からの仕事の依頼を何気なくかわす
など、ビジネスからプライベートまで幅広く応用できる。
332:デフォルトの名無しさん
11/12/30 17:22:32.80
>>331
不合格ｗ
333: ◆QZaw55cn4c
11/12/30 17:24:06.02
>>331
はい。不合格。
334:デフォルトの名無しさん
11/12/30 17:32:18.70
スルーしても糞コテがいなくならないんだもん
黙ったままでいても糞コテには意味が無い
俺を黙らせるためにスルー力検定なんてもんを貼ってやがる
暗号に詳しくてもお前の態度が気に食わない、
理解できないようだから答えないんだよ
335: ◆QZaw55cn4c
11/12/30 17:40:07.95
>>334
はい。不合格w
>>332
先をこされたか。
336:デフォルトの名無しさん
11/12/30 17:58:34.45
コテがコテに批判的な人をスルーできないのは問題ないんだ
なんつーダブスタ
337:デフォルトの名無しさん
11/12/30 18:10:53.67
他人にはスルー力を強要するが自分はスルーしなくていいとか
人として駄目だろう
338: ◆QZaw55cn4c
11/12/30 20:35:36.69
>>334
>暗号に詳しくてもお前の態度が気に食わない、
>理解できないようだから答えないんだよ
言うだけならかんたんだよ。詳しいというんだったら、その実力をみせてよ。
>>336-337
不合格w
339:デフォルトの名無しさん
11/12/30 20:43:50.65
〃∩ ∧＿∧
⊂⌒（ ・ω・） はいはい不合格不合格
｀ヽ_っ⌒/⌒ｃ
⌒ ⌒
340:デフォルトの名無しさん
12/01/10 17:08:48.36
URLﾘﾝｸ(en.wikipedia.org)
* E(c1)E(c2) = E(c1 + c2)
* collisions must be detectable, without revealing the plaintext
シャッフルしない Mental Poker Protocol というのが、意味がわからないのだが・・・
それぞれのプレイヤーが暗号化した数字を出しあって、暗号化したまま足し算して、
カードの衝突があればもう一回って、そんな器用なことできるものなのか？
中身は分からないが、衝突は発見できる、って、そんな無茶な
341:デフォルトの名無しさん
12/01/11 08:43:35.07
できるように暗号を設計するんだよ
なんにも考えてない暗号だったら無理だろうけどさ
342:デフォルトの名無しさん
12/01/13 20:52:08.10
あの……落とし物ですよ？
∧__,,∧
（´・ω・`）
(つ夢と）
｀ｕ―ｕ´
あなたのすぐ後ろにありましたよ？
343:デフォルトの名無しさん
12/01/20 02:17:31.25
和や積の準同型暗号自体なら
ElGamal暗号やPaillier暗号が昔から知られているよ
URLﾘﾝｸ(ja.wikipedia.org)
２つの暗号文から減算（または除算）した結果が
平文"0"（または"1"）の暗号文になっていれば
二つの暗号文の中の平文の同一性は判定できるんじゃね？
ダメかな？
>>340の参照元の論文
URLﾘﾝｸ(crypto.stanford.edu)
だと，なんか分散計算でやってるみたい
３ページ目の最後の６行の理屈がどうしてもわからない・・・
344:デフォルトの名無しさん
12/01/25 20:28:04.22
hoshu
345:デフォルトの名無しさん
12/02/03 07:42:13.98
アンゴーで飯を食うことはできるんか
346:デフォルトの名無しさん
12/02/12 01:57:51.36
クラウドで暗号とか言ってるけど、安全なの？
URLﾘﾝｸ(cloud.watch.impress.co.jp)
347:デフォルトの名無しさん
12/02/12 03:02:00.72
>>346
みかかごときが暗号に詳しいわけないだろ
348:デフォルトの名無しさん
12/02/12 07:16:33.19
みかか研といえば、FEALとかE2とか、国際的に通用する（前者は攻撃法を発見されてしまったが）
暗号で知られてるぞ。
現場のバカが泥をぬったくってくれてるがw
349:デフォルトの名無しさん
12/02/21 20:10:19.76
だれか暗号といてくれ！！
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: ◆HR1gMcB9n7yt
12/02/24 17:48:11.73
>>349
解いてみた。
結果は先頭に#を付けて名前欄に書いておいたｗ
これって学校の課題とか？
351:デフォルトの名無しさん
12/02/24 18:14:37.61
>>349
解けた！
ってかこれ暗号じゃないだろ
352:デフォルトの名無しさん
12/02/25 10:48:26.50
アウィサムブラックホールって何さ？
353: ◆HR1gMcB9n7yt
12/02/25 16:10:14.22
てす
354: ◆HR1gMcB9n7yt
12/02/26 12:47:12.18
a we some blackhole
？？なんだこの符号化
355:デフォルトの名無しさん
12/02/26 13:32:52.69
awe some blackhole
だろバカ
356:デフォルトの名無しさん
12/02/26 14:47:07.60
おー寒っ
357:デフォルトの名無しさん
12/02/27 01:14:31.07
awesome blackhole
だろ低能
358:デフォルトの名無しさん
12/02/28 23:28:31.00
nintendoのＷＥＢ入社試験問題だね
359:デフォルトの名無しさん
12/03/05 01:47:43.33
>>358
マジかよ・・・
検索エンジンに引っかからないし、難易度的に学校の課題とかかと思ったら
そういうことだったのか・・・
360:デフォルトの名無しさん
12/03/16 11:10:09.01
他者と通信する必要もなく個人で暗号化する場合って
公開鍵暗号方式って意味ある？
361:デフォルトの名無しさん
12/03/16 13:36:01.46
基本ないと思う。
何を暗号化するかによるけど有効な場合を示せるかも知れない。
362:デフォルトの名無しさん
12/03/16 13:52:47.75
電子「署名」だったらあるかも。
改竄される恐れがない秘密鍵を別媒体に持っていることが前提だけれど、
kernelとか好き勝手に入れ替えられると困るよね。
kernelに対して電子署名を検証できれば改竄されていないkernelって信用できる。
ううーん、、、
公開鍵「暗号」を使って『暗号化』が有効だと思える例は思いつかない。
ごめん。
うーん。
現在でも公開鍵暗号で『暗号化』するのって、
対象鍵暗号で使う「対象鍵」だもんね。
通信しないのであれば公開鍵暗号の旨味はないと思う。
電子[署名」なら考えれば良い例があるかもね。
363:デフォルトの名無しさん
12/03/16 14:09:05.96
個人でも暗号化するPCと複合化するPCを明確に分けれるとか。
364:デフォルトの名無しさん
12/03/16 15:26:19.71
>>360
いちいちパスワードを入力しなくてすむ。
365:デフォルトの名無しさん
12/03/16 19:05:39.42
世界に自分ひとりしか存在しないなら、公開鍵暗号も秘密鍵暗号も無用の長物。
世界で自分以外の全てが敵なら、公開鍵暗号は無用の長物。秘密鍵暗号は有用。
世界に自分と、敵と、敵ではない誰かがいるなら、公開鍵暗号も有用。
「他者と通信する必要もなく個人で」という用途の中に家族とか友人とか
そういう緩めの第三者がいないなら、公開鍵暗号は意味ないだろうね。
366:デフォルトの名無しさん
12/03/16 19:22:02.21
味方でも見られたら恥ずかしいデータというのがあってだな。
367:デフォルトの名無しさん
12/03/16 19:27:34.55
>>364
いや、公開鍵暗号でも公開鍵暗号の秘密鍵を守る必要があって、
そのために公開鍵暗号の秘密鍵を対象鍵暗号で暗号化して保存してるんだよ。
368:デフォルトの名無しさん
12/03/16 19:29:37.30
その最後の対称鍵は暗号化しなくていいんですか？
369:デフォルトの名無しさん
12/03/16 19:33:23.29
暗号化って、通信中の解析が難しいってだけでしょ
わかってる人は、途中からやろうなんて考えないでしょう
370:デフォルトの名無しさん
12/03/16 19:47:41.88
>>368
key = sha1(password)
decrypt(cipher, key)
みたいなことをして復号するから対象鍵(=key)暗号化しなくて大丈夫。
passwordが分からないと正しいkeyを生成できない。
371:デフォルトの名無しさん
12/03/16 20:19:08.99
>>370
仮にそれを364が言った「いちいちパスワードを入力しなくてすむ」方法の中身だとして、
果たしてそれは秘密鍵暗号では不可能で公開鍵暗号でのみ特有な何かがあるのかな？
って言おうとしたら突っ込むべきところが違ってた。SHA-1は公開鍵暗号じゃねーよｗ
メッセージダイジェストとかハッシュ関数とかそういうカテゴリだ
372:デフォルトの名無しさん
12/03/16 20:24:40.29
PCの盗難も考えると、最後の鍵はパスワードとして暗記するしかないと思う。
パスワードは強度を増そうと複雑にすると覚えらないし、
頻繁に変更すると忘れやすいし、ほんと困るね。
373:デフォルトの名無しさん
12/03/16 20:28:31.72
>>371
374:デフォルトの名無しさん
12/03/17 01:20:20.30
>>371
何を言ってるの…？
375:デフォルトの名無しさん
12/03/17 02:03:43.64
>>371
>>371
>>371
376:デフォルトの名無しさん
12/03/23 15:35:58.49
酔っ払って書き込んだのかな
377:デフォルトの名無しさん
12/03/24 00:28:54.15
公開鍵暗号でゲームのデータの一部をエンコードしているよ。
データを吸い出すことは出来ても、チートデータは作りにくいはず。
378:デフォルトの名無しさん
12/03/24 01:10:17.59
通信対戦じゃなかったら意味なくね？
対象鍵暗号でも一緒じゃん。
公開鍵暗号である意味がない。
379:デフォルトの名無しさん
12/03/24 07:57:29.87
>>378
対象鍵暗号じゃデコードルーチンと秘密鍵をユーザーがいくらでも
覗けるから、エンコードルーチンを簡単に作れてしまう。
これでは容易に改造可能。
目的はデータ秘匿ではなく改ざん防止。
380:デフォルトの名無しさん
12/03/24 07:59:23.78
ちなみに対称ね
381:デフォルトの名無しさん
12/03/24 10:04:44.76
少なくともデータ比較での解析は無理で、アセンブラと暗号化の知識が必要となる。
382:デフォルトの名無しさん
12/03/24 10:31:56.89
数学的なお話しでは、
暗号化・復号の際の非対称性をうまく利用してるって話ね。
納得。ありがとう。
crackしようかと思った場合は暗号化方法を判断しないといけないわけですが、
これは各暗号化方法に固有の定数を見つけ出して当たりを付けてるんでしょうか？
もしそうなら、定数を適当に0xff辺りでxorして守っておいた方がいいのかなー？
と思ったので聞いてみました。
383:デフォルトの名無しさん
12/03/24 11:14:33.71
>>382
暗号化方法が何かはコードを読むしか無いよね。
自分はオリジナルの式を使ってるから、文献をそのまま当てはめても、まず見つからないし。固有の定数も無い。
クラッカーがマシンコードを読めるのは当たり前として、秘密鍵(形式も秘密)とエンコードルーチンは
自分しか知らないから、データだけの改竄はまず無理。
とは言えマシンコードそのものを変えられて、改造データを暗号化することなく読み込んで
しまうようなクラックをされたらどうにもならないげどね。
その場合はプログラムに署名してOSや認証局に頼るしかない。
384:デフォルトの名無しさん
12/03/24 14:25:26.95
もっと凄腕だと思って質問したんだけど、
もーいーや。
385: ◆QZaw55cn4c
12/03/24 15:38:16.22
>>384
お前 ◆QZaw55cn4cか？ｽﾚﾘﾝｸ(tech板:330番)
386:デフォルトの名無しさん
12/03/24 16:34:12.84
いや違う
387:デフォルトの名無しさん
12/03/24 23:03:49.37
ノートPCが盗まれたとき、ログインパスワードの強度が重要だと思うんだけど、
WindwosのNTLMv2認証って信用できるの？
388:デフォルトの名無しさん
12/03/24 23:12:51.13
盗まれる前提ならパスワードだけで防御するのが間違ってる
389:デフォルトの名無しさん
12/03/24 23:18:08.70
盗まれない前提ってアホかw
390:デフォルトの名無しさん
12/03/25 01:19:01.76
NTLMv2認証の説明をざっと読んだ限りでは、ノートが盗まれたときのダメージを
左右する種類のものではないように思うんだけど。サーバからのチャレンジデータをどうこうらしいし。
WindowsならUltimateにしてBitlocker使うのが一番手っ取り早いんですかね？
391:デフォルトの名無しさん
12/03/25 08:21:37.54
Windowsの暗号化ファイルシステムは、XPで、AES256+RSA1024。
しかし、ログインされると丸見え。
392:デフォルトの名無しさん
12/03/25 09:23:48.32
なるほど、レスありがとうございます。。
つまりXP＋暗号化ファイルシステムのノートが盗まれた場合、
犯人のPCにノートPCから取り出したHDDを変換ケーブル等で繋いでもAES256+RSA1024が
破られない限りは大丈夫。
しかし、そのままノートをネットワークで犯人のPCで繋いでネットワークログオン(ここでNTLMv2？)が
成功するとファイルが丸見えになるということですね。それなら左右しまくりますね。
393:デフォルトの名無しさん
12/03/25 13:45:34.73
ログインを成功させられるならネットワークいらねえよ
394:デフォルトの名無しさん
12/03/25 14:34:56.77
いや、だからNTLMv2の安全性がどうこうの話になったんでしょ。
まあチャレンジレスポンスならヒントにはならなそうだけど。
パスワードがわかればネットワーク必要ないとかいうのは的外れ。
395:デフォルトの名無しさん
12/03/25 17:40:07.97
ローカルログオンでもNTLMv2認証。
396:デフォルトの名無しさん
12/03/26 21:47:22.06
NTLMv2はMD5だからもうダメだろう。
397:デフォルトの名無しさん
12/03/28 23:41:27.37
＞まあチャレンジレスポンスならヒントにはならなそうだけど。
チャレンジレスポンスは、これを使用したネットワーク認証の通信部分は強くなるが、他の面では弱くなるぜ？
この辺分かってないやつが多いが。
チャレンジレスポンスに対応してるってことは、盗まれた場合の強度は逆に弱くなっているということ。
なぜならパスワードデータベースにソルトが使えなくなるから。
398:デフォルトの名無しさん
12/03/28 23:45:45.71
＞パスワードがわかればネットワーク必要ないとかいうのは的外れ。
どういう意味か分からんが、盗まれたらオフラインでパスワードデータベースをクラックできる。
ネットワークは関係ないな。
で、このパスワードデータベースのクラックは、チャレンジレスポンスに対応してるせいで逆に楽になってるわけだよ、
399:デフォルトの名無しさん
12/03/28 23:59:55.79
そこで生体認証ですよ。
400:営利利用に関するLR審議中＠詳細は自治スレへ
12/03/29 14:31:30.65
MD5ハッシュって破られてるんだっけ？
401:営利利用に関するLR審議中＠詳細は自治スレへ
12/03/29 19:24:25.04
強衝突耐性については、だいぶ弱いとわかっている
402:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 00:18:29.10
新規に採用するのは非推奨、というあたりではないのん？
いや知らんけど
403:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 08:02:20.07
新規に採用するのにSHA2以外はありえんだろ。暗号学的強度が必要なら。
とは言え、ひところ危惧されたほどSHA1は弱くなかったということなので、
既にあるものまでなにがなんでもSHA2にしろ、というほどでもないかな。
404:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 11:40:54.97
使い所による。
署名のダイジェストとかに使うなら避けるべき。
パスワードハッシュとかなら別に好きにしろ。
まあパスワードハッシュなら本当はPBKDF2使うべきだが。
PBKDF2ならベースハッシュが多少弱くてもあんまり実害無い。
405:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 15:48:13.58
一様かつ予測不能な乱数を生成したいので、メルセンヌ・ツイスタを使おうと思いました。
しかし、メルセンヌ・ツイスタは、一様な乱数を生成するものの、乱数の履歴から、
2^19937-1 のどこの地点から乱数を取ってきてるのか分かったら、次の乱数を予測
されてしまうので安全ではない、暗号学的ハッシュ関数を通す必要がある、らしいですね。
なるほどそういうものかと思って、SHA256 で切り刻むコードを書きました。
URLﾘﾝｸ(www.sourcepod.com)
しかし、これは安全なのですか？
ハッシュ操作してるとバレてるなら、攻撃者も同じように、メルセンヌツイスタの周期まるごと
SHA256でハッシュ化したデータを抱えて、いままでの数値の履歴から、結局、次の数値が
分かってしまうと思うのですが。
（ちなみに、本筋とは関係ないですが、単なる sfmt のコードはこれです。URLﾘﾝｸ(www.sourcepod.com) ）
406:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 15:57:27.78
僕は素人だけど、 2^19937-1 個のハッシュ値を丸ごと抱えるってなかなかできないと思うよ
407:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 16:39:49.02
>>405
しかし、それなら、同じ理由で素の 2^19937-1 の値使うことには問題なさそうに見えます
URLﾘﾝｸ(ja.wikipedia.org)
> メルセンヌ・ツイスタは線形漸化式によって生成されるため、予測可能である
線形漸化式では暗号に使えないなら、どうすればいいんだろうか
408:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 19:02:41.11
予測可能の意味を、たぶん取りそこなってるのかな。
MTのナイーブな実装の場合、内部ビットの個数分（19937ビット）の出力列があれば、
その後の出力列が予測可能でしょ？
たとえば線形合同法 X(n+1) = (a*X(n)+b) mod p で、X(n) の情報があれば、
X(n+1) を予測可能であるように、全体の空間に比べてごくわずかな情報から、
次の数が予測可能である、ということを、この場合に「予測可能」と言うわけ。
409:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 19:14:41.71
生成した乱数列の羅列があればステータスを確定出来るんだろ？
ハッシュを通せば元の乱数列は不明だからステータスを確定出来ないだろ。
元の乱数が分からんと言うことは、周期分順に試していかないと、
どの部分か見つけられないって事。
全然違う。
410:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 19:21:35.46
極端に言うと例えば、
1から順の整数列が有るとする。
この整数列のあるところから開始する。
例えば123456789123456789だったとする。
当たり前だが予測できる。
ハッシュを取ってみる。
もう予測出来ないだろ。
元の値が123456789123456789だってことが分からないから。
これを調べるには、例えば1から順に全部ハッシュを取っていって、同じになるまで探さなきゃいけない。
411:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 20:05:37.02
>>408
ワタシは SFMT の内部構造は全く知らず、複雑でわからないんですが、ともかく、
内部ビットの個数分の出力さえあれば、総当りとかじゃなく、なにか逆算とかすれば、
内部ステータスが分かって、その後の出力も予測できるってことでしょうか。
コードで書いたとおり、256bit分の乱数を、sha256ダイジェスト生成API通して受け取った別物の256bitを乱数として
使えばよさそうですね。
412:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 21:38:07.61
まあそういうこったね。
内部ビット数と同じとは限らず、周期よりずっと短いデータで内部状態を逆算できる場合も同じだね。
もっと直観的な説明でいくと、内部状態が結果列から逆算できる→予測できるってこと。
つまり一方向にしか導けない条件が必要であり、これってつまるところ暗号ハッシュと同等の性質をもつものしかダメってこと。
単なる乱数生成期で暗号ハッシュと同等の一方向性を持てるわけないよね。
413:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 23:59:11.83
>>412
>>412
414:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 01:48:22.01
使う側が互換する共通のアルゴリズムで使用すれば確率的に破られる運命だろ。
アルゴリズムを検証できる環境そのものが複製できちゃえばいつかは解析される。
合理的な共通規格そのものが暗号が破られる原因である。非合理で他に類似性が
なければ非常に単純であってもそれを推測することすらできない。
手品とか種がばれれば非常に簡単なのに、分からない場合は絶対に解明できな
かったりする。
415: ◆QZaw55cn4c
12/04/04 01:54:44.62
>>414
それは現代の暗号の考え方に反する。アルゴリズムを公開してもなお安全であることを追求する、のがポイントだ。
いいかえると、暗号の安全性が鍵の秘密にのみ依存するのが理想の暗号だ。
416:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 03:18:50.66
全てのセキュリティは鍵のみに宿る。
って一言で言えないのかしら。
417:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 06:12:49.46
そうなったのは、暗号については過去2000年ぐらいの歴史のうち、たかだか最近100年のことだからな。
418:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 11:13:56.70
だから何？
419:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 12:04:24.71
今世の中に存在するもので、100年以上昔に進歩が終わった技術で出来てるものなんてなかなか無いぜ。
420: ◆QZaw55cn4c
12/04/04 12:13:38.36
>>417
過去の考え方や >>414 は安全を追求していない。内部造反者等も考慮しなければならない。
>>416
ナイスですね。
421:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 12:23:59.15
URLﾘﾝｸ(www.math.sci.hiroshima-u.ac.jp)
> 出力列を8ワードごとに切って、ハッシュ関数で 1ワードに圧縮して使う
というようなこと書かれてはいますが、sha256 をアルゴリズムとして使うぶんには
MTが生成した乱数 256bit をハッシュ化して出力した 256bit
これを予測できない乱数として使っていいですよね
コード -> URLﾘﾝｸ(pastebin.com)
422:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 13:08:33.86
念のために元乱数列を多めにしといた方がベターだとは思うけど、悪くはないでしょ。
あと用途によってはストレッチングも検討。
423:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 14:25:33.89
別に圧縮は必要ない。
なんとなく、暗号ハッシュ自体の目的のイメージから、なんとなく圧縮って言ってしまっただけに見える。
まあどっちでも別に問題はない。
424:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/08 17:41:48.19
PKCS#5って何のメリットがあるの？
これ使えばパスワードクラックに対して強くなるの？
425:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/08 21:19:51.19
うん。
ブルーとフォースや辞書攻撃などをオフラインで実行された場合に、圧倒的に強くできる。
パスワードハッシュにも使える、これを使うとパスワードデータベースの耐性も簡単に上げられる。
よくパスワードハッシュで、MD5やSHA1は危ないからSHA2を使わないとダメダメとか分かった風なことを言ってるのを見るが、
パスワードハッシュの用途ではSHA2使ってもそれほどは耐性は上がらないことを理解してない。
耐性を上げるにはPBKDF2を使う、これで比較にならないほど上げることが出来る。
426:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/08 23:45:33.20
計算回数増やせば強くなるが、saltは飾りです。
427:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/09 00:19:22.84
saltはテーブル化を防げればそれで十分役に立ってる。
428:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/09 19:45:50.80
ていうか、それ単に最初からストレッチングを前提に設計されてんじゃん。
比較対象としてなんか違う。
429:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/09 22:45:58.07
そりゃ耐パスワードクラックにはストレッチングこそ必要って話なんだから。
何が違うのかようわからん。
430:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/09 22:49:02.23
おかしいのは、パスワードハッシュの耐性とか、やたらうるさくこだわりながら、
単にハッシュを一回かけるだけとかで、やたら気にしてるのはハッシュ関数の種類だけ
みたいなの。
突っ込みたくもなるわ。
431:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/10 20:27:41.23
saltの意義はいくら調べても分かりません。
どの説明もバレない前提の説明ばかり。
しかし、実装レベルの説明ではバレてもいいみたいこと書いてる。
432:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/10 20:38:34.17
> バレない前提の説明
それが原理的に考えておかしい。
あらかじめ時間をかけて、大量にハッシュ値を計算しておく、という攻撃への対策として、
塩を混ぜてからハッシュ値を計算することで、情報を知ってからハッシュ値を計算しなければ
ならなくする、というのが目的なんだから、塩の秘匿（ないし公開）は、ハッシュ値の秘匿（ないし公開）と
同じ扱いでよい。
433:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/10 20:49:27.42
そういう理由なら反復回数の秘匿でハッシュ値の秘匿も達成されるじゃん。
434:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 05:33:30.00
saltはランダム値を使ってこそ意味がある。
平文aを1というsaltで暗号文bをつくり、bと1を送る。
しかし、また同じ平文aを送りたいとき、bと1を送れば、
盗聴されてる場合は解読はされてないが、同じ平文を送ったことがバレる。
しかし、平文aを2というsaltで暗号文cを作れば、同じ文を送ったかどうかはバレない。
435:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 09:40:48.58
>>434
それは確率的暗号方式
（鍵生成だけではなく、暗号化アルゴリズムも確率的アルゴリズムになっていて
たとえ同じ平文を暗号化しても毎回異なる暗号文になる）
の暗号化処理で使うランダムネスの話ですね
そういう目的で暗号化アルゴリズムへ入力する・アルゴリズム内で生成する
乱数やランダムネスをソルトと呼ぶことはあまりないと思う
てかパスワードハッシュのソルトの目的って>>472以外の何物でもないのに
バレない前提（ソルトがバレない限り安全ということ？）ってどういうこと？
>>431の読んだ参考書や解説が知りたい
436:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 09:47:17.77
>>435のレスアンカー間違えた
472じゃなくて>>427だ
そういやずっと前に
共通鍵メッセージ認証の鍵（当然送信者と受信者以外に明かしてはいけない）を
ソルトって呼んでたブログや技術文書がどっかにあったような・・・
437:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 11:35:24.53
>>435
暗号化処理で暗号化毎に使うランダム値もまあソルトって言う気がするけどな。
パスワードハッシュやパスワードベースの暗号化の場合とは目的は違ったりしても。
438:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 15:01:25.17
ストレッチングでテーブル化は防げるんだからsaltは不必要でしょ。
439:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 15:05:02.47
ストレッチングは計算量をかせぐ目的のものであって、あらかじめ計算されてしまう、
という問題への対策ではない。
440:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 15:18:06.14
不必要である、なくてもいいという反論になってないな。
残ってるのは、歴史的理由でしょう。
元々 鍵+塩 で後から ストレッチングが追加されただけ。
441:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 16:19:57.11
>>437
そうなの？
暗号理論の論文ではまず見ないから知らんかった
実装ではそういうもんなのか
>>438
反復回数ってどれぐらいの幅をもたせられるもんなのかね
あと>>439にもあるけど、ユーザーごとに異なるソルトを使わずに反復回数だけを変化させた場合
流出したパスワードハッシュに何回かハッシュ値をかけて
全部のパスワードのハッシュ関数反復適用回数を、たとえば10万回に揃えれば
一度計算した「反復回数10万回のハッシュ値」が全部のパスワードとの比較に利用できるから
やっぱり反復回数を変えただけじゃソルトの代わりにはならないんじゃないかな
442:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 16:32:44.92
>>440 目的が違う、という結論に対して、同じもんなんだから要らない、という
論理が生き残れると思える発想がわからないな。
443:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 17:14:39.81
昔、ワープロ派とPC派がいてだな。
ワープロ派は目的が違うからとずっと言っていた。
444:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 17:33:20.29
今、ケータイ派とスマフォ派がいてだな。
ケータイ派は目的が違うと言っている。
445:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 17:40:27.20
ストレッチング回数なんていう、変に制約を気にしなければならない方式をわざわざ採用するメリットがない。
簡単に制約なくソルトで対応出来るのに、わざわざ制約をかけたがる意味が分からない。
ストレッチング回数なんていまでも多分10万回くらいだろう。
場合によっては幅が1万回もいかない。
それだとバースデーパラドックスで100人に一人くらいは一致する可能性が高くなる。
しかもソルトと違って途中経過も保存可能、こういうのは何らか攻撃手段を与えるきっかけになる。
こんなデメリットばかりなのにあえて使う意味が分からない。
446:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 18:06:50.54
>多分10万回くらいだろう。
ふつう1000回ぐらいだよ。
>途中経過も保存可能
不可能だよ。どんだけ容量いるんだよ。
md5の128bitで1000回で、16000バイト。
大小英文字、数字8文字のパスワードのパターンだけで、62^8 * 16000 ≒ 3エクサバイト
実装したことない人？
447:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 18:10:25.12
そういうこと言ってんじゃないの。
継続計算できるって性質そのものが何らかの弱点を作り出すきっかけになりかねないって言ってんの。
暗号関連の経験あるなら、こういうのはできる限り避けるのは当たり前の感覚だろがよ。
448:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 18:24:06.15
だから実装上ありえないって言ってるの。総当りも実装上は継続計算。
暗号化、複合化が公開されてる暗号化手法で継続計算できない暗号手法なんて存在しない。
どの手法も常にコンピュータの計算力のリスクに晒されてる。
449:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 20:01:43.16
継続計算って何？
「なりかねない」って何。暗号理論で「なりかねない」なんて言葉、
あまり使わないと思うのが当たり前の感覚だと思うが。
>>443-444
木槌の代わりに金槌を使って痛い目に遭ったりしたことがないんだろうなw
多分、死ぬような目に遭わなきゃわからないんだろうなw
死んじゃったらわかりようもないけどw
450:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/11 20:09:42.25
きちがい
451:デフォルトの名無しさん
12/04/11 21:18:59.05
おまえ実は暗号関係素人だろ。
計算量のみに依存してる話と、何らかの問題によってその計算量が減らされる事象とは全く違う。
計算量を想定より減らされる危険があればそれは立派な弱点だよ。
それが暗号の世界だ。
じゃなきゃ例えば中間一致攻撃なんて弱点は存在しない。
実装上ありえないって、中間一致攻撃なんて実装上もっとあり得ない。
今回の話では、例えば繰り返し回数1000回程度の場合に、例えば1から1000回まで幅を持たせたら、
たまたま回数が低い場合に単純に耐性が1000分の一とかになる。
いくらなんでもこれは意味ないから例えば1000から2000回にしたとする。
ここで1000回目の値があれば、そこから1001回目の計算は1回分の計算でできる、これが継続計算できるの意味。
例えばレインボーテーブルの一種として1000回目の値を保持しておけば、
0回から1000回の計算で値が計算できる。つまり繰り返し1000回分の耐性が削られるわけだよ。
暗号の世界じゃこんなものは脆弱性以外の何物でもない。
そしてこんな不合理な方法使わなくても単純にソルトで安全に制約なく目的を達成できるんだ。
こんなバカなことをする奴はいない。
452:デフォルトの名無しさん
12/04/11 21:22:02.64
そもそも現在不可能なこと以上を気にする必要ないなら、
128ビット暗号化とか無駄なものを作るやつは実装経験のないバカなのか？
今の暗号の仕組みなんて今現実じゃ実装不可能なレベルの耐性を考慮してるものばかりだよ。
453:デフォルトの名無しさん
12/04/11 21:23:25.00
MD5やSHA1の脆弱性だって現実実装上、やぶれる環境なんて存在しない。
じゃあこれを気にするのは実装したことがないバカなのか？
笑わすなっつうの。
454:デフォルトの名無しさん
12/04/11 21:27:55.19
>>453
ネゴかかるところから送信受信の全データ捕獲すれば、解けないことはないでしょ
リアルタイムに解析ってのは無理かもしれんけど
455:デフォルトの名無しさん
12/04/11 21:32:47.27
>>454
一応、今言ってんのは単純にMD5自体を破る話な。
パスワードとか関係なく、あくまで暗号関連の脆弱性話の例として出しただけ。
456:デフォルトの名無しさん
12/04/11 21:35:44.87
アルゴリズムわかってるのを暗号というのはどうなんかね？
ネタバレしたら手品にならんような
457: ◆QZaw55cn4c
12/04/11 21:44:26.35
>>456
>>415
458:デフォルトの名無しさん
12/04/11 22:02:48.07
>>457
机上の空論？
別に考えることを否定してるわけじゃないよ
459:デフォルトの名無しさん
12/04/11 22:28:54.27
実際、無線LANが実際突破されちゃったからねぇ。
タダでインターネットができるツールって堂々とクラックツールを路上販売してるんだもの。
WEP限定だけど。
460:デフォルトの名無しさん
12/04/11 22:40:55.85
暗号化するってことは簡単な暗号解読ぐらいできないと意味無いでしょう
461:デフォルトの名無しさん
12/04/11 22:57:07.20
>>451
ストレッチングはバカが考えたということ？
462:デフォルトの名無しさん
12/04/11 23:02:52.51
>>451
たった10^-3じゃなぁ。
レインボーテーブルも結局、HDDの容量の壁にごっつんこだな。
463: ◆QZaw55cn4c
12/04/11 23:06:36.20
>>458
暗号を解読する方法があったとしても、途方もない計算資源が必要で事実上解読できない、
たとえ暗号のアルゴリズムを公開したとしても、鍵さえ秘密であれば、実用上問題ない、
という考え方もあると思う。
実際に使用するときには、暗号化の方法を秘密にしてもなんら差し支えないし、そうするのが普通だろう。
しかし、仮に内部通報者がいて、暗号化の方法を暴露する、あるいは暗号化のプログラムそのものを暴露する、ということがあっても、鍵さえ暴露されなければ問題なし、という方がより安全だろう。
現代の暗号は、そういうシチュエーションも考慮して暗号アルゴリズムを追求していると考えている。
464:デフォルトの名無しさん
12/04/11 23:17:01.79
>>462
はいはいもう消えろよ。
465:デフォルトの名無しさん
12/04/11 23:18:36.23
>>463
通信経路の暗号だと
鍵が見えたら、どうにでもなることでしょ、アルゴリズムがバレてたら
だから、通信中に鍵変えるのがあるでしょ
ファイル暗号だと鍵がわからないと手が出ないってだけ
総当たりするにしても時間がかかる
466:デフォルトの名無しさん
12/04/11 23:19:26.51
>>464
ほう。大小英数字8文字のレインボーテーブルがこの世に存在するのか？
容量はいくらだ？
467:デフォルトの名無しさん
12/04/11 23:20:56.93
10^3だからわざわざデメリットばかりの方法使うって？
あほだな。
だいたい元の状態から比較したら、10^3じゃなくてストレッチングの意味がなくなるんだぜ。
レインボーテーブルはHDD容量でぶつかるって？
だったら最初からソルトとかテーブル化を防ぐ処置なんていらないんだよ。
なのになんでそれを防ぐようにしてるんだ？
まあそもそもテーブルだってそうあたりじゃなくて辞書をい使うんだがな普通は。
ソルトが10^3ってのも少なすぎて笑うけどな。
468:デフォルトの名無しさん
12/04/11 23:22:19.40
はい今度はレインボーテーブル対策は無意味とね。
くすくす、次は何を言い出してくれるのかな。
469:デフォルトの名無しさん
12/04/11 23:23:01.52
>>466
誰がそんなこと言ったんだよきちがい。
470:デフォルトの名無しさん
12/04/11 23:23:27.14
>>466
これ以上無知をさらす前に消えろよ。
471:デフォルトの名無しさん
12/04/11 23:25:13.76
だいぶ前にexcelの暗号化ファイルのパスワード解析した人がいたなあ
472:デフォルトの名無しさん
12/04/11 23:27:03.68
WindowsのNTLMv2だったかなんかはレインボウテーブル実在したよな確か。
あれはソルト使ってねーからな。
チャレンジレスポンスに対応するためやむを得ないんだが。
473:デフォルトの名無しさん
12/04/11 23:28:02.23
8文字以上のパスワードにするだけで、
そんなレインボーテーブルはこの世に存在しないから、総当りしかない。
ここで防御力を発揮するのがストレッチング。メタルスライムレベルの防御力。
474:デフォルトの名無しさん
12/04/11 23:29:25.00
>>470
無知はおまえだ。存在しないものは存在しない。
あるなら、どのハッシュのものでもいいからURL張れ。
475:デフォルトの名無しさん
12/04/11 23:33:23.37
だから辞書と組み合わせるんだっつの。
本当にあほだなお前。
476:デフォルトの名無しさん
12/04/11 23:34:51.85
あとそもそも実在するかどうかなんて関係ないんだよ。
暗号にかかわるならそんなことは常識で理解できるだろ。
実在実在見当はずれなこと言ってるのはお前だけ。
477:デフォルトの名無しさん
12/04/11 23:37:07.19
8文字長のレインボーテーブル出せで、なんで辞書の組み合わせテーブルなんだよw
テーブル劣化しすぎwwww
478: ◆QZaw55cn4c
12/04/11 23:37:18.90
>>465
＞通信経路の暗号だと
＞鍵が見えたら、どうにでもなることでしょ、アルゴリズムがバレてたら
そのとおり。
しかし、通信を行う双方で同一の鍵を使うことが可能で、かつその鍵が第三者には明らかにならない方法が存在する。
つ「DH鍵交換」
あるいは、暗号化で使用する鍵と復号化で使用する鍵が異なり、送信側に暗号化用の鍵を渡して、自分の復号化用の鍵を秘密にしておく方法もある。
このとき秘密にしている復号化用の鍵は、暗号化用の表に公開する鍵からは簡単には計算できない仕組みになっている。
つ「RSA暗号」「公開鍵暗号」
つ「一方向関数」
479:デフォルトの名無しさん
12/04/11 23:42:25.12
>>476
実在しないことが前提で今の暗号化の強度は成り立ってます。
実在したとなればそれは破られたと同義です。DESがいい例。
480:デフォルトの名無しさん
12/04/11 23:43:01.39
>>478
片側しか見えんとでも思ってるの、今のnet環境？
その手のやつは、ある程度時間経つと鍵変えてるような気がするけど
481: ◆QZaw55cn4c
12/04/11 23:47:22.17
>>480
＞片側しか見えんとでも思ってるの、今のnet環境？
kwsk
＞ある程度時間経つと鍵変えてるような気がする
素数を使用するタイプの公開暗号系では、確率的ではあるが素数判定方法があるので、お手軽に素数を算出してはそれを暗号に使用している。
お手軽に算出する程度のものだから、頻繁に鍵＝鍵に使用する素数を変える必要があるのだろう。
482:デフォルトの名無しさん
12/04/11 23:47:53.00
>>477
なんで勝手にお前が出した条件にあうものを応えなきゃならないんだよ基地外かお前は。
お前が言ったテーブルが実在するかなんて誰も問題にしてないんだよ。
っていうか誰も実在するなんて言ってない。
馬鹿かよ。
お前が言ったテーブルがなければそんで安全なのか？
論点ずらしまくってんじゃねーよこの基地外。
それで済むなら暗号技術なんてどうでもいいもんばっかなんだよ。
お前はひとりで繰り返し回数をソルトの代わりに使うバカシステムでも作ってろよ。
まともな人間が見たら指摘されるだろうけどな。
483:デフォルトの名無しさん
12/04/11 23:48:10.70
>>478
見えるのは途中の経路にぶら下がったところだからね
末端の人には見えないから安全ってだけでしょ
484:デフォルトの名無しさん
12/04/11 23:49:01.56
まさか>>415-416の話に賛成できない人がいるとは思わなかった。
Security through Obscurityと言われたりもするっけ。byだっけ。
>>415-416の考え方を「知らなかった」ならわかるけどそれに反論するとか
どんなチャレンジャーだよ。
485:デフォルトの名無しさん
12/04/11 23:50:07.59
>>479
また論点がずれてるぜ。
それは安全性の保証じゃなくて、すでに破られているわけではないことの保証にしかならない。
現実に破られてないからOKなら、128ビットの暗号化なんて不要。
危険性の説明に実在するかどうかなんて関係ないだろうが。
実在しないのは安全性のための必要条件に過ぎない。
486:デフォルトの名無しさん
12/04/11 23:51:41.65
>>482
じゃあ、単純に実在しないよと言えばいいのに、
なんで「これ以上無知をさらす前に消えろよ。」なんだよw
キミの感情を複合化してやるよ。
くやしいんですね。わかりますw
487: ◆QZaw55cn4c
12/04/11 23:51:43.34
>>483
残念だがその意見は違うだろう。
公開暗号系を使用すれば、途中の経路で通信内容が全部傍受されたとしても、暗号を解読することは事実上不可能だ。
末端でみえようとみえまいと、あるいは途中の経路でみえようみえまいと、プロバイダがすべての通信のログを取得しようと、安全性には全然関係ない。
むしろ Windows のログオンパスワードの脆弱さといったら、お話にならないくらいだ。
488:デフォルトの名無しさん
12/04/11 23:51:56.04
ああ、>>479は人違いで逆の意味でいったのかな、だったら勘違いすまんね。
489:デフォルトの名無しさん
12/04/11 23:53:47.07
IPSecは糞と言いたいんだな。
490:デフォルトの名無しさん
12/04/11 23:55:30.35
実在しないかどうかは知らないもん。
お前が初めから実在するかどうかが重要ってスタンスで聞いてくるから、
実在するかどうかは関係ないって言ってんだろうが。
悔しいって笑わすな、ずっとずれたこと言い続けてんのはお前じゃねーか。
実際に実在しない保証はないが、まあおそらく総当たりのテーブルは実在しないだろう。
で、だからどうしたの？そんなことは話の本筋に関係ないといってる。
491: ◆QZaw55cn4c
12/04/11 23:56:00.33
>>484
最初に暗号に触れる人には、理解に一定の困難が伴う考え方だと思う。「チャレンジャー」も理解を促進するひとつの方法だろう。
ただ理解しているものはそれに丁寧に回答する義務はあるかもしれない。
492:デフォルトの名無しさん
12/04/11 23:58:06.14
＞キミの感情を複合化してやるよ。
噴いた。
493:デフォルトの名無しさん
12/04/12 00:02:25.62
話の本筋を理解できないもしくはごまかし続ける相手に説明するのは無理、時間の無駄。
どうせごまかしたり論点ずらしたりするだけなんだから。
繰り返し回数をソルトの代わりに使うことの合理性をきちんと説明してみろって。
ああ、こいつの言い分だとそもそもソルトとかテーブル対策は要らないんだったｗ
8文字以上のレインボーテーブルは存在しないのでテーブル化対策は不要です、キリっ
494:デフォルトの名無しさん
12/04/12 00:09:35.68
>>487
流れてるパケットの量が半端じゃないからね
ピンポイントでやろうってのがいないだけなんじゃねえの？
495:デフォルトの名無しさん
12/04/12 00:11:14.65
中間者攻撃でアウト。
特に無線LANとかだとひっかけやすい。
だから証明書とかが必要なんだな。
496:484
12/04/12 00:12:58.03
>>491
確かに暗号の話を教える/教わるとき最初の山が公開鍵暗号あたりで、その次が
Security through Obscurity(がダメという話)かもしれませんね。順番は逆かも？
とはいえ俺は理解はしてるけど他人を理解させられるレベルではないので
えらそうなことは言えませんね。
497:デフォルトの名無しさん
12/04/12 00:15:05.53
レインボーテーブルの弱点はsaltと長パスワードでOK？
498: ◆QZaw55cn4c
12/04/12 00:26:39.87
>>496
なに、理解はらせん状に行きつ戻りつ進んでいくものだし、他人に説明することは自分の理解の深化にも寄与すると期待している。
ここは匿名の場であるし、遠慮なく自分の考えの述べるのはお互いにとっても最終的に利益になると思う。
お考えをうかがいたい。
499:デフォルトの名無しさん
12/04/12 00:43:26.82
C++のAES256の枯れたライブラリってある？
500:デフォルトの名無しさん
12/04/12 08:54:02.73
>>497
OK
501:デフォルトの名無しさん
12/04/12 09:06:07.92
しかし、英数字パスワードだと、1文字辺りって6ビット程度だよな。
記号入れても7ビットはいかないが。
8文字だと48ビット程度か。
ビット数だけならDESより余裕で弱いんだな。
まあそれ以前にパスワードのエントロピーなんて乱数よりずっと低いが。
48ビットだと組み合わせ数は256Tか。
計算途中を再開するためには全情報が要るが、
単なるテーブルなら先頭の例えば64ビット分だけでも十分かもしれん。
とすれば8バイト×256Tで、2Pバイトか。
暗号関連の、ホントに現実的じゃない安全想定に比べたら、
余裕で実現可能なレベルだな。
502:デフォルトの名無しさん
12/04/13 04:47:14.97
Ciphertext stealingって1ブロック以下のときはどうやってパディングするの？
503:デフォルトの名無しさん
12/04/16 08:36:16.49
楕円曲線暗号の掛け算について分からないので教えて下さい。
ｈURLﾘﾝｸ(deztec.jp)
このページ中で「同意された点8に75を掛けると点26になる」
という部分なのですが、点8に75を掛けてみても点26に出来ません。
どの値にどのように掛ければ良いのか、教えて頂けると幸いです。
504:デフォルトの名無しさん
12/04/16 09:02:54.18
瓶詰演算
これら楕円曲線上の点の上に、次のような演算を定義すると、群になる。
すなわち、(x1, y1) という点と、 (x2, y2) という点の「和」 (x3, y3) を、次の
ように約束する。
x3 = λ2 - x1 - x2
y3 = λ(x1 - x3) - y1
λとは何者か？というと、異なる点を足す場合、つまり一般の場合には
λ = (y2 - y1) × (x2 - x1)-1
とする。同じ点を足す場合、これでは分母分子ともゼロになってしまうが、そ
の場合には、
λ = ( 3x12 + a ) × 2y1-1
とする。 a とは楕円曲線の1次の係数で、①では2である。さらに、x1 = x2 で
y1 = -y2 というケースがある。その場合、足し算の結果は「無限遠点」とする。
「無限遠点」自身は、この演算に関してゼロとして機能する。ここで-1乗という
のは逆数（ℤ7上でかけると1になる相手の数）のこと。
505:503
12/04/16 10:50:04.28
>>504
回答有難う御座います。
まだ試してないので、ちゃんと理解出来たのか怪しいですが
もう少し頑張ってみます。
506:504
12/04/16 14:45:35.89
>>505
>>503で貼り付けているsite内を検索してごらん
507:デフォルトの名無しさん
12/04/16 16:15:02.73
>>502
CTSなんてブロック暗号利用モードがあるんだ
知らなかった
全くの思い付きだけど、最初から1ブロックしか暗号化しないってことは
共通鍵暗号で単純に1つのメッセージを暗号化するときと同じだから
PKCS#5 Paddingとかでメッセージの長さを1ブロック分にして
それを暗号化するのではないかと予想
てか秘匿とメッセージ認証以外にもいろんなモードの規格が準備されてるんだね
URLﾘﾝｸ(csrc.nist.gov)
URLﾘﾝｸ(www.cryptrec.go.jp)
メッセージ認証と鍵ラッピングは知ってたけど
認証子付き暗号化とかディスク暗号化なんてのもあるのか
508:503
12/04/16 20:42:26.64
>>506
追加のアドバイス、有難う御座います。
ちゃんと理解する為には色々と検索しなければならなさそうですがｗ、
今考えている方法を試して駄目だったら検索もやってみます。
509:デフォルトの名無しさん
12/04/18 18:17:06.76
共通鍵暗号におけるIV(initial value?)というのは、
解読時までKeyと一緒に覚えておく必要があるのでしょうか？
もしそうなら、公開鍵暗号と一緒に用いる場合、
Keyと一緒に暗号化しておくべきでしょうか？
510:デフォルトの名無しさん
12/04/18 18:40:15.18
cbc modeの話だと仮定します。
IVは暗号化前に生成しておいて、
復号時にも同じ値をIVとして使用します。
通常IVは暗号化しません。
また、Keyは対称鍵暗号で使う対称鍵のことと仮定しますが、
Keyのみを公開鍵暗号で暗号化して、
暗号化対象の実体は対称鍵(Key)で暗号化します。
511:デフォルトの名無しさん
12/04/18 19:22:56.39
情報が不足していてすみませんでした
まさに対称鍵暗号のCBCやCTRを想定していました
回答ありがとうございました
512:デフォルトの名無しさん
12/04/24 18:42:15.56
コンテンツ暗号化するときは毎回コンテンツごとにコンテンツ暗号化キーをランダムに生成。
で、コンテンツ自体を暗号化(だいたい対称暗号で)。で、コンテンツ暗号化キー自体を
自分の何からしの鍵(キー暗号化キー)で暗号化して、その暗号化されたキー暗号化キーと暗号化されたコンテンツをセットに
する。キー暗号化キーをどうするかは用件しだいで、>>510のように、公開鍵暗号で暗号化したり、
パスワードベースにするならPBKDF2などのキー導出関数を使って、導出させる。
513:デフォルトの名無しさん
12/04/24 18:46:06.85
まぁ、暗号化だけじゃ、機密性しか提供できないから、一貫性チェックのために、
暗号化する前に、コンテンツのハッシュを求めて、コンテンツとハッシュをあわせたものを
暗号化するなどして、復号化時に、コンテンツの一貫性をチェックできるようになる。
Windowsの暗号化ファイルシステム(EFS)をだいたい同じ。EFSは使用するとEFS用の
自己署名された証明書とその公開・非公開鍵ペアをつくって、その非公開鍵が
キー暗号化キーになるイメージ。
514:デフォルトの名無しさん
12/04/24 18:55:04.74
コンテンツ暗号化キーを暗号化するときに、１つのキー暗号化キーで暗号化するのでは
なく複数のキー暗号化キーを使って、暗号化されたコンテンツ＋複数それぞれのキー暗号化キー
で暗号化されたコンテンツ暗号化キーをセットにしておけば、１つのキー暗号化キーを
忘れても他ので復号化できるので安心。EFSに回復エージェントって仕組みがあるけど
まさしくそれ。
515:デフォルトの名無しさん
12/04/24 19:43:56.51
暗号化ファイルシステムがハックされたら、終わり
516:デフォルトの名無しさん
12/04/25 05:49:50.07
「ハックされたら」の一言で計算量理論もなにもかもをふっとばせるバカはお気楽でいいな
517:デフォルトの名無しさん
12/04/25 06:20:04.43
Windowsの暗号化ファイルシステム(AES256+(ECC256 or RSA2048))はザル。
ログインパスワードさえ突破しさえすれば丸見え。大半は辞書攻撃で突破可能。
518:デフォルトの名無しさん
12/04/25 07:23:33.81
鍵の不適切な運用を前提に議論するとか、最強の論理体系ですねw
519:デフォルトの名無しさん
12/04/25 07:31:34.85
事実、現実が不適切な運用だらけなのに、
それを前提にしないシステムは欠陥ありというべきであろう。
最低限、EFSを使用する場合には、ログインパスワードのセキュリティポリシーを
強制的に厳しくするべきだね、MSは。
520:デフォルトの名無しさん
12/04/25 17:04:02.53
個人用の場合、忘れたもしくは自分が死んだらおしまいの、パスワードベースでいいんだけど、
EFSは証明書に基づく公開・非公開鍵要求するからふざけるなって感じ。
BitLockerでいいよ。
521:デフォルトの名無しさん
12/04/26 02:50:46.22
コンテンツのハッシュをとってから暗号化するのと、
暗号化してからキー付ハッシュをとるのとどっちがいい」？
522:デフォルトの名無しさん
12/04/26 04:18:20.27
>>521
暗号文とハッシュ値、ハッシュの秘密鍵と復号鍵の格納場所がどこで
どんな経路を通じて誰が一貫性（完全性ともいう）チェックと復号をするのかによって
いろいろ変わるのかもしれないけど、一般的にはEncrypt-then-Macといって
（１）最初に暗号化する
（２）次にその暗号文のキー付きハッシュをとる
という順番になる
もとのデータを利用したいときは
（１）まず暗号文の完全性をチェックする。エラーを検出したらそこで終了
（２）暗号文を復号する
という手順になる
この順番にすることで、勝手なデータを復号処理に入力して、その出力結果を観測して
暗号の安全性を破る攻撃（選択暗号文攻撃）を防ぐことができる
あるいは最初から秘匿とメッセージ認証の機能をあわせもつ
認証付き暗号（認証子付き暗号ともいう）を使うという手もある
523:デフォルトの名無しさん
12/04/26 11:42:17.37
そこらへんの暗号化や署名したデータのフォーマットを各自が考えると相互運用性や
可搬性が低くなるからCMS(Cryptography Message Syntax)ってものがある。RFC3852読むといいよ。
CMSのデータはネストできる構造になってるんだが、そこで、Digested-Dataようはハッシュしたデータの
項みると、
Typically, the digested-data content type is used to provide content
integrity, and the result generally becomes an input to the enveloped-data content type.
となってて、一般的にハッシュしたデータはEnvelped-Data(要は暗号化)の入力になるとは書いてある。
524:デフォルトの名無しさん
12/04/26 11:47:45.07
Win8でWindows APIにCNG DPAPIってデータを保護するAPIが追加されるらしいんだけど、それが
CMS使ってて、その構造をURLﾘﾝｸ(msdn.microsoft.com)
でみると、一番外側が図で類推する限り、Enveloped-Dataになってて、それで、
>>513では、ハッシュを先にするべきなのかなとハッシュを先に書いた。
525:デフォルトの名無しさん
12/04/26 11:54:55.18
>>522はURLﾘﾝｸ(tools.ietf.org)のAuthenticated Enveloped Dataかね。
526:デフォルトの名無しさん
12/04/26 12:29:28.11
まぁ、RFC3852(5652),RFC3370,RFC5754,RFC3565を気合入れて読みながら、Windowsの
CryptoAPIのCMSを操作する関数をここ2週間いじくりまくって身に付けた程度の知識だから、
Secruity Condisderationsとかそこまでは手回ってなく、詳しくはわからんけど、
選択する暗号アルゴリズムやハッシュアルゴリズムを強度が高いものにして、
後は鍵管理をしっかりしとけば、ハッシュした後、暗号化しとけばとりあえず
問題ないとは思うけどな。自分だけ復号化できればいいんだったら。わざわざ、
メッセージ認証する必要ねぇとは思う。
527:デフォルトの名無しさん
12/05/11 13:32:46.81
OpenSSLのRAND_bytes()を使おうと思うのですが、
RAND_add()は、常駐してエントロピーを収集するようなプログラムが使うもので、
ユーザープログラムは、RAND_bytes()を呼び出すだけで済むという認識で正しいでしょうか？
528:デフォルトの名無しさん
12/05/11 15:01:32.57
RAND_add()は、RAND_seed()とほぼ同じ関数だよ。
乱数の乱数性を強化する際に使う関数。
>>527はRAND_bytes()を呼び出すだけという認識でいいよ。
529:デフォルトの名無しさん
12/05/11 16:37:59.92
毎回種蒔くのは面倒だと思っていたので、すっきりしました
回答ありがとうございました
530:デフォルトの名無しさん
12/06/05 18:30:28.73
CIPHERUNICORN-A、Hierocrypt-3、SC2000の
ソースコード探してるのですけど
在りかを知ってる方がいれば教えて頂きたいです。
…できれば言語がCだと有難いです。
531:デフォルトの名無しさん
12/06/06 20:56:26.20
Hierocrypt-3はあった
URLﾘﾝｸ(ci.nii.ac.jp)
532:デフォルトの名無しさん
12/06/07 09:10:40.65
>>531
ありがとうございます！
非常に助かりました。
533:デフォルトの名無しさん
12/06/15 13:43:33.76
これからはCDのコピー禁止フラグのような軽いプロテクトも流行るんじゃないかな。
534:デフォルトの名無しさん
12/06/15 13:47:20.86
何も重いプロテクトをかけるだけがいいことでは無い。
プロテクトを外す行為が違法ならあえて軽いプロテクトにして、外した者を
どんどん逮捕したらいい。
535:デフォルトの名無しさん
12/06/15 14:15:25.05
フラグ1個でも技術的保護手段っていうの？
536:デフォルトの名無しさん
12/06/15 14:17:14.63
要はコピー禁止の意志がファイルに付いていると認められるということ。
537:デフォルトの名無しさん
12/06/17 13:24:12.69
>>534
違法行為で暗号を解読した証拠は裁判所で証拠にならないので
犯罪に使われた解読後の結果が証拠になるなら、他者の所有物の解読は
違法ではないという判断になるんじゃない？
538:デフォルトの名無しさん
12/09/17 09:35:08.91
2ch_prog20004140935082220001
のSHA256ハッシュを取ると
00000000015FBAE7DCBE0642BE86EAD87962183AF994884DD2159188B90EF494
で0のビットが先頭に39個続く
2ch_progから始まる文字列でこれより長く0のビットが続くの探してみて
539:デフォルトの名無しさん
12/09/18 21:01:37.05
【IT】マイクロソフトが発見！中国製PCに出荷時からウィルス「中国製のパソコンや情報端末の購入には、慎重になったほうがいい」★２
ｽﾚﾘﾝｸ(newsplus板)
＊＊＊＊＊＊＊＊＊＊＊＊
可能性としてありうる。
１、中国製パソコンの画像データには以下の実行
プログラムソースがふくまれてる。
２、有事の際には中国当局からネットで全世界の
パソコンに指示を出し、機能停止が可能。
３、夜間定期的に送受信メールやテキストファイル、PDFの中身を
自動的にスキャンして、中国に対する不利益な動きに対し
自動的に中国当局に警報メールを発信する。もちろんIPアドレスから
そのPCの位置情報、個人情報のすべて。
４、上記を検出、ソース表示をしようとする動きに対し、フリーズ、暴走する機能内蔵
技術的にはすぐにでも可能。
というかすでに中国出荷の全PCやBIOS
のレベルでインスコ済みの可能性がある。
＊＊＊＊＊＊***************
540:デフォルトの名無しさん
12/10/10 21:46:53.81
保守
541:デフォルトの名無しさん
12/11/06 14:51:31.15
不正防止とコスト
市場はどっちを選択するんだろうなぁ
542:デフォルトの名無しさん
12/11/06 15:19:32.37
誰かがコストを選択して痛い目に遭ってから、不正防止を選択します。
顕在せぬ危険性について、株主が理解することは不可能でしょ。
どっかの株価大暴落がないと駄目だろうね。