07/02/08 21:59:36
写像という考えかたを使わない、数学をつかった暗号ってあるのかな
3:にょにょ ◆yxpks8XH5Y
07/02/08 22:06:06
今だ！2ゲットォォｫｫ！！
￣￣∨￣￣￣￣￣￣￣￣
∩ ∩
～| ∪ | (´´
ﾍﾉ ﾉ (´⌒(´
(（つ ﾉ⊃≡≡≡(´⌒;;;≡≡≡
￣￣￣(´⌒(´⌒;;
ｽﾞｽﾞｽﾞｽﾞｽﾞ
4:１３２人目の素数さん
07/02/08 22:09:45
未来のコンピューター
１ ＯＳがいらない
２ 電源もいらない
３ 持ち運びかんたん
４ メモリーもいらない
ソロバン
5:１３２人目の素数さん
07/02/08 22:12:41
cinco!
6:１３２人目の素数さん
07/02/08 22:13:04
しりとりで暗号を送る方法
りんご
ごりら
らくだ
だめよ
よして
7:１３２人目の素数さん
07/02/08 22:17:24
５ 脳内ネットをつかって演算する
６ 通信は光を視覚で受ける
７ テレパシーも使える
８ サイコキネシスは４万キロまで
９ メモリーも脳内記憶に頼る
8:１３２人目の素数さん
07/02/08 22:19:13
空軍の開発した思っただけでガトリングガンが起動する赤外線ＭＲＩ
ヘルメットインターフェイスであそべるやつ
9:１３２人目の素数さん
07/02/08 22:28:13
パソコンはネットゲームと検索・通信できればいい
軌道上の小型マイ衛星を制御できる
軌道上でリアルに対戦できる
ニュートリノ通信できる
10:１３２人目の素数さん
07/02/08 22:30:06
ニュートリノ無線ＬＡＮをカミオカンデで作れば宇宙規模のネットが
できる。銀河ギガー
11:１３２人目の素数さん
07/02/08 22:39:34
ＭＡＣのノートの外についてる小箱は何？
12:１３２人目の素数さん
07/02/08 22:40:41
ＣＩＡのビルの入り口のオブジェの暗号は解読されていない
13:１３２人目の素数さん
07/02/08 22:43:14
タキオン媒体超光速ネットワーク
14:１３２人目の素数さん
07/02/08 22:46:56
今後必要とされる科学技術
転送ポッド
ホロデッキ
Ｍｒ．フュージョン
アンチグラビテイーエンジン
15:１３２人目の素数さん
07/02/08 22:48:13
グループベロシテイーＬＡＮ
海底糸電話
16:１３２人目の素数さん
07/02/08 22:49:15
ナノ炭素繊維の糸電話は超高速振動
17:１３２人目の素数さん
07/02/08 22:50:57
超音波ＬＡＮ 犬が苦しむ？
手旗信号ＬＡＮ 伝送メデイア不要 ラインオブサイト
空気砲ＬＡＮ
18:１３２人目の素数さん
07/02/08 22:53:51
補聴器型携帯電話 両手が使えます
コンタクトレンズ型アイカメラ アイルビーバック
Ｐ波ＬＡＮ
Ｓ波ＬＡＮ
19:１３２人目の素数さん
07/02/08 22:55:52
マントルにＰ波を集中させて記録するマントルデイスク 数億万年は保存できます。
20:１３２人目の素数さん
07/02/08 22:57:12
星座の位置で暗号を送る方法 銀河規模の通信に使えます
21:１３２人目の素数さん
07/02/08 23:15:24
海底ベルトコンベアーをつくれば
22:１３２人目の素数さん
07/02/09 00:17:56
網膜をキーとすれば本人以外には読めない
23:１３２人目の素数さん
07/02/09 01:52:47
>>22
それでも読もうとする犯罪が多発。
目をくりぬかれた死体がry
24:にょにょ ◆yxpks8XH5Y
07/02/09 09:20:08
>>12
これか！面白そうだな！
URLﾘﾝｸ(www.elonka.com)
25:１３２人目の素数さん
07/02/13 23:49:42
ほしゅ
26:１３２人目の素数さん
07/02/17 18:13:06
ほしゅ
27:１３２人目の素数さん
07/02/17 20:02:44
本当のことを言っても誰も信じないと思ったらいうだろ ジャックスパロー
28:１３２人目の素数さん
07/02/17 20:40:50
眼科のデータベースがハックされる。
29:１３２人目の素数さん
07/02/17 21:23:24
網膜キーが問題なのは解読キーがばれてしまえばどんな暗号もスカだから。
無線ＬＡＮのルーターの解読キーも大きな素数を順番にあてがってるだけなので
すぐ解読されてしまう。
ＣＩＡがＲＳＡを公開させたのもバックドアーを持っているからだ。
ＣＰＵが解読キーをレジスターにＵＰするときのバスの電磁波信号は起動上空の
スパイ衛星で簡単に察知されている。
30:１３２人目の素数さん
07/02/17 21:24:23
完全・光バス回路のＰＣが開発されない理由がなぜかもうわかるだろ。
31:１３２人目の素数さん
07/02/17 21:34:46
探知したバス信号をロジアナにかけるだけ。別のＰＣにまわしてもいい。
バス回路の信号は暗号化すべきなのに丸見え。
32:１３２人目の素数さん
07/02/18 01:29:30
そろそろCRYPTO 2007の締切
33:１３２人目の素数さん
07/02/18 07:16:42
■暗号技術【ROUND2】■@プログラム技術板
ｽﾚﾘﾝｸ(tech板)
ＲＳＡ暗号 解読 助けてください！！@セキュリティ板
ｽﾚﾘﾝｸ(sec板)
暗号アルゴリズムに重大な欠陥発見の報告相次ぐ@セキュリティ板
ｽﾚﾘﾝｸ(sec板)
暗号技術は変わるのか？@通信技術板（IPアドレス表示）
ｽﾚﾘﾝｸ(network板)
日本の数学者が馬鹿だったから暗号がばれた@軍事板
ｽﾚﾘﾝｸ(army板)
暗号化仮想ドライブ作成ソフト Part3@ソフトウェア板
ｽﾚﾘﾝｸ(software板)
フリーのファイル暗号化ツール 2MB@ソフトウェア板
ｽﾚﾘﾝｸ(software板)
34:１３２人目の素数さん
07/02/18 07:17:24
【認証局】SSLに関するスレ１枚目【ぼろ儲け】@自宅サーバ板
ｽﾚﾘﾝｸ(mysv板)
SSH その5@Unix板
ｽﾚﾘﾝｸ(unix板)
PGP / gpg スレ@Unix板
ｽﾚﾘﾝｸ(unix板)
35:１３２人目の素数さん
07/02/18 07:19:07
情報理論・符号理論を語るスレ@理系板
ｽﾚﾘﾝｸ(rikei板)
擬似乱数@プログラム技術板
ｽﾚﾘﾝｸ(tech板)
P=NP問題について真面目に語るスレ@数学板
ｽﾚﾘﾝｸ(math板)
符号理論を語るスレ@数学板
ｽﾚﾘﾝｸ(math板)
素数判定は「決定的」多項式時間で可能@数学板
ｽﾚﾘﾝｸ(math板)
楕円曲線@数学板
ｽﾚﾘﾝｸ(math板)
情報学板
URLﾘﾝｸ(science5.2ch.net)
Complexity Classについて語れ@情報学板
ｽﾚﾘﾝｸ(informatics板)
【疑似】乱数をつくる【本物】@電気電子板
ｽﾚﾘﾝｸ(denki板)
乱数@シミュレート板
ｽﾚﾘﾝｸ(sim板)
【量子】「商用の量子コンピュータを開発」と発表 カナダのベンチャー企業@科学ニュース＋板
ｽﾚﾘﾝｸ(scienceplus板)
放射性崩壊を利用した本物の乱数をネット上で手に入れよう@科学ニュース＋板
ｽﾚﾘﾝｸ(scienceplus板)
36:１３２人目の素数さん
07/02/18 07:20:18
おまけ
[諜報・防諜]インテリジェンス総合2[情報機関]@軍事板
ｽﾚﾘﾝｸ(army板)
Windows Media DRM について語るスレ@DTV板
ｽﾚﾘﾝｸ(avi板)
DRM解除 その3@ソフトウェア板
ｽﾚﾘﾝｸ(software板)
【高速化】ビット演算 0x02@プログラム技術
ｽﾚﾘﾝｸ(tech板)
アセンブラ… (゜□゜) ↑アッー！↓@プログラム技術
ｽﾚﾘﾝｸ(tech板)
37:１３２人目の素数さん
07/02/22 02:07:54
「メルアド」知られない 匿名通信手法、電通大が開発
URLﾘﾝｸ(www.business-i.jp)
この前のSCISで発表してた研究だね
おまけ
URLﾘﾝｸ(benli.cocolog-nifty.com)
この先生がこんなに痛い人だとは思わなかった・・・
38:１３２人目の素数さん
07/02/25 05:52:54
リング署名って参加者が誰かもわからないようになってるの？
39:１３２人目の素数さん
07/02/25 11:05:04
マルチは市ね。ｗ
40:１３２人目の素数さん
07/03/01 21:33:10
URLﾘﾝｸ(upload.wikimedia.org)
これを解読して
41:１３２人目の素数さん
07/03/01 21:56:38
URLﾘﾝｸ(www.ancientscripts.com)
42:１３２人目の素数さん
07/03/01 22:05:05
URLﾘﾝｸ(www.people.ku.edu)
43:１３２人目の素数さん
07/03/01 22:06:14
URLﾘﾝｸ(www.people.ku.edu)
44:１３２人目の素数さん
07/03/09 13:49:15
電通大 認証処理時間１０分の１ 「使い捨てＩＤ」システムコスト低減 - CNET Japan
URLﾘﾝｸ(japan.cnet.com)
45:１３２人目の素数さん
07/03/09 14:32:46
>>44自己レス
今度のISECの発表ですね
太田・國廣研究室やるな
こりゃ眞鍋かをりが取材に来る日も近いか！？ｗ
46:１３２人目の素数さん
07/03/11 21:47:21
398
47:１３２人目の素数さん
07/03/20 14:41:40
【電機】東芝：暗号メッセージ3分の1に圧縮、｢円分多項式｣適用…カード・おサイフ携帯簡素化に期待 [07/03/20]
ｽﾚﾘﾝｸ(bizplus板)
この研究成果は、20日から名古屋市天白区の名城大学で開催される電子情報通信学会で22日に
発表される。
▽News Source FujiSankei Business i.on the Web 2007年03月20日
URLﾘﾝｸ(www.business-i.jp)
URLﾘﾝｸ(www.business-i.jp)
48:１３２人目の素数さん
07/03/23 00:06:43
【家電】ソニー：暗号鍵で新技術｢CLEFIA(クレフィア)｣開発・演算量抑えながら安全性向上…AES技術比1.6―1.2倍 [07/03/22]
ｽﾚﾘﾝｸ(bizplus板)
▽News Source IT+PLUS 2007年03月22日20時40分
URLﾘﾝｸ(it.nikkei.co.jp)
▽Press Release
URLﾘﾝｸ(www.sony.co.jp)
新しい共通鍵ブロック暗号方式をFSE2007で発表するってさ
49:１３２人目の素数さん
07/03/23 00:22:29
camelliaに対抗する理由って何よ。
それと、誰か中の人の情報よろしく。
50:１３２人目の素数さん
07/04/03 18:58:27
kusosure
51:１３２人目の素数さん
07/04/04 20:00:03
誰か、ネタ投入すれ
52:１３２人目の素数さん
07/04/08 04:31:53
共通鍵暗号の最大差分確率とか最大線形確率って
具体的にどうやって求めるんだろう
53:１３２人目の素数さん
07/04/12 22:40:33
符号理論について勉強中です。
軟判定のビタビ復号ってどうやるんですか？
54:１３２人目の素数さん
07/04/12 23:37:06
>53
君はこっちだ
符号理論を語るスレ
ｽﾚﾘﾝｸ(math板)l50
55:１３２人目の素数さん
07/04/15 19:20:19
公開鍵暗号方式を用いて文書のディジタル署名を行う場合、鍵の関係に関する記述のうち、適切なものはどれか？
ア 暗号化鍵は公開しないが、復号鍵は公開する。
イ 暗号化鍵は公開するが、復号鍵は公開しない。
ウ 暗号化鍵、復号鍵とも公開しない。
エ 暗号化鍵、復号鍵とも公開する。
ねぇねぇ、「イ」って答えちゃってるけど
今どんな気持ち？
∩＿＿＿∩ ∩＿＿＿∩
♪ | ノ ⌒ ⌒ヽﾊｯ __ _,, -ー ,, ﾊｯ / ⌒ ⌒ 丶|
/ (●) (●) ﾊｯ (／ "つ`..,： ﾊｯ (●) (●) 丶 今、どんな気持ち？
| ( _●_) ミ ：/ :::::i：. ミ (_●_ ) | 研究ばかりで頭固くなってない？
＿＿＿ 彡 |∪| ミ ：i ─::!,, ミ､ |∪| ､彡＿＿__ お国は「ア」っていってるけど ねぇ、どんな気持ち？
ヽ＿＿＿ ヽノ､｀＼ ヽ.....::::::::: ::::ij(_::● / ヽノ ＿＿＿/
/ ／ヽ < r " .r ミノ~. 〉 ／＼ 丶
/ ／ ￣ ：|::| ::::| :::i ﾟ。 ￣♪ ＼ 丶
/ ／ ♪ ：|::| ::::| :::|： ＼ 丶
（＿ ⌒丶... ：` | ::::| :::|_： /⌒＿）
| /ヽ }. ：.,' ::（ :::} } ﾍ /
し ））. ：:i `.-‐" J´（（
ｿ ﾄﾝﾄﾝ ｿ ﾄﾝﾄﾝ
56:KingOfUniverse ◆667la1PjK2
07/04/15 19:43:28
talk:>>55 どの国だよ？
57:１３２人目の素数さん
07/04/15 19:57:08
情報処理試験なんじゃないか。この週末にあった。問題みていないけど。
58:１３２人目の素数さん
07/04/15 23:36:11
>>56
hBDZHA7M2tkYDHelnmrQlnfTLlV0VF4GhHNCwGnjyKs6R6q1CjnlXMk4881ZWjivf7HTHuGF6lt6XMV7olkYNIHi6F88YnCI4yNL89suUIC8UHVYnTA8zgLzkjywBLr7oCaz4zom5dj2R14IqYXZmuGTVNmueFJAlJzsKmcSngyrG6jOWqUApIkhF9qHvhUAkzEiMm6U
VQXU1SLqrLB4y2Hmq7X1DrCPY21UK9TV21aVzrdBsdM8iGCKb0ptqBWiNOeybvDaBGMo9340W2MVkvhxlgGuvbQPu9yfEXgO86g4CcZrhv5a0uko29RphO8HHWxNzJ047ZyBS1lpILXW7zgZbXYFCEHD7sb9rwgFkvio3eB0aUFnsJ9LXetSZBk2tj1mVZ1ebVRwHl83
phtYpwcNQOl1jDp99ksOHeBwkmJka0o4HQeICIvqnremFe4xoBUIob8rAw2DiRhibHsEQjgx6kWMvGspnU7creAaKEP63yaAOWtN8RsTINS9FfVFvjEju1uP7YIu9TB5H1gyfZl7EG7mwtVa07nJejpYt0fvs7OCkKl4XZUfkXH8PLGrKUuDykhJwk1Ah24DncGT2sVu
dwiuEJTz4LhgyO8QZezvLippsBMC6l47evLXk0jzvLNbxsaGxAFKh38IsUoZLsI7vUeFS1tMTiHhPMIbnwZ8PJHQ78yjfpdjBr9xaIcdpNHx4MunCiHWmgMQPpm0cWpITMWw3jVoyvr6KiIgEvnKKCK91ziVuLRBLUuBS3MyuX1AmlFdPZ8AHpTqb5sd31xGoJfQ9vP9
40usGfIXkLLx5vtssItYi93Qqb7HBN8xpMhJG0vlA66rLhzZPu09kHK3KGDSjquTVCCEXloGXHdJtH3HIs38ioC69KS3leNoumjE0kZwETjzHgdN0GuwuYszbSUPPTWcn0kcljYj0SotGJgF4IXJJfw9zxxc2RizpuFXBqTc7bKDlTPmLKVg5FEbzpc192c8BenJl7QZ
HPoRuJuPFqPMcG1Ho9Jk38ADwa5ZlxFZd6uM5x33aWzI2bJCZdwDd2gtAerkc9Cdmxo0pq6Bf6VnayTsMB0X5qqOLSRxxRFGJQlcQJ5FhXpvGWjKCJZfj94yUFC88OnXhbAGmeMitNOxIK586BHnguiIyteVhy1yQjRn5Uh4LJiT3kuJy5LLfPqBfvpUP3xeO8cnCpaN
hitpAesSET54eQQruWsphPvd0rF6i7vaz2acviVAkQswK1GcwSVVGgcYZY2prfsoBv2jL26YHAgiYGxl1DzmRu2XLWCqd9U5He7ld7tk521tu0ucKqEfI21f59aqEAaRA4hfhoKLOZWGAXQ0U48T5qidS5aDViO1hnn5fPkYLtrsJWbGZHGhn575cyCcYAsOhURRO3m0
59:１３２人目の素数さん
07/04/16 05:04:29
＞文書のディジタル署名を行う
これ本物の問題文？なんか変だね
60:１３２人目の素数さん
07/04/18 21:24:15
「公開鍵暗号を用いてデジタル署名を行う…」
RSAとかが念頭にあるんだろうけど、なんか変じゃない？
暗号と署名はあくまで別機能だろと。
61:１３２人目の素数さん
07/04/18 21:54:30
>>60
そっちは別にいいんでないの？
「文書の署名を行う」という表現が気になった
「文書に署名する」か「文書の署名を生成する」じゃないかと
でもぐぐったら「調印文書の署名を行う」みたいな表現がいっぱい出てきた・・・そうなのか
62:１３２人目の素数さん
07/04/18 23:34:15
「調印文書の署名を行う」これは現実で、紙に印を押す際に用いられているんじゃないの？>>61
電子署名とは別物の気がするが。
63:１３２人目の素数さん
07/04/19 07:15:18
APOP破りが話題になてるようです
URLﾘﾝｸ(fse2007.uni.lu)
64:１３２人目の素数さん
07/04/20 10:10:41
APOPじゃ弱いんだろうなあとは思ってたが、多くのispはAPOPしか提供してなかったし、逃げ場がなかった。
酷いもんだ。
65:１３２人目の素数さん
07/05/03 11:13:34
格子で有名な Nguyen が7日に電通大で講演を行うそうです
以下コピペ
日時：平成19年5月7日（月） 13:00-15:00
会場：総合研究棟306室
講演者：Dr. Phong Q. Nguyen (Ecole Normale Superieure, France)
タイトル： Hermite's Constant and Lattice Algorithms
概要: Lattice algorithms are arguably the most popular
tool in public-key cryptanalysis. In this talk, we will
describe the main lattice algorithms, such as the
celebrated LLL algorithm. This will be done by highlighting
connections with a mathematical constant
introduced by Hermite in the 19th century.
66:１３２人目の素数さん
07/05/07 14:45:27
暗号の面白さって言うのは能力的に上の相手が敵であるときにも
解読されない方法についての情報技術なんだが。
暗号理論的な世界がどこまで普遍性を持つのかが気になる。
67:１３２人目の素数さん
07/05/08 02:02:02
>>66
意味分からん。まじで。
世界が普遍性を持つとはどういう意味？
曖昧すぎてわからん。
68:１３２人目の素数さん
07/05/08 03:20:51
数学でおｋ
69:１３２人目の素数さん
07/05/20 15:33:25
>>66
基本は暗号のレイヤ上だけで考えてるんだから、
普遍って言うのは大分無理があるんじゃないかな？とｵﾓﾀ。
ところで以前から思っていたんだが、
AESとかの最後のラウンドでmixcolums操作が行われないのって具体的にどんな意味があるんだ？
70:１３２人目の素数さん
07/05/22 01:17:39
ShiftRowsはやるのにMixColumnsはなぜ省くのかっていうこと？
71:69
07/05/22 12:53:43
>>70
そう。
最後を非線形変換で終わらせたいのかな？とか思ったけど俺のショボい脳ではよくわからんかったのよ。
何かわかるようだったら、教えてはくれないだろうか？
72:１３２人目の素数さん
07/05/22 20:36:23
俺も良く分らん。
まあ細かいこと気にすんなや。考えすぎると禿げるよ。
73:KingOfUniverse ◆667la1PjK2
07/05/22 20:52:29
人の脳を読む能力を悪用する奴を潰すのが先だ。
74:66
07/05/31 19:11:38
一方向性は宇宙全体に見ることができます。
力や権力を人は武器や法律を作ることで対処してきました。
こうした社会的人間的レベルから物理世界を含めて暗号のような
機能を持つものが構成可能な範囲はどこまで広がっているのだろう
という意味です。
75:１３２人目の素数さん
07/06/01 12:56:27
特定されるのを恐れずに、もっと活発に議論してくださいよ、暗号理論屋さんたちｗ
76:１３２人目の素数さん
07/06/01 23:12:18
>74
意味が分からん
関数を通した結果、情報量は保たれているのに計算量的に（現実的な時間で）戻せないのが一方向性
どうやってこれを社会的人間的に適用するの？
君のその書き方だと量子力学的経済学の人と変わらんよ？
77:１３２人目の素数さん
07/06/01 23:39:04
>情報量は保たれているのに
ここはいらないんジャマイか
78:１３２人目の素数さん
07/06/01 23:41:13
>>75
業界が狭いから、ちょっとマニアックなこと書くと特定されちゃうしなあ。
79:76
07/06/02 14:12:29
>77
ハッシュ関数のこと忘れてたorz
80:１３２人目の素数さん
07/06/08 22:26:27
今暗号論ってどうなってるんだ？
興味はあるけど専攻する価値があるのか怪しいんだよな～
81:１３２人目の素数さん
07/06/08 22:28:39
暗号論は死滅しますた
82:１３２人目の素数さん
07/06/08 23:02:49
この暗号が解けるかな？
ＷＩ＝１２
ＭＯ＝９
ＤＯ＝１１
※１２＝Ｄ
ＳＮ＝●
ＴＩ＝■
●－（■×２）＝▲
●▲■の数字はなんでしょ～？
83:１３２人目の素数さん
07/06/09 07:29:49
>>80
じゃあ、専攻しなきゃいいじゃん。
他にもたくさん分野はあるんだし。
84:１３２人目の素数さん
07/06/09 11:39:19
一番知りたいのが金になるかだ
85:１３２人目の素数さん
07/06/09 11:40:24
儲かりまっかー？
86:１３２人目の素数さん
07/06/09 11:56:50
>>82
暗号と虫食い算かクイズか何かを間違えちゃいないか？
87:１３２人目の素数さん
07/06/09 14:58:26
>>83
まあそうなんだが、他の専攻はもっとつまらなさそうなんだよな…将来性はあっても
まーゆっくり考える
88:１３２人目の素数さん
07/06/10 12:18:23
戦時中の暗号について(どのように暗号化されていたのか、解読はどの程度されていたのか)について
そこそこ詳しく書かれた本ってありますでしょうか?
89:１３２人目の素数さん
07/06/10 12:21:31
エニグマの本読んだ？
90:１３２人目の素数さん
07/06/11 00:15:21
>>80
私見だけど…
暗号やってて最もよかったと思ったのは、研究らしい研究ができた事、
暗号やってて最も虚しかったのは、思ったほど実社会の役に立たなかった事。
91:１３２人目の素数さん
07/06/11 01:43:25
>>89
読んでないっす
92:１３２人目の素数さん
07/06/11 18:27:56
>>90
やっぱあらかた出尽くしてるから研究だけで終わるような事しかないんですかね…
困った…
93:１３２人目の素数さん
07/06/13 01:33:41
【nビット】 Furer 乗算【n log n 2^O(log^* n)】
ｽﾚﾘﾝｸ(math板)
94:１３２人目の素数さん
07/06/13 11:30:33
開示したくない情報はセルごと"墨塗り" - 日立、電子署名技術の新成果発表
URLﾘﾝｸ(journal.mycom.co.jp)
95:１３２人目の素数さん
07/06/16 21:51:15
>>92
「流行ってる」と言われはじめてから随分たつからね。
暗号をやってて一番得したのは「暗号？なにそれ？」
って言われるような時代からやってた人たちだし。
今からおいしい思いをしたいなら「なにそれ？」って
言われるような分野を探したほうがいいかも。
とっくに流行ってるものに後から参入してきて、
頭の回転だけで勝とうとするのはあまり賢くない。
96:１３２人目の素数さん
07/06/16 22:37:05
>>88
サイモン・シンの「暗号解読」に結構書いてある。
97:１３２人目の素数さん
07/06/16 22:39:19
>>95
頭の回転が良い人は遅れて参入しません
98:１３２人目の素数さん
07/06/16 23:02:58
自分で頭の回転がいいと思っている人は結構参入する。
99:１３２人目の素数さん
07/06/16 23:18:35
なあ田んぼ一反３００坪だよな。つまり田んぼの周り一周走ると２ｋｍ走った事になるが間違ってる？
100:１３２人目の素数さん
07/06/17 12:03:30
300坪≒300平方ヤード＝15ヤード×20ヤード
15ヤード＋20ヤード＋15ヤード＋20ヤード＝70ヤード≒63メートル
だと思うのだが。>>99
101:１３２人目の素数さん
07/06/17 12:05:13
>>99
たんぼの形で違ってきます。
円形だと最少です。
102:１３２人目の素数さん
07/06/17 12:12:18
300坪≒300平方ヤード
の部分がかなり間違ってる。
1坪≒3.305785㎡
1平方ヤード≒0.83612736㎡
田んぼ一周の長さは
((3.305785×300)^0.5)*4≒125.967ｍ
2キロ走りたければ16週。
103:１３２人目の素数さん
07/06/17 12:16:58
円形なら
((3.305785×300÷3.14159265358979)^0.5)*2*3.14159265358979≒111.636ｍ
これで2キロ走りたかったら18週って所か。
104:１３２人目の素数さん
07/06/17 12:18:17
総突っ込みカワイソスｗｗｗ
105:１３２人目の素数さん
07/06/17 12:19:03
たんぼの形によっては一周で2Kmになります。
106:１３２人目の素数さん
07/06/17 12:27:11
円形のたんぼなんてどこにあるんだ？
107:１３２人目の素数さん
07/06/17 12:28:56
990平方メートルで一周 往 復 2キロか。
細い田んぼだな。
108:１３２人目の素数さん
07/06/17 12:29:45
ギザギザ形のたんぼなら一周１０Ｋｍでも可能です。
109:１３２人目の素数さん
07/06/17 12:32:15
幅20センチに満たなかったら田んぼとは言えなくなってくるぞｗｗ<<一周10キロ
110:１３２人目の素数さん
07/06/17 12:34:12
お前ら、暗号の話より乗りがいいじゃねーか。
ちゃんと研究してるのか？
111:１３２人目の素数さん
07/06/17 12:34:39
寧ろ、歩く部分が一周10キロなら田んぼとしての機能を何一つ果たさないような気が。
112:１３２人目の素数さん
07/06/23 19:44:47
田んぼ型強力暗号
113:１３２人目の素数さん
07/06/26 07:25:50
>>112
アルゴリズムの伝授キボンｗｗｗｗｗｗ
114:１３２人目の素数さん
07/06/29 02:02:26
age
115:１３２人目の素数さん
07/07/06 01:24:20
津田塾大学数学・計算機科学研究所報の26号と28号に、
「戦中日本暗号解読史における数学者の貢献」、「第二次世界大戦と高木貞治」
というマニアックな論文が収録されている。
面白くはないが、他書にはない独特な論文だ。
著者の講演を聞くためだけに、藤原正彦が津田塾のシンポジウムに来ていたことは、
その筋では有名だ。
数学板の人なら良し悪しがわかるのだろうが、俺には数学史の素養がないのが残念だ。
116:１３２人目の素数さん
07/07/06 10:47:24
FOCS 2007の論文リストｋｔｋｒ
URLﾘﾝｸ(focs2007.org)
CanettiらのCryptography from Sunspotsって気になるな
117:カカロフ
07/07/06 10:49:09
大道廃れて仁義有り。（老子）: 改正前の教育基本法の「教育」は、「education」 = 「学び教える場（学び場）」の意味という説
URLﾘﾝｸ(kakalov.cocolog-nifty.com)
118:１３２人目の素数さん
07/07/08 15:57:02
AES は連立一次方程式になるので、解読可能と聞きましたが、
大丈夫ですか？Mac の暗号化disc image にエロ画像おいてるんですけど
119:１３２人目の素数さん
07/07/13 20:56:51
ファイルにパスをかけるフリーツールで完全暗号のツールはありますか？ラプラスやWinRARは(全角文字など入れて少し長めのパスを設定しておけば)完全暗号でしょうか？よろしくお願いします。
120:１３２人目の素数さん
07/07/13 21:12:03
完全暗号の定義よろ
121:１３２人目の素数さん
07/07/13 21:17:07
ワンタイムパッドなら完全じゃね？
122:１３２人目の素数さん
07/07/14 22:02:51
>>119
何かを知りたい気持ちは分からんでもないが、多重投稿はやめれ。迷惑だから。
ｽﾚﾘﾝｸ(tech板)
123:１３２人目の素数さん
07/07/17 12:55:34
>>119
暗号化するファイルと同じサイズで絶対に盗聴されないファイルを使ってワンタイムパッド
124:１３２人目の素数さん
07/07/17 23:07:37
同じサイズで絶対に盗聴されないなら原文を送れよ
125:１３２人目の素数さん
07/07/18 22:04:04
ところで、DH鍵交換を何回も行ってOTP用の鍵を作るってのはだめなの？
素数Pを大量に用意するのは大変だろうけど、乱数a,bはMTなんかから適当に持ってきて
K=(α^ab mod p) mod 2^256
とかで固定長の乱数を共有して、OTP
126:１３２人目の素数さん
07/07/19 09:38:43
FUN 無線LAN 乙
127:１３２人目の素数さん
07/07/19 12:57:26
完全暗号の定義がわからないが、情報理論的に
安全と言う意味であれば、
> ところで、DH鍵交換を何回も行ってOTP用の鍵を作るってのはだめなの？
はDDH仮定におちるのでダメ。
DDH仮定を認めるのであれば素直にCramer-Shoup。
128:128
07/07/19 21:01:11
128 = 2^7
129:129
07/07/19 22:25:09
129=3*(3*(3+3*3)+5)
130:１３２人目の素数さん
07/07/19 23:07:45
>>115
読んでみた。
あの論文の良いところは、陸軍暗号学理研究会誌第一号其の他を引用して、
「偉い数学者の方々が熱心に暗号研究をしたんだ」という辻井教授や藤原正彦の俗説を、
論破しているところにあるな。
131:１３２人目の素数さん
07/07/21 03:50:37
>125
MTは暗号学的な疑似乱数生成器ではないので単純に乱数生成器として使うのは宜しくない。
そういえば今度のSACにMTを利用した暗号が通ってる。
やっぱり強引に非線形にしてるの?
132:１３２人目の素数さん
07/07/22 17:53:00
MTの擬似乱数のRD5ハッシュ取るとかすれば非線形になりそうな気が
133:１３２人目の素数さん
07/07/22 18:03:55
for(i=0;i<100;i++)
MD5(i)
これでも出力は非線形になりそうな気が
134:１３２人目の素数さん
07/07/23 08:05:15
まさにランダムオラクル
135:１３２人目の素数さん
07/07/24 12:52:04
125 の本質的な問題は、なんとなく安全そうな
共通鍵を用意してから、とにかく「最後にOTP」を行えば
完璧な安全性を持っていると勘違いしているところだろう。
136:１３２人目の素数さん
07/07/25 21:03:32
Pairingはどう？
137:無知
07/07/26 12:40:28
URLﾘﾝｸ(web1.nazca.co.jp)
これってすごいの？暗号化のすごいツール使いたいんだけど。高度な。
138:１３２人目の素数さん
07/07/26 12:48:32
「すごい」の定義をよろしく
139:無知
07/07/26 14:27:06
>>138
比較的すごいやつ。とりあえずラプラスやWinRAR(←圧縮ツールだけど)よりすごいやつ。 より解読時間に時間かかりそうなやつ。
今の技術で最低数十年～数百年くらい解読無理のやつ(←長い鍵=パスが必要ならそのパスの例、短いパスでも解読により時間のかかる高度な暗号化技術を使ったものが理想だけど、
暗記できないほどの長いパスがあったほうが解読難しくなるというならその長いパスも人に知られないように暗号化したり、
そういうのを全部ひっくるめて総合してより解くのが難しい複雑な(今存在する中で優れた技術も適用されてる)暗号化・その仕組みを使ったツールが知りたいです。フリーウェアでありますかね。。)。
すごい暗号化、すごいアルゴリズム 今現在の技術で とくにすごいファイル暗号化ツールはありますか？
137みたいにメジャーではないものとかでも Winで使えて暗号化にかかる時間もできれば比較的少ないのがいい
日本語めちゃくちゃですが、伝えたいことだいたい解釈してもらえれば嬉しいっす。。
140:無知
07/07/26 14:31:59
「キー=鍵=パス」を暗号化するって間違いっすかね‥。短いものなら暗記したり、長いものはどこかにメモして暗記できるくらいの長さのパスかけておいたり？
その長いパスもそのままじゃ使えない、暗記できるくらいのカラクリ使ったり？(ラストに何かを追加するとか、○文字めに何か追加するとか？)
とりあえずすごい今あるツールの中ですごい暗号化技術のツール知りたいyo
141:１３２人目の素数さん
07/07/26 15:02:33
小学生か中学生って所だろうが、もうちょっとまともな文が書けないのか？
何がしたいのかもさっぱり理解できない。
とりあえずワンタイムパッドなら解読は不可能。
ファイルを暗号化するツールも多分あるだろう。自分で探せ
こんな下らない事を書く前に宿題終わらせろよ、屑
142:無知
07/07/26 16:47:38
>>141
いえ、高2ですw
理解できないのはあなたの能力不足。
とりあえずワンタイムパッドなら解読は不可能←これも説明足りないと思う。
ファイルを暗号化するツールも多分あるだろう←多分って言うかありますけど、パス圧縮できるものなら自分で書いたラプラスとWinRAR、仮想ドライブ作って全て暗号化するならトゥルークリプトとか。
だけど、個別ファイルの暗号化ツールはあまり話題ない感じなので聞き込みで探してる感じ。
「ワンタイムパッドなら解読は不可能。」とか言ってるけど、鍵(パス)がばれた時点で終わりですよ？
ワンタイムパッドを適用してるツールで、解読が不可能になる理論を簡単に説明して下さい。
143:１３２人目の素数さん
07/07/26 17:01:23
>>142
俺は>>141ではないけど、>>139-140では言いたいことが伝わらないのではないか。
高校生なら単に「すごい」という表現がどれだけ曖昧なものかは分かると思う。
例えば「解読にかかる計算量が～」など、その分野でふさわしい「すごさ」の表現がある。
144:無知
07/07/26 17:11:13
ちょっと論点ずれたのでもうちょい言うと、パスzipの解析は一般ユーザーの場合、解析ソフトで特定の文字で総当りで照合していきますが、
単純にそれだけなら、より複雑なパスにするだけで解読できないものになる。
総当りにしないでもファイル自体を調べてパス情報を解析する方法もあるかもしれない。
それができるツールだとしたら、どんな複雑なパスに設定しても解析する人によっては簡単に解析されてしまう。
パス技術において、単純に照合していくのみしか解析方法がないとするなら、解析技術としては照合スピードをあげることのみが早い解析の実現に繋がる。
(まぁ、半角英数字、全角文字、記号などいろいろ使えるので、記号など多く混ぜていれば解析はすごく難しくなると思いますが。)
暗号化された状態のファイルは、本当にあてずっぽうに、特定の文字の種類を決めたりして総当りで照合していく方法しかないというものなのでしょうか？
暗号化自体の技術がものすごく複雑だとして、それを解くには鍵(文字のパスワードを使ったり、他のファイル自体をリアル鍵[パス]にしてみたり)が必要ですよね？
鍵を文字列のパスワードにするって考え方が古いのでしょうか？複雑に暗号化して2つに分割して、さらに結合の際にパスを設定する、とかのほうがいいのかな‥。
自分にしか使えないように、暗号化するとしたらどういう方法がいいと思いますか？
145:１３２人目の素数さん
07/07/26 17:29:37
>>142
は？鍵が分かったら解読できるのは当然だろ。何を言ってるんだ？
鍵が分からないからこそ暗号解読って分野があるんだろ。鍵が盗まれても安全な暗号なんて存在しない。
ワンタイムパッドの原理なんて書く気にもならん。検索すればすぐ出るだろう
ファイルを暗号化する～、ってのはワンタイムパッドを使った物の話だよ。ファイルの暗号化にワンタイムパッドを使ってるのなんてそう多くはないだろうからな
146:１３２人目の素数さん
07/07/26 17:32:04
>>144
単純に自分で使える最高精度の暗号を何重にもかければ？
147:無知
07/07/26 17:49:49
>>145
どうも。やはりどんなに優れた暗号化技術でも鍵がばれた時点で終わりってことですね。
その鍵は文字列にする必要もないので、ファイル+文字列にしといて、ファイルは別の場所に保存して、そのファイルが見つかってしまった場合でも(まぁ暗記できる)複雑な文字列のパスを設定しておけば少しは解読が難しくなるという感じですかね。
その、ワンタイムパッドとか(バーナム暗号とか？)で複雑に暗号化された(鍵の嵌められていない)暗号化ファイルというのは、
暗号処理で複雑にされているので、元もとのファイルの用途の機能は0と考えていいのでしょうか？つまり、
テキストとかを動画とかをワンタイムパッドなどで圧縮したとして、その鍵の嵌められていない暗号化ファイルをどう調べたとしても、
テキストに書いてある文字や、動画の一部を見たりすることは不可能と考えていいでしょうか？それがテキストや動画のファイルということも判明しないのでしょうか？
なんかめちゃくちゃな感じですみません。
148:無知
07/07/26 17:51:19
テキストとかを動画とかをワンタイムパッドなどで圧縮したとして
→テキストとか動画とかをワンタイムパッドなどで暗号化したとして
です、すみません‥
149:１３２人目の素数さん
07/07/26 21:49:09
えーとな…まずは、暗号なんちゃらより会話を学ぼうな。そっちのほうがよっぽど役に立つぞ。
150:１３２人目の素数さん
07/07/26 23:23:23
>142
シャノンの論文読めというのは無しとして
情報量の教科書にでも乗ってんじゃないの?
>147
ワンタイムパッド≠バーナム暗号
151:１３２人目の素数さん
07/07/27 00:18:03
いつから暗号文を書き込むスレになったんだ？
152:無知
07/07/27 09:06:53
>>150
>>150
どもっす。「シャノン 論文」で検索したら
ウィキでクロード・シャノンさんが引っかかりました。
URLﾘﾝｸ(ja.wikipedia.org)
自分が興味あるのは、具体的な暗号化の内容(技術)より、指摘された通り、既にワンタイムパッドなどの解読不可能な完全暗号？の技術があると仮定して、
その暗号化を解く鍵と、暗号化されたファイル自体の関連性を焦点にして、どのようにしたら、144の最後に書いた通り、「自分にしか使えないように鍵と暗号化ファイルを管理できるか」ということです。。
返信はもらえませんでしたが、147に書いた、「鍵の刺さっていない暗号化ファイル自体は機能0のファイルか？」というのもおそらく、ワンタイムパッドは完全暗号ですごく複雑に暗号化されているということだと思うので、そうなんだと思いますが、
まぁ暗号化技術＝基本的に第三者に使われるのを防ぐためのもの、だと思うので、鍵の技術も一緒に考えなくちゃいけないものなんじゃないか、と‥。
でもこれは、今自分の知りたいファイル暗号化のみの話で、通信技術とかにも暗号化とか使うと思うので、鍵を使って解除するような暗号化の仕組みが必要ないってことももちろんあるんですかね。。暗号化っていうのは。。
もちろんワンタイムパッド≠バーナム暗号なんてことは分かりますよw どちらの技術も完全暗号と聞いた覚えがあって、その技術で暗号化されたファイルは「元もとのファイルの用途の機能が0になるかどうか」ということが知りたくて質問したので。。
153:１３２人目の素数さん
07/07/27 10:05:50
>>147
＞元もとのファイルの用途の機能は0
＞テキストとかを動画とかをワンタイムパッドなどで圧縮
＞鍵の嵌められていない暗号化ファイル
の意味はよくわからないけど
＞暗号化ファイルをどう調べたとしても、
＞テキストに書いてある文字や、動画の一部を見たりすることは不可能と考えていいでしょうか？それがテキストや動画のファイルということも判明しないのでしょうか？
はい
154:１３２人目の素数さん
07/07/27 13:42:30
＞ワンタイムパッドは完全暗号ですごく複雑に暗号化されて
「完全暗号」の定義にもよると思うが、まぁOTPが完全暗号だというのはいいとして
お前OTPの暗号化方式知らないだろ。複雑どころか滅茶苦茶簡単なんだが。
＞それがテキストや動画のファイルということも判明しないのでしょうか？
判明する場合もある。例えばファイル名からばれたり。（「記念写真」て名前のファイルが音楽ファイルなんて事は普通ないよな？）
155:無知
07/07/27 19:42:08
>>153,154
ども。
ワンタイムパッドはここでちらっと見ましたが、文字列と鍵を剰余演算して暗号文を作る、とありました。仕組み自体は簡単でも全体を鍵と剰余演算して結果的には複雑といえるので、解けないってことなのでは。。(違かったらすまそ)
URLﾘﾝｸ(ja.wikipedia.org)
そりゃ、暗号化したいファイルは通常ファイル名も変更すると思いますよ。。(少なくとも自分の場合は、ファイル名を伏せるために一度複数のファイルor単一のファイルを圧縮して、ファイル名を変更したあとに、それをパス圧縮するようにしてます。。
そうすればパスが解析されない限り、1つ下の階層の最初に圧縮したファイル名のみしか漏れる情報がないので。。もちろんファイル自体は何のファイルか漏れることはないと思います。)
ちょっと今生活もやばいんで(超寝不足＆金欠になりそう)、ワンタイムパッドなど使っているツール探しとか、鍵の付け方、鍵の管理法とか、このあとはちょっと自分でやってみようと思います。スレ違いなのにいろいろ付き合ってもらってすみませんでした。
156:無知
07/07/27 19:51:06
御礼言い忘れました。ありがとうございました。
157:１３２人目の素数さん
07/07/27 21:31:09
同じ内容の通信を何度も傍受すれば解読できるから
OTPも言うほど完全ではないけどな
158:１３２人目の素数さん
07/07/28 08:24:19
> 157
何度も同じ鍵を使ったらそれはもうOTPではない。
159:１３２人目の素数さん
07/07/28 10:14:53
>>158
鍵が毎回違っても通信内容が同じならバレる
160:１３２人目の素数さん
07/07/28 10:18:44
>>159
どうやって？
161:１３２人目の素数さん
07/07/28 13:06:39
>>159
通信する前の平文が同一である事の判定法を是非教えて欲しい。
162:１３２人目の素数さん
07/07/28 13:16:48
>>155
剰余演算も確かにするが、それはn進法の下1桁を求めるために使うのであって、
演算そのものはシーザー＝カエサル暗号とあまり変わらない。違うのは1文字ごとに鍵が変わるって程度か。
鍵を作るところと鍵を送信するところを除けば、日本の小学校2年生でもできる内容。（なんせ必要なのは足し算と引き算だからね。）
163:162
07/07/28 13:25:15
もう一つ言うと、解けない理由ってのが「適当な鍵で復号化してもちゃんとした文になってしまう」って点だな。
例えば平文が[This is a pen.]の14バイトだとして、それを暗号化したら
同じく14バイトの[g6SYrpJFvU2Wc5]てなのになったとする。でも鍵が分からないと、
[This is a car.]が原文なのか、[This is the AI]が原文なのか、はたまた[wKGDU8Q2rHwnYp]みたいなのが原文なのかは分からない。
だから鍵が分からないと解けない。
164:１３２人目の素数さん
07/07/28 13:33:45
>>160
鍵が完全にランダムなら何度も傍受する事によって平文の統計的偏りがわかる
鍵が完全にランダムじゃないならそもそも"弱い"暗号になってしまう
>>161
KPAは暗号分野では有名な攻撃方法の一つ
165:１３２人目の素数さん
07/07/28 14:04:29
＞鍵が毎回違っても通信内容が同じならバレる
＞鍵が完全にランダムなら何度も傍受する事によって平文の統計的偏りがわかる
それはまた面白いことを聴いた。平文の統計的偏りが分かるとは直感的に思えないのだが、
分かったところで何語で書かれているかが判明する程度だと思っていたからな。
内容まで分かるとは驚きだ。
ところで既知平文攻撃ってOTPに適用できるの？
166:１３２人目の素数さん
07/07/28 18:08:31
>>164
もうちょい詳しく
KPAでなんの安全性を破るという話？
167:１３２人目の素数さん
07/07/28 19:14:08
「完全にランダム」の定義って、予測不可能性と再現不可能性のどっち？
まさか無作為性があれば完全にランダムって訳じゃないだろうなｗ
168:１３２人目の素数さん
07/07/28 20:09:00
＞鍵が完全にランダムなら何度も傍受する事によって平文の統計的偏りがわかる
そんなことはありえない。もしそうなら、「十分に圧縮可能なデータ列は、暗号化しても十分に圧縮可能である」という事が言えてしまう。
169:169
07/07/28 20:28:26
√(169) = 13
170:１３２人目の素数さん
07/07/28 21:23:03
>>164
それってどっかの文献とか教科書に書いてあること？
それともあなたが独自に見つけたこと？
171:１３２人目の素数さん
07/07/28 21:29:31
>鍵が完全にランダムなら何度も傍受する事によって平文の統計的偏りがわかる
で、その統計的偏りとやらに対して平文を一意に対応させる方法は？
172:１３２人目の素数さん
07/07/30 11:34:11
自分は158だが、164には逃げずに是非答えてもらいたい。
今から0か1のどちらかを、鍵(1bit)をランダムに変えながら10回
暗号化する。平文は固定のままだ。平文を1/2より有意に
高い確率で求める具体的な手順を示してくれ。
暗号文: 1, 0, 1, 1, 0, 1, 0, 1, 0, 0 (合計10個)
173:１３２人目の素数さん
07/07/30 12:02:58
鍵がランダムでなければ弱くなる とは必ずしも言えない
なぜならば、1つの鍵に2通り以上の意味を含ませた
マルチプルキーゲートエンコーディング(MKE)が有り得るからだ
通常の鍵暗号においては、シングルキーゲートエンコーディング(SKE)
が取られるので、ランダムでなければ弱くなる
しかし、公式にはSKEにみせかけておいて、
実際はMKEな方式の暗号化がとられれば、
この事実を知っている人間ならば、すべてのキーゲートを
解きほぐすことで、弱体化が図れるものの、
そうでない人間からは、複雑に絡み合った暗号のままであり、
たとえ公式に確認できる1つのキーゲートの、ランダム性の脆弱化
をついて、暗号を解けたとしても、それは氷山の一角に過ぎず、
総キーゲート数30、公開キーゲート数1、ならば、
公開キーゲートのランダム性の脆弱化をついて解けた平文のみが
出回ったとしても、水面下で29の機密情報が解かれないまま
闇にまぎれることになる
174:１３２人目の素数さん
07/07/30 13:51:50
面白いけど
それはそれでまた別の安全性の話ですね
175:１３２人目の素数さん
07/07/30 15:51:37
統計的な偏りが分かるんだったら必要な回数繰り返せば平文が得られるだろ
どうやったら偏りが分かるのか知らんが
176:１３２人目の素数さん
07/07/30 18:07:58
また登場してすんません。
>>162,163
返信ありがとうございます。
頭悪くてよくわからないのですが‥。
カエサル暗号＝文字をずらす単純なシフト暗号↓とありました。
URLﾘﾝｸ(www2.cc.niigata-u.ac.jp)
＞解けない理由ってのが「適当な鍵で復号化してもちゃんとした文になってしまう」って点だな。
＞例えば平文が[This is a pen.]の14バイトだとして、それを暗号化したら
＞同じく14バイトの[g6SYrpJFvU2Wc5]てなのになったとする。でも鍵が分からないと、
＞[This is a car.]が原文なのか、[This is the AI]が原文なのか、はたまた[wKGDU8Q2rHwnYp]みたいなのが原文なのかは分からない。
＞だから鍵が分からないと解けない。
の「でも鍵が分からないと、[This is a car.]が原文なのか、[This is the AI]が原文なのか、はたまた[wKGDU8Q2rHwnYp]みたいなのが原文なのかは分からない。だから鍵が分からないと解けない。」
あたりがよくわかりませんでした‥。
まず、短い鍵でも長い鍵でも[g6SYrpJFvU2Wc5]というような複雑な文字列になるのでしょうか？(ならないと困ると思いますが‥) また、長い鍵の場合、鍵自体の解読が難しくなるということだけでなく、原文の暗号化自体もより複雑になるのでしょうか？
そして、原文に近い「[This is a car.]や[This is the AI]」は、「[wKGDU8Q2rHwnYp]」のような意味のない羅列としての結果が星の数ほどあるうちの1例ということでしょうか？
そうではなく、少しの解析結果で、「[This is a car.]や[This is the AI]」のような原文に近い文が得られるというなら、
つじつまの合った英語や日本語の文が正解だと通常は分かってしまうと思うので、早い段階で正解に近いものがバレてしまう、と思ったのですが‥。
a penの部分がa carやthe AIに変わったりしてますが、やはり、そういうのは星の数ほどある対象の一部で、原文に近いものが早い段階ですぐに解析結果の対象となってしまうわけではないのでしょうか？(もしすぐに対象になるとしたら非常に困ると思うのですが‥。)
177:176
07/07/30 18:08:34
わかりにくくて＆ずれたこと言ってたらすみません‥。 また、ラプラスのツールがOTPかどうかとかは調べることなどは出来ますか？暗号化されたzipや通常のzipの形成？構造？をよりよく見れるエディタみたいのはあるでしょうか？
(まずzipの)暗号化の仕組みとか、暗号化の作りとかが直に見れるエディタみたいのがあれば、と思ったのですが‥。
178:178
07/07/30 18:29:39
1+7=8
179:１３２人目の素数さん
07/07/30 19:17:12
162じゃないけど
>>176
>まず、短い鍵でも長い鍵でも[g6SYrpJFvU2Wc5]というような複雑な文字列になるのでしょうか？
>(ならないと困ると思いますが‥)
>また、長い鍵の場合、鍵自体の解読が難しくなるということだけでなく、原文の暗号化自体もより複雑になるのでしょうか？
「鍵自体の解読」って何だ？は別として
例えばもっと簡単に，メッセージも鍵も同じ長さの数字の列で，暗号化は各桁同士の足し算とする．
例1：平文が22504，鍵が01673ならば，暗号文は23177
例2：平文が12345，鍵が00000ならば，暗号文は12345
で，鍵がわからない状態で，暗号文"73529"が渡されたとする．このとき平文は何だ？と言われても，
鍵が00000ならば，平文は73259
鍵が00001ならば，平文は73258
・・・
鍵が99998ならば，平文は84360
鍵が99999ならば，平文は84369
ということまでしかわからない．
どの平文も同程度に元の平文の可能性があるということまでしかわからない．
>そして、原文に近い「[This is a car.]や[This is the AI]」は、
>「[wKGDU8Q2rHwnYp]」のような意味のない羅列としての結果が星の数ほどあるうちの1例ということでしょうか？
そう．しかも星の数ほどの結果の中には
[I am Japanese.]や[He has the pen]みたいなものまで含まれる．
180:162
07/07/31 01:47:46
調べてないが、zipのパスはOTPではないはず。
なぜなら、OTPで暗号化したら平文を得るのに、平文の2倍の量の情報が必要になるため。
「平文＋同量の乱数列」を圧縮して、平文よりファイルサイズが激減するなんてことはおかしい。
なぜならOTPで使えるような乱数列は非常に圧縮しにくいか、あるいは単に圧縮できないのだから。
バイナリエディタでヘッダを調べる程度なら前情報何もなくてもなんとかなりそうだが。<<zip
181:１３２人目の素数さん
07/07/31 09:21:25
なんて乱数列を保存する必要があるのよ
182:176
07/07/31 11:36:36
>>179
ありがとうございます
「鍵自体の解読」→「鍵自体の解析」っすね‥。zipのパス解析ソフトの検索のようにあてずっぽうに当てはめていく感じのことについてです‥。
足し算の仕組みとか、OTPは(今のところ？)完全暗号というのはわかったのですが、「鍵が99998ならば，平文は84360 鍵が99999ならば，平文は84369」←ここがちょっとわからなかったっす‥。16進数ではないなとは思ったのですが。。
>>180
ありがとうございます
OTPは単純に(テキストファイルや動画ファイルなどどんなファイルに対しても？)2倍の情報量が必要になるのでしょうか？
「平文＝テキストファイル？」とか思ったのですが、
「動画や音声の重いファイルなども、データにすると全て平文のような扱い=ファイルと同サイズ分の乱数列が必要になる」ということでしょうか‥？
(それとも、そのようなファイルには、鍵の乱数列を全体の平文的な要素のみに足すだけで、ファイル全体に暗号化の効果が出せるので、同サイズ分の乱数列は必要ないのでしょうか？)
あと、今の技術では(OTPで暗号化されている)ファイル自体を調べて鍵を解析＆復号化しようとする方法はなく、普通のzipのパス解析ソフトのようにあてずっぽうに照合していく方法しかないのでしょうか？
バイナリエディタは00とか01とかの行列で構造が見れるみたいですが、知らない人が見てもあまり勉強にならないですかね‥。
zipのパスはOTPでないのは決定的として、比較的簡単に？解析されてしまう技術だとしたら、少し精通した技術者の人たちには簡単にパスを解析されてしまったりしますかね‥。
(そうだとしたらパスzipじゃ安心できないですし、OTPなど使われたツールを探して使ったほうがいいですかね‥)
183:１３２人目の素数さん
07/07/31 22:35:34
横レス。
>182
>179は10進OTP
下一桁だけみると
8 = 8+0 mod 10
8 = 9+9 mod 10
共有している乱数列（共有鍵）が違えば暗号文も違う。
>OTPは単純に…
OTPの場合、ファイルの長さと同じ長さのの乱数列でマスクする。
鍵=マスク用の乱数列
ストリーム暗号（バーナム暗号）で一つの鍵からファイルサイズ分の乱数列を作るんだったら、
鍵≠マスク用の乱数列
ちょっと調べたところWinZipだとAESを使っているらしい。
URLﾘﾝｸ(www.winzip.com)
184:162=tech/1180280982/の83
07/07/31 22:37:29
>>182
OTPは鍵の長さが平文の長さと等しくて、かつ暗号文の長さと平文の長さが等しいから
復号化に必要な情報の量⇒暗号文の長さ＋鍵の長さ＝平文の長さの2倍⇒平文の2倍の情報量
鍵の長さ＜平文の長さ の時OTPは成り立たない。だから同じサイズ分の乱数列が必要。
今の技術ではってか、OTPは鍵が分からないときに正しく復号化することは不可能であることが
数学的に証明されているわけだが。
勿論あてずっぽうにやっても意味無い。
そもそもその試した鍵が合っているかどうかを確かめることができないからな。
（プレーンテキスト以外の）同じ拡張子のファイルなら、大抵、最初の数バイトは一致している。
その一致の多い部分をヘッダと言って、ここの値を調べるといろいろなことが分かる。
最初の2バイトがBMだったらビットマップだなとかMZだったらWindowsの実行ファイルだなとか。
＞比較的簡単に？解析されてしまう技術だとしたら、少し精通した技術者の人たちには簡単にパスを解析されてしまったりしますかね‥。
だからさっきからずっとそう言っているのだが・・・。
で、もしそんなことがあるならとっくの昔に「5分で解除します」的ソフトが誕生してる。
185:162
07/07/31 22:42:13
で、今現在をもってOTPが一般的には使われないのは、
もしOTPに任せても平気なら最初っから出る幕が無いんだよな。
平文と同じ大きさの鍵（ファイル）を安全に輸送できるなら、
最初っから平文を安全に輸送しろって話なんだ。
もちろん、4重5重にOTPによる暗号化をかけて、暗号文＋いくつかの鍵をすべて別ルートで送るとか
そういう安全性の図り方はあるけど。
186:１３２人目の素数さん
07/07/31 22:47:30
そこまでして守りたい182の情報に興味が向いた今日この頃。
つーか、マジで何がしたいのよ
187:１３２人目の素数さん
07/07/31 23:01:18
というか176はネットに頼ってないできちんと文献にあたってこい。
あとそこまでOTPにこだわるならきちんと自分で暗号化（復号）を試してこい。
できません、って言うならそもそも話のスタートラインにすら立ててないってことだし
きちんとできたのであれば自分がどれだけ検討違いのことを言っていたのかも理解できるはずだからさ。
188:１３２人目の素数さん
07/08/01 14:47:46
確かに176は暗号技術どころかコンピュータサイエンスのイロハも分かってないみたいだし
入門者用の文献でもまず読んだ方が話が早いと思うぜ。
URLﾘﾝｸ(www.hyuki.com)
とか読んでみたらいいと思う。
189:１３２人目の素数さん
07/08/01 22:49:24
次の暗号を解読してください
「12 150 50 113 86 121 68 30 160 38 68 86」
公開鍵：E＝１２７、N＝１８７
（解読はアスキーコードで）
わからん・・・
190:１３２人目の素数さん
07/08/02 00:09:35
111 109 97 101 103 97 115 117 107 105 100 97
何で答えがこれかは自分で考えろ。
191:１３２人目の素数さん
07/08/02 00:41:26
>>190
お前が好きだ
はわかります。
公開鍵とかが全くわかりません。
192:182超時間ないのでまた明日・・
07/08/02 20:24:02
遅レスすいません‥
>>183
どもっす。
まだちょっとわからないのですが、ただ繰り上がり無視して、1の桁だけ計算した場合、
99998
+84360
73258
99999
+84369
73258
となったのですが、暗号文とは5と2の位置が逆で、1の位も9ではなく8になってしまうのですが、どう間違っているのでしょうか‥。
＞OTPは単純にファイルの長さと同じ長さの乱数列でマスクする。(鍵=マスク用の乱数列)
絶対2倍のサイズになるということですね‥。
＞ストリーム暗号（バーナム暗号）で一つの鍵からファイルサイズ分の乱数列を作るんだったら、鍵≠マスク用の乱数列
まだ調べ途中なんですが、ストリーム暗号[URLﾘﾝｸ(ja.wikipedia.org)に
「鍵ストリームとして完全なランダムシーケンスを採用すると、OTP(One Time Pad)となって情報理論的安全性を持つ。しかし、平文と同じ長さの乱数が必要であり、
OTPは広くは採用されていない。」とありました。自分で適当に長いランダムな鍵(乱数列)を考えて平文以上の長さにしたら完全暗号になるということですかね‥。
WinZIP(ラプラスやWinRARなど？)はAESを使っているということで、今ちょっと調べてる途中です。。
＞関連鍵攻撃により、256ビットのAES暗号の9ラウンド目までを解読可能。選択平文攻撃により、192ビットおよび256ビットのAES暗号の8ラウンド目まで、
＞128ビットのAES暗号の7ラウンド目までを解読可能 (Ferguson et al, 2000)。
とか書いてあったんですが、大丈夫ですかね。。
193:182超時間ないのでまた明日・・
07/08/02 20:26:04
URLﾘﾝｸ(ja.wikipedia.org)
には
＞信頼性の低い暗号アルゴリズムとは、暗号アルゴリズムのピア・レビューの過程で専門家により排除されたものをいう。
となっているのですが、
＞AES暗号か、CRYPTREC、NESSIEで選定された暗号アルゴリズムがとりあえず安全と言える。
となっていて、安全なのか安全じゃないのかわかりません。。
平文以上の長さの鍵を自分で考えるか、もしくはビットとかの問題で平文以上の長さの鍵を付ける事ができないのか。。
>>184
ありがとうございます
＞OTPは鍵の長さが平文の長さと等しくて、かつ暗号文の長さと平文の長さが等しいから
＞復号化に必要な情報の量⇒暗号文の長さ＋鍵の長さ＝平文の長さの2倍⇒平文の2倍の情報量
＞鍵の長さ＜平文の長さ の時OTPは成り立たない。だから同じサイズ分の乱数列が必要。
＞今の技術ではってか、OTPは鍵が分からないときに正しく復号化することは不可能であることが数学的に証明されているわけだが。
＞勿論あてずっぽうにやっても意味無い。そもそもその試した鍵が合っているかどうかを確かめることができないからな。
「OTPは鍵が分からないとどれが正解かもわからないもの」とわかりました。
今、調べて鍵は自分で平文以上のものを考えるものだとわかりました。。(もし自動で生成できるものでしたらすみません。。)
＞（プレーンテキスト以外の）同じ拡張子のファイルなら、大抵、最初の数バイトは一致している。
＞その一致の多い部分をヘッダと言って、ここの値を調べるといろいろなことが分かる。
＞最初の2バイトがBMだったらビットマップだなとかMZだったらWindowsの実行ファイルだなとか。
よくわかりました。ヘッダはメモ帳などで見れば見れるものですかね‥。OTPやバーナムで暗号化されたものはヘッダさえ見れなくなりますよね。
194:１３２人目の素数さん
07/08/02 21:18:55
自分の無知を棚に上げて人から知識を引き出してるんだから、最低限の礼儀くらいわきまえろよ、屑が
195:184
07/08/02 23:08:48
>>193
メモ帳でも最初の2～3バイトは正常に認識できる文字として読み取れることが多いが、
バイナリエディタの方が視認・識別できない文字に対応しやすい。(00と0aと0dと20の違いとか、黒い点とか四角とかになる化け文字のそれぞれの違いとか。）
バイナリエディタは個人的にTSXBINとStirlingを愛用しているが、BzとかFOXBINとかが使いやすいって言う人も居るだろうし
どれを使えとは言わんから、どれかを使う事を推奨する。
196:１３２人目の素数さん
07/08/03 10:17:12
>>192
あ、>>179で出した例の最後２つは計算ミスってた。すまん
＞AES
それから7年たってもフルラウンド版が解読されてないから
まあ大丈夫なんじゃないの？
197:１３２人目の素数さん
07/08/03 13:14:51
素人ですが、教えてください。
周期Nの疑似乱数で作った無限長の乱数列があったとします。
ここから、真性乱数を用いて間引いて作った乱数列は、疑似乱数ですか、真性乱数ですか？
私は真性乱数ではないかと思うのですが、疑似乱数だと言われました。よくわからない。
198:１３２人目の素数さん
07/08/03 13:21:57
そりゃ擬似乱数でしょ。元に偏りがあるんだから
199:１３２人目の素数さん
07/08/03 13:28:44
>>198
たとえば、平文と真性乱数のmodをとると真性乱数になりますが、これとどう違うのか教えてください。
200:193
07/08/03 18:33:30
書き込もうとしたらPC落ちて消えてしまいました‥
ウザくて長いんで断片的に見てください。。すんません。。
>>196
ありがとうございます
>>195
ありがとうございます。
具体的なソフトまで教えていただいてマジありがたいです。今度使ってみますね。
193の
＞信頼性の低い暗号アルゴリズムとは、暗号アルゴリズムのピア・レビューの過程で専門家により排除されたものをいう。
は
＞特にAESなどの暗号規格策定の際に、かなり有力なものが排除されている。
の間違えでした。
193の上のサイト「信頼性の低い暗号アルゴリズム」のE2の注2)などを見ると、
『E2は「頼性の低い暗号アルゴリズムのリスト」に米国NISTによって挙げられている、しかし
オリジナルのE2が10ラウンドまで解読できるわけではなく、安全性に関してのみ比較するならば、E2はAES(Rijndeal)と同レベルである』
とあり、AESは「安全性高い」というようなことが書いてありました。
でも、排除され「信頼性の低い暗号アルゴリズム」に認定された=安全性低い？というふうに書いてありました。
でも、「AES暗号の暗号アルゴリズムがとりあえず安全と言える。」と、安全性高いように書いてあったのでやはり高いのでしょうか。。
AESは「ブロック暗号」で、
URLﾘﾝｸ(ja.wikipedia.org)
多くのブロック暗号で採用されているラウンド関数のSPN構造とありました。
wikiでブロック暗号を見ると、「鍵長nビットに対して2nの計算量的安全性以上の安全性を有しない。鍵の全数探索で必ず解読可能。これは、ブロック暗号の鍵長を定める際に最も重要な要素の一つであり、
現在DES (56ビット) が推奨されないのもその鍵長の短さが原因のひとつである。」とありました。DESは1977年にできたものですが、AESなどの128ビットのものでも鍵の長さのmax値は短いのでしょうか？
wikiのブロック暗号のページに↓とありましたが、
＞ブロック暗号は、メインのスクランブラと拡大鍵を生成する鍵スケジューラから構成されているものが多い。
＞さらに、鍵スケジューラは鍵を入力として複数個の拡大鍵を出力し、スクランブラは複数のラウンドからなり、
201:193
07/08/03 18:34:23
＞個々のラウンドで拡大鍵を使って入力の置換・転置等を行う構成になっているものが多い。この構成の暗号をProduct cipher（積暗号）という。
＞また、ラウンドが同じ関数の繰り返しになっている場合にはIterated cipher（繰返し暗号）という。
＞ラウンド関数の主な構成法に、Feistel構造とSPN構造の２つがある。DES, MISTY1, CamelliaはFeistelで、AESはSPNの暗号である。
この「積暗号」と「繰返し暗号」では、同じ関数が使われている分、繰返し暗号のほうが精度低いのでしょうか。。
自分の入力する鍵から、乱数列や拡大鍵？が生成されて平文と合わせられて暗号文となるのなら、どんな長い(入力する)鍵を考えても、暗号化したもの自体の全ラウンド解析されたら、平文全て(&入力する鍵)が解析されるということでしょうか？
「入力する鍵」と「平文と組み合わせる乱数や拡大鍵？」の違いで、ストリーム暗号の場合は、「128bit程度の秘密鍵を用いて擬似乱数を発生させる(バーナム暗号の場合は真の乱数)」とあり、ブロック暗号の場合は「鍵を入力として複数個の拡大鍵を出力」とありました。
「＞ブロック暗号=鍵の全数探索で必ず解読可能」は、平文の長さくらいの鍵を使った場合、完全暗号に近づくのでしょうか？
暗号化されたファイル自体を調べる方法はなく、「全数探索」で入力した鍵を解析する方法しかないとしたら、入力する鍵をより複雑にすればいいとは思うのですが‥。
また、128ビットとかわからないのですが、ビットとバイトの違いを調べたら、8ビット=1バイトとありました。でも意味がよくわからないっす。
バイトは半角文字1文字。8ビットで1バイト。128ビットで16バイト？128ビットは2の128乗=3.4x10の38乗(340澗種類)らしく、それなら8ビットは2の8乗で256種類。こういうのは全部0と1のみの2進数の情報なのでしょうか？
(暗号化されたもの自体の情報なども全て0と1の2進数のみの情報‥？)
素数
URLﾘﾝｸ(ja.wikipedia.org)
今のところ見つかってる最大の素数は0が980万個であり、無量大数は0が68個なので、980÷68=無量大数が13000個分‥
202:193
07/08/03 18:35:46
数字0～9の10文字、アルファベットa～zとA～Zの52文字、全角(2バイト)の漢字の1万～1万5千文字くらい、＆記号とかで、2バイトの文字の種類はかなり多くなりますが、鍵から作られる乱数などは、
本当にそんな多い種類の漢字などに対応できるのでしょうか？(鍵が複雑な漢字でも、鍵から作られる乱数や拡大鍵は、全角文字は使わず半角英数字(orその他or0と1のみ？)で構成される情報‥？)
漢字や全角文字が全て同じ文字だと見なされてしまうとしたら、論外ですよね。。てか、本当に難しい漢字などを使ったとして、正しく(例えいくつかダブりがあってもちゃんと対応した情報を通して)暗号化されるのでしょうか？
もし漢字などを使って正しく暗号化できない場合、やはり半角英数字で長い複雑なものにすれば有効なのでしょうか？
数字0～9の10文字、アルファベットa～zとA～Zの52文字、合わせて62文字で、2バイトでは2文字なら62の2乗通りで3844通り。3バイトで3文字なら62の3乗通りで238328通り。
でも128ビットは16バイトなので、半角16文字分の情報量が限界？(という考え方は間違いでしょうか？)
下に書いてある、「ブロック暗号=(128ビットなら(2^128)の階乗通り(で、0と1のみを使って構成される？」(絶対間違えまくりで申し訳ないです)
もし漢字が有効だとして、2バイトで1万種類の文字があるとすれば、4バイトで2文字なので1万の1万乗、6バイトで3文字なので(1万の1万乗)の1万乗。
1万は0が4個で、現在の最大素数である0が980万個の数は、980万÷4で、4の2450000乗個0がある。4バイトの2文字で1万の1万乗は、(1万は0が4個なので)4の10000乗個0がつく《4×4×4×‥(9996回)‥×4 (個)》、
6バイトでは、4の10000乗個0がついたものに1万乗個0がつく。(勘違いしてたらすみません)
「OTPは必ず、平文以上の長さの鍵が必要(サイズ2倍になる)」ですが、その鍵はPCで乱数を生成するのでしょうか。(自分でキーボードをめちゃくちゃ打ち続けたりしたら時間がかかりすぎるのでないと思いますが‥)。
PCで作る場合、本当に世界中で何万年、何億年以上先まで同じ組み合わせが存在しないように乱数を発生させることが専用の高いソフトなど使わず簡単にできるのでしょうか？
203:193
07/08/03 18:37:00
「鍵が平文の長さ以上なら完全暗号となる。」ですが(平文の長さに近ければほぼ完全暗号？)、
暗記はもちろん無理なので、鍵をPCなどに(簡単な鍵などを付け)保存するしかありませんが、それでは安全性が保てないので、何かアイデアなどが必要になると思うのですが、
もし鍵が1つずれただけで全体がぐちゃぐちゃにずれた状態になる暗号技術だとすれば、「○文字目に○〇○の文字列を挿入」や「○文字目と○文字目を入れ替える」など、頭の中で暗記などしておくと安全性が保たれるのではないか、と思ったのですが。。
もしOTPやバーナム暗号は鍵が1つずれただけで全体がぐちゃぐちゃになる暗号技術でないなら、1つずれただけで全体がぐちゃぐちゃになる暗号技術が必要かな、と思いました。と、思いましたが、
逆にそれだと正解が解析されたときにまさにぴったり読めるものになるのでだめなのですか？それとも、量が多すぎてぴったり読める例が他にも数え切れないほどできるので、そのへんの問題はないということでしょうか。。
上に書いた「すごく長い鍵のどこかから文字列を抜いたり、文字を入れ替えたもの」から、適当に全数探索を始めたとして、いつか高性能なPCが出たとき解析できてしまうでしょうか。。(でも難しいですよね。。)
話戻ってすいません。
AESの○ラウンド目というのもよくわからないのですが、(ビット別だとは思いますが、)全体で何ラウンドあるのでしょうか？
もし12ラウンド中の9ラウンドとかだとしたら、75%ですが。。
短い鍵でもそこから生成される「拡大鍵」や「乱数列」は限界ビット数まで目いっぱい長さがあるのでしょうか？
(しかもその鍵から生成される乱数は複雑でなくては困りますが。例え1文字の手入力の鍵だとしても、暗号化されたもの自体は複雑で、(全数探索をすればすぐ解析できますが、)全数探索をしなくちゃ鍵が分からないくらいに複雑になるものでしょうか？)
暗号化されたファイル自体は、「元の鍵が短いものと長いもの」でほとんど変化はないのでしょうか？
つまり、フルラウンド版が解読されたときにどんな長い複雑な鍵を付けていたとしても、平文を全て読み出せるということでしょうか？(ごちゃごちゃですいません‥)
204:193
07/08/03 18:38:46
OTPが解読される日というのは一生こないのですよね？鍵(=乱数文)や平文の形跡が暗号化の時に全く残らないものだとすればどれが正解かもわからなくなるので。。
でももし暗号化の時に鍵(=乱数文)や平文の形跡が残るものだとすればいつか解読される日は来ますが、それはないですかね。。
暗号化の速さはブロック暗号よりストリームのほうが速いらしいですが、そんな変わらないのでしょうか。。
基本的に1バイトずつorブロックごとの違いだけで、あとはブロック暗号は「ブロックサイズ分のデータが揃うまで暗号化処理を開始できない」や「平文がブロックサイズの整数倍ではない場合に必要なパディング処理」のため少し遅くなるみたいですが。。
ブロック暗号
URLﾘﾝｸ(ja.wikipedia.org)
平文を64ビットや128ビット等の一定サイズ毎に暗号化する暗号
(単純換字式暗号の換字表の種類は26!(26はA～Z)サイズだが、)ブロック暗号はブロック長が64ビットのとき、(2^64)!という巨大なサイズとなる。
(=128ビットなら(2^128)!ということでしょうか。。とすると、3.4x10の38乗(340澗種類)の更に階乗ということなら相当長いっすよね‥？)
無意味に長くてほんとすいません。論点ずれてて、話ぐちゃぐちゃで、知識も間違ってますが、重要だと思う部分に返信いただけたら嬉しいです。
特に知りたいあたりは、
「全角文字の漢字などは、1万文字くらい全て別々のものとして捉えられ、正しいものを入力しないと解析できないのかどうか」
「AES暗号は短い鍵でも長い鍵でも、暗号化されたファイルは全体が暗号化されているということで、外見はそんな変化がないのかどうか」→今、5文字(5バイト)書き込んだテキストを、10文字と30文字の鍵で非圧縮で圧縮したら、
どちらも125バイトになりました。入力する鍵の長さに関わらず暗号化には常に(少なくともテキストの場合)120バイトの情報が使われるということですかね。200文字の鍵で試しても125バイトでした。
つまり、どんな長いどんな複雑な鍵をつけたところで、フルラウンド解読(おそらく暗号化されたファイル自体を調べる解読？)がされたら解読されてしまうということでしょうか‥」
205:193
07/08/03 18:39:18
「長い鍵とその保存方法のアイデア」「入力する鍵と、その鍵から生成される乱数列や拡大鍵の情報がより複雑で、それが全体の平文と組み合わせられて暗号化されたファイルもより複雑になり、解読が難しい技術。1番はやはりOTP？ 」
「バーナム暗号って平文以上の鍵なら完全暗号なんですよね？ ストリーム暗号のほうがブロック暗号より暗号化の処理など速いし利用性高いのですか？
wikiには、『ソフトウェア実装すると一度の暗号化処理で1bitあるいは1byteしか扱えないため性能が悪くなりがちである』など書いてあったんですが、あまり気にする必要ないんすかね。。
更にwikiに『常に平文サイズ＝暗号文サイズ。処理遅延が少ない、データサイズが増加しない』とあり、これで完全暗号ならバーナム暗号は利用性高いな、と思ったのですが。」
「より計算量が多くないとor時間を掛けないと解読できない暗号はどれでしょうか？←てか、OTPはどれが正解かもわからないので、正解がないんですよね。。
でも、長い乱数列の生成や、暗号化・復号化に掛ける時間・手間を考えたとき、他に(ほぼ)完全暗号で利用性高いものはあるかどうか。」
「AESはどんな長い鍵でも120バイトくらいですが、これでもまだ解読されてない暗号技術なんですよね。OTPのように、直接全ての平文1文字ずつに対して乱数割り当てて暗号化していくほうが確実だとは思いますが、
少し原始的で手間掛けすぎかなとも感じます。。」
ウザくて長過ぎてすみません。。。
206:193
07/08/03 19:28:16
俺終わってる‥ すみません
200の「＞特にAESなどの暗号規格策定の際に、かなり有力なものが排除されている。 」
は、AESは暗号化技術のことじゃなく暗号規格策定？のことだったんですね。すみません。
つまりAESは今のところ安全性高いと言っているのですね。。
201の「980÷68」は「980万÷68」の間違えっす‥。でも、0が980万個の数は単なる飛び飛びで法則適用して見つけて発見した素数の数で、0が980万個の数まで(例え数字のみでも)全通り試していくなんて(少なくとも今は)できるわけもないんすよね‥。
基本的に暗号化の解析っていうのは、入力された鍵を全数探索で地道に調べていくものではないのでしょうか。。入力された鍵が関係なく解析される可能性のものもあるんですよね？(暗号に使う情報の少ないAESとか？)
ちなみに土日はまたネットできないんで書き込みできないっす。(親にネットできなくされる虐待されるんで‥) すんません。。
207:１３２人目の素数さん
07/08/03 21:25:56
>>193
梅どぶろくの名に心当たりは？
208:１３２人目の素数さん
07/08/03 21:33:31
文章を掲示板に投稿する前に
エディタの編集画面に一度打ち込んでみて
編集するといいよ
>>200
＞とあり、AESは「安全性高い」というようなことが書いてありました。
＞でも、排除され「信頼性の低い暗号アルゴリズム」に認定された=安全性低い？というふうに書いてありました。
＞でも、「AES暗号の暗号アルゴリズムがとりあえず安全と言える。」と、安全性高いように書いてあったのでやはり高いのでしょうか。。
この段落は何を言いたいのかよくわからないけど
1. AESはNISTによって「安全性が高い」と認定されている
2. E2はNISTによって「安全性が低い」と認定されている
3. Wikipediaの解説によれば，E2はNISTによって「信頼性の低い暗号アルゴリズム」と認定されてはいるが
実際にはそれほど安全性が低いわけではなく，AES(Rijndeal)と同レベルに安全な暗号である
この説明を読んで「結局AESの安全性は高いの？低いの？わからない！」と悩んじゃうのは
暗号以前に日本語の読解能力に問題があると思う
そこに引用されてるWikipediaの文章もわかりにくいけど
209:１３２人目の素数さん
07/08/03 21:43:04
>>200
＞DESは1977年にできたものですが、AESなどの128ビットのものでも鍵の長さのmax値は短いのでしょうか？
なんでそう思った？
>>201
＞個々のラウンドで拡大鍵を使って入力の置換・転置等を行う構成
＞ラウンドが同じ関数の繰り返しになっている場合
＞この「積暗号」と「繰返し暗号」では、同じ関数が使われている分、繰返し暗号のほうが精度低いのでしょうか
その二つは排反じゃないと思う
＞自分の入力する鍵から、乱数列や拡大鍵？が生成されて平文と合わせられて暗号文となるのなら、
＞どんな長い(入力する)鍵を考えても、暗号化したもの自体の全ラウンド解析されたら、
＞平文全て(&入力する鍵)が解析されるということでしょうか？
「暗号化したもの自体の全ラウンド解析」ってどういうこと？
＞「＞ブロック暗号=鍵の全数探索で必ず解読可能」は、平文の長さくらいの鍵を使った場合、完全暗号に近づくのでしょうか？
ならない．というか「完全暗号」の定義をだれか教えてください．
＞入力する鍵をより複雑にすればいいとは思うのですが‥。
＞8ビット=1バイトとありました。でも意味がよくわからないっす。
＞こういうのは全部0と1のみの2進数の情報なのでしょうか？
＞Wikipediaの素数の項目
意味がよくわからないっす
210:１３２人目の素数さん
07/08/03 21:59:30
>>202
＞鍵から作られる乱数などは、
＞本当にそんな多い種類の漢字などに対応できるのでしょうか？
＞漢字や全角文字が全て同じ文字だと見なされてしまうとしたら、論外ですよね。。
まず暗号の勉強はいったん中止して
下に挙げた本を最初から最後までちゃんと読もう
図解雑学 コンピュータのしくみ
山田 宏尚 著
ナツメ社
ISBN:4816339787
図解でわかる文字コードのすべて―異体字・難漢字からハングル・梵字まで
清水 哲郎 著
日本実業出版社
ISBN:4534032242
211:１３２人目の素数さん
07/08/03 22:52:45
いやー、下らないね
何を長々と書いてるかと思えばど素人が意味不明な持論を語ってるだけか
212:184
07/08/03 23:50:29
やや遅レス
>>197>>199
真性乱数って言うのは、その乱数列をまんま保存するのより効率的に保存されたパラメータから再現する方法がない乱数列だから
無限長だろうが周期がある時点で真性乱数とはいえない。
テキストとの和を256とかで剰余演算した余りの数列は、最悪、乱数ですらない。つーか暗号文だろ。
テキストが十分に長い場合は、「出力された数列」より「圧縮されたテキスト」＋「周期nの乱数列を得るのに必要なパラメータ」
の方が短い場合が多々あることが想定される。よって、ある程度長い数列を取ると真性乱数とは言えなくなって来る。
それと、コンピュータ上では現在、真性乱数を電子的な情報から出力することは不可能。
なぜなら電子的なデータは正確に複製できるため。
（ただし物理的なデータ（ハードディスクの温度とか）から得られる情報を元に真性乱数を作ることは可能。再現できないからな。）
213:184
07/08/04 00:02:11
>>201
いやいや、「0が」980万個 ではなく、「桁数が」980万桁 だろ。
>>202
因みに、SJISだと全角文字は日本じゃ使わないような漢字とかあと記号とか含めて7000種類位な。
uniだともっとあるだろうが。
>>203
KCKっていう方法でファイルをより安全に守る方法がある。
用は平文を暗号化するときに使った鍵（乱数）を、もっと小さな鍵で暗号化して、その小さな鍵を記憶するわけだな。
>>204
ハードディスクに平文を保存してしまったのなら、サルベージでファイルが甦る可能性がある。
そこまで慎重になるなら、適切なソフトを導入するべき。
あと、普通は圧縮されてから暗号化されるから、それで正常。
>>206
本題とは関係が薄いか単に関係がない事だが
ミラーラビン素数判定とか、AKS素数判定とか、弱いのだとフェルマーの小定理とか、
そういう方法ででたらめな数列の素数性を調べることは可能。
214:１３２人目の素数さん
07/08/04 00:17:49
>>212
肝心のお答えが書いてないようです。
真性乱数は物理乱数で、無限長と思ってください。
疑似乱数を真性乱数で攪乱したものは真性乱数でよいですね？
215:１３２人目の素数さん
07/08/04 07:25:27
>>214
「擬似乱数を真性乱数で攪乱したもの」のエントロピー計算してみろよ
それが同じ長さの真性乱数と同じエントロピーもってたら真性乱数って言えるだろ
まあ言えないと思うが
216:１３２人目の素数さん
07/08/04 07:57:52
>>215
ごめんなさい。数学は素人で計算法がよくわかりません。考えてみます。
異なる例ですが、たとえば、単一光子を半透鏡のひとつの入力ポートから入射し、２つの出射ポート（０／１）の
どちらに到着するかを検出することに基づいて乱数を生成すると、これは物理乱数になります。
このとき、入力（入射ポート）は完全規則列、出力（出射ポート）は真性乱数列になります。
こういう例もありますが、真性乱数になるかどうかは（真性乱数を用いた）入力→出力のマップの性質に依存
する、すなわち一般的には断定できないと言うことでしょうか？
217:１３２人目の素数さん
07/08/04 09:30:43
>>216
何が言いたいんかよくわからんが、光子の例は量子効果を使ってるだろ
古典力学の世界だとどんな計算でもエントロピーを減らす方向にしか働かない
つまり出力のエントロピーは入力のそれ以下であるが
量子効果使えばdeterministicなプロセスでも古典の意味でのランダム性を得ることはできる
つまりエントロピーゼロの入力からエントロピーを増やすことができる
218:１３２人目の素数さん
07/08/04 09:42:12
>>217
量子効果は使っていません。半透鏡は真性乱数に基づくコイン投げと同じです。
コインの裏表に依存して、０／１を決めているのに等しく、そういう意味では入力状態に依存しない
プロセスになってますね・・・・・
そうすると、入力状態に依存しないプロセスであることが、真性乱数を得るためには必要ということ
になりますが、それは納得がいきます。
たぶん、>>197は入力に依存しないプロセスになっているんだろうと思います。
参考になりました。
219:１３２人目の素数さん
07/08/04 10:49:54
補足すると、入出力関係が一意写像であれば、それが線形であろうと非線形であろうと、入力の周期性が出力の周期性
になって見えることは自明と思われます。
今考えているようなプロセス（真性乱数に基づく間引き）は、一対多の写像であり、決定的ではない確率的写像です。
このとき、確率過程の寄与の大きさによっては、出力は入力に依存することもあり得るでしょう。
こうなると、入力のクセ（周期性）が出力に現れることは十分考えられます。
出力が真性乱数となるためには、この写像は入力のクセを完全に打ち消すほどのものでなくてはならず、入力に依存する
写像であってはならないと理解しました。
220:206
07/08/04 12:41:06
返信くれた方>>208,209,210,213マジありがとうございます。
余裕できたときによく勉強してみようと思います。
親がいない間にちょっとだけネット‥。
とりあえず、202がめちゃくちゃでした。
現在の最大素数である0が約980万個の数は、0が約4の2450000乗個ではなく0は約4+4+4+‥(2449996回)‥+4 個で、約10000の2450000乗の数字。
1万の1万乗(213さんに7000種と教えていただいてますが‥)は、0が4の10000乗個ではなく0は4+4+4+‥(9996回)‥+4 個、つまり4×10000で40000個0がつく。
(1万の1万乗)の1万乗は、40000の10000乗の0の数で、0は40000+40000+‥(9997回)‥+40000 個つまり40000×10000で、400000000個の0がつく。
この時点で0の数が約980万vs4億個なので、漢字の文字全てに別々の識別を与えて暗号化できるなら6バイトのほうが勝つな～と思ったのですが、無理な話っぽいですね、すんません。。あと日本語とカタカナを忘れてました。。
221:184
07/08/04 18:18:24
>>220
SJISだと漢字は2バイト食うので、6バイトだと7000の3乗で、3430億通りな。
どっから7000が出てきたかっていうあたりは昔暇つぶしに調べたら認識可能な文字が7700個ほどあったことから。
ただし、実際に鍵として使える文字はもっと少ない。「覚えれない、入力できない、読めない」の3拍子がそろった鍵を
誰がどうやって使うんだ？
その980万桁の素数の桁の数字は規則性あるし、（つーか2進数だと1ばっかりじゃないか）
かなり有名な数列だろうから、暗号では鍵として使うことはできないと思う。
結論：どちらも鍵としては使いにくい。
222:200
07/08/06 12:09:04
>>208
すみません、もっとまとめてから投稿するべきっすね。。
AESは206のように勘違いしていました。。
>>209
ブロック暗号自体、全数解析で必ず解読される暗号だとあったので。。
例えそうだとしても複雑な鍵が解読されるのは非常に現実的ではないのですかね。。
「排反でない」ということは、特に大きな違いはないということでしょうか。。
ラウンド解析自体よくわかっていないのですが、「○ラウンド目まで解析」というのは、
「入力した鍵」関係無しに、暗号文から何かしらの方法で平文を取り出すようなことかと思ったのですが。。
＞＞「＞ブロック暗号=鍵の全数探索で必ず解読可能」は、平文の長さくらいの鍵を使った場合、完全暗号に近づくのでしょうか？
＞ならない．というか「完全暗号」の定義をだれか教えてください．
ありがとうございます。短い平文の場合はすぐ解読されてしまうと思いますが、基本的に解析方法が「全数探索」しかないのであれば、
単純に鍵をより複雑にすればするほど解析は難しくなると思いますが。。
ストリーム暗号であるバーナム暗号は、鍵が平文以下だと完全暗号にならないが、平文以上にすれば完全暗号になるんですよね。。
自分も128bitの(ブロック暗号などの)暗号技術というのがよくわからないっす笑
8ビットは2の8乗で256種類というのは2進数の情報の区別の仕方(平文と組み合わせる乱数列などの情報として使える？)？
半角文字をいれるとしたら8ビットに1種類しか入らないんですよね。。
で、思ったのですが、
平文には何も暗号化処理を施さず(手を加えず)そのままの状態で残し、入り口の部分にすごい複雑な鍵を設定していたとしても、
暗号化されたファイルの調べ方によっては、その変更されていない平文の情報を、(例え鍵がわからない状態でも)取られてしまうことがあるかもしれない‥。。
で、暗号化というのは「入り口に複雑な鍵をつける」ではなく、平文全体をどのように乱数列などと組み合わせて暗号化するか、というのが焦点‥？
だとすれば、OTPのような長い鍵の暗号技術が有効？
短い鍵(or長い鍵)でも、平文や鍵(&鍵から生成される乱数列)の形跡を残さないよう、平文を複雑にずらしたり複雑にシャッフルすることができれば、と思ったのですが、難しいのでしょうか。。
223:200
07/08/06 12:09:48
鍵がわからなければ、「その暗号化の処理の仕組み、全ての知っている暗号化技術(ソフト)を作った開発者達」でさえ平文がわからない暗号化技術もあるのですよね‥？
例え短い鍵でも、すごい複雑な乱数列発生させて平文を(時間かけたりして)よりぐちゃぐちゃに暗号化するツールが理想‥？
で、暗号化の時に同時に複雑な乱数列の(長い)平文くらいの鍵を別ファイルで生成させれば？と思ったのですが、OTPで既にあります、ね‥。
OTPは1文字ずつ論理演算でずらしていくみたいですが、「鍵=乱数列の情報」と「平文の情報」で、それぞれ最初の1文字と最初の1文字があれば、平文の最初の1文字が判明するのでしょうか？
それとももっと複雑で、長い乱数列の鍵があったとし、その長い鍵の1万文字目～1万5文字目の半角英数字5文字を抜いて他の半角英数字5文字と入れ替えられていたとしても、その5文字だけ入れ替えられている長い鍵があれば、
1万文字目分まで＆1万5文字目以降は正確に復号化できるということでしょうか？ それとも、順番通りに並んではいるが全て(全体)が正しい鍵でないと復号化できないものなのでしょうか？
もしくは、順番通りに並んでいるわけではなく、全く復号化できないものでしょうか？ 俺の浅はかな思考ですみません。。実際はもっと(ビットのなどの識別使い？)精度高いものだと思います、暗号化技術は。。
＆漢字全てに別々の識別を持たせた(2ビットとかでの？)情報を与えることができる=8ビットで256種類とか、ブロック暗号なら128ビットで(2の128乗)の階乗？
＝ {3.4 × 10^38 (340澗)}×{3.4 × 10^38 (340澗)-1}×{3.4 × 10^38 (340澗)-2}×‥340澗-3くらい繰り返し‥とかだとしたら、7000文字の漢字(2バイト)で3,4文字(6,8バイト)にするだけで、0の数が物凄く多い組み合わせができるので、
平文全体に0と1の物凄く多い情報を組み合わせて暗号化できるとして、わざわざ長い鍵を与えなくても、短めの鍵で物凄い計算量が必要になるくらいの暗号化が可能なのではないでしょうか？
それとも2進数の情報使って平文の情報を他の何かの情報に完全に変えることは難しいのでしょうか。。2進数の情報で平文を少しずらして暗号化してあっても、暗号化としては不十分で、平文が読み出せてしまう‥？
224:200
07/08/06 12:10:24
>>210
どもです
「バーナム・OTP・AES の暗号化の仕組み winで使えるツール 処理時間や手間なども考慮し、実用性考えた 今現在精度の高い 最新のツールを使うならこのサイトをチェック」みたいなのが厨房にもわかりやすく書いてあるのがあれば理想っす。。
>>213
どもです
そのKCKという方法は、精度の高い暗号化なのでしょうか？
yahooで検索しても見つかりませんでした‥
URLﾘﾝｸ(search.yahoo.co.jp)
＞平文を暗号化するときに使った鍵(乱数)をもっと小さな鍵で暗号化し小さな鍵を記憶
このような三角関係もいいかもしれないっすね‥。
自分は削除は一応「完全削除」ってツールつかってて、設定も変え、復元ってソフトやDataRecoveryってソフトで復元の対象ファイルにならないようにしています＆理想はファイルシステムがNTFSでなくFATらしいんでそのうち変えたいっすね。
>>221
ありがとうございます
読めて入力できる漢字のみ使ったとしても、バイト数をある程度使えば物凄い数になる‥？とか思ってたのですが、致命的な過ち指摘してくれありがとうございます‥
上のは1万の1万乗ではなく1万の2乗、1万の1万乗の1万乗ではなく1万の3乗でしたね、ほんとすいません‥
やはり漢字はあまり使う意味がなく、今あるOTPやバーナムが確実みたいですね‥
バーナムやAESなどの詳しい暗号手法などは既に公表などされているのでしょうか。。わかりやすく解読が難しい理由を知りたいです。
もし公表されてない部分があるとすれば、作成者のみが「その暗号技術(ツール)を使って作られたどんな暗号文も解読できるような情報を隠しで埋め込んである」とかですかね。。
225:１３２人目の素数さん
07/08/06 12:14:36
だめだこりゃ。アルゴリズムと鍵の関係も分かってないよ
こんな所に長文書くより、暗号の入門書読んだほうが絶対早いぞ
別に図解暗号～とかいうのでもいいから
サイモンの暗号解読が面白くて技術的な事も入ってるから一番だが
226:１３２人目の素数さん
07/08/06 15:35:52
>>223
＞例え短い鍵でも、すごい複雑な乱数列発生させて平文を
＞(時間かけたりして)よりぐちゃぐちゃに暗号化するツールが理想‥？
どうも君のレスを読んでると、「長い鍵・短い鍵」の他に「複雑な鍵・単純な鍵」という概念があって
「複雑な鍵で暗号化＝暗号文を解読するのが困難」と考えているように思えてならないのだが
「複雑な鍵」なんて考え方はないよ
227:１３２人目の素数さん
07/08/06 16:48:52
積分も分からないのに二重積分をしてるような印象を受ける
228:１３２人目の素数さん
07/08/06 19:28:19
頑張って理解しようとする姿勢は確かに見て取れるんだけどね
ネット初心者かつ暗号初心者だとネット情報が膨大すぎて見つけられないのは仕方ないかと
ネットの断片的情報を自分なりにまとめようとして、さらに理解困難な状況に陥ってるようだから
皆さんがおっしゃられているように、まずは入門書を読んだほうが手っ取り早いです
暗号技術入門-秘密の国のアリス (単行本（ソフトカバー）)結城 浩
あたりがオススメかと。大きめの図書館にならあると思います。
読んだことは無いけど結城さんだし、レビューを見ると数式もないようなので。
何はともあれ急がば回れですよ。
229:１３２人目の素数さん
07/08/06 22:42:51
>「その暗号技術(ツール)を使って作られたどんな暗号文も解読できるような情報を隠しで埋め込んである」
この一言を書いた時点でお前さんが何も理解してないの丸分かりだぞ、おい…
230:１３２人目の素数さん
07/08/07 13:26:24
>>225
すみません、ありがとうございます
興味あるのでこれから時間があるときに読んでいきたいと思います
>>226
どうもです
特に「複雑な鍵・単純な鍵」という概念はないのですが、短い鍵でも文字に種類が多ければ「○通りの乱数列発生させる」という部分で
より多くの異なる乱数列を発生させられるんじゃないか、ということです。わざわざ平文と同じ長さまでの「鍵＝乱数文」を用意する必要が
そのうちなくなるんじゃないか、と…。そんな長い鍵がないと完全暗号にならないって考えが原始的に思える、と言いますか。。
PC進化して計算量早くなれば、ありかもしれませんが、その分解析のスピードもあがりますよね。。でも、PCが進化すれば解析よりも暗号化のほうが有利になるような気もします。
>>227
はい、学ぶ前に考え過ぎって感じですね…、すみません
>>228
ありがとうございます
まさに図星です。機会あったら図書館で探して見ますね。。
今はあまり時間ないのですが。。
>>229
そうですか？ 自分はツールによってはありえると思うんですけどね‥。長い鍵で平文全体を暗号化してるものは難しいのかもしれませんが、
平文はほとんど(全く？)書き換えず(=暗号化せず)入り口に鍵を作るようなものなら、余計な情報を少し付加してそこに簡単に解読できるような情報を
いれておく、とか‥。「何も理解していない」わけではないのはレスを読めばわかると思いますが、できれば理由も添えていただけると有難いです。
それで、1つ聞きたいことなのですが、ラプラスやWinRARで10～20バイトくらいのパスで(漢字なども混ぜたほうがいい？)圧縮したものよりも、
ラプラスやWinRARでそれ以上のパスで圧縮する以外に、今現在解明されている技術において、Winで使えるフリーツールで
(「パスが長すぎる」や「暗号化・復号化に時間かかりすぎる」など実用性の低いものを除いて)暗号化の質があがる(=より解読が難しくなる)ものはあるでしょうか？
暗号化の技術は興味あるので今後調べていきたいのですが、今は時間がないのでとりあえずこれだけ聞きたいです。よろしくお願いします。。
231:１３２人目の素数さん
07/08/07 16:09:40
それはここで聞く内容じゃないな。ただのソフトウェアに関する質問だ。
232:１３２人目の素数さん
07/08/07 16:13:32
>>230
> 「その暗号技術(ツール)を使って作られたどんな暗号文も解読できるような情報を隠しで埋め込んである」
こんなことをすると情報量が変わってしまうので、とても「まともな暗号」とは呼べない。
233:１３２人目の素数さん
07/08/07 16:17:51
>>230
>>「何も理解していない」わけではないのはレスを読めばわかると思いますが、
中途半端な間違った知識は何も理解してない状態より下だぞ。
今から何も知らない人と君が同時に暗号の勉強を始めたら、君の方が間違いなく理解が遅い。
234:230
07/08/07 17:57:55
>>231
はい、そうします‥(っても前に質問してたんですが、winで使えるツールがそんなにないのか、具体的な返信はあんまなかったっす)
>>232
その付加した分の情報量が少し増えるだけだと思うのですが、何かまずいことなどあるのでしょうか？
「まともな暗号」ではないとしてもやはりありえるのですよね。。
>>233
すみません‥。
時間＆環境がないのでまともに勉強できる状態でもないんす。。
まともに勉強していないのに皆さんに知識ばかり求めていたのはちょっと図々しかったですね‥、すみません。。
間違った知識を信じているのではなく、「こうではないか？」って仮定というかそんな感じですね…。
まだ表面的なことのみがむしゃらに得てる段階で詳しく勉強しようとしている状態でもないので、機会あったらまともに調べたいです。
でも、欲を言えば知識あれば答えられるような具体的なことをもう少し答えてもらいたかった←死。
tech/1180280982/の83さんにはお世話になりました。礼儀知らずの厨房ですみません。
235:235
07/08/07 21:54:21
2+3=5
236:１３２人目の素数さん
07/08/07 22:41:31
>230
とりあえず基礎知識の前に人に物を尋ねるときの態度を勉強してこい。
（誰も指摘しないんで気にしているのは俺だけかもしれんが、
何でもかんでも句点連発してネタっぽい文章にされると真面目に答える気も失せてくるぞ）
237:184
07/08/07 22:59:48
色々書いてたら本文が長すぎるって怒られたorz
>>222
ラウンドについては調べてないが、おそらくその暗号を解くには、例えばAの式を解いてBの式を解いて、と手順を踏まなければならず
「最初の数個は逆計算が可能である」事に対し、「○○ラウンド目までは解析可能」という言い回しが使われるのかと。
ブロック暗号で言う128bitだのそういう値は、「鍵か何かから乱数を作るとその大きさになるから、その分まとめて暗号化処理してしまおう」という
発想じゃないかと。ストリーム暗号だとこれが1Byteとか1bitとか、もっと細かい処理単位になる。
ちなみに1Byte=8bitな。
暗号化方式によって多少異なるけど、殆どの暗号はまず、鍵か何かから乱数のようなものを生成して、
その乱数と平文との排他的論理和を取ったりして暗号文を作成する。だから、平文は全体的に暗号化されてます。
で、この時攻撃対象になりうるのが、例えば乱数のようなものを生成する関数。前までに出た値から次の値が予測できるとき、これは暗号強度に問題があるとみなされる。
>>223
＞鍵がわからなければ、「その暗号化の処理の仕組み、全ての知っている暗号化技術(ソフト)を作った開発者達」でさえ平文がわからない暗号化技術もあるのですよね‥？
というより、それが前提だと思うんだが。
鍵以外の情報は（暗号化方式や暗号文、あと非対称鍵暗号なら公開鍵も）全て相手に知らされている、という仮定の上で
鍵空間への全数検索をするより効率的に平文が復元できるか、という問題に対し、NOと言えるのが一般人が手に取る場所にある暗号化方法な訳で。
＞例え短い鍵でも、すごい複雑な乱数列発生させて平文を
＞(時間かけたりして)よりぐちゃぐちゃに暗号化するツールが理想‥？
短い鍵でも安全だとは言えない。短い鍵でも十分なら、今度は乱数の生成関数ではなく、鍵の方が攻撃対象になる。
鍵が十分に短ければ、それこそ一瞬で暗号は解かれてしまう。
＞＆漢字全てに別々の識別を持たせた(2ビットとかでの？)情報を与えることができる=8ビットで256種類とか、ブロック暗号なら128ビットで(2の128乗)の階乗？
あのな、計算があっているかは兎も角として、計算に階乗は使わないし、そんな長い鍵をいちいち生成できるなら、OTPやれよ。
238:184
07/08/07 23:00:50
>>224
KCKは説明したと思ったが。
1.ファイルを暗号化するときに、大きなサイズの乱数を鍵として使う。
2.その時使った乱数の鍵を、今度は人間の頭で覚えられる程度の鍵で暗号化する。
3.すると、ファイルは乱数の鍵で守られ、乱数の鍵はユーザーの頭の中とかにある鍵で守られる。
これで何が良いかっていうと、例えば普通の人間の頭で覚えられる程度の鍵はとても特徴があるから
暗号化後のファイルから、大体の予想が付いてしまうことがある。
でも、乱数で暗号化し、さらにその乱数も別の鍵で暗号化した場合、どちらにも乱数が入っているため、鍵を予想しにくくなる。
＞もし公表されてない部分があるとすれば、作成者のみが「その暗号技術(ツール)を使って作られたどんな暗号文も解読できるような情報を隠しで埋め込んである」とかですかね。。
さて、これで何度目だろうか？「隠すことによるセキュリティ－」は、暗号では「やってはいけない事」の一つに指定されているんですが。
過去には、暗号化方法そのものを隠すことによって暗号の強さを出しているところも確かにあったが、
シーザー・カエサル暗号を使ったら内容がばれて処刑されたりとか
エニグマも最終的には数学者とかに解かれてたし。
239:184
07/08/07 23:01:27
>>230
＞PC進化して計算量早くなれば、ありかもしれませんが、その分解析のスピードもあがりますよね。。
関係無くは無いが、分散型のプログラムが出てきてるから、解析のスピードは凄まじい。
＞PCが進化すれば解析よりも暗号化のほうが有利になるような気もします。
計算量の問題だから、PCのスペックは関係ない。
ちなみに、今の技術なら、オーバークロックすれば8GHzとか出るらしい。
＞そうですか？ 自分はツールによってはありえると思うんですけどね‥。
たしかにその類の処理をするソフトは存在するが、使う意味が違う。
暗号化ソフトはデータを「見つかっても読めなくする」のが目的で
そのソフトはデータを「読めても良いから、見つからないように隠す」のが目的。
＞(「パスが長すぎる」や「暗号化・復号化に時間かかりすぎる」など実用性の低いものを除いて)暗号化の質があがる(=より解読が難しくなる)ものはあるでしょうか？
パスが短すぎるのもどうなんだ、というのはおいておくとして、暗号化や復号化にかかる時間は、大抵の場合、非対称鍵暗号の方が共通鍵暗号よりかかる。
暗号の強度は、専門家が時間をかけて調べるものだから、メジャーな共通鍵暗号なら大抵その条件に当てはまる。
240:１３２人目の素数さん
07/08/07 23:04:09
このスレはいつ「語るスレ」から「質問スレ」になった
241:１３２人目の素数さん
07/08/08 08:56:04
時間がなく、かつ他人の説明が理解できる基礎知識がないのなら
まず寝る時間を削って入門書を読みましょう
ここである疑問が解決しても、さらに「なぜ？」が増えるだけです
242:１３２人目の素数さん
07/08/08 09:20:59
時間が無いのにこんな長文を打つ暇はあるんだね
簡単な本なら1時間程度で概要は掴めるだろうに
243:１３２人目の素数さん
07/08/08 10:08:28
逆に質問
なぜ暗号アルゴリズムは公開されるのか？
そして何故公開された暗号アルゴリズムが利用されているのか？
これが答えられなければ基本が判っていない証拠
244:222
07/08/08 11:42:51
>>237
ありがとう
AES暗号
URLﾘﾝｸ(ja.wikipedia.org)
に
＞関連鍵攻撃により、256ビットのAES暗号の9ラウンド目までを解読可能。選択平文攻撃により、192ビットおよび256ビットのAES暗号の8ラウンド目まで、128ビットのAES暗号の7ラウンド目までを解読可能 (Ferguson et al, 2000)。
とあり、
＞選択平文攻撃（CPA）は、任意の平文に対応する暗号文を得られる条件で、暗号文から平文を求める攻撃である。公開鍵暗号の場合には、公開鍵を用いて任意の平文を暗号化することができるため、選択平文攻撃に対して安全であることが必須である。
とありました。
公開鍵暗号
URLﾘﾝｸ(ja.wikipedia.org)
とは、通信を受ける者（受信者）が全ての人に対して公開鍵を配信し、その鍵を使い暗号化され送られてきてたものを、
自分(受信者)しか持っていない秘密鍵（復号のための鍵）で復号化するもの
とあります。
＞公開鍵暗号の場合には、公開鍵を用いて任意の平文を暗号化することができるため、選択平文攻撃に対して安全であることが必須である。
というのが、もし可能なら全ラウンド解析されないということだと思うので、その技術を使えれば、と思うんですけどね‥。(無理な話ではありますが)
URLﾘﾝｸ(ja.wikipedia.org)
共通鍵より、公開鍵のほうが遅くできたということですが、復号化のみを考えたときに解読がより難しくなるのは暗号化と復号化の鍵が異なる公開鍵のほうだ、ということはないのでしょうか。。