■暗号技術【ROUNDsurea】■

1 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 00:49:42 ] 前スレ ■暗号技術【ROUND2】■ pc11.2ch.net/test/read.cgi/tech/1088530204/ 擬似乱数 pc11.2ch.net/test/read.cgi/tech/1146071975/ 暗号数学について語ろう。ROUND 3 science6.2ch.net/test/read.cgi/math/1170938965/ 素数判定は「決定的」多項式時間で可能 science6.2ch.net/test/read.cgi/math/1028813059/ 【疑似】乱数をつくる【本物】 science6.2ch.net/test/read.cgi/denki/1074867250/ ＲＳＡ暗号　解読　助けてください！！ pc11.2ch.net/test/read.cgi/sec/1026903337/ お前らって本当に自分じゃ何もしないよな。 前スレ>>990->>994 罰としてスレタイで辱めてやる 464 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:17:01.79 ] >>462 はいはいもう消えろよ。 465 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:18:36.23 ] >>463 通信経路の暗号だと 鍵が見えたら、どうにでもなることでしょ、アルゴリズムがバレてたら だから、通信中に鍵変えるのがあるでしょ ファイル暗号だと鍵がわからないと手が出ないってだけ 総当たりするにしても時間がかかる 466 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:19:26.51 ] >>464 ほう。大小英数字8文字のレインボーテーブルがこの世に存在するのか？ 容量はいくらだ？ 467 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:20:56.93 ] 10^3だからわざわざデメリットばかりの方法使うって？ あほだな。 だいたい元の状態から比較したら、10^3じゃなくてストレッチングの意味がなくなるんだぜ。 レインボーテーブルはHDD容量でぶつかるって？ だったら最初からソルトとかテーブル化を防ぐ処置なんていらないんだよ。 なのになんでそれを防ぐようにしてるんだ？ まあそもそもテーブルだってそうあたりじゃなくて辞書をい使うんだがな普通は。 ソルトが10^3ってのも少なすぎて笑うけどな。 468 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:22:19.40 ] はい今度はレインボーテーブル対策は無意味とね。 くすくす、次は何を言い出してくれるのかな。 469 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:23:01.52 ] >>466 誰がそんなこと言ったんだよきちがい。 470 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:23:27.14 ] >>466 これ以上無知をさらす前に消えろよ。 471 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:25:13.76 ] だいぶ前にexcelの暗号化ファイルのパスワード解析した人がいたなあ 472 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:27:03.68 ] WindowsのNTLMv2だったかなんかはレインボウテーブル実在したよな確か。 あれはソルト使ってねーからな。 チャレンジレスポンスに対応するためやむを得ないんだが。 473 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:28:02.23 ] 8文字以上のパスワードにするだけで、 そんなレインボーテーブルはこの世に存在しないから、総当りしかない。 ここで防御力を発揮するのがストレッチング。メタルスライムレベルの防御力。 474 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:29:25.00 ] >>470 無知はおまえだ。存在しないものは存在しない。 あるなら、どのハッシュのものでもいいからURL張れ。 475 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:33:23.37 ] だから辞書と組み合わせるんだっつの。 本当にあほだなお前。 476 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:34:51.85 ] あとそもそも実在するかどうかなんて関係ないんだよ。 暗号にかかわるならそんなことは常識で理解できるだろ。 実在実在見当はずれなこと言ってるのはお前だけ。 477 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:37:07.19 ] 8文字長のレインボーテーブル出せで、なんで辞書の組み合わせテーブルなんだよw テーブル劣化しすぎwwww 478 名前： ◆QZaw55cn4c mailto:sage [2012/04/11(水) 23:37:18.90 ] >>465 ＞通信経路の暗号だと ＞鍵が見えたら、どうにでもなることでしょ、アルゴリズムがバレてたら そのとおり。 しかし、通信を行う双方で同一の鍵を使うことが可能で、かつその鍵が第三者には明らかにならない方法が存在する。 つ「DH鍵交換」 あるいは、暗号化で使用する鍵と復号化で使用する鍵が異なり、送信側に暗号化用の鍵を渡して、自分の復号化用の鍵を秘密にしておく方法もある。 このとき秘密にしている復号化用の鍵は、暗号化用の表に公開する鍵からは簡単には計算できない仕組みになっている。 つ「RSA暗号」「公開鍵暗号」 つ「一方向関数」 479 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:42:25.12 ] >>476 実在しないことが前提で今の暗号化の強度は成り立ってます。 実在したとなればそれは破られたと同義です。DESがいい例。 480 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:43:01.39 ] >>478 片側しか見えんとでも思ってるの、今のnet環境？ その手のやつは、ある程度時間経つと鍵変えてるような気がするけど 481 名前： ◆QZaw55cn4c mailto:sage [2012/04/11(水) 23:47:22.17 ] >>480 ＞片側しか見えんとでも思ってるの、今のnet環境？ kwsk ＞ある程度時間経つと鍵変えてるような気がする 素数を使用するタイプの公開暗号系では、確率的ではあるが素数判定方法があるので、お手軽に素数を算出してはそれを暗号に使用している。 お手軽に算出する程度のものだから、頻繁に鍵＝鍵に使用する素数を変える必要があるのだろう。 482 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:47:53.00 ] >>477 なんで勝手にお前が出した条件にあうものを応えなきゃならないんだよ基地外かお前は。 お前が言ったテーブルが実在するかなんて誰も問題にしてないんだよ。 っていうか誰も実在するなんて言ってない。 馬鹿かよ。 お前が言ったテーブルがなければそんで安全なのか？ 論点ずらしまくってんじゃねーよこの基地外。 それで済むなら暗号技術なんてどうでもいいもんばっかなんだよ。 お前はひとりで繰り返し回数をソルトの代わりに使うバカシステムでも作ってろよ。 まともな人間が見たら指摘されるだろうけどな。 483 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:48:10.70 ] >>478 見えるのは途中の経路にぶら下がったところだからね 末端の人には見えないから安全ってだけでしょ 484 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:49:01.56 ] まさか>>415-416の話に賛成できない人がいるとは思わなかった。 Security through Obscurityと言われたりもするっけ。byだっけ。 >>415-416の考え方を「知らなかった」ならわかるけどそれに反論するとか どんなチャレンジャーだよ。 485 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:50:07.59 ] >>479 また論点がずれてるぜ。 それは安全性の保証じゃなくて、すでに破られているわけではないことの保証にしかならない。 現実に破られてないからOKなら、128ビットの暗号化なんて不要。 危険性の説明に実在するかどうかなんて関係ないだろうが。 実在しないのは安全性のための必要条件に過ぎない。 486 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:51:41.65 ] >>482 じゃあ、単純に実在しないよと言えばいいのに、 なんで「これ以上無知をさらす前に消えろよ。」なんだよw キミの感情を複合化してやるよ。 くやしいんですね。わかりますw 487 名前： ◆QZaw55cn4c mailto:sage [2012/04/11(水) 23:51:43.34 ] >>483 残念だがその意見は違うだろう。 公開暗号系を使用すれば、途中の経路で通信内容が全部傍受されたとしても、暗号を解読することは事実上不可能だ。 末端でみえようとみえまいと、あるいは途中の経路でみえようみえまいと、プロバイダがすべての通信のログを取得しようと、安全性には全然関係ない。 むしろ Windows のログオンパスワードの脆弱さといったら、お話にならないくらいだ。 488 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:51:56.04 ] ああ、>>479は人違いで逆の意味でいったのかな、だったら勘違いすまんね。 489 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:53:47.07 ] IPSecは糞と言いたいんだな。 490 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:55:30.35 ] 実在しないかどうかは知らないもん。 お前が初めから実在するかどうかが重要ってスタンスで聞いてくるから、 実在するかどうかは関係ないって言ってんだろうが。 悔しいって笑わすな、ずっとずれたこと言い続けてんのはお前じゃねーか。 実際に実在しない保証はないが、まあおそらく総当たりのテーブルは実在しないだろう。 で、だからどうしたの？そんなことは話の本筋に関係ないといってる。 491 名前： ◆QZaw55cn4c mailto:sage [2012/04/11(水) 23:56:00.33 ] >>484 最初に暗号に触れる人には、理解に一定の困難が伴う考え方だと思う。「チャレンジャー」も理解を促進するひとつの方法だろう。 ただ理解しているものはそれに丁寧に回答する義務はあるかもしれない。 492 名前：デフォルトの名無しさん mailto:sage [2012/04/11(水) 23:58:06.14 ] ＞キミの感情を複合化してやるよ。 噴いた。 493 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 00:02:25.62 ] 話の本筋を理解できないもしくはごまかし続ける相手に説明するのは無理、時間の無駄。 どうせごまかしたり論点ずらしたりするだけなんだから。 繰り返し回数をソルトの代わりに使うことの合理性をきちんと説明してみろって。 ああ、こいつの言い分だとそもそもソルトとかテーブル対策は要らないんだったｗ 8文字以上のレインボーテーブルは存在しないのでテーブル化対策は不要です、キリっ 494 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 00:09:35.68 ] >>487 流れてるパケットの量が半端じゃないからね ピンポイントでやろうってのがいないだけなんじゃねえの？ 495 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 00:11:14.65 ] 中間者攻撃でアウト。 特に無線LANとかだとひっかけやすい。 だから証明書とかが必要なんだな。 496 名前：484 mailto:sage [2012/04/12(木) 00:12:58.03 ] >>491 確かに暗号の話を教える/教わるとき最初の山が公開鍵暗号あたりで、その次が Security through Obscurity(がダメという話)かもしれませんね。順番は逆かも？ とはいえ俺は理解はしてるけど他人を理解させられるレベルではないので えらそうなことは言えませんね。 497 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 00:15:05.53 ] レインボーテーブルの弱点はsaltと長パスワードでOK？ 498 名前： ◆QZaw55cn4c mailto:sage [2012/04/12(木) 00:26:39.87 ] >>496 なに、理解はらせん状に行きつ戻りつ進んでいくものだし、他人に説明することは自分の理解の深化にも寄与すると期待している。 ここは匿名の場であるし、遠慮なく自分の考えの述べるのはお互いにとっても最終的に利益になると思う。 お考えをうかがいたい。 499 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 00:43:26.82 ] C++のAES256の枯れたライブラリってある？ 500 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 08:54:02.73 ] >>497 OK 501 名前：デフォルトの名無しさん mailto:sage [2012/04/12(木) 09:06:07.92 ] しかし、英数字パスワードだと、1文字辺りって6ビット程度だよな。 記号入れても7ビットはいかないが。 8文字だと48ビット程度か。 ビット数だけならDESより余裕で弱いんだな。 まあそれ以前にパスワードのエントロピーなんて乱数よりずっと低いが。 48ビットだと組み合わせ数は256Tか。 計算途中を再開するためには全情報が要るが、 単なるテーブルなら先頭の例えば64ビット分だけでも十分かもしれん。 とすれば8バイト×256Tで、2Pバイトか。 暗号関連の、ホントに現実的じゃない安全想定に比べたら、 余裕で実現可能なレベルだな。 502 名前：デフォルトの名無しさん mailto:sage [2012/04/13(金) 04:47:14.97 ] Ciphertext stealingって1ブロック以下のときはどうやってパディングするの？ 503 名前：デフォルトの名無しさん mailto:sage [2012/04/16(月) 08:36:16.49 ] 楕円曲線暗号の掛け算について分からないので教えて下さい。 ｈttp://deztec.jp/x/05/faireal/23-index.html このページ中で「同意された点8に75を掛けると点26になる」 という部分なのですが、点8に75を掛けてみても点26に出来ません。 どの値にどのように掛ければ良いのか、教えて頂けると幸いです。 504 名前：デフォルトの名無しさん mailto:sage [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になる相手の数）のこと。 505 名前：503 mailto:sage [2012/04/16(月) 10:50:04.28 ] >>504 回答有難う御座います。 まだ試してないので、ちゃんと理解出来たのか怪しいですが もう少し頑張ってみます。 506 名前：504 mailto:sage [2012/04/16(月) 14:45:35.89 ] >>505 >>503で貼り付けているsite内を検索してごらん 507 名前：デフォルトの名無しさん mailto:sage [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 メッセージ認証と鍵ラッピングは知ってたけど 認証子付き暗号化とかディスク暗号化なんてのもあるのか 508 名前：503 mailto:sage [2012/04/16(月) 20:42:26.64 ] >>506 追加のアドバイス、有難う御座います。 ちゃんと理解する為には色々と検索しなければならなさそうですがｗ、 今考えている方法を試して駄目だったら検索もやってみます。 509 名前：デフォルトの名無しさん mailto:sage [2012/04/18(水) 18:17:06.76 ] 共通鍵暗号におけるIV(initial value?)というのは、 解読時までKeyと一緒に覚えておく必要があるのでしょうか？ もしそうなら、公開鍵暗号と一緒に用いる場合、 Keyと一緒に暗号化しておくべきでしょうか？ 510 名前：デフォルトの名無しさん mailto:sage [2012/04/18(水) 18:40:15.18 ] cbc modeの話だと仮定します。 IVは暗号化前に生成しておいて、 復号時にも同じ値をIVとして使用します。 通常IVは暗号化しません。 また、Keyは対称鍵暗号で使う対称鍵のことと仮定しますが、 Keyのみを公開鍵暗号で暗号化して、 暗号化対象の実体は対称鍵(Key)で暗号化します。 511 名前：デフォルトの名無しさん mailto:sage [2012/04/18(水) 19:22:56.39 ] 情報が不足していてすみませんでした まさに対称鍵暗号のCBCやCTRを想定していました 回答ありがとうございました 512 名前：デフォルトの名無しさん mailto:sage [2012/04/24(火) 18:42:15.56 ] コンテンツ暗号化するときは毎回コンテンツごとにコンテンツ暗号化キーをランダムに生成。 で、コンテンツ自体を暗号化(だいたい対称暗号で)。で、コンテンツ暗号化キー自体を 自分の何からしの鍵(キー暗号化キー)で暗号化して、その暗号化されたキー暗号化キーと暗号化されたコンテンツをセットに する。キー暗号化キーをどうするかは用件しだいで、>>510のように、公開鍵暗号で暗号化したり、 パスワードベースにするならPBKDF2などのキー導出関数を使って、導出させる。 513 名前：デフォルトの名無しさん mailto:sage [2012/04/24(火) 18:46:06.85 ] まぁ、暗号化だけじゃ、機密性しか提供できないから、一貫性チェックのために、 暗号化する前に、コンテンツのハッシュを求めて、コンテンツとハッシュをあわせたものを 暗号化するなどして、復号化時に、コンテンツの一貫性をチェックできるようになる。 Windowsの暗号化ファイルシステム(EFS)をだいたい同じ。EFSは使用するとEFS用の 自己署名された証明書とその公開・非公開鍵ペアをつくって、その非公開鍵が キー暗号化キーになるイメージ。 514 名前：デフォルトの名無しさん mailto:sage [2012/04/24(火) 18:55:04.74 ] コンテンツ暗号化キーを暗号化するときに、１つのキー暗号化キーで暗号化するのでは なく複数のキー暗号化キーを使って、暗号化されたコンテンツ＋複数それぞれのキー暗号化キー で暗号化されたコンテンツ暗号化キーをセットにしておけば、１つのキー暗号化キーを 忘れても他ので復号化できるので安心。EFSに回復エージェントって仕組みがあるけど まさしくそれ。 515 名前：デフォルトの名無しさん mailto:sage [2012/04/24(火) 19:43:56.51 ] 暗号化ファイルシステムがハックされたら、終わり 516 名前：デフォルトの名無しさん mailto:sage [2012/04/25(水) 05:49:50.07 ] 「ハックされたら」の一言で計算量理論もなにもかもをふっとばせるバカはお気楽でいいな 517 名前：デフォルトの名無しさん mailto:sage [2012/04/25(水) 06:20:04.43 ] Windowsの暗号化ファイルシステム(AES256+(ECC256 or RSA2048))はザル。 ログインパスワードさえ突破しさえすれば丸見え。大半は辞書攻撃で突破可能。 518 名前：デフォルトの名無しさん mailto:sage [2012/04/25(水) 07:23:33.81 ] 鍵の不適切な運用を前提に議論するとか、最強の論理体系ですねw 519 名前：デフォルトの名無しさん mailto:sage [2012/04/25(水) 07:31:34.85 ] 事実、現実が不適切な運用だらけなのに、 それを前提にしないシステムは欠陥ありというべきであろう。 最低限、EFSを使用する場合には、ログインパスワードのセキュリティポリシーを 強制的に厳しくするべきだね、MSは。 520 名前：デフォルトの名無しさん mailto:sage [2012/04/25(水) 17:04:02.53 ] 個人用の場合、忘れたもしくは自分が死んだらおしまいの、パスワードベースでいいんだけど、 EFSは証明書に基づく公開・非公開鍵要求するからふざけるなって感じ。 BitLockerでいいよ。 521 名前：デフォルトの名無しさん mailto:sage [2012/04/26(木) 02:50:46.22 ] コンテンツのハッシュをとってから暗号化するのと、 暗号化してからキー付ハッシュをとるのとどっちがいい」？ 522 名前：デフォルトの名無しさん mailto:sage [2012/04/26(木) 04:18:20.27 ] >>521 暗号文とハッシュ値、ハッシュの秘密鍵と復号鍵の格納場所がどこで どんな経路を通じて誰が一貫性（完全性ともいう）チェックと復号をするのかによって いろいろ変わるのかもしれないけど、一般的にはEncrypt-then-Macといって （１）最初に暗号化する （２）次にその暗号文のキー付きハッシュをとる という順番になる もとのデータを利用したいときは （１）まず暗号文の完全性をチェックする。エラーを検出したらそこで終了 （２）暗号文を復号する という手順になる この順番にすることで、勝手なデータを復号処理に入力して、その出力結果を観測して 暗号の安全性を破る攻撃（選択暗号文攻撃）を防ぐことができる あるいは最初から秘匿とメッセージ認証の機能をあわせもつ 認証付き暗号（認証子付き暗号ともいう）を使うという手もある 523 名前：デフォルトの名無しさん mailto:sage [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(要は暗号化)の入力になるとは書いてある。 524 名前：デフォルトの名無しさん mailto:sage [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では、ハッシュを先にするべきなのかなとハッシュを先に書いた。 525 名前：デフォルトの名無しさん mailto:sage [2012/04/26(木) 11:54:55.18 ] >>522はtools.ietf.org/html/rfc5083のAuthenticated Enveloped Dataかね。 526 名前：デフォルトの名無しさん mailto:sage [2012/04/26(木) 12:29:28.11 ] まぁ、RFC3852(5652),RFC3370,RFC5754,RFC3565を気合入れて読みながら、Windowsの CryptoAPIのCMSを操作する関数をここ2週間いじくりまくって身に付けた程度の知識だから、 Secruity Condisderationsとかそこまでは手回ってなく、詳しくはわからんけど、 選択する暗号アルゴリズムやハッシュアルゴリズムを強度が高いものにして、 後は鍵管理をしっかりしとけば、ハッシュした後、暗号化しとけばとりあえず 問題ないとは思うけどな。自分だけ復号化できればいいんだったら。わざわざ、 メッセージ認証する必要ねぇとは思う。 527 名前：デフォルトの名無しさん mailto:sage [2012/05/11(金) 13:32:46.81 ] OpenSSLのRAND_bytes()を使おうと思うのですが、 RAND_add()は、常駐してエントロピーを収集するようなプログラムが使うもので、 ユーザープログラムは、RAND_bytes()を呼び出すだけで済むという認識で正しいでしょうか？ 528 名前：デフォルトの名無しさん mailto:sage [2012/05/11(金) 15:01:32.57 ] RAND_add()は、RAND_seed()とほぼ同じ関数だよ。 乱数の乱数性を強化する際に使う関数。 >>527はRAND_bytes()を呼び出すだけという認識でいいよ。 529 名前：デフォルトの名無しさん mailto:sage [2012/05/11(金) 16:37:59.92 ] 毎回種蒔くのは面倒だと思っていたので、すっきりしました 回答ありがとうございました 530 名前：デフォルトの名無しさん mailto:sage [2012/06/05(火) 18:30:28.73 ] CIPHERUNICORN-A、Hierocrypt-3、SC2000の ソースコード探してるのですけど 在りかを知ってる方がいれば教えて頂きたいです。 …できれば言語がCだと有難いです。 531 名前：デフォルトの名無しさん mailto:sage [2012/06/06(水) 20:56:26.20 ] Hierocrypt-3はあった ci.nii.ac.jp/naid/10016220863 532 名前：デフォルトの名無しさん mailto:sage [2012/06/07(木) 09:10:40.65 ] >>531 ありがとうございます！ 非常に助かりました。 533 名前：デフォルトの名無しさん [2012/06/15(金) 13:43:33.76 ] これからはCDのコピー禁止フラグのような軽いプロテクトも流行るんじゃないかな。 534 名前：デフォルトの名無しさん mailto:sage [2012/06/15(金) 13:47:20.86 ] 何も重いプロテクトをかけるだけがいいことでは無い。 プロテクトを外す行為が違法ならあえて軽いプロテクトにして、外した者を どんどん逮捕したらいい。 535 名前：デフォルトの名無しさん mailto:sage [2012/06/15(金) 14:15:25.05 ] フラグ1個でも技術的保護手段っていうの？ 536 名前：デフォルトの名無しさん mailto:sage [2012/06/15(金) 14:17:14.63 ] 要はコピー禁止の意志がファイルに付いていると認められるということ。 537 名前：デフォルトの名無しさん mailto:sage [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に出荷時からウィルス「中国製のパソコンや情報端末の購入には、慎重になったほうがいい」★２ 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 ] 不正防止とコスト 市場はどっちを選択するんだろうなぁ 542 名前：デフォルトの名無しさん mailto:sage [2012/11/06(火) 15:19:32.37 ] 誰かがコストを選択して痛い目に遭ってから、不正防止を選択します。 顕在せぬ危険性について、株主が理解することは不可能でしょ。 どっかの株価大暴落がないと駄目だろうね。

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef