■暗号技術【ROUNDsurea】■

■ このスレッドは過去ログ倉庫に格納されています
2007/05/28(月) 00:49:42
前スレ
■暗号技術【ROUND2】■
http://pc11.2ch.net/test/read.cgi/tech/1088530204/

擬似乱数
http://pc11.2ch.net/test/read.cgi/tech/1146071975/
暗号数学について語ろう。ROUND 3
http://science6.2ch.net/test/read.cgi/math/1170938965/
素数判定は「決定的」多項式時間で可能
http://science6.2ch.net/test/read.cgi/math/1028813059/
【疑似】乱数をつくる【本物】
http://science6.2ch.net/test/read.cgi/denki/1074867250/
ＲＳＡ暗号　解読　助けてください！！
http://pc11.2ch.net/test/read.cgi/sec/1026903337/

お前らって本当に自分じゃ何もしないよな。
前スレ>>990->>994
罰としてスレタイで辱めてやる
2012/04/11(水) 23:23:27.14
>>466
これ以上無知をさらす前に消えろよ。
2012/04/11(水) 23:25:13.76
だいぶ前にexcelの暗号化ファイルのパスワード解析した人がいたなあ
2012/04/11(水) 23:27:03.68
WindowsのNTLMv2だったかなんかはレインボウテーブル実在したよな確か。
あれはソルト使ってねーからな。
チャレンジレスポンスに対応するためやむを得ないんだが。
2012/04/11(水) 23:28:02.23
8文字以上のパスワードにするだけで、
そんなレインボーテーブルはこの世に存在しないから、総当りしかない。

ここで防御力を発揮するのがストレッチング。メタルスライムレベルの防御力。
2012/04/11(水) 23:29:25.00
>>470
無知はおまえだ。存在しないものは存在しない。
あるなら、どのハッシュのものでもいいからURL張れ。
2012/04/11(水) 23:33:23.37
だから辞書と組み合わせるんだっつの。
本当にあほだなお前。
2012/04/11(水) 23:34:51.85
あとそもそも実在するかどうかなんて関係ないんだよ。
暗号にかかわるならそんなことは常識で理解できるだろ。
実在実在見当はずれなこと言ってるのはお前だけ。
2012/04/11(水) 23:37:07.19
8文字長のレインボーテーブル出せで、なんで辞書の組み合わせテーブルなんだよw
テーブル劣化しすぎwwww
2012/04/11(水) 23:37:18.90
>>465
＞通信経路の暗号だと
＞鍵が見えたら、どうにでもなることでしょ、アルゴリズムがバレてたら
そのとおり。
しかし、通信を行う双方で同一の鍵を使うことが可能で、かつその鍵が第三者には明らかにならない方法が存在する。

つ「DH鍵交換」

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

つ「RSA暗号」「公開鍵暗号」
つ「一方向関数」
2012/04/11(水) 23:42:25.12
>>476
実在しないことが前提で今の暗号化の強度は成り立ってます。
実在したとなればそれは破られたと同義です。DESがいい例。
2012/04/11(水) 23:43:01.39
>>478
片側しか見えんとでも思ってるの、今のnet環境？
その手のやつは、ある程度時間経つと鍵変えてるような気がするけど
2012/04/11(水) 23:47:22.17
>>480
＞片側しか見えんとでも思ってるの、今のnet環境？
kwsk

＞ある程度時間経つと鍵変えてるような気がする
素数を使用するタイプの公開暗号系では、確率的ではあるが素数判定方法があるので、お手軽に素数を算出してはそれを暗号に使用している。
お手軽に算出する程度のものだから、頻繁に鍵＝鍵に使用する素数を変える必要があるのだろう。
2012/04/11(水) 23:47:53.00
>>477
なんで勝手にお前が出した条件にあうものを応えなきゃならないんだよ基地外かお前は。
お前が言ったテーブルが実在するかなんて誰も問題にしてないんだよ。
っていうか誰も実在するなんて言ってない。
馬鹿かよ。
お前が言ったテーブルがなければそんで安全なのか？
論点ずらしまくってんじゃねーよこの基地外。
それで済むなら暗号技術なんてどうでもいいもんばっかなんだよ。
お前はひとりで繰り返し回数をソルトの代わりに使うバカシステムでも作ってろよ。
まともな人間が見たら指摘されるだろうけどな。
2012/04/11(水) 23:48:10.70
>>478
見えるのは途中の経路にぶら下がったところだからね
末端の人には見えないから安全ってだけでしょ
2012/04/11(水) 23:49:01.56
まさか>>415-416の話に賛成できない人がいるとは思わなかった。
Security through Obscurityと言われたりもするっけ。byだっけ。
>>415-416の考え方を「知らなかった」ならわかるけどそれに反論するとか
どんなチャレンジャーだよ。
2012/04/11(水) 23:50:07.59
>>479
また論点がずれてるぜ。
それは安全性の保証じゃなくて、すでに破られているわけではないことの保証にしかならない。

現実に破られてないからOKなら、128ビットの暗号化なんて不要。
危険性の説明に実在するかどうかなんて関係ないだろうが。
実在しないのは安全性のための必要条件に過ぎない。
2012/04/11(水) 23:51:41.65
>>482
じゃあ、単純に実在しないよと言えばいいのに、
なんで「これ以上無知をさらす前に消えろよ。」なんだよw
キミの感情を複合化してやるよ。

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

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

2012/04/11(水) 23:51:56.04
ああ、>>479は人違いで逆の意味でいったのかな、だったら勘違いすまんね。

2012/04/11(水) 23:53:47.07
IPSecは糞と言いたいんだな。
2012/04/11(水) 23:55:30.35
実在しないかどうかは知らないもん。
お前が初めから実在するかどうかが重要ってスタンスで聞いてくるから、
実在するかどうかは関係ないって言ってんだろうが。
悔しいって笑わすな、ずっとずれたこと言い続けてんのはお前じゃねーか。

実際に実在しない保証はないが、まあおそらく総当たりのテーブルは実在しないだろう。
で、だからどうしたの？そんなことは話の本筋に関係ないといってる。
2012/04/11(水) 23:56:00.33
>>484
最初に暗号に触れる人には、理解に一定の困難が伴う考え方だと思う。「チャレンジャー」も理解を促進するひとつの方法だろう。
ただ理解しているものはそれに丁寧に回答する義務はあるかもしれない。
2012/04/11(水) 23:58:06.14
＞キミの感情を複合化してやるよ。
噴いた。
2012/04/12(木) 00:02:25.62
話の本筋を理解できないもしくはごまかし続ける相手に説明するのは無理、時間の無駄。
どうせごまかしたり論点ずらしたりするだけなんだから。

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

8文字以上のレインボーテーブルは存在しないのでテーブル化対策は不要です、キリっ
2012/04/12(木) 00:09:35.68
>>487
流れてるパケットの量が半端じゃないからね
ピンポイントでやろうってのがいないだけなんじゃねえの？
2012/04/12(木) 00:11:14.65
中間者攻撃でアウト。
特に無線LANとかだとひっかけやすい。

だから証明書とかが必要なんだな。
496484
垢版 |
2012/04/12(木) 00:12:58.03
>>491
確かに暗号の話を教える/教わるとき最初の山が公開鍵暗号あたりで、その次が
Security through Obscurity(がダメという話)かもしれませんね。順番は逆かも？
とはいえ俺は理解はしてるけど他人を理解させられるレベルではないので
えらそうなことは言えませんね。
2012/04/12(木) 00:15:05.53
レインボーテーブルの弱点はsaltと長パスワードでOK？
2012/04/12(木) 00:26:39.87
>>496
なに、理解はらせん状に行きつ戻りつ進んでいくものだし、他人に説明することは自分の理解の深化にも寄与すると期待している。
ここは匿名の場であるし、遠慮なく自分の考えの述べるのはお互いにとっても最終的に利益になると思う。

お考えをうかがいたい。
2012/04/12(木) 00:43:26.82
C++のAES256の枯れたライブラリってある？
2012/04/12(木) 08:54:02.73
>>497
OK
2012/04/12(木) 09:06:07.92
しかし、英数字パスワードだと、1文字辺りって6ビット程度だよな。
記号入れても7ビットはいかないが。

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

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

暗号関連の、ホントに現実的じゃない安全想定に比べたら、
余裕で実現可能なレベルだな。
2012/04/13(金) 04:47:14.97
Ciphertext stealingって1ブロック以下のときはどうやってパディングするの？
2012/04/16(月) 08:36:16.49
楕円曲線暗号の掛け算について分からないので教えて下さい。
ｈttp://deztec.jp/x/05/faireal/23-index.html
このページ中で「同意された点8に75を掛けると点26になる」
という部分なのですが、点8に75を掛けてみても点26に出来ません。
どの値にどのように掛ければ良いのか、教えて頂けると幸いです。
2012/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になる相手の数）のこと。
505503
垢版 |
2012/04/16(月) 10:50:04.28
>>504
回答有難う御座います。
まだ試してないので、ちゃんと理解出来たのか怪しいですが
もう少し頑張ってみます。
506504
垢版 |
2012/04/16(月) 14:45:35.89
>>505
>>503で貼り付けているsite内を検索してごらん
2012/04/16(月) 16:15:02.73
>>502
CTSなんてブロック暗号利用モードがあるんだ
知らなかった

全くの思い付きだけど、最初から1ブロックしか暗号化しないってことは
共通鍵暗号で単純に1つのメッセージを暗号化するときと同じだから
PKCS#5 Paddingとかでメッセージの長さを1ブロック分にして
それを暗号化するのではないかと予想


てか秘匿とメッセージ認証以外にもいろんなモードの規格が準備されてるんだね

ttp://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html
ttp://www.cryptrec.go.jp/estimation/techrep_id2011.pdf

メッセージ認証と鍵ラッピングは知ってたけど
認証子付き暗号化とかディスク暗号化なんてのもあるのか
508503
垢版 |
2012/04/16(月) 20:42:26.64
>>506
追加のアドバイス、有難う御座います。
ちゃんと理解する為には色々と検索しなければならなさそうですがｗ、
今考えている方法を試して駄目だったら検索もやってみます。
2012/04/18(水) 18:17:06.76
共通鍵暗号におけるIV(initial value?)というのは、
解読時までKeyと一緒に覚えておく必要があるのでしょうか？
もしそうなら、公開鍵暗号と一緒に用いる場合、
Keyと一緒に暗号化しておくべきでしょうか？
2012/04/18(水) 18:40:15.18
cbc modeの話だと仮定します。

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

また、Keyは対称鍵暗号で使う対称鍵のことと仮定しますが、
Keyのみを公開鍵暗号で暗号化して、
暗号化対象の実体は対称鍵(Key)で暗号化します。
2012/04/18(水) 19:22:56.39
情報が不足していてすみませんでした
まさに対称鍵暗号のCBCやCTRを想定していました
回答ありがとうございました
2012/04/24(火) 18:42:15.56
コンテンツ暗号化するときは毎回コンテンツごとにコンテンツ暗号化キーをランダムに生成。
で、コンテンツ自体を暗号化(だいたい対称暗号で)。で、コンテンツ暗号化キー自体を
自分の何からしの鍵(キー暗号化キー)で暗号化して、その暗号化されたキー暗号化キーと暗号化されたコンテンツをセットに
する。キー暗号化キーをどうするかは用件しだいで、>>510のように、公開鍵暗号で暗号化したり、
パスワードベースにするならPBKDF2などのキー導出関数を使って、導出させる。
2012/04/24(火) 18:46:06.85
まぁ、暗号化だけじゃ、機密性しか提供できないから、一貫性チェックのために、
暗号化する前に、コンテンツのハッシュを求めて、コンテンツとハッシュをあわせたものを
暗号化するなどして、復号化時に、コンテンツの一貫性をチェックできるようになる。
Windowsの暗号化ファイルシステム(EFS)をだいたい同じ。EFSは使用するとEFS用の
自己署名された証明書とその公開・非公開鍵ペアをつくって、その非公開鍵が
キー暗号化キーになるイメージ。
2012/04/24(火) 18:55:04.74
コンテンツ暗号化キーを暗号化するときに、１つのキー暗号化キーで暗号化するのでは
なく複数のキー暗号化キーを使って、暗号化されたコンテンツ＋複数それぞれのキー暗号化キー
で暗号化されたコンテンツ暗号化キーをセットにしておけば、１つのキー暗号化キーを
忘れても他ので復号化できるので安心。EFSに回復エージェントって仕組みがあるけど
まさしくそれ。
2012/04/24(火) 19:43:56.51
暗号化ファイルシステムがハックされたら、終わり
2012/04/25(水) 05:49:50.07
「ハックされたら」の一言で計算量理論もなにもかもをふっとばせるバカはお気楽でいいな
2012/04/25(水) 06:20:04.43
Windowsの暗号化ファイルシステム(AES256+(ECC256 or RSA2048))はザル。
ログインパスワードさえ突破しさえすれば丸見え。大半は辞書攻撃で突破可能。
2012/04/25(水) 07:23:33.81
鍵の不適切な運用を前提に議論するとか、最強の論理体系ですねw
2012/04/25(水) 07:31:34.85
事実、現実が不適切な運用だらけなのに、
それを前提にしないシステムは欠陥ありというべきであろう。

最低限、EFSを使用する場合には、ログインパスワードのセキュリティポリシーを
強制的に厳しくするべきだね、MSは。
2012/04/25(水) 17:04:02.53
個人用の場合、忘れたもしくは自分が死んだらおしまいの、パスワードベースでいいんだけど、
EFSは証明書に基づく公開・非公開鍵要求するからふざけるなって感じ。
BitLockerでいいよ。
2012/04/26(木) 02:50:46.22
コンテンツのハッシュをとってから暗号化するのと、
暗号化してからキー付ハッシュをとるのとどっちがいい」？
2012/04/26(木) 04:18:20.27
>>521
暗号文とハッシュ値、ハッシュの秘密鍵と復号鍵の格納場所がどこで
どんな経路を通じて誰が一貫性（完全性ともいう）チェックと復号をするのかによって
いろいろ変わるのかもしれないけど、一般的にはEncrypt-then-Macといって

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

という順番になる

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

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

という手順になる

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

あるいは最初から秘匿とメッセージ認証の機能をあわせもつ
認証付き暗号（認証子付き暗号ともいう）を使うという手もある
2012/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(要は暗号化)の入力になるとは書いてある。
2012/04/26(木) 11:47:45.07
Win8でWindows APIにCNG DPAPIってデータを保護するAPIが追加されるらしいんだけど、それが
CMS使ってて、その構造をttp://msdn.microsoft.com/en-us/library/windows/desktop/hh706817%28v=vs.85%29.aspx
でみると、一番外側が図で類推する限り、Enveloped-Dataになってて、それで、
>>513では、ハッシュを先にするべきなのかなとハッシュを先に書いた。
2012/04/26(木) 11:54:55.18
>>522はhttp://tools.ietf.org/html/rfc5083のAuthenticated Enveloped Dataかね。
2012/04/26(木) 12:29:28.11
まぁ、RFC3852(5652),RFC3370,RFC5754,RFC3565を気合入れて読みながら、Windowsの
CryptoAPIのCMSを操作する関数をここ2週間いじくりまくって身に付けた程度の知識だから、
Secruity Condisderationsとかそこまでは手回ってなく、詳しくはわからんけど、
選択する暗号アルゴリズムやハッシュアルゴリズムを強度が高いものにして、
後は鍵管理をしっかりしとけば、ハッシュした後、暗号化しとけばとりあえず
問題ないとは思うけどな。自分だけ復号化できればいいんだったら。わざわざ、
メッセージ認証する必要ねぇとは思う。
2012/05/11(金) 13:32:46.81
OpenSSLのRAND_bytes()を使おうと思うのですが、
RAND_add()は、常駐してエントロピーを収集するようなプログラムが使うもので、
ユーザープログラムは、RAND_bytes()を呼び出すだけで済むという認識で正しいでしょうか？
2012/05/11(金) 15:01:32.57
RAND_add()は、RAND_seed()とほぼ同じ関数だよ。
乱数の乱数性を強化する際に使う関数。
>>527はRAND_bytes()を呼び出すだけという認識でいいよ。
2012/05/11(金) 16:37:59.92
毎回種蒔くのは面倒だと思っていたので、すっきりしました
回答ありがとうございました
2012/06/05(火) 18:30:28.73
CIPHERUNICORN-A、Hierocrypt-3、SC2000の
ソースコード探してるのですけど
在りかを知ってる方がいれば教えて頂きたいです。

…できれば言語がCだと有難いです。
2012/06/06(水) 20:56:26.20
Hierocrypt-3はあった
http://ci.nii.ac.jp/naid/10016220863
2012/06/07(木) 09:10:40.65
>>531
ありがとうございます！
非常に助かりました。
533デフォルトの名無しさん
垢版 |
2012/06/15(金) 13:43:33.76
これからはCDのコピー禁止フラグのような軽いプロテクトも流行るんじゃないかな。
2012/06/15(金) 13:47:20.86
何も重いプロテクトをかけるだけがいいことでは無い。
プロテクトを外す行為が違法ならあえて軽いプロテクトにして、外した者を
どんどん逮捕したらいい。
2012/06/15(金) 14:15:25.05
フラグ1個でも技術的保護手段っていうの？
2012/06/15(金) 14:17:14.63
要はコピー禁止の意志がファイルに付いていると認められるということ。
2012/06/17(日) 13:24:12.69
>>534
違法行為で暗号を解読した証拠は裁判所で証拠にならないので
犯罪に使われた解読後の結果が証拠になるなら、他者の所有物の解読は
違法ではないという判断になるんじゃない？
538デフォルトの名無しさん
垢版 |
2012/09/17(月) 09:35:08.91
2ch_prog20004140935082220001

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

2ch_progから始まる文字列でこれより長く0のビットが続くの探してみて
539デフォルトの名無しさん
垢版 |
2012/09/18(火) 21:01:37.05
【IT】マイクロソフトが発見！中国製PCに出荷時からウィルス「中国製のパソコンや情報端末の購入には、慎重になったほうがいい」★２
http://uni.2ch.net/test/read.cgi/newsplus/1347879086/

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

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

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

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

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

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

540デフォルトの名無しさん
垢版 |
2012/10/10(水) 21:46:53.81
保守
541デフォルトの名無しさん
垢版 |
2012/11/06(火) 14:51:31.15
不正防止とコスト
市場はどっちを選択するんだろうなぁ
2012/11/06(火) 15:19:32.37
誰かがコストを選択して痛い目に遭ってから、不正防止を選択します。
顕在せぬ危険性について、株主が理解することは不可能でしょ。
どっかの株価大暴落がないと駄目だろうね。
2012/11/12(月) 03:17:15.66
なんでITだと、「こんなこともあろうかと」が無いんでしょうかね
2012/11/12(月) 09:52:00.63
>>543
物理的な「こんなこともあろうかと」は認知しやすく
論理的な「こんなこともあろうかと」は認知しにくい

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

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

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

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

でも、知ってて黙ってたってのだから、違いはするか。
2013/01/11(金) 13:43:23.71
ここの皆さんはやはり凄腕客家ーなんですかね・・
2013/01/11(金) 16:37:50.93
えっ？
2013/01/11(金) 17:56:36.65
ROUNDsurea
ってことは
surea
が何番かってことなのか
2013/04/03(水) 17:22:15.21
WinRARでパスつき(AES)ファイルを作成したりしていますが、フリーで使えるツールの中ではAESは1番強度の高い暗号アルゴリズムでいいのかな。
71のレスを読むと、AESアルゴリズムを使っていても他の部分で脆弱性があれば、解析されやすくなるということだと思いますが、AESのツールの中でそういうのを少しでも判別する方法があるか調べてみたい。
2013/04/03(水) 18:00:41.37
また、強度を少しでも強くするためのパスワードのつけ方について、
解析方法を「数字のみ」「英数字」など選択せずに、全数探索で「1,2,3‥」として、
1文字目を存在するすべての文字を照合してから2文字目にいくとして、
「abc123」と「,.;:^|」は同じ6文字で強度はあまり変わらないのかな。
全角文字でパスワードをつけた場合のことも調べる必要あるし、長いパスワードをつけても何文字目かまでしか認識されていないツールがあるというのも見ました。
2013/04/03(水) 18:03:02.24
今のスーパーコンピュータなどを使っても解析に数年から数百年以上かかるくらいの強度を、今のフリーのツールでも実現できていてほしい。
「パスワード 解析にかかる時間」でぐぐってあとで見てみます。
2013/04/03(水) 18:37:54.99
できました！ありがとう。
552デフォルトの名無しさん
垢版 |
2013/05/11(土) 19:28:10.10
ブロック暗号化って暗号データと元データがあると解析されやすいらしいけど
HDDを暗号化するとしてHDDの後半とかには大抵ゼロうめされた領域があるじゃない？
ってことは元データをゼロ決め打ちして解析することってできちゃうんじゃないの？
そこんとこどうなの？
2013/05/11(土) 20:20:07.67
元データがあるなら解析しなくて済む罠
2013/05/11(土) 20:49:54.33
>>552
LBAをCTRにするとか。
2013/05/12(日) 04:29:50.98
なるほど、わからん
2013/05/14(火) 03:34:40.09
まったくの素人だがとあるソフトの暗号通信解析してたらちょっと感動した
まず クライアント内で最初から持ってる鍵 で GetTickCountで取得した時間と最初の鍵を織り交ぜた復号用の鍵 を生成して
その鍵を 最初の鍵 で暗号化して鯖に送ってそれの返答でサーバーから 別の鍵 が送られてきてその鍵を 前回の復号用の鍵 で復号して
復号した鍵 から 新たな復号用のカギ を生成して 前回送られてきた鍵 をそのまま 最初の鍵 で暗号化してサーバーに送って鍵を確定させて
帰ってきたデータを 復号用のカギ で復号してそのあと前回サーバーに送った確定した鍵を元に 暗号用のカギ を生成して
それ以降は一定時間毎にサーバーから新たな鍵が送られてきて元の鍵を混ぜ合わせて更新するという流れだった。

大体のソフトの通信も似た感じなんだろうけど、最初から通信監視してないとまず復号できないし、すごいなーって素で思っちゃったよ
2013/05/14(火) 10:01:48.72
要はCBC
558デフォルトの名無しさん
垢版 |
2013/06/03(月) 17:32:24.62
初歩的な質問ですみません。
完全に自作のアルゴリズムではなくPHPやPerlで標準のハッシュ・文字列関数等のみで
「入力と出力の対が知られても変換の法則の推測は難しい」関数を作ることはできるでしょうか？
文字列A(人間が覚える必要はない。例えば128ビット)を入力して、
その後ある認証を行い成功したら、Aを元にした文字列Bを返すプログラムを作りたいのですが、
攻撃者が認証を繰り返しAとBのペアを例えば1万通り入手したら、そこから変換の法則を推測し、
以後認証プログラムを使わなくても自前でAからBを得られるようになってしまうでしょうか？
2013/06/03(月) 18:54:55.02
yes
yes


攻撃者（）がAからBを得られたところでどうでもいい
560デフォルトの名無しさん
垢版 |
2013/06/03(月) 20:13:59.29
すみません。質問が悪かったようです。
(あと業務で使うものではないので絶対に破られてはならないものではないです)
Web上でPerlで動いているプログラムXに特殊な方式の認証機能を追加したいのですが、
この認証方式のフリーのプログラムがPHP版しか見つからず、Perlで作り直す余裕もないため、
XはユーザーにチャレンジAを発行＆セッションに保存→ユーザーは認証プログラムにまずAを入力
→さらにある認証をし、成功したらレスポンスBを出力→ユーザーはXにBを入力
という方法を考えました。
暗号アルゴリズムも詳しくないので、定数リテラルでソルトを与える・入力の部分文字列からソルトを生成・
複数回ハッシュを計算など、単純な関数だけの組み合わせで法則が推測困難な物は作れるのかと思いまして。
法則が推測されると認証しなくてもチャレンジからレスポンスが生成できるので、システムが成り立ちません。
2013/06/03(月) 20:40:36.90
>>558 の質問の答えが yes yes だったとしても
チャレンジからレスポンスが生成できなくしてしまえばいい
2013/06/03(月) 20:43:06.44
captchaのことかな
563558
垢版 |
2013/06/03(月) 21:04:16.90
>>562
はい。

>>559>>561
まずyes yesというのは、何重にも組み合わせることでより時間がかかるようにはできるが、
いくら難しくしても結局は現実的な時間内で解析可能、ということでしょうか。
そして、チャレンジからレスポンスが生成できなくしてしまえばいい
というのは、バレたら(もしくは一定時間ごとに)新しい法則に変えてしまえばいいということでしょうか。
2013/06/03(月) 21:20:34.15
そうじゃなくて関数自体は解析されてもレスポンスを作れなければ良いんです
言い換えると認証確認時に鯖側でチャレンジからレスポンスを作るのが間違ってる
565558
垢版 |
2013/06/03(月) 22:16:45.70
>>564
そもそもチャレンジというものを使わず、ユーザーには最初に認証プログラムにアクセスするようにさせ、
認証成功時は時刻同期OTPのような方法か、または認証プログラムからXに裏側でBを送るかし、
ユーザーがXに入力したBの値を検証するようにすれば、チャレンジがわからないからレスポンスもわからない？

あ・・・そもそもレスポンスすらいらず、成功時認証PがXにGETなりして「認証成功」ってセッション作らせて、
Xが発行したセッションIDをユーザーに通知して、ユーザーはそれを持ってXにアクセスすればいいのか・・・？
2013/06/03(月) 22:35:37.20
チャレンジレスポンスの仕組みは利用するよ
2013/06/04(火) 21:53:05.11
解析されてもレスポンスが作れないって意味が分かってないだろうから具体的に教えてあげれば？
言わんとしてることがよく分からないから俺は教えてやれないが。
2013/06/04(火) 22:27:29.13
webサーバーが乗っ取られて（覗かれて）も、大丈夫なようなnetwork構成にするとか
2013/06/05(水) 04:05:20.15
馬鹿には無理
2013/10/03(木) 00:21:10.88
AESキャッシュ攻撃のアルゴリズムが詳しく載っている論文知らないですか？
プログラムだとベストです
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況