07/05/28 02:19:11
1乙
3:デフォルトの名無しさん
07/05/28 02:33:33
ところで、暗号化後のファイルの圧縮率の悪さなら
平文（元ファイル）は2GBの0埋めで実験したんだが
おいらが試した限り一度もファイル長が縮まなかった、
そこそこの速度のある暗号があるんだが、誰か試してみてくれないか。
zip、rarはWinRARの最高圧縮モード+パスを格納しない、lzh、bhはlhaplusのデフォルトで試したんだが。
lasrmとか何とか言う奴だった気がする。最新版の評価と解析ｷﾎﾞﾝ
4:デフォルトの名無しさん
07/05/28 02:38:01
それが正しい。圧縮率が悪いのは仕様です。
5:デフォルトの名無しさん
07/05/28 02:38:11
エンコード後のエントロピーが偏る暗号方式なんて使い物にならないべ?
6:デフォルトの名無しさん
07/05/28 08:07:12
だから低脳がスレ立てるなと一体何度言わせれば・・・
7:デフォルトの名無しさん
07/05/28 11:07:05
あたりまえだ
8:デフォルトの名無しさん
07/05/28 22:39:59
理想的なのは分かったが、「全く縮まない」となると
擬似乱数に使えないか？「そこそこ速度はある」らしいし。
少なくとも2GBにかけて安定している（？）乱数表の生成にはもってこいだと考えるが、どうだろう？
9:デフォルトの名無しさん
07/05/28 22:46:59
ある平分を暗号化した暗号文が擬似乱数として使えるかどうか？
「使える。」が答え。
だけど、擬似乱数生成速度が暗号化速度と等しいわけで、暗号化関数を擬似乱数生成関数としてみた場合、低速。
それだったら最初から擬似乱数生成関数を使え。という話。
10:webmaster@気まぐれアナスイ
07/05/28 23:26:55
!(Φ＿Φ+)
暗号技術という物はNet.に於いて使うのであれば、
「access.を知られない様に出来ないか？」という事を基に創られる物の筈です。
疑問を持たなくては為らないのが…
最も、完全な暗号を読み取れるのか？
11:webmaster@気まぐれアナスイ
07/05/28 23:32:04
>>10『追加』
開発者は偉大だと思います。
それでは完全な配列を幾つ創ったのか？
12:デフォルトの名無しさん
07/05/28 23:35:23
なんかよくわからんがあぼーんしておくか
13:webmaster@気まぐれアナスイ
07/05/28 23:41:09
>>12
!(Φ＿Φ+)
『あぼ～ん』を使うのですか？
14:webmaster@気まぐれアナスイ
07/05/29 00:29:19
{あぽ～ん}
ζ
!(+Φ＿Φ)つ√ζ
+⊂. + 〆∂ {Ж}
"〆∂∂
〆〆
.:"
15:webmaster@気まぐれアナスイ
07/05/29 10:04:24
!(-＿Φ+){0000000000Ｘ=9876543210=x}
絶対に解けません。
16:webmaster@気まぐれアナスイ
07/05/29 10:10:02
|
17:webmaster@気まぐれアナスイ
07/05/29 10:12:53
>>16
!(-＿Φ+){click text all selection.をどうぞ。}
18:webmaster@気まぐれアナスイ
07/05/29 10:14:40
!(-＿Φ+){ ... }
z y x|
19:webmaster@気まぐれアナスイ
07/05/29 10:18:06
|
!(-＿Φ+){確認です。}
20:webmaster@気まぐれアナスイ
07/05/29 10:19:28
|
!(-＿Φ+){完璧です。}
21:webmaster@気まぐれアナスイ
07/05/29 10:20:22
|xyz
22:webmaster@気まぐれアナスイ
07/05/29 10:26:51
!(-＿Φ+){式の始まり。}
|aabcdefghijklmnopqrstuvw|xyz
zyx|wvutsrqponmlkjihgfedcbaa|
23:webmaster@気まぐれアナスイ
07/05/29 10:30:35
!(-＿Φ+){ずれました。}
|aabcdefghijklmnopqrstuvw|xyz
zyx|wvutsrqponmlkjihgfedcbaa|
24:webmaster@気まぐれアナスイ
07/05/29 10:35:07
!(-＿Φ+){ずれました。}
|aabcdefghijklmnopqrstuvw|xyz
zyx|wvutsrqponmlkjihgfedcbaa|
25:webmaster@気まぐれアナスイ
07/05/29 10:36:37
!(-＿Φ+){ずれました。}
|aabcdefghijklmnopqrstuvw|xyz
zyx|wvutsrqponmlkjihgfedcbaa|
26:webmaster@気まぐれアナスイ
07/05/29 10:43:11
!(Φ＿Φ+){表記は出来るのですが…}
27:webmaster@気まぐれアナスイ
07/05/29 10:44:49
!(Φ＿Φ+){ 覚えたので消してしまいました。}
28:webmaster@気まぐれアナスイ
07/05/29 11:26:11
!(Φ＿Φ+){忘れては為らない大切な事は…}
『どの様な暗号でも構成には配列が必ず在る』
という事ですか…
『0000000000Ｘ=9876543210=x』
にも勿論、在ります。
29:webmaster@気まぐれアナスイ
07/05/29 11:28:54
!(-ｙΦ+){ fireFox！}
▽
△
30:webmaster@気まぐれアナスイ
07/05/29 13:57:54
!(Φ＿Φ+){My, sory.}
通常、click.をするとtext.を選択します。
式の構成を表示しなくても何となくは分かり使えるかも知れないです。
31:デフォルトの名無しさん
07/05/29 19:08:58
符号化と暗号化の本質的な違いや如何に
32:デフォルトの名無しさん
07/05/29 19:19:47
符号化：たとえば、文字列を2進数表示する事
ABC→01000001 01000010 01000011
暗号化：主に符号化などをして扱いやすくなったデータを、元に戻す事が可能な手段で変更を加える事
33:デフォルトの名無しさん
07/05/29 20:41:15
リードソロモン符号は暗号化ですか？
34:デフォルトの名無しさん
07/05/30 12:02:49
ASCIIのテキストファイルをZIPで圧縮して
BASE64にかけたものをSMTPで送信しても
単なる多重符号化であって暗号化じゃないのだよな
35:デフォルトの名無しさん
07/05/30 14:44:11
ZIPで圧縮するときにパスワード入れれば医院で内科医
36:webmaster@気まぐれアナスイ
07/05/31 01:41:03
!(Φ＿Φ+)
理解する事が出来ました。
install.毎に暗号を組む事にします。
37:デフォルトの名無しさん
07/05/31 18:43:56
Goppa符号は暗号化ですか？
38:デフォルトの名無しさん
07/05/31 19:17:40
>>32
暗号の要件には鍵の存在が含まれると思うが
39:デフォルトの名無しさん
07/05/31 19:42:40
いい加減に>>32を許してやれよ。
40:デフォルトの名無しさん
07/05/31 19:52:46
どんな符号化であっても、暗号になりえるが、
誰でもその中身が見れるような情報が公になっているのであれば
その時点で暗号とは呼べない。
Winnyのキャッシュファイルも暗号とかいっているけど、
誰でもその中身を見ることが出来るので暗号ではない。
41:デフォルトの名無しさん
07/06/01 22:24:02
あぁ、金庫の上に鍵が放ってあるっていう話か。
42:デフォルトの名無しさん
07/06/02 00:15:07
そういえばなんで Winny はオニオンルーティングとか使わんかったんかねぇ。
43:webmaster@気まぐれアナスイ
07/06/02 03:18:35
!(Φ＿Φ+)
暗号はとても大切だと同感します。
なので、個人で作成した暗号は確りとsystem.に教えてあげています。
44:デフォルトの名無しさん
07/06/02 08:00:18
47滋賀暗号に関してど素人だったから。
共通鍵の扱い方とかで分かるだろ。
45:webmaster@気まぐれアナスイ
07/06/04 12:15:26
!(ΦｙΦ+)
不機嫌です… かなり危険な暗号を創りました。
46:デフォルトの名無しさん
07/06/04 22:18:26
どうせ作るなら「安全」な暗号創ってくれ
47:デフォルトの名無しさん
07/06/04 22:28:02
安全な暗号なんてOTP暗号で十分。
鍵の受け渡しが出来ない？そんなもんはDH鍵交換で生成すればいい。
48:デフォルトの名無しさん
07/06/05 10:39:31
OTPの鍵をDH鍵交換で共有すると、安全性の根拠が
情報理論的安全性から計算量理論的安全性（DH問題の難しさ）に変化しますね
実用的な長さの鍵（乱数表）を共有するために必要な通信回数／計算回数もかなり大きくなりそうです
49:デフォルトの名無しさん
07/06/07 07:15:46
64bitのMに対して48bit程度のa,bを通信し、計算された値の下位32bitを用いるとか。
うん？それだとupするのに必要なdown量がup量を超えると言う不思議な現象が発生するな。
50:webmaster@気まぐれアナスイ
07/06/09 18:26:00
!(ΦｙΦ+){ 【暗号】成功しました。}
999 999 999 999
999 999 999 999
999 999 999 999
999 999 999 999
51:webmaster@気まぐれアナスイ
07/06/09 18:32:07
>>50『続』
!(ΦｙΦ+)
忘れていました。一瞬ですが？tty.出力されました。
組み合わせて使う事にしました。
52:デフォルトの名無しさん
07/06/15 19:47:46
ちょっとスレ違いですが、ファイルを相互にやり取りする際の暗号化って
意味有るんですかね？
(パスワードキーで復号するタイプのもの)
それこそZIPでパスワードを設定した方がよほど使い勝手が良いですよ。
結局どちらもパスワードを解読されたら同じじゃないですか。
それなら圧縮されている方が、まだ良い。
(圧縮自体も暗号見たくなりますし)
53:デフォルトの名無しさん
07/06/15 20:26:56
圧縮と暗号化を同列にしてるのはなぜ？
54:デフォルトの名無しさん
07/06/15 20:34:14
>>53
例えば、ハックする方からすれば、暗号化されていようが圧縮されていようが、
パスワードを解析するだけだから。
もちろん技術的に異なる事はわかるが、それは内部の問題であって、
外部からはどちらも一緒なんでは？って事です。
55:デフォルトの名無しさん
07/06/15 20:45:07
>>52
パスワード付きZIPは要するに圧縮＋暗号化という処理をしているだけよ
暗号化してないと思ってた？
56:デフォルトの名無しさん
07/06/15 21:14:21
>>55
へー、そうなんですか。
圧縮だけだと思っていました。
57:デフォルトの名無しさん
07/06/15 23:06:24
結局何が言いたかったんだろう…
58:デフォルトの名無しさん
07/06/16 16:50:22
オナニー
59:デフォルトの名無しさん
07/06/27 16:29:45
ZIPの暗号化はパスワードがクラックされやすいから
使い物にならないって言いたかったんだと E.S.P.
60:デフォルトの名無しさん
07/06/28 01:33:29
そりゃブルートフォースアタックで簡単にクラックできるようなパスワード長にするほうが悪い。
パスワードを次の英文にした時に数日でクラックできるかどうか試してみ
I am the bone of my sword. Steel is my body, and fire is my blood.
61:デフォルトの名無しさん
07/06/28 06:57:18
せめて Challange Response にすべき
62:デフォルトの名無しさん
07/06/28 22:50:19
>>60
それ、なんていうエミヤの詠唱？
63:デフォルトの名無しさん
07/06/29 01:37:28
>>６１
馬鹿は黙ってた方がいいよ
64:デフォルトの名無しさん
07/07/13 20:59:25
ファイルにパスをかけるフリーツールで完全暗号のツールはありますか？ラプラスやWinRARは(全角文字など入れて少し長めのパスを設定しておけば)現在の技術で数百年～数千年以上は解除不能な完全暗号になるでしょうか？
(ラプラスやWinRARはバーナム暗号なのでしょうか？)よろしくお願いします。
65:デフォルトの名無しさん
07/07/13 21:12:20
完全暗号の定義よろ
66:デフォルトの名無しさん
07/07/13 21:41:36
>>64
ED 暗号
でググレ
67:デフォルトの名無しさん
07/07/13 23:52:49
attachecase
68:デフォルトの名無しさん
07/07/14 09:24:05
>>64
ラプラスやらWinRARやらは暗号化ソフトの名称だから、それだけでは何とも言えない。
「少し長め」の定義よろ
暗号化目的で使ってるならあれは共通鍵暗号だから、普通に企業とかで使う分には
内部は128bitとか256bitとかあれば十分では？
3DESはbit長の割に強度に問題あるがなー。
69:68
07/07/14 09:34:37
個人的には、>>3が言ってたツールがお気に入り。
空間は256bitらしいが、そこそこの速度はあるし。
70:デフォルトの名無しさん
07/07/14 23:23:12
OpenSSLでいいじゃん。
71:デフォルトの名無しさん
07/07/15 00:56:08
「256bitAES使用で強固なセキュリティ」
とか謳う暗号化ソフトあるけど
暗号化による強度って暗号化手法もさることながら
キーの管理に寄るところの方が大きいと思うんだが
そこら辺まできちんと説明されている暗号化ソフトって少ない気がする
いくら鍵長が長かろうがユーザーが入力したパスワードから生成していたら
イタズラ防止程度にしかならない気がする…
現実的に人間が覚えられる長さ・パターンなんて限界があるし
ここら辺って暗号化ソフトを導入している企業でも理解できていないところ多いような…
72:デフォルトの名無しさん
07/07/15 02:25:33
暗記できないほど複雑でメモが必要な鍵と、暗記できる鍵のどちらが
安全かは微妙な問題だな。
73:デフォルトの名無しさん
07/07/15 07:04:01
メモ残し厳禁
↓
結局忘れるのでその都度リセット
↓
管理者だけ何でもあり
↓
管理者のパスワードは？
↓
毎回一緒有効期限なし暗記可能かなり単純
74:デフォルトの名無しさん
07/07/15 15:27:31
そこで催眠術か何かを併用したランダムな英数字による12桁のパスワードの丸暗記ですよ
75:デフォルトの名無しさん
07/07/15 21:22:39
>>73
笑えない
76:デフォルトの名無しさん
07/07/15 21:38:59
admin/admin
administrator/admin
の会社を何件か知ってる
77:デフォルトの名無しさん
07/07/15 21:41:17
奇遇だな
漏れも知ってるよ
78:デフォルトの名無しさん
07/07/15 23:00:28
それは知らないが
system/weblogicadmin
の会社なら知ってる
79:デフォルトの名無しさん
07/07/16 00:36:13
悲しいかなadministratorにパスワードなしのとろころもあるのが現実
80:デフォルトの名無しさん
07/07/16 09:22:34
administrator/h16saitama
の高校を一つ知ってる。
81:64
07/07/17 08:59:32
返信ありがとうございます
PCの知識はあまりないのですが、
>>68
「ラプラスやらWinRARは共通鍵暗号」というのはどういうことでしょうか？
全角文字(漢字なども含む)や半角英数字などを混ぜて10～15文字のくらいのpass(メモなどせず頭の中で暗記)をつけたとしてもラプラスやWinRARなどの開発者達にはすぐに解読されてしまうということでしょうか？
普通に企業などで使うものではなく「そのようなソフトの開発者や高度な技術者など、どのような人を対象にしても」としたとき解除不能なpass(or偽造など？)を(できればフリーの)ツールで付けようと考えたら難しいのでしょうか？
(無理の場合、比較的より困難なpassの付け方、passの羅列の例＆ツールなどよかったら知りたいです。)
《やっとネットが繋がったので(夜は使えなくなりますが‥)「共通鍵暗号」を調べたら暗号化の時と復号化のときに使うpassが同じということみたいですね‥、すみません‥。》
あとpassをかけるのが目的ならラプラスで圧縮設定3でzip非圧縮にすると圧縮の時間が短縮できるので、自分はそうしてます。そうしてもlzhは非圧縮ではなく普通に圧縮されました。
自分は1度lzh(またはzip)で(passつけるorつけないで)圧縮した後、そのファイルのファイル名を変えたりして、さらにそれをpassつきzipで圧縮すると中のファイル名も、もちろんファイル自体も人に伏せることができるので、そうしてます。
一番上のようにやはり「どのような技術を用いても少なくとも数百年以上解読不能なpassファイルを作る。
(passは自分の頭の中で暗記できるくらいの長さのものorメモなどで長いpassを保存するとしてもそのメモを他人に少なくとも今の技術で数百年以上知られないようにする保存方法がもしあれば(ないですかね笑)そうして。)」ということは難しいのでしょうか？
bitとかよくわかりません・・。
82:64
07/07/17 09:00:26
>>71
順番は別々でも半角英語8文字 数字3文字 数字4文字の15文字を組み合わせるとして、他で質問したところラプラスは秒間で35万個ほどのパスワードが検索できるので、上の組み合わせだと5垓個ほど組み合わせがあって、50万世紀ほどかかる計算になるらしいです。
それで、この計算は完全にランダムな文字列を総当りで解読した場合なので、パスワードが意味のある単語などになっていた場合に、上記の(英語8文字)が辞書探索の1万語目で見つかったなら、3日で解読されるらしいです。
また、zipのパスワードは安全性が低く「パスワードが正しいかの判断の前に、それがパスワードの可能性があるかどうかを判定する」らしく、それでも数桁の速度アップとなるだけで、これでも50万世紀から数桁減ったところで生きているうちには解読できないらしいです。
でももし(ソフトの開発者などが)ファイル自体を調べて解析するやり方が存在していたりしたら解読されてしまいますかね‥。
自分はドライブ全体を暗号化するより個別のファイルの暗号で今の技術では何百年、何千年以上暗号を解除することができないツールのほうに興味があります。
今ある高度な暗号の技術のツールを2種類くらいつかって2重以上で複雑なpassを掛けてれば解読するのはより難しくなるでしょうか？
ファイルやフォルダにpassをかけることのできる(できればフリー)ツールで今の技術で高度なpassをかけることのできるものが知りたいです。
ラプラス、WinRAR以外にもっと高度なものは何かあるでしょうか？より解読が難しく(できれば完全暗号にでき、)暗記できるくらいのpassの組み合わせの例など知りたいです。長くてすみません‥。＆寝不足です‥。
83:68
07/07/17 19:11:05
>>64
共通鍵暗号ってのは暗号化するときに使う鍵と復号化するときに使う鍵が
同じ物を言う。だから、パスワードをかけるのは共通鍵暗号に似ている。
WinRARの開発者は確かにRAR圧縮に関してかなりの知識を持っている事が予想されるが、
その人がその暗号を簡単に解除することが出来るのならそれは「隠すことによる秘密保持」
に該当するので、おそらくそんな事はない。
（もちろんそんな保証はないが、そんな事があればどんなパスワードでも数秒で解除する類のソフトが
出回っているだろう。）
良質なパスワードなら、乱数サイコロを百回くらい振ればいいのが作れるかと。
攻撃者が個人か団体かに因ってくる。
例えばteam2chは団結力とか凄いので(2000年以上かかる計算を2年で終わらしたとか何とか）、
パスワード長は攻撃を受ける期間とその速度・突破されたときの被害等を考慮して決める必要があると思う。
「どのような技術を用いても」という時点で、まず諦めていただきたい。
例えば。その情報を盗みたがっている人が実はピッキングが得意な泥棒で、情報が入力されているコンピュータそのものを持ち去っていくかもしれない。
例えば。その情報を盗みたがっている人が実はプロパイダの管理者で、中間者攻撃を仕掛けてくるかもしれない。
例えば。暗号化された情報を手に入れた人が実は割と新しいスーパーコンピュータの所持者で、物凄い勢いで解読を試みるかもしれない。
例えば。暗号化された情報を手に入れた人が実はこの暗号に関して天才的な頭脳の持ち主で、暗算と勘でパスワードを求めるかもしれない。
84:デフォルトの名無しさん
07/07/17 19:47:26
長文のうえに「らしいです」ばかりで読む気がしない。
85:デフォルトの名無しさん
07/07/17 22:56:09
だから完全暗合ってなんだよ
86:デフォルトの名無しさん
07/07/17 22:56:54
じゃなくて完全暗号ってなんだよ
87:デフォルトの名無しさん
07/07/19 04:38:49
どんな鍵を使っても復号できない暗号
88:デフォルトの名無しさん
07/07/19 05:55:50
完全暗号って量子暗号のことか？
89:デフォルトの名無しさん
07/07/19 18:20:56
バーナムかなあ。
90:デフォルトの名無しさん
07/07/19 23:12:46
いやXORだろ
91:無知
07/07/25 11:18:06
第9回NSUGシンポジウム報告
www.nsug.or.jp/readme/no26/sympo98.html -キャッシュ
鍵長とその強度に関して、100MIPSのコンピュータを100台同時に動かし
たときの解読時間が示された。56ビットのDESでは1秒以内に解読可能であるの
に対し、128ビットのIDEAでは8,000億年かかる。鍵長が128ビットに満たない
共有鍵暗号を信用してはならないということなどが説明された。
公開鍵暗号については、その代表的なものにRSA暗号があり、これは掛け算は容易であるが素因数分解は困難であるという特性を利用した初の本格的な公
開鍵暗号であるということが説明された。
RSAの強度として100MIPSのコンピュータを同時に1億台動かした場合の解読時間も紹介され、共有鍵暗号の場合と異なり、公開鍵暗号であるRSAの場合は
1024ビット以上の鍵を使うことが強く推奨された。
3のLASRMデ検索したんですが
URLﾘﾝｸ(web1.nazca.co.jp)
なんかここにすごいって書いてある→URLﾘﾝｸ(web1.nazca.co.jp)
WinRARとかより優れた暗号技術なんすかね‥
92:デフォルトの名無しさん
07/07/25 12:08:41
暗合の安全性はそういう単純な話ではなかろう
93:無知
07/07/25 12:18:53
暗号化の技術 + その鍵 じゃない？基本的に。
単純じゃない、とだけ言われてもよくわからんよ。
94:デフォルトの名無しさん
07/07/25 19:13:36
それより今の量子コンピュータの性能が知りたい。
何年か前に15=5*3の素因数分解に成功したのは聞いたが…
95:デフォルトの名無しさん
07/07/25 20:37:18
量子コンピュータなんぞができる頃には
量子暗号が普及しててあんま意味無さそう。
96:デフォルトの名無しさん
07/07/25 22:50:02
ようとは暗号解読だけじゃないだろ
97:デフォルトの名無しさん
07/07/25 22:52:07
単に計算量だけの話なら、長い鍵長をサポートしさえすりゃいくらでも延びるわな
98:デフォルトの名無しさん
07/07/26 07:16:29
↑
97
暗記以外での鍵の保存方法は？
99:デフォルトの名無しさん
07/07/26 10:29:45
>>95
量子暗号って通信でだけ使えるもので、保存では使えないぞ。
原理とかわかってて書き込んでるのか？
>>98
USBメモリとかでリアル鍵みたいに扱えばいい。
100:デフォルトの名無しさん
07/07/26 11:04:28
>>99
＞USBメモリとかでリアル鍵みたいに扱えばいい。
ってどういうことでしょうか？リアル鍵‥？
フラッシュメモリはもってるのですが‥
101:デフォルトの名無しさん
07/07/26 11:33:18
扉に鍵を挿すのと同じように、USBポートに(鍵ファイルの入った)USBメモリを挿すという意味じゃね？
102:100
07/07/26 11:34:57
リアル鍵
＞家の鍵よか車の鍵とか、実際に物体として存在する鍵
＞USBメモリに暗号データを記録しておき、そのデータのUSBメモリをPCに挿してないと
＞動作しない、というような使い方を意味すると思われ
そのUSBメモリも使われたら開けられてしまうこともある＆USBメモリをなくしたり壊したりしたらもう一生開かないって感じ‥？バックアップもしたり、ですか‥。
103:デフォルトの名無しさん
07/07/26 11:41:04
>>101
ありがとう
104:デフォルトの名無しさん
07/07/26 11:53:29
>>102
まさにリアル鍵だね
>>97
世の中に出回ったハードウェア・ソフトウェア製品の鍵長を変更する手間がかかるよね
IPv6はもう二度とアドレス空間の拡張をしなくていいように設計したらしいけど
（計算量的な困難さに基づく）暗号技術は百年後も千年後もいたちごっこと製品更新が続くのかな
105:デフォルトの名無しさん
07/07/26 13:11:54
100年後なんてまったく想像つかんわ
106:デフォルトの名無しさん
07/07/26 15:35:11
とりあえず2038年を乗り切らねば
107:デフォルトの名無しさん
07/07/26 19:15:20
IPがv4からv6に変わってところで暗号自体には影響ないだろ
何のためにレイヤーを分けているのかと
108:デフォルトの名無しさん
07/07/26 21:22:32
暗号化って学習するの楽しいの？
109:デフォルトの名無しさん
07/07/26 21:54:34
どうせ100年後の香具師らにかなり馬鹿にされるんだろうなぁ
110:デフォルトの名無しさん
07/07/26 23:42:07
>>108
離散数学楽しいよ。
って友達と喋ってたら「お前ヘンだよ」って言われた。ファック。
111:デフォルトの名無しさん
07/07/27 00:21:00
>>107
いや、>>104では別に「IPv6に使われている暗号技術の話」をしたいわけじゃなくて・・・
112:デフォルトの名無しさん
07/07/27 20:22:40
>>110
俺、今ググるまで「離散数学」て時計演算とか曜日演算とか九去法とかで使う「剰余算」の事だと思ってたorz
>>104
千年後は知らんが、百年後くらいまでは普通に
ハッカー(防御)VSクラッカー(攻撃)の鼬ごっこだと思う。
113:デフォルトの名無しさん
07/10/27 11:14:14
疑似乱数のスレが新スレに移行
疑似乱数２
ｽﾚﾘﾝｸ(tech板)
114:デフォルトの名無しさん
07/11/20 12:18:44
暗号―この不可思議で魅惑的な世界って本買ってみた
115:デフォルトの名無しさん
07/11/20 22:12:52
面白いのか報告頼む
116:デフォルトの名無しさん
07/11/20 22:54:21
・ページ数が200以下 ・紙が厚い ・文字が大きい ・図表が多い ・簡単な文章
ということでもう読み終えてしまった
（ここまで簡単に書くのにかなり苦労してる雰囲気が本全体に漂ってるがｗ
序論にも書いてあるけどこれは読み物
大学の一般教養の講義を受けてるみたいで脳味噌を回すことなくすらすら読める
内容は深入りしないけど技術の背景にあるバックボーンはわかりやすく的確に
ピックアップしてるから暗号についてプチ勉強（笑）したい人にもお勧めできる（素早く半日で読破できるし）
だがちゃんと暗号を勉強したい人は立ち読みがお勧めだ（高いし素早く半日で読破できるし）
一言でいうと楽しい読み物だな
むかし「○○のひみつシリーズ」のマンガを読んでたがあんな感じだ
117:デフォルトの名無しさん
07/11/21 07:35:32
>>116
報告㌧
読み物的なものが読みたいなぁと思っていたのですが少しボリュームが足りなさそうなので
今度本屋で立ち読みしてみますね
118:デフォルトの名無しさん
07/12/02 22:47:48
age
119:デフォルトの名無しさん
08/03/13 04:18:41
Hello Kitty used as drug lord's messenger: report
URLﾘﾝｸ(afp.google.com)
麻薬王がメッセンジャーに選んだのはキティちゃん
URLﾘﾝｸ(www.afpbb.com)
120:デフォルトの名無しさん
08/03/14 00:41:51
暗号化ソフトは本当にファイルをユーザーが入力したキーを元に暗号化しているのか
作者は実はマスターキーを用意しているのでは
入力したキーは作者のみが知るキーで暗号化されてデータに埋め込まれているのでは
121:デフォルトの名無しさん
08/03/14 03:44:05
暗号化ソフトってなに？
122:デフォルトの名無しさん
08/03/14 14:11:49
ファイルフォーマットも処理様式も公開されておらず
第三者が検証できないようなツールは使わない。
という方針でいいんではない?
123:デフォルトの名無しさん
08/03/29 09:11:14
科技庁はどのように選択すればよいのですか？
124:デフォルトの名無しさん
08/04/11 20:34:03
なんかすごいのが見つかったみたいだけど。
URLﾘﾝｸ(www.atmarkit.co.jp)
125:デフォルトの名無しさん
08/04/11 20:57:30
見つかったというか、読んだ限りでは関数自体も差し替え可能な「鍵」とすることで
鍵のバリエーションが完全に無制限に ＝ 解読が完全に不可能になった、という意味かな。
むしろ 8 ギガビットの巨大な鍵でストリームが可能というのはすごいな (SSL のように
共通鍵だけというオチでなければ)。
まぁ実際はクリアアタックかけてその関数の推測から始まるんだろうけど。
126:デフォルトの名無しさん
08/04/11 21:57:50
「暗号化の鍵の組み合わせ」を相手方にわからせないと意味なくない？
それはどうやって伝えるんだ？
127:デフォルトの名無しさん
08/04/11 22:03:07
読んだ限りでは公開鍵としても使えるようだから渡し方自体は今までどおりでいいでしょ。
128:デフォルトの名無しさん
08/04/11 22:04:28
>>127
> 読んだ限りでは公開鍵としても使えるようだから渡し方自体は今までどおりでいいでしょ。
じゃあそこにスキができるじゃんよｗ
129:デフォルトの名無しさん
08/04/11 22:13:16
?
例えば?
130:デフォルトの名無しさん
08/04/11 22:15:18
相手にどの式を使ったか教えなければ複合ないんじゃないの？
131:デフォルトの名無しさん
08/04/11 22:21:59
確かによくわからん…
使う関数が自由に選べちゃったら復号側が困るよなぁｗ
132:デフォルトの名無しさん
08/04/11 22:40:33
おまいらこのスレに居る以上は公開鍵暗号理解してると思ってて良いんですか?
133:デフォルトの名無しさん
08/04/11 22:55:39
公開鍵と秘密鍵の対は今までみたいに使われる関数がきまっているから一回手元で作るだけで良かったんだろうけど、
今回のそれはそういう事できんの？ っていう疑問でしょ。
普通に考えたら、鍵化の関数をランダムに選ばれちゃったら、公開鍵、秘密鍵の対も毎回違っちゃうんでないの？、と。
まぁ、そのＣＡＢ方式とやらで一回 ペアの鍵を作ったら、その一方の鍵でどんな関数をつかって暗号しようが関係なく、
初めに作った秘密鍵で全て復号できる！っていうなら話はわかるんだけど…
134:デフォルトの名無しさん
08/04/12 00:21:31
そんなことが果たして可能なのか
135:デフォルトの名無しさん
08/04/12 04:36:25
その他もこの暗号の一部とかいってるわけだから、
公開鍵＋公開関数をセットでやりとりするとかか？
でも秘密鍵＋秘密関数をセットで保持しなきゃならないし
その関数の安全性をちゃんと図らないとだめだろうし
鍵も関数も大量の管理が必要になり面倒だろうし・・・
136:デフォルトの名無しさん
08/04/12 05:42:25
俺は話半分くらいに受け取っている。
ZeoSync(100分の1圧縮)ほどの大嘘でないにしても、大したことなさそうな…
結局のところ、アルゴリズムを特定しないことによって、プロトコル名だけでは
復号の仕方が分からないというだけの話じゃないかね。
137:デフォルトの名無しさん
08/04/12 05:55:58
251 名前：名無しさん＠八周年 本日のレス 投稿日：2008/04/12(土) 00:17:48 vbnqIY+x0
解読できる「確率」が定義できるような安全性のレベルを問題にする場合は、
バーナム暗号よりいい方法は存在しないことが知られている（というか学部生でも
すぐわかる）よ。記者がよくわかっていないのならいいけど、
この人の場合、前にNP問題が解けたとか言ってた前科があるからなあ。。。
138:デフォルトの名無しさん
08/04/13 15:03:07
ηTペアリングの高速な実装
URLﾘﾝｸ(labs.cybozu.co.jp)
139:デフォルトの名無しさん
08/05/18 20:18:27
AES(Rijndael) って危ないんですか？
140:デフォルトの名無しさん
08/05/19 09:12:46
どこがどう危ないと聞いたんだ？
141:139
08/05/19 21:35:49
>>140
どこが、というのは具体的にはきいていないのですが、こんなのがありました。
ｽﾚﾘﾝｸ(newsplus板:421番) (今はdat落ちです。）
>そこまでやって採用されたAES、じつは「簡単に解けてヤバいんじゃねーの？」というのは知れてる
じゃ、どんな問題があるかな、と思った次第です
で、検索してみたところ、次のような指摘はありました。
URLﾘﾝｸ(www.watch.impress.co.jp)
URLﾘﾝｸ(en.wikipedia.org)
ここで、URLﾘﾝｸ(cryptrec.nict.go.jp) の URLﾘﾝｸ(www2.nict.go.jp) をみたところ、
心配する必要はないとのことですが、これは 2004 年の報告で、続報はありません。
ということで、最近の動向をご存知の方がおられたら、と考えました。
煽る意志はまったくありません。
142:デフォルトの名無しさん
08/05/22 00:44:35
話をもの凄い勢いでぶった切る上に質問で本当に申し訳無いと思っているのですが
線形解読法のS_boxの近似の方法がよく分からないのですが、簡単に説明していただけますか？
論文を読んだのですが、式の意味が分からず、本当にわからなくて死にそうです
143:デフォルトの名無しさん
08/08/08 03:34:15
ほしゅ
情報処理推進機構 セキュリティセンター
暗号技術に関するe-Learning教材
URLﾘﾝｸ(www.ipa.go.jp)
ITセキュリティ評価・認証に関するe-Learning教材
URLﾘﾝｸ(www.ipa.go.jp)
144:デフォルトの名無しさん
08/08/15 14:26:26
PBKDF2による鍵派生で疑似乱数関数にHMAC-SHA1を使用した場合について
パスワードに十分なエントロピがあったとすると、
派生される鍵のパスワードに基づくエントロピの上限は
512ビット？
それとも160ビット？
もちろん長い鍵を派生した場合の話ね。
パスワードは512ビットだった場合。
145:デフォルトの名無しさん
08/08/15 14:32:11
補足、PBKDF2でHMAC-SHA1を使った時点で160ビットに制限される
みたいな記述を見たことがあるんだけど、
なんか512ビットのような気がして微妙に納得いかないんだ。
詳しい人おせーて。
146:デフォルトの名無しさん
08/08/18 15:35:22
誰か暗号化鍵交換（EKE: Encrypted Key Exchange）の特許について詳しい人おらん？
147:デフォルトの名無しさん
08/08/19 06:54:20
特許について詳しい
って専門職すぎる
148:デフォルトの名無しさん
08/08/19 21:32:46
弁理士すれにいったほうがよくね？
149:デフォルトの名無しさん
08/09/15 22:36:56
>>144
SHA1が完全に破られたとしてもHMAC-SHA1は安全だと思う？
>>146
アルゴリズムには詳しいから特許に抵触する場合は抵触すると答えれると思う。
150:デフォルトの名無しさん
08/09/16 00:57:55
SHA1が完全に破られたってどういう状態を言うの？
っていうか、それは>>144の疑問にどのように関わってくるのだろうか？
151:デフォルトの名無しさん
08/09/26 12:10:58
どこで聞けばいいのかわからないのでここにレスさせてください。
よく雑誌などについていたりするユニークな英数字のIDがありますが、
あのIDの生成とデコードの基礎的な理論はどうやって調べればよいでしょうか？
152:デフォルトの名無しさん
08/09/26 12:51:25
>>151
「よく雑誌などについていたりするユニークな英数字のID」がなんのことだかわからんので
答えようがないのだが...たとえば具体的にどういうID？
153:デフォルトの名無しさん
08/09/26 13:00:55
「ASHJUDFHDJS」
のような特定桁数の英数字の組み合わせのものです。
たとえばビットキャッシュなどのプリペイド系のコードや
ネットゲームのアイテム交換コードなどもそれにあたります。
少数なら発行コードと該当する内容をデータに保存という考え方もできますが、
万単位になると管理が大変だと思うので・・・
154:デフォルトの名無しさん
08/09/26 15:15:02
照会方法？
サーバ | クライアント
+-------------------------------+--------------------
発行時| IDを生成してDBに記録 |発行されたIDを受け取る
利用時| 受け取ったIDからDBの記録を照会 |サーバへIDを照会
155:デフォルトの名無しさん
08/10/12 15:03:13
ＰＫＣＳ＃１に関する事をどなたか教えて下さい。
以前、ＰＫＣＳ＃５のブロックパディング方式で暗号するプログラムを組んだ事があるのですが、ＰＫＣＳ＃１も所定サイズ（鍵長？）に満たない場合にパディングを付与したりするのですか？何バイト分付与するかで付与する値が固定で決まってはいないのでしょうか？
156:デフォルトの名無しさん
08/11/23 09:07:37
The SHA-3 Zoo
URLﾘﾝｸ(ehash.iaik.tugraz.at)
どのハッシュ関数が生き残るんでしょうねー
157:デフォルトの名無しさん
08/11/23 18:37:49
>>156
いつのまにか公募終わってたんだな
これから一年かけてサバイバル一回戦か
参考：URLﾘﾝｸ(ja.wikipedia.org)
158:デフォルトの名無しさん
08/12/03 12:43:35
暗号前文字「acfeadda8d008302e28f0547800c3587fb7d8f15」
暗号後文字「CLJEes3f4ENLYW76WtkhojDfDGs/91tKRihLMeRLqVg=」
暗号化方式もキーも何も分からないんだけど、
解読方法って分かるかな？
無理だよな・・・
調べて分かる暗号なんて使わないよな・・・
駄目もとで書いてみた
スレ汚しスマソ
159:,,・´∀｀・,,）っ-○◎●
08/12/19 19:52:47
AES Sboxのbitslice実装って使えないな
どのみちビットシャッフルはバイト単位しかないからSIMDで攪拌＋マージしたほうが効率いい
160:デフォルトの名無しさん
09/02/23 01:33:39
>>158
遅レスだけど、一例だけだと分からん。
xorしてbase64しただけだったりして。