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しただけだったりして。