暗号

この暗号解いてみ〜〜
GP03DのCGがでてくるよん☆
解けたらあげまする〜

本場の的は私作の暗号アルゴが通用するかのテストだよん♪
CGほしい人はがんばってん


http://www.geocities.co.jp/SiliconValley-Sunnyvale/4822/aaas_a.jpg

１を読まずに・・・

>1
ファイルがねぇ（１０時２９分現在）

あるぞ。

> http://www.geocities.co.jp/（以下略
> 別のサイトにジャンプしようとし（以下略

ここで右クリックして「対象をファイルに保存」すれ。
ちなみに俺は暗号わからん

復号できる人物いないんかねこれ？

>>1
ファイル形式はjpgですか？
それとも、書庫か何か？

先頭は　FF D8 FF E0 00 10 4A 46 ？

view-source:http://www.geocities.co.jp/SiliconValley-Sunnyvale/4822/aaas_a.jpg

だと汚れたのがでてくるぞ

拡張子はjpgだけど内容は暗号化したデータですよん
右クリックで保存してくださいな

先頭は　DD D9 B2 02 8F　のはずっすよ
ちゃんと保存すればそうなるはず
こっちで落として確認とりましたです

>>9
いや、>>6は手をつけるきっかけがなかったので、
複合したら何のデータになるのかな〜？と思って。

>>10

>>1のとおりですよ

>>7

復号すればってことですね(爆死
そのとおり　FF D8 FF E0 00 10 4A 46　です
ってこれは誰でもわかるか

>>1
おまえ
「暗号が破られる」
の
「破られる」
という動詞の意味を勘違いしてないか？

暗号化されたデータを一つだけだされたって、
そんなの解読できるわけないだろ。
世の中に出回ってる､暗号を使って
暗号化前と､暗号化後のデータの関係を考えてみろ。

って言ってもわからなさそうだから書くと
ki番目とli番目のビットを入れ替える暗号を考えてみろ。
(i=1〜N)
でてくるビット列はランダムだろーが､このクソバカ

そして､マジレスしてるバカは少し頭使え

>>13
できる奴もいるよ。
そして、誰でもわかるようなことを偉そうに言うバカは少し頭使え

>>14
例えの暗号だけど、それじゃどのファイルにも適用できないんじゃない？

>>13

破ってこそ風呂だろ糞！！

>>15

s/4/3/g

>例えの暗号だけど、それじゃどのファイルにも適用できないんじゃない？
ビット列の長さも
関数を決定するパラメーターの一つと考えればいいだろ？

>>13
ある数字を暗号化しました
11111111
さていくつでしょう。
って言われてるのと変わらない。
1を50個くらい並べて、電話番号です、
って言われてるのと変わらない。
わかる？

この暗号はちゃんと解けますので安心してね
暗号と復号をするプログラムもちゃんと作りましたゆえ
がんばってみてね

>>3
ﾌﾟｯ
jpeg画像じゃねえんだから表示されるわけねえだろ

解けますた。
複合結果をここにあげとくよ。
ttp://www.ichigo.sakura.ne.jp/~rebanira/hager2/mokei/mokeido/gp03d.html

てゆーかＣＧでないし

デジタル信号化されてるから、一応CGなんじゃないの？

>>19
これで暗号が解けなくてもそれが通じるかどうかはわかんないよ。
なぜなら、今回与えられた情報は暗号化されたデータ一つのみ。
暗号復号アルゴリズムは非公開で復号したあとの画像もない。
こんな好条件なら、だれでも解けないアルゴリズムは作れる。
本当に通用するか調べたいなら、他の暗号解読テストと同じような条件にしようね。

>>23
そういえば確かに・・・

とりあえず暗号化ツールのほうがあれば解けるかも。
Perlのcryptみたいな

＞解けないアルゴリズム
「解くのが非常に難しい」のほうが正確でない？

暗号化する前のファイルを公開しましょうか？
ほしい人はラッキーかも
解きたい人もラッキーかも

以前こんなコードから少しパラメータの違うだけのを出題したけど解けなった

function　 MyCipherStr(const s:String;decode:Boolean):string;
var i,n,m,siz,r:Integer;
const k='ひみつ';
begin
RandSeed:=(ord(k[3])*$10000+ord(k[1])*$100+ord(k[2]));
Result:='';
siz:=Length(s);
r:=random($FFFF);
if decode then siz:=siz div 2;
for i:=1 to siz do begin
if decode then　n:= StrToInt('$'+copy(s,i*2-1,2))
　　　　　 else　n:= ord(s[i]);
　m:= ( n xor ord(k[1+(i mod Length(k))]) xor random(256)) xor (r and $FF);
if decode then　r:=(r*331 + m) else r:=(r*331 +n) ;
if decode then　Result:=Result+Char(m)
　　　　　 else　Result:=Result+IntToHex(m,2);
end;
end;

暗号化前・後の1セットだけではちょっと無理
何パターンか自分で任意のデータを暗号化したりして検証しないと・・・

ヒントとしては
パスワード・バイナリコード(キーファイルみたいなもん)・乱数
を使用して暗号化してます
パスワードは秘密鍵です
今回のはパスワード未指定

暗号復号アルゴリズムくらい晒せ

実は1の補数で暗号化を行っていたのです！

それって答えじゃん。

馬鹿だコイツ
そんなもん全くヒントにならないよ

統計からアルゴリズムを予測する>それなりのサンプルが必要
ゲームとかの暗号>逆汗

そもそも、キーファイルを使って暗号化した物なんか
ファイル一つじゃ普通解けないよ

実は1の補数+1で暗号化を行っていたのです！

乱数を使って暗号化したものを複合化できるもんなのか？？？
暗号化されたデータから、その乱数の値を取得する方法がないような
（ファイルの先頭とか最後に乱数を保存したりしない限りは）

とりあえず、実行ファイルを晒せ。話はそれからだ。

これだけ言って、このスレを上げる奴がいるなら
もう手遅れだな。

>「解くのが非常に難しい」のほうが正確でない？
非常に難しいというレベルがどのくらいかというと、無理の一歩手間程度です。

もう一度､ほとんど同じ事を書くけど、
1が暗号化したデータが、例えば全部1だった場合
どうやって解析するんだ？
１の暗号化の方法、あるいは暗号化前のデータによっては
暗号化した後のデータが1111.......である可能性はある。
たまたま、今回は違っただけ。
直感的に解析手法がない事くらい分かるだろ。

>パスワードは秘密鍵です
>今回のはパスワード未指定
この日本語って暗号化されてるんだよな？
この暗号を解くほうが、よっぽどためになるぞ。

>>37
処理系依存です、シードを保存してます。ってか？（ワラ

実はこのスレの記事は日本語に機械変換して偽装した.NET2のベータ版ソースコードです

>>32

教えろてか

パスワード処理-乱数初期化-暗号前データ読み込み-乱数取得-
乱数をもとにバイナリコードから暗号後データ取得-終了

>>41
そうだとしたら、スレの内容が極端に少なくないか？
そうか！ キーファイルが相当でかいんだ(w

>>42
　という事は >>29　の16進変換しないみたいな感じかな？

>>1
通用するかどうかって一体どんな用途を考えているんだ？
個人的な奴なら秘密鍵とのXORで十分だろ。

バイナリコードだけで7MBあるし(爆死

運用性の面からして通用しない罠

まあ好きにすればいいんじゃない

>>42
つーかね、標準乱数使ってるんじゃ完全にその処理系に依存してるし、
乱数が自前だとその説明じゃアルゴリズムの説明になってない。
単に概要を説明してるだけ

祝*乱数を使った暗号初登場・・・
乱数はキーでした・・・
作者「キーはパスワードです」
２ｃｈ「キー＝パスワードじゃないの？」
作者「キーは秘密鍵です」

祭りの方向で＞ﾐﾅｻﾏ

>>1
おまえのWEBサイトあっぷしちゃうぞ

>>39
＞1が暗号化したデータが、例えば全部1だった場合
＞どうやって解析するんだ？
確かにそのデータだった場合、無理の一歩手前程度だろうな。
だが現実に、そのような極端なデータに出くわす可能性は非常に低い。
1がどのようなアルゴリズムを用いていても、ほとんどのデータはそこまで極端にはならない。

>>1に問題。

次の16進数は私の名前を16バイトのバイナリコードで一文字ごとにXORしたものである。
パスワードも乱数も使用していない。さて私の名前は何か？

F4 36 3D 9B 5A EA 97 61 39 23 10 36 37 5B 87 63

ヒントは暗号後のデータが一つあるだけだけど、アルゴリズムも公開して
パスワードも乱数も使ってないから、>>1ならこれぐらい解けるよね。

溶けない奴の悪あがき(糞

>>54
おまえも>>53やってみろ。

じゃあ、聞くが
0111111111........だったらどうよ？
1011111111........だったらどうよ？
0011111111........だったらどうよ？

(i)(ii)より､仮定が正しい
帰納法終了

下の暗号は私の名前で私の名前を1バイトずつxorしたものです。
ごくごく単純な構造です、解読してください。

00 00 00 00 00 00 00 00 00 00 00 00

>ほとんどのデータはそこまで極端にはならない。
２ｃｈのレベルってこれかよ・・・

コインを振って表が出たら1､裏が出たら0
じゃあ結果を羅列すると
0010101110011100
これならあり得ると
0000000000000000
これはありえないと・・・
でも、これって最初の結果の、違う表現の仕方なんだよね。
3回目、5回目、７，８，９、１２，１３回目は
気分で裏が出たら1､表が出たら0って書くことにしたんだよ。

私のHNを暗号化してみました

　53 C0 8E FE A4 35 9D 54

解いてみ

っていうか、暗号化アルゴリズムの検証って
符号化複合化アルゴリズムを公開した上で、
それに虚弱性がないかを検証する事じゃないのか？
実際の現場で1のアルゴリズムを使って、
実行ファイルを解析されてあぼーんじゃいみないだろ

>>59
あんたの暗号アルゴリズムは少なくともココにいるレベルの人間じゃ解けないよ

1 使用している乱数発生アルゴリズムを再現しなければならない
2 キーファイルとやらも特定しないとならない

というか、ここで名前をエンコードしている香具師は、
とりあえず日本語の文字コードは明示しといてください。
おながいします。

>>58
すまん。俺が間違っていた。

>>59
「がる〜ら」だろ。

SJISﾅﾘ

>>64

解き方を考えてください

>>59
sasamijouyu

57ﾑｽﾞｲ…

なまえが６文字って珍しいな。

名字も含んでひらがなで６文字なり

>>67

答えは｢がる〜ら｣なんだって
解き方を考えて

ヽ(`Д´)ﾉ頭が痛い！！！！！！！！！！

上が「がる〜ら」をShift-JISコードで表したやつ
下がそれを暗号化したやつ
82 AA 82 E9 81 60 82 E7
53 C0 8E FE A4 35 9D 54

＞71
わからない、というより、多すぎて特定できない。

>>71
暗号前と、複合語を比較して調べるんだよ。
わかったら、お前も暗号前とアルゴリズムを公開しろ。

>>74

全部言え(糞

あと、バイナリコードとデフォルトのパスワードと乱数もね。

>>76
全部なんて言ってたらｷﾘがないが、
82>53
AA>C0
82>8E
E9>FE
81>A4
60>35
82>9D
E7>54
の変換テーブルを作る

>>75
間違えた。「暗号前と、暗号後」ね。

＞76
たとえば、z*(x+y)=2^64
を満たす自然数x,y,zを全部言えるのか？

もうそろそろ、>>1は自分の馬鹿さ加減に気づいたころかな。

>>80
対数取るとかわいい計算式に

>>80

全部言え(糞

>>81

溶けない奴の悪あがき(糞

＞83
一瞬スクリプト書いてこのスレつぶそうかとｵﾓﾀ

>>83 >>84
最後の糞って負け惜しみ？
なんか悪者が負けたときに言う「糞。覚えてろよ。」みたいな。

もうそろそろ、ここの住人は自分の馬鹿さ加減に気づいたころかな。

>>86
・・・・・・・・正解！

>>86

みたいな(糞

>>87

偽物は消えてきだせ

>>81
気づいたみたいよ。(>>87)

64 ：デフォルトの名無しさん ：02/05/24 22:45
>>59
「がる〜ら」だろ。

ヤバイ､腹が痛い。
面白過ぎ。

>>86

大正解(糞

やっぱり、「ﾈﾀﾃﾞｽﾀ」でごまかそうとするのかな。

z=1のとき、xとyは2^64通りか。
z=2のときは2^32通り
z=3は無しで
z=4は2^16通り
ハァハァ

ﾈﾀﾃﾞｽﾀ

>>96

消えてくれるかな

32 -> 63
16 -> 62か?

ヤバイ､このスレ
今までで一番おもしろい
笑いが止まらない。

１００エントロピーげと。

私は本気です。私の作ったの暗号アルゴが通用するか知りたいのです。

>>101

右に同意

だったらアルゴリズムを公開しろっつーの

げろ〜ら「キーはパスワードです」
２ｃｈ「キー＝パスワードじゃないの？」
げろ〜ら「キーは秘密鍵です」

スクリはＨＳＰで書いたから完璧です。

>>105

ずぼしです

>>103
それは秘密です。公開したら簡単に解かれるじゃないですか。
私の口の堅さが暗号強度です。

>>101
おまえの暗号はどういう流れで使うんだ？

例えば､俺が「abc」という文字を送りたかったとする。
どうするんだ？

マヂレス。

暗号のアルゴリズムが第三者のアタックに耐えうるものか否かを知りたいのなら、
ロジックを公開して検証してもらうべき。

あと「暗号の秘密とウソ」って本がためになると思うよ。一読の価値あり。

げろ〜らっ
じぇーむすぶらうん?

偽者やめようぜ。
つまんなくなってる。

結論

>>1のアルゴリズムは使えない。

ネタは他でやれ

>>113
>>113

うっさい！！！お前氏ね！！>>116

アルゴは以下のとおり

パスワードを元に乱数を初期化−元ファイルから1バイト取得−乱数取得−
乱数を元にバイナリコードから1バイトデータ取得−データ置き換え−
元ファイルから次の1バイト取得−乱数取得−・・・・

簡単だけどまず解けないかと

　

そういや、SSLにClientCertificationってあるやん。
あれってクライアントに証明書くばらないかんけど、
その証明書が逆汗されたりして、取られてほかのアプリとか
につかわれたりせえへんの？

おまえの暗号はどういう流れで使うんだ？

例えば､俺が「abc」という文字を送りたかったとする。
どうするんだ？

>>118
公開鍵暗号

>>116
それはアルゴリズムって言わないんだって
フロー（チャート｜リスト）って言うの。

>>116
復号はどうやるの？

>>121
アルゴとか人前で平気で言う時点で痛い。

>>121

アルゴリズムってのは処理の流れのことですよ
フローチャートもアルゴリズムのあらわし方の一つ

究極の圧縮スレ以来の馬鹿スレですかここは

>>123
日本語わかんないのか？

>>124
必要な情報(ex.乱数)の定義がされていないので、
フローリスト以外の何者でもなく、アルゴリズムとは呼べません。

>パスワードを元に乱数を初期化−元ファイルから1バイト取得−乱数取得−
>乱数を元にバイナリコードから1バイトデータ取得−データ置き換え−
>元ファイルから次の1バイト取得−乱数取得−・・・・
素人の俺が代わりに書き換えると、
パスワードをシードとした乱数列Rn
8ビットごとの（ブロック）暗号化を行う関数F(text,param)
暗号化したいテキストをTn
暗号化したテキストをRn
Rn=F(Tn,Rn)
とする。

>>127

アルゴリズムの意味わかってる？

＞120
公開鍵暗号をどう使うと、そのての攻撃に安全になるん？

>>116
この方法は暗号の初歩ですね。まさかこれだけ？

Cのrand関数を使うことが前提か？
あれ、乱数と言うにはお粗末。

>>116

初歩だけに溶けにくい(糞

要は乱数の生成ルーチンさえ見破れば言い訳だ。
で、生成ルーチンの暗号化はどうなってるの？

結局>>1のアルゴリズムは復号の計算量が少ないので
復号ソフトさえあれば簡単に解けるということですね。

>>135
ネタスレにマジレスですか？

>>132
あれってなに？
実装まで規定されてないんで、別に線形合同法を使おうが、MTを使おうが問題ないんだが。

がるーらという方は暗号の基礎を勉強した方がいいと思います。

>>136
えっこれってマジレスになるの？
俺、暗号とかそんなに詳しくないのに。
えへへ。

乱数わかってもバイナリコードわかんないとね
何通りあると思ってんの？

というか、>>1 よ。復号はどうするよ？
パスワードを与えれば、数秒以内に復号できるプログラムはあるんだろうな？

>>140
意味不明なので解説して下さい。

結局暗号化するにも複合化するにもバイナリコードが必要なので
バイナリコードを公開しないと意味無い思いますが。

>>143
バイナリコードってなんですか？あなたの言う。

バカばっか

>>145←MVP

>46から予想するに
プログラムに7MBの固定のバイナリ列を含んでいるんでしょう。
暗号化も複合化も乱数シードを指定して得られた数値に従って
この辞書となるバイナリ列を参照するだけという
ネタレベル暗号化プログラムじゃないでしょうか。

２ｃｈのレベルも高が知れてる。

＞何種類あると思ってるんですか？
バイナリダンプって知ってますか？

>>130
自分で調べてくれ

>>149
ダンプ松本って知ってますか？

>>147が正しいとすると
がるーらは小学生レベルの頭しかなさそうだな。

>>1が作っているのは個人向け暗号ソフトです。
自分で暗号化して自分で復号する以外には使えません。

>>147

そこまでわかってんなら溶いてみろ(糞

きっとプログラムは非公開で必要な人に手渡しするんですよ。
これだとバイナリダンプできないでしょ。

復号の字を間違えているﾔｼがいますね。わざとですか？
もしそうでなかったら…

本名なんだっけ？エリカだっけ？エリナだっけ？

ここで少し視点を変えて

＞この暗号解いてみ〜〜
＞GP03DのCGがでてくるよん☆
＞解けたらあげまする〜

＞本場の的は私作の暗号アルゴが通用するかのテストだよん♪
＞CGほしい人はがんばってん

敢えてデンドロビウムの著作権的観点から追い込んでみるというのは？

155=1
と野暮なことを言ってみるテス（以下省略）

>>159
いや、まさかそれはないだろう。痛いにもほどがある。
ありえないとはい（略）

祭り終了の予感
最後にどうやれば､暗号破れるか教えようかな・・・
どうしようかな・・・

これは2000念前のシーザー暗号という変字式暗号と同じと思われ･･･(以下省略)

>>1ってこのアルゴリズムをどういう用途で使用するか答えてないんだよね。


わ　ざ　と　で　す　か　？

というわけで烈しくネタスレでした。
1の頭の悪さは分かって頂けましたでしょうか？
皆様わざわざ時間を無駄にしてまでこのネタスレに
つき合って頂いてありがとうございました。

>>162
あるテーブルとあるテーブルの要素が１：１対応してるって奴？

>>165
で、そのテーブルが7Mある。

256^7000000とおり？

結局ネタだったみたいだけどわざわざ
http://www.geocities.co.jp/SiliconValley-Sunnyvale/4822/aaas_a.jpg
を公開したのはうまいよね。
こうするとツールも一般公開するように見えるから。

>>167
で、そのテーブル自体は平文なのでやろうと思えばいくらでも解析可能と。

暗号文が完全な平文を含んでいない時点で暗号データとしての価値はなし。

>>169

一生終わりそうにないけど

>>153が答えです。

本物は自分のバカさ加減に気づいて逃げたようです。

>>171
まぁ、逆アセンブルされるだけで使い物にならなくなる暗号は暗号としてダメっしょ。

>>173

見学中です

私の暗号は完璧です。

＞150
たとえば、
http://www.zdnet.co.jp/help/howto/win/win2000/0007special/directory/18.html
で、ここの４やと思うけど、クライアントとして、必要なデータはみんなソフト
(client)の中にあるわけで、抜き出し可能なのでわ？ってことなんやけど……

良く考えてみたら、暗号プログは
あまり公開しない方がいいですね。

では

ところでガンダムはやっぱり0083ですね
モーラの乳首がかろうじて見えたり見えなかったり

つまらなかった。暗号の基礎未満だったし。

>>180

溶いてから言え(糞

良く考えてみたら、暗号プログは
あまり公開しない方がいいですね。

良く考えてみたら、暗号プログは
あまり公開しない方がいいですね。

では


何がしたかったんだろう？

>>181
そもそも解けるたぐいの物じゃないし、
万が一解けたとしても意味がある物じゃない

>>184

バカの負け惜しみ(糞

>>183
後悔したかったんじゃない？

ようするに使い道0です。
暗号化・復号化プログラムを本人に直接渡すくらいなら、
本人に直接データだけ渡した方が速いし。

>>1　これでも読んで出直せ。
http://www.amazon.co.jp/exec/obidos/tg/detail/customer-reviews/-/books/4881359967/250-6299661-4476243

>>185
そうです、馬鹿の負け惜しみです。
しかし、偶然に頼って今回のケースが解けたとして、
その解くことが出来た課程や方法は全く再利用が聞かない
技術的価値が全くない物です

がるーら氏は本気でやってるわけじゃないですよね。
まだ>>185のように騙されてる人がいるからやってるだけですよね。
もしかして本気？

>>177
だから､公開鍵暗号嫁って

>>128
よく考えたらランダムインデックスによる単純なテーブル置換じゃ
復元できないじゃん

>>190
まだ､中学生なので

みんな驚いた？

で、結局このスレは何だったんですか

大がかりなｵﾅﾆｰ

じゃあもう寝ます

>>192
だから覚え立ての疑似乱数をつかってるんじゃ？
どっちにしても

　　　　　（（　　　　　　　　）　））
　　　　（（　（　　　　　）　　　）　）
　　　（　（　　（　　　　）　　）　 　）　
　　’　（（　　　　　　　　　　）　）　）
　　　　　（　（（　｜　｜　　）　）
　　‘ 　　　　（（ ｜　｜　）　）　　‘
　　　　　’　　　 ｜　｜　　　　　　　　　　　　　　　　　　　　春ですね。
　　 ○ｲｻﾞﾍﾞﾗ! ｜　｜　 ’　ξ○ξ ｽﾐｽ･･･
　−＋−　　　 ｜　｜　　　 　 Ｖ　，
　　 ｜　　　　　｜　｜　　　　 ｜　　
　 ／＼　　　　／　　＼　　 　／＼

.<ﾓﾐｼﾞﾏﾝｼﾞｭｰ

λ..... ＜ ２００エントロピーげと…

次はマ板に立てやがった。

アゴ
http://pc.2ch.net/test/read.cgi/prog/1022253343/l50

なら、レスもコピペしますか？

soregaii

本人が立てたわけじゃないと予想されますが…

compjapanよりマシ。

204=1
とまたまた野暮な予想を立ててみるテスト（以下省略）

完全に>>128の通りだとやっぱり復号できなくない？
暗号化した後データサイズが4倍になるならわかるけど。

実行ファイルわたしましょうか？

まさか本人が釣れるとは…

>>209
相手は中学生なんだからそれくらいで許しといてヤレよ。

一式うｐして下さい
アルゴリズム批評スレに移行せよ

>>210

気味こそ中学生(糞

「xyz」

これは私の発明した暗号で、ある文字列を暗号化したものです。
さて、もとの文字列は何でしょう？ 解けないとしたら、この
暗号が実用的だと言うことですね。

(↑　1の言ってることはこれと同様。)

>>213
examine your zipper

>>213
つーかそれはもうみんな知ってる。


要するにこういう事だろ。
#include <stdio.h>
#include <stdlib.h>

const char binalytable[RAND_MAX] =
{
　　固定データを適当に
};

main()
{
　　srand(password);
　　for(ファイルの終わりまで1バイトずつ)
　　　　putchar(getchar() ^ binalytable[rand()]);
}

binaly->binary

>>213
街狩人を呼ぶ為の暗号だろ

>>215
これだけの事に12時間もかかるとは
2chは相当レベル低いな。

>>212>>218
糞スレageんなヴォケ

その7MBのファイルの一部がこんな感じなんだろ。

　2201 4de2 8fca 1d52 020a b9b1 f51c 54bc
　71ff e2de 97c7 d292 f728 8e7a 3b1b d25d

つまらんな。日本語のテキストでも出るかと思ったんだが。

同じひとつのプログラムで暗号化も復号もできるんだろ？
2回通せば元に戻ると。

プログラムを公開すると安全でなくなるような暗号は、
現在では暗号のうちに入らない。

まあ中学生にしては上出来だと思うよ。
窓際プログラマどもを数十分×数十人は悩ませただろうからね。

>>222
暗号を解くのにじゃないけどね

>>215
世に出回ってる偽装ツールはこの程度の事しかしてないソフトも
結構あるんじゃないか？

>>222
＞×数十人
え？ 1と俺とあんたの3人しかいないぞ。

>>224
ファイルをトップダウンからボトムアップに変更して保存するだけでも暗号化。
昔やろうとしたがばかばかしいのでやめた。

溶いてから言え(糞

>>226
ひっくり蛙か？

暗号化して復号化もできるの作ってるだけマシ
本人も解けない暗号を公開して勝ち誇るよりマシ
すべてマシ

>>215
>const char binalytable[RAND_MAX] =
<const int TABLESIZE = 7000000;
<const char binalytable[TABLESIZE] =

>putchar(getchar() ^ binalytable[rand()]);
<putchar(getchar() ^ binalytable[rand() % TABLESIZE]);

じゃないのか？恥ずかしいぞ。

そういや、昔、自作暗号ソフトをつくって、エロ画像を
暗号化したら、ロジックにバグがあって復元できなく
なった、という香具師がいたな。

>>231
漢の中の漢

ビットを反転させただけでも暗号化ですか？

>>232
本当に漢の中の漢だったら暗号化なんかしないで堂々と壁紙に使うだろ

前から読んで後ろから吐けば暗号化です。

>>233

暗号化　＝　他人にわからないデータに置き換えること

から考えるとそうなりますね

つーか、shift-jisやその他も暗号化♪

つーかバイナリダンプも暗号化。

>>238
(ﾟДﾟ)ﾊｧ?

>>237の
符号化=暗号化は分かるのですが

>>238は意味が良く分

＞238
暗号＝「なんかよくわからない文字列」ってことカナ？

分かりますた。

可逆的でエンコード後は元のデータとしての役割を果たせないもの？

こいつの暗号って実は再強かもよ
７Mのテーブル全部試すのに1000年、2000年じゃすまないぞこれ

漏れはテーブルを100MBにして更に強力な暗号化ソフトを作るぜ。

>>244
7Mは多すぎ。

がる〜らが将来プログラマになると仮定すると、
このスレの住人の半分は10年後にはがる〜らに技術力で抜かれます。

>244
ていうか、7MB以上の(14MBくらい？)
オリジナルと暗号化ファイルのセットがあればよいのかも。
テーブルの出発地点を決めた後はぐるぐる回って使ってるだけだろうから。

>>248
乱数の種はパスワードで決まるから別のパスワードかけられたりしたらどうするよ。

>249
テーブルのスタート地点決めてるだけじゃないの？パスワードは

>>250
それはsrandどrandの実装次第じゃないのか？

>>250
って事は、３バイトもあれば、パスワードが重複するってか？

>>250
32bit値の種でsrandして、
randを7000000回実行するんだよ？
スタート地点決めてるだけじゃないだろ？

>>247
つーか、16歳までに世界最強の暗号を作ってほしい。

>>248
とりあえず7MB以上じゃ間違いなく無理。
4G以上いるんじゃないか？

1) パスワード入力　→　16bitのチェックサム取得
2) それを7MBのテーブルのスタート地点とする。
3) そこから1byteずつ拾って元のデータとXORとる。
だけかと思ってるんだけど。
(↑これが違ってたらスマン)

すると100KBのファイルのセット（オリジナル＆暗号化）なら70〜140個とか
（パスワードが違ってスタート地点の異なるもの）
があれば、そこからテーブルの一部を割り出して
共通する部分を重ね合わせてつなげていけば元の7MBのテーブルが得られるのではないかと。

いったんテーブルが解析できてしまえば、パスワードがかかっていても
JPEGの最初の数バイトは分かってるんだから
テーブルのどこから使いはじめたかはパスワード無しでも大体推測できるんではないかと。

なんか違うような気もするんでちょっと前の方読んできます。

>>256

1バイトごとに乱数を使ってるみたいだよ

>>250には難しすぎたのか？
1) パスワード入力　→　32bitのハッシュ取得
2) 1のハッシュを種に乱数列初期化
3) 次の乱数を取得する
4) テーブルの(3で取得した乱数/テーブルの大きさの余り)番目のバイトと元データのxorを取る。
5)3)と4)をファイルの終わりまで繰り返し。

窓際プログラマどもの10%くらいは今のがるーらに負けてる予感。

>258
あ、なるほど。ちがってましたね。すみません。

パスワードが同じなら1つファイルのセットがあれば他のも解けるのかな。
（長さがそれより短いファイルなら）

ここに書きこみしてる奴等は全員バカです。
１に使われてるとも知らずに・・・。

１は、今ごろ友達にでも自慢してるでしょう。
2chの奴等が解読できない暗号化アルゴリズムを作ったってね。

まぁ〜、2chにいるやつらはアホしかいないので、ぜんぜん自慢にもなってないけど。

単に俺が言いたかったのは、お前等はアホ。 解読できるわけあ〜りましぇんかぁ〜。

>>261
溶けそうだけど、ハッシュ関数にファイルサイズ等も一緒に使われたら終わりだな。

(このスレの住人の7割)>>>>がるーら>>>>>>>>(残り3割)>>>>>>>>>>>>>>>>>>>>>>>>>262

>>262
解読してからいえ。

>>262

負け犬の遠吠え(糞

>>262
少なくともお前が中学の時には>>1のレベルの暗号化は思いつかなかっただろうな。
まあお前が中学卒業したかどうかは定かではないが。

なんか勝手に中学生にされてるし
中学生じゃないんだけど・・・
パソ暦13年だし
最初に触れたプログラムはN88BASICだし

>>268はがるーらが中学生である事を信じたくない
リストラ寸前職業プログラマ。

本物なんだけどね
18歳だし

>>270

18歳窓際糞グラマ

>>271
鏡でも御覧になりましたか？

本当は26歳です。

本当は６歳です。

>>273は100%偽物で、
>>270はどうだか分からんので

とりあえず今の職業プログラマの3割は中学生以下の
論理的思考力である事が分かりました。

なんでこのスレこんなに盛り上がったんだ？

>>276

>>1の策略

>>277
なるほど。じゃあ、このスレにカキコした奴はみんな>>1の策略にはまったということか。
俺はもう書き込むのヤメトコ。おやすみ。

ある暗号サイトの問題なんですが、全然わかりません。
誰か教えて！


＠＄∩　Ж◎∩＜＠Ｃ◎　￥◎√＜＠♯／∋√Ｃ＠／♯√◎　
＄＠＜∩＄∋√＜＠♯Ｃ♯∴◎　 ◎＜◎√＠∩。　
Ｃ∋＜◎∩Ж◎∩＄◎∩Ｃ＠　√＠＋＋＠／＠　＜＠＜∩＜∩／＠＄∩√◎　
Ж♯∵♯＋∩＜∋♯＄＠＋∩♯√Ж＠　／♯＜＠∠￥∩√ｄ♯＄♯＋∩√♯　
＄￥∩∩Ｃ◎∩＄∋￥◎。

>>279
ある暗号サイトを見つける方が難しい。

>>1に誰も勝てない気がしてきた････

>>280
サイトを教えましょうか…？

答えを暗号で書いてあげればいいのでは？
1さんなら解読できるでしょう。

>281
てゆうか、
このスレに書いてる人の殆どは>>1と同程度の物を作れる，
このスレに書いてる人の殆どはそのどれをも解くことができない，
だと思われ。

この前よお、
駅前裏のまんが喫茶行ったんだわ。
そこで、えらいミニはいた女がいてな、
もういてもたってもいられなくてよお。
好きだ。なんちゃって。って言ったら、
いやだモー。オカマだけどいいのモー。って言われたよ。
おしまい。
--------------------------------------------
暗号になってマス。
この暗号を解けない人はここに来ないで下さい。

このスレはもう終りか？

>>285
5行目縦読み

うお、5列目だ

>>1に馬鹿にされ糞グラマーズ

ランダムネスが32bitしかないんだよね。
鍵長32bitの暗号って今どき…

>>290
7MBのテーブルも秘密情報のうちだろう。
だから、攻撃者が推定しなければいけないbit数は
56000032bitある。

テーブルの秘密が保たれ、かつテーブルを2回使わないならば
乱数なんか使わなくても(単にテーブルを先頭から使っても)
破ることは原理的に不可能だ。(Vernamのone time pad暗号。)

テーブルを何度も使い回していると、統計的解析で破られる
可能性が出てくる。だから、送りたいメッセージ以上の長さ
のテーブルをあらかじめ受信者に渡しておく必要がある。

外交上のトップシークレットには今もこの手の暗号が使われ
ているはず。(テーブルに当るコードブックは、外交官が外交
行嚢に入れて運び相手に手渡しする。)

用はすごい暗号はすごい暗号だが、車輪の大発明って奴ね

このスレまだ続いてたのか・・・

>>292

でも、今回の場合「メッセージの長さ以上のテーブル」を
安全に相手に渡せるなら、メッセージ自体を安全に渡せる
からそもそも意味がない（藁

>>1の最強かも
ある意味で

>>295
その通り。

キーコードは

256P256(順列)分の30000

からなりますよ
解きたい人はがんばってくださいね

↑プラス順番はバラバラです

祝300

まじめに私の暗号を解いて下さい。
名前： がる〜ら
E-mail：
内容：
批判は本スレで。

だれか立ててもらえませんか？

λ... ＜ ３００エントロピーげとできなかった…

いまだ書き込む糞グラマ

ｵﾏ(略

要は、この>>1って構ってほしいんでしょ
必死だな

もう今出てきてるのは偽物だよ。
キーコードは付けてないって最初の方に書いてあるし。

友は道連れ

>>1さんへ
勘違いで、必死だな。とか言っちゃって本当にどう言っちゃっていいのか、、
ちょと最近カキコデビューなんてしちゃって、調子に乗っちゃってたんだと思います
匿名性があるといっちゃっても、私の信条に反しちゃったりしちゃうのでageちゃったりして謝っちゃたりします
どうか怒らないでちゃって。。。

あぁsageちゃったり。。。まぁいいか

基地外がわいてるな・・・

>>279
テキトーに書いたと思ったら、実際にあったんだな
サイトは見つけたが、答えはわからん。スマソ

＠＄∩　Ж◎∩＜＠Ｃ◎　￥◎√＜＠♯／∋√Ｃ＠／♯√◎　
＄＠＜∩＄∋√＜＠♯Ｃ♯∴◎　 ◎＜◎√＠∩。　
Ｃ∋＜◎∩Ж◎∩＄◎∩Ｃ＠　√＠＋＋＠／＠　＜＠＜∩＜∩／＠＄∩√◎　
Ж♯∵♯＋∩＜∋♯＄＠＋∩♯√Ж＠　／♯＜＠∠￥∩√ｄ♯＄♯＋∩√♯　
＄￥∩∩Ｃ◎∩＄∋￥◎。

>>311
見た目換字式っぽいから頻度とかから攻められそうだけど
言語は何? 日本語? かなのみ?
ていうかむしろサイト探すほうが難しかったり（´д｀;）

>>312
http://www.ne.jp/asahi/pon/specter/index.html
ここの３問目です。お願いします。

∩∩∩∩∩∩∩∩∩∩∩∩∩∩∩∩∩
＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠
◎◎◎◎◎◎◎◎◎◎◎◎◎
♯♯♯♯♯♯♯♯♯♯♯♯
＜＜＜＜＜＜＜＜＜＜＜
√√√√√√√√√√
＄＄＄＄＄＄＄＄＄
ＣＣＣＣＣＣ
／／／／／
∋∋∋∋∋
＋＋＋＋＋
ЖЖЖЖ
￥￥￥￥
∴
∵
∠
ｄ
。。

法則を見つけて
「Ж∩√＋」
を変換して、URLを完成させるんだから、
>>279の文自体には意味がないかもしれない。

頻度調べてやりはじめたけど、
途中からすぐわかっちゃった。

asu　houkago　yonkairengarino　
sakusenkaigiwo　okonau。　
gekouhousouga　nattara　kakukurasuno　
himitukeisatuinha　rikazyunbisituni　
syuugouseyo。

>>316
すごい！ありがとうございました！
>>316さんの手にかかれば、あのサイトは楽勝だったり…。
精進します。

アルファベットを単純に置き換えただけなら、
たくさん出てくる文字が母音になるんだ！

答えがわかってから見ると似た形の記号を使っているんですね。

>>318
探偵学校にでも入れ

>>311にあるような単純置き換え暗号文を
標準入力から入力し自動解析して解読後の文章標準出力にプログラムを作れ。
もし辞書が必要であればftp://ftp.ox.ac.uk/pub/wordlists/あたりを使ってもよし。
こんなスレにいる窓際糞グラマには無理だろうがな。

窓プログラマを馬鹿にするな！

>>319
カゲマンか？

>>320
今から単純換字暗号の解析ツール作ってもな…
cryptanalysis toolで検索するといっぱい出てくる。

昔ASCIIに連載があったなあ。
シーザー暗号、ビジュネール暗号、プレイフェア暗号とか。
解析用のBASICプログラムリストも載ってた。

単純換字でない暗号はどうやって解読するのでしょう。

>>324
簡単なのは総当たり。
逆アセンブルはどんなアルゴリズムにもある程度は有効。

逆アセンブルはプログラムがある場合に有効ですが、
あらかじめ決め事を相手に渡しておいた場合はどうなるのでしょう？

例えば文字の下位2Bitが後に続くダミー文字数とか。

>>326
総当たりは最後の武器だよ。
総当たりでしか解けなくて、その探索空間が十分広いなら、
その暗号は「安全だ」ということになる。

>>325
基本はアルゴリズムごとに現れる統計的な偏りを使う。

例えばビジュネール暗号は、１字ごとに換字表をずらしながら
繰り返し使う。Cで書くと
char *key; // 鍵文字列
char *p = key;

while ((c = getchar()) != EOF) {
// c は'A'-'Z'だけとする。
putchar(((c - 'A') + *p++) % 26 + 'A');
if (*p == '\0') {
p = key;
}
}
という感じになる。

コンピュータなんかが無い時代にこれをどうやって破ったかと
いうと、変換結果で同じ2文字並びが現れる位置を見る。

例えば「XY」という2文字並びが7の倍数間隔に高い頻度で現れ
ていたとすると、これは英語に高い頻度で出てくる2文字並び
(bigram)が変換された結果で、鍵の長さは７文字だろうと推定
できる。あとは単純換字式と同じ。

ずれた。>>325と>>324だった。

サイモン・シンの「暗号解読」を嫁。

この本、かなりおもしろかった。

お前ら、クリプトノミコン読めよ

長田順行なら読んだことがあるんだが…ﾓｳﾜｽﾚﾀﾖ…

じゃ、文字が書かれたビットマップを暗号化してあった場合はどうするの？

元の文を一文字づつ大きさやフォントの異なる文字をビットマップ
に書いていって、まとめて暗号化しるの。

人間が見てアルファベットを判断しないと解らないようにすれば、
復号は大変じゃない？

>>332 復号(正当な受信者が平文に戻すこと)じゃなくて攻撃ね。

そういうデータだと、符号あたりの情報量が極めて少なくなる
(符号1ビットあたり、伝える情報量は数十分の1ビットくらい？)
から、鍵が発見できたかどうかの判定は自動的にできると思う
な。エントロピーが小さくなったら(つまり整然としたビット列
になったら)解けたんじゃないかと報告して、最終判断は人間に
任せれば良い。統計的な偏りも、同じ理由で強く出ると思う。

もちろん、事前にデータ圧縮しておけば攻撃は困難になる。
大昔から「空白は取り除いて大文字だけにする」のは常識だし、
暗号化ソフトは必ず暗号化前に圧縮する。

ところで、全くのでたらめな文だったら、
復元は不可能と解るのでしょうか？

分からないだろうね。

なら、コンピュータは延々と解読を試みるんですね。

>>336
解析法によるんじゃない？
アルゴリズムが分かってて、統計的な偏りを探しても
見つからないなら、おかしいと分かるはず。

暗号はジグソーパズルに例えると、
ピースをさらに違う形に変化させて保存してるんだから
それを元に戻すのは不可能、よほどの好条件がそろってないと解けない。
最大のセキュリティホールはパスワードチェックだと思える罠。

このスレ見てて、ずーっと昔（１０年以上前？）に考えた暗号化アルゴリズム思い出したよ。
乱数テーブルを一度作って保管しておけば、何回でも使いまわせるってのがミソ。
下の例のrt(乱数テーブル)は小さいけれど、これを十分大きくとれば
実用になるんじゃないかなんて考えてたけど、どうよ？

typedef unsigned char uchar;

uchar rt[256];

void encode(uchar *b, uchar *t, int tz, uchar *k, int kz)
{
  int i, j;
  uchar c;

  for(i=0;i<tz;i++){
    for(c=0,j=0;j<kz;j++) c^=rt[(i+k[j])%sizeof(rt)];
    b[i]=c^t[i];
    }
}

#include <time.h>
#include <stdlib.h>

uchar plain[]="hello world", key[]="2ch", crypt[16], out[16];

int main(void)
{
  int i;

  randomize(); /*乱数初期化*/
  for(i=0;i<sizeof(rt);i++) rt[i]=(uchar)random(256); /*0-255までの乱数を生成*/
  encode(crypt, plain, sizeof(plain), key, sizeof(key));
  encode(out, crypt, sizeof(plain), key, sizeof(key));
  return 0;
}

＞これを十分大きくとれば
それわわわ、長さ無限の擬似でない乱数列を用意できれば解読不可能な暗号通信ができるというのと類似でわわわないでしょうか？

>>340
無限である必要はない。程々でいい。１Ｍとか。個人で保管するのに適したサイズ。
１Ｍを超えるテキストの場合、ファイルを１Ｍより小さい単位で区切り、
最後に次のブロックの鍵（乱数で生成）をつけてやる、みたいな感じで対応する。

>>341
>>292-295

>>342
んな事、百も承知。ていうか、"それ" への対策そのものなのだが？
さっき個人で保管と書いたが、もっと極端な話、ネットで乱数列を公開して
全世界で共有しても問題ないと思う。

ここで問題となるのは「（真の）乱数列 ^ （真の）乱数列」で作成された
（疑似？）乱数列の "偏り" を発見する方法があるか、という事になるんだけど。

>>343
？？公開しちゃったらその時点でアウトだと思うけど。

>>339のコードでは何回もXORとってるけど、別にそれで
randomnessが増しているわけではないので、Vernam Cipherと
同じになる。

同じキーを何度か使った場合、
rt2[i]=rt[('k'+i)%256]^rt[('e'+i)%256]^rt[('y'+i)%256];
という固定の乱数列rt2を使い回していることになる。

いずれ統計的解析で破られる。("From:"とか"Received:"で始まる
文字列を暗号化しちゃったら、その時点で破られそう。)

>>343
発見するのは乱数列の偏りじゃなくて元のデータの偏りから来る出力の偏りだよ。
たとえば >>339 は、256文字ごとに同じ変換になるので、単純換字式暗号より
256倍のデータがあれば簡単に破れる。

DESというのは入力の偏りが出力に現れない(だから総当たりしかない)と思われて
いたんだけど、線形攻撃法という解析法で破られることが分かった。その時に
実際に破るのに使ったデータ量は数十テラバイトくらいだったと思う。

それくらいデータを集められても耐える(総当たり以外に弱点がない)暗号じゃ
ないと実用とは呼べない。

＞ 数十テラバイトくらいだったと思う。
確認したら、2^43バイトだった。8テラバイトだね。

ｽﾏｿ｡ちょっとコードがわかりにくかったか？

何で何回も XOR を取っているのかといえば、要するにその鍵を利用して
元の乱数表から（その鍵に基づいた）"新しい" 乱数表を生成している訳。

で、長文対策は具体的に言うとこういう事。

平文を "hello world.moukarimakka?botibotidenna." とする。
鍵を "2ch" とする。

・平文を "hello world."、"moukarimakka?"、"botibotidenna." に分解する
・ブロック２とブロック３に対して、プログラム側が（乱数で）鍵を自動的に生成する。
・ブロックを生成し、各々に対して対応する鍵を使用して暗号化する。
＊ブロック１(鍵：2ch)の中身「平文："hello world."、ブロック２の鍵："mona"」
＊ブロック２(鍵：mona)の中身「平文："moukarimakka?"、ブロック３の鍵："itteyoshi"」
＊ブロック３(鍵：itteyoshi)の中身「平文："botibotidenna."」

>>347
そのblock#2, #3の鍵を選ぶ乱数の種はどこからくるの?

>>347
CFB(Cipher Block Chaining)だね。

>>347
CFBを使うとマシだけど、やっぱり総当たりより楽な攻撃が
可能だろう。

短めの素数長で循環する乱数テーブルを数十種類用意して、
それを重ねてxorするなら統計取れない気がするんだけど

>>351
単に周期が長くなるだけ。

>>351
多表式暗号だね。
ナチスのエニグマ暗号や日本軍の紫暗号。
大戦中に破られた。

>>352
素数長なんだから周期が現れないんじゃない？

>>353
まぁ、解析されてるだろうとは思ったけどね。
そんな昔に解析されてるんじゃ今だとすぐ解けちゃうのかな

>>347
てけとー。疑似乱数でかまわない。
>>349
そゆこと。
>>350
で、どういう攻撃？
>>352
テーブルの "組み合わせ全体" によってえられる周期に注目せずに、
"一つのテーブルの周期" が長くなると「ほんとに統計的に有意なデータが
とれるんかい？」って気にならない？
エニグマ世代の「アナログ機器」で作られた乱数表とは比べ物にならないと思う。
おれの記憶はあいまいだけど、エニグマの "円盤" で一番大きい奴の
"一周の長さ" ってせいぜい数百ぐらいじゃ無かったっけ？

エニグマ暗号が破られたのは、理論的に弱かったわけではなくて
当時の技術では十分大きな周期が作れなかったからだね。

素数だからって周期は無限になるわけじゃないよね。
例えば周期11と周期13の乱数列を組み合わせても周期143の乱数列に
なるだけでやっぱり周期はある。

周期が十分長い乱数列でも、乱数列に特別な性質があれば解析されて
しまう。線形合同法やM系列を使った疑似乱数の場合は解析法が知られ
ている。(だからそこらのライブラリ関数を使ったやつはダメ。)

例えば Xn+1 = MD5(Xn)という128bitの数Xnの列の、下位8ビットずつ
を使ってXORするような暗号なら、キー長128bitの暗号として実用に
なる。(MD5以外でも、いわゆる「暗号学的に安全な」乱数列を使えば
良い。)

CBCの場合、メッセージの総バイト数じゃなくて
メッセージの数が増えてくると解析される。
最初の方は同じ系列を使うから。

特にメールみたいに、最初の方の文字列が決まってる
と、CBCにしたからといって安心できない。やはり
多表式暗号みたいに弱いやつは避けるべきだろう。

>>356
エニグマの周期は26の8乗＝208827064576≒2^37
そこらの疑似乱数列より長いよ。それでも破られた。

エニグマ自体が連合軍に渡ってたのと、平文が予測できる通信が行われた
ので解読できたらしいですね。運用次第ではかなり強力な暗号だったはず。

>>357
あ、それとついでに断っておくけど、
おれの提案した方法は、あの手の方法とは違って
基本的に "周期" なんて物はないよ。
次のブロックの鍵は "適当" に生成するんだし。
まぁ、生成できるテーブルの数には自ずから
限度が出てくるけど、それによって現実的な
問題は起こらないと思う。

>>361
適当でどうやって復号するの?

>>361
それ、354への返信じゃないの？

>>362
前の発言を嫁。
なんか、この部分に「周期のある」疑似乱数を使用する事に
かなりこだわっている奴がいるみたいだけど、それはいわゆる
"木を見て森を見ず" ってやつだろ。
別にこの方法（次のブロックの鍵を現在のブロックに埋め込む）
は俺の発案した方法ではないし、現実に使用されている方法だよ。
どうしても気になるなら、その部分は人手で入力してもらえば良い。
テーブルが十分大きかったら、それほど苦になる作業でもない。

>>363
あら、そ。それはすまんかった。

（´д｀;）

ECBだろうとCBCだろうと、周期の短い乱数を使ったら論外だろ。
最初のブロックが推定されると後は全部解かれる(attack propagation)。
特に既知平文攻撃(最初のブロックの平文がFrom:とか推定できる)に弱い。

ところで、>>339 も専門家じゃないみたいだが(俺も違うが)、
ちょっと勉強したくらいだと強い暗号を考案するのは無理。

PGPを作ったPhil Zimmermanでさえ、独自に考案した暗号(Bass-O-Matic)
を専門家(Biham)に見せたら数分で致命的な欠点をいくつも指摘された。

大人しくTriple-DESあたりを使っている方が無難だ。

>>366
>ちょっと勉強したくらいだと強い暗号を考案するのは無理。
それは十分に分かっている。
別にこの方法が完全だと思っている訳でもないし。
なにせ遥か昔に考えてそのまま放っておいたアイデアを
このスレでふと思い出したので、欠点を詳しい奴に指摘して
もらえると嬉しいから書込んだだけ。

>特に既知平文攻撃(最初のブロックの平文がFrom:とか推定できる)に弱い。
たとえば、俺の方法で最初の文が From だと分かっていた場合（いや、
いっその事、最初のブロックの "平文すべて" が分かっていた場合でも良い）、
どういう対策が取れると思う？
平文に対して XOR を取った乱数列が分かったところで、その乱数列を
生成するのに使用した "鍵" を見つける方法は総当たり以外にあるの？

>>367
鍵が分からなくても乱数列が分かれば十分では。

たくさんのメッセージの、最初のブロックと二番目のブロックを集めて
統計的に解析すると、二番目のブロックの暗号化に使われた乱数列が
わかる（…んじゃないの？アルゴリズムの説明が曖昧で良く分からない
けど）あとは順に同じ手順を繰り返す。

>>367
例えば、メッセージが10億個くらい手に入ったとする(総当たりよりはずいぶ
ん少ない数だよね)。最初のブロック長の乱数列が分かったとすると、次の鍵
文字列Xk, Xk+1, ..., Xk+mが分かる。

鍵文字列中で同じ文字(例えばe)が現れると、表中の同じ位置を使うはずだか
ら、その場合だけの統計を取ると、アルファベットの出現確率からその位置の
表の値が推定できる。(例えば、0x8bが最も高い確率で現れていたとすると、
その位置の値xは、'e'^0x8b, 't'^0x8b , 'a'^0x8b, ...等ではないかと推定
できる。)

こうして表中のいろいろな位置の値が推定できる(いくつもの可能性が残るだ
ろうけど)。その推定をもとにさらに次のブロックの統計を調べてみれば、ど
の推定が正しいか判定できるはず。

悪い。もうちょっと具体的に説明する。

使用する元の乱数表(rt[6]={3,1,4,1,5,9}とする)と鍵(k[2]={1,3}とする)
から平文に XOR を取る乱数列(st[6]とする)を生成するには
st[0]=rt[(k[0]+0)%6/*=1*/]^rt[(k[1]+0)%6/*=1*/];/*=0*/
st[1]=rt[(k[0]+1)%6/*=4*/]^rt[(k[1]+1)%6/*=5*/];/*=1*/
st[2]=rt[(k[0]+2)%6/*=1*/]^rt[(k[1]+2)%6/*=9*/];/*=8*/
st[3]=rt[(k[0]+3)%6/*=5*/]^rt[(k[1]+3)%6/*=3*/];/*=6*/
st[4]=rt[(k[0]+4)%6/*=9*/]^rt[(k[1]+4)%6/*=1*/];/*=8*/
st[5]=rt[(k[0]+5)%6/*=3*/]^rt[(k[1]+5)%6/*=4*/];/*=7*/
となる。
これと平文(t[4]={1,2,3,4}とする)と次のブロックの鍵(l[2]={2,4}とする)
の組との XOR をこのブロックの暗号文(b[6]とする)とする。
b[0]=t[0]^st[0];/*=1*/
b[1]=t[1]^st[1];/*=3*/
b[2]=t[2]^st[2];/*=11*/
b[3]=t[3]^st[3];/*=2*/
b[4]=l[0]^st[4];/*=10*/
b[5]=l[1]^st[5];/*=3*/
こんな感じ。

たとえばこれで平文が "1,2,3,4" だと分かっていたとしても
（当然それから XOR を取った乱数列 "0,1,8,6" は分かるが）
それから次のブロックの鍵 "2,4" を知る為には元の鍵 "1,3"
が分かっていなくてはいけないだろ。
しかし、それを知る為には総当たりで調べるしかないんじゃないの？
これっていわゆる「詰め込み問題」になるのだと思うのだが。

>>370
えーと、st[0]〜st[5]はわかっちゃうのだから、l[0]とl[1]もわかっちゃうよね？
(暗号化結果b[0]〜b[5]は手に入っているんだから。)

あ、ごめん。st[0]〜st[5]は出力しないのね。

で、その次のステップでは
b[0]〜b[5]をk[0]〜k[5]に入れて
最初に戻れば良いのかな？

ありゃ、話を飛ばしたか？
平文が分かれば st[0]〜st[3] は分かるが
依然として st[4]〜st[5] は分からないだろ。
んで、st[4]〜st[5] を知る為には当然
st[0]〜st[5] を生成する方法が分かってなくては
いけないが、その為には元の鍵 k を調べなくては
いけないという事。

いや、いちばんわからないのは、次のブロックをどうやって暗号化するのか
（次のブロックへの鍵として何をつかうのか）なんですが。

それによっては、統計的解析が効いちゃうかも知れない。

次のブロックの鍵は l[2]={2,4} だよ。
上の説明の k の所を l に読み替えてみれ。

で、その l の生成方法だが（常識範囲であれば）何でも委員じゃない？
単純な擬似乱数列で十分。
もしどうしても心配なら、上にも書いたように人手で乱数を
入力してもらってもいいし。

えーと？？？ああ、そうやってl[0], l[1]を受信者に渡すわけね。
やっとわかった。

まず、簡単のために生成する鍵の列が毎回同じだとすると、
乱数列stは毎回同じになるから、何度も使うと簡単に
解析されるね(Vernam暗号そのもの)。

例えばn文字目とXORするst[n]は鍵列k, l, ...が同じだと
いつも同じになるんだよね？

やっぱり鍵をどうやって毎回変えるかの方法が重要だね。

すごい素朴な疑問なんだけど。
暗号化の前段で圧縮するのって定石だよね。
統計的手法って、圧縮されたデータに対しては、どうやって使うの？

たとえば、動的ハフマンの亜種（圧縮率に主眼を置かないような）みたいな
奴だったら、キャラクタの区切りすら判らないんじゃないのかな。

現実に暗号を破る人がいるんだから、なんらかの方法はあるんだろうけど。

圧縮したら統計的解析は難しくなると思うよ。

ただ、圧縮ライブラリが付けるへッダとかはかえって手がかりに
なっちゃうかも。

今普及してるアルゴリズム(3DES, Blowfish, AES, CAST128等)だと、
圧縮しなくても偏りが現れないから、へまをしない限り解読されるっ
てことはないんじゃないかな。(何か欠点が見つかる可能性はあるけ
ど、そうなったら大ニュース。)

>>379
thx.
現在の暗号は、もともと統計的手法が使えないんだ。なるほどー。

>>377
何故にそこにこだわるのかがサパーリ分からん。
必要ならさいころでも振ればいいじゃん。

激しく外出だけど、何故に平文と同じ量の乱数表を送る
暗号が使われないかというと、単に「非公開の乱数表を
安全に送るのに手間がかかる。そんな事をするのなら、
最初から平文を送ったほうがましだ」
って事だろ。別に乱数表を生成するのが大変だって
言ってる訳じゃなくて。

今回の場合、読み手が必要とする非公開の情報は、
最初のブロックの鍵だけなのだから、本質的な問題が
解決されていると思うのだが。

>>381
ん？ 乱数表rtも送っとくんだと思ったが。
それはアルゴリズムの1部として固定で良いと言うことかな？

まあそれは良いや。

なんで漏れが乱数列の生成法にこだわるかというとですね、
まずそこに線形合同法やM系列のような安易な方法は使えないよね。

そこで鍵系列に暗号学的に安全な乱数列を使ったとするとですね、
そもそも表を使い回すような危険を犯すよりも単にその乱数列と
XOR取るだけの方が安全じゃないんか、という根本的な疑問が湧い
てくるからなんですよ。

>>382
>それはアルゴリズムの1部として固定で良いと言うことかな？
それもまた善し。一般に公開されていても何の問題も無い。

>そもそも表を使い回すような危険を犯すよりも単にその乱数列と
>XOR取るだけの方が安全じゃないんか、という根本的な疑問が湧い
>てくるからなんですよ。

わからんやっちゃなー。
上にも書いたけど、"安全に送るのに手間がかかる" んだけど？

ここで使われている乱数には２種類あるよな。
  １．rt の乱数表
  ２．n を生成する乱数
で、１の方は上にも書いた通り、世間一般に知られててもかまわない。
で、２の方は安全に正規の読み手に送る方法は以前に書いた通り。
その乱数の作り方なんぞは御自由にどうぞ。
>暗号学的に安全な乱数列を使ったとするとですね
って書いてあるのを見る限り、そういう乱数が作れる事は承知している
みたいだし。

以上。なんか問題あるって話。

わりい、n は l の間違いね。

>>383
わからん人だな〜（ｗ

すべての暗号はごく単純化しちゃえば「安全な乱数列と
XORしてくこと」と言っちゃって良いわけだから(XORの
結果の伝播の仕方にCBC, OFB, CFBなどとあるけど)、
その安全な乱数列が得られたらそれで終りでしょうが。

それ以上ややこしくして(最初の数文字がばれるような)
危険なものにしてどうするの？

例えば、MD5の初期値128bitを秘密情報として共有した
とする。(あるいはMD5に食わせるもっと長いパスフレー
ズでも良い。) そうすると >>357 みたいな方法で
cryptographically secureな乱数列が作れる。

あとはそれを平文とXORした結果を送れば終りでしょ？
(もちろんCBCモードやCFBモードで)。

-245 -10917 -1077 -11656 -7074 -17540 -6515 -23023 -31212 -8984 -14500 -3582 -22
819 -18558 1400 -5381 -26651 22523 -25080 27078 -31381 -7224 -13960 -31159

おら解読してみろよ！
文字列なんだけどできたらキスしてやってもいいぜ！！

>>386
禿しく外出 >>213

>>385
>その安全な乱数列が得られたらそれで終りでしょうが。
そらそうだ。

>それ以上ややこしくして(最初の数文字がばれるような)
>危険なものにしてどうするの？
だからどうばれて、どう危険なの？

専門家じゃないからすぐに欠点は見つけられないけど、
余計なステップが増えれば欠陥が入る可能性がそれだけ
増えると思う。

欠陥がないと確信してるわけじゃないって言ってたよね？
だったら欠陥が入る可能性をなるべく減らすようにする
のが良いと思う。

>>370

＞たとえばこれで平文が "1,2,3,4" だと分かっていたとしても
＞（当然それから XOR を取った乱数列 "0,1,8,6" は分かるが）
＞それから次のブロックの鍵 "2,4" を知る為には元の鍵 "1,3"
＞が分かっていなくてはいけないだろ。

この場合だと簡単に分かるよね。

b[0] = t[0]だから、k[0], k[1]は{1,3}か{3,1}しかありえない。
(rtの中に等しい数字は1組しかないから。)

で、どちらであっても実は暗号化結果は同じになるんじゃないか？
k[0]とk[1]を入れ替えても、st[0]〜st[5]の値は同じになる。
いずれにせよlが{2,4}だというのはすぐにわかる。

>>339のプログラムでも、鍵文字列が"2ch"でも"c2h"でも"ch2"
でも同じ結果になるよね。鍵の情報量がえらく減ってしまう。

鍵文字列が"abba"とかだったりするとそもそも暗号にならなかっ
たりする危険もある。

>>339の問題点（とりあえずすぐ分かるところ）

xがわかっているとき、x = a ^ b ^ c をみたすa, b, cの組は
(各8ビットとして)65536通りしかない。3バイトから2バイトに
探索空間が減っている。

a, b, cが固定の表から選ばれるので、表の中に0〜255の数の
うち欠けている値があったりすると、さらに探索空間が減る。

また、a, b, cは入れ替えても良いわけだから、探索空間がさ
らに6分の1に狭くなる。総当たり(2の24乗)と比較すると1536
分の1以下の探索ですむ。鍵が長いとさらに差が広がる。

表に特定の性質(xになる組が少ないとか)があったり、鍵文字列
に特定の性質(同じ文字が含まれてるとか)があると、極端に弱い
暗号になる可能性がある。

いや、やっぱり初めの数文字の平文が分かっていたりすると、
ほとんど暗号にならない気がするな。

1文字目 x1 = a1 ^ b1 ^ c1
2文字目 x2 = a2 ^ b2 ^ c2

これで、a1とa2, b1とb2, c1とc2は表の中でそれぞれすぐ隣り
に並んでいるんだよね。これを満たすような組合わせはそんな
に多くないんじゃないか。3文字目、4文字目もあわせれば、
鍵はほとんど一意に決まってしまうと思う。

なんか一杯書込まれててﾁｮﾄ嬉し。

>>389
>余計なステップが増えれば欠陥が入る可能性がそれだけ
>増えると思う。
全くその通り。でもこの方法って DES なんかと比べて
ステップ数はやたら少ない（少なすぎ？）と思わない？

>>390
>b[0] = t[0]だから、k[0], k[1]は{1,3}か{3,1}しかありえない。
>(rtの中に等しい数字は1組しかないから。)
例が小さいから実感が湧かないかも知れないが、それって
"総当たり" による検索だよね。
鍵となる数字や、テーブルのサイズが増えたときの事考えてくれ。

>>391
>a, b, cが固定の表から選ばれるので、表の中に0〜255の数の
>うち欠けている値があったりすると、さらに探索空間が減る。
もし欠けている値があったとしても、それをどうやって利用する訳？
これらの a b c ってのは表の中の要素の複数回の XOR で
生成されるんだよ。

>>391
>xがわかっているとき、x = a ^ b ^ c をみたすa, b, cの組は
>(各8ビットとして)65536通りしかない。3バイトから2バイトに
>探索空間が減っている。
>>392
>鍵文字列に特定の性質(同じ文字が含まれてるとか)があると、
>極端に弱い暗号になる可能性がある。
それらを解決する方法として、演算を XOR じゃ無くて
"非対称" な演算（表）を使う手があるのだが、
話がややこしくなるので・・・
（個人的にはあまり本質的な問題じゃないと思う。
組み合わせと順列、どちらも総当たりをするには
量が多すぎる）

>>392
>これで、a1とa2, b1とb2, c1とc2は表の中でそれぞれすぐ隣り
>に並んでいるんだよね。これを満たすような組合わせはそんな
>に多くないんじゃないか。
そこ。

俺が一番気にしているのは、このような乱数表の組み合わせ
によって作られた（疑似？）乱数表をうまく（総当たりでない方法で）
分解する方法があるんじゃないかって事なんだけど？
知っている奴いない？

おまえらそんな初歩的な事は本を嫁。

>>393

> >>389
> >余計なステップが増えれば欠陥が入る可能性がそれだけ
> >増えると思う。
> 全くその通り。でもこの方法って DES なんかと比べて
> ステップ数はやたら少ない（少なすぎ？）と思わない？

単に乱数列とXORするのに比べると多すぎると思うけど…
それに、DESはブロック全体でのbit入れ替えや、非線型な表引きを行っている。

> >>390
> >b[0] = t[0]だから、k[0], k[1]は{1,3}か{3,1}しかありえない。
> >(rtの中に等しい数字は1組しかないから。)
> 例が小さいから実感が湧かないかも知れないが、それって
> "総当たり" による検索だよね。
> 鍵となる数字や、テーブルのサイズが増えたときの事考えてくれ。

テーブルは固定だから、弱点はじっくり探せると思う。
弱点の条件がはっきりすれば、楽に探せる。
だいいち、表全体から2つ選ぶくらいで「総当たり」とは言わない。

暗号学で総当たり(全探索)といったら、鍵空間全体を調べることだろ。
それより著しく短い(桁が違うくらいの)攻撃回数で攻撃が成功する確率が
十分高ければ、その暗号は「弱い」とみなされる。

乱数列とのXOR(Vernam暗号)にはそういう欠点がないよね。

> >>391
> >a, b, cが固定の表から選ばれるので、表の中に0〜255の数の
> >うち欠けている値があったりすると、さらに探索空間が減る。
> もし欠けている値があったとしても、それをどうやって利用する訳？
> これらの a b c ってのは表の中の要素の複数回の XOR で
> 生成されるんだよ。

？？ a=rt[k1], b=rt[k2], c=rt[k3]だろ。
rt[i]=qをみたすiの一覧p[q]を作っておくのは簡単だよね。

> （個人的にはあまり本質的な問題じゃないと思う。
> 組み合わせと順列、どちらも総当たりをするには
> 量が多すぎる）

24bitあるはずの探索空間が14bit未満に減ってしまったら、それだけで
その暗号は「破られた」と言っていいんじゃないかな。

>>29　のコードで平文と暗号文が判ってしまった場合の強度ってどの程度？

単純に総当りでやるとすると　最初の乱数種が2^24

後 線形合同法の r:=(r*331 + m) の331も変数として 2^32/ln(2^32)

強いのか弱いのか

すいません、こちらの方々なら解読できるのではと思い、書き込みます。
以下の文章、数字に、のあとに数字のみの羅列がくるのですが化けています。
３つに別れているはずです。
メールで化けてきてのですが、なんとかなるまでしょうか？
連絡がとれないし、重要な数字だしで困っています。
宜しくお願いいたします。

数字にbr> D$$$F!"%$%s%9%H!<%k%^%K%e%"%k$NCf$KF~$C$F$$$k$O$:$@$H;W$$$^$9$N$G$43NG'$r$
*4j$$$$$?$7$^$9!#

暗号っぽいけど暗号じゃない。
JISコードにして見れ

398さん、恐れ入ります、ありがとうございます。
可能性がある訳ですね。
JISコード・・・はなんとなく判りましたが・・・
http://www.hosibune.net/~mak/tools/index.shtml
こういうのでいいでしょうか？
ちよっとやってみます。

漢字コード変換じゃなくて、
メーラの設定をJISコードにしてみる

だ、駄目です・・・意味が分かりません・・・涙

メーラー設定、了解です。
自分宛てにこの文字列を送付してみます。

・・・

駄目でした・・・
ここの数字だけが化けているのです、シフトＪＩＳとかの切り替えの
問題ではないように思えるのですが、うーーーむ、困りました。
確かに文字コードを切り返ると全部が似たような感じの化け方でした。

全部の数字とアルファベットを書いて、メールで自分に送って、
コード切り替えして化けさせて、
あとは同じのを探していけばいいですね。
時間かかると思いますがやってみます。

駄目です。
この部分だけは中国台湾あたりの書式をカットペーストしたものと思うのです。
なのでこちらではその部分が化けているのかと思います。

疲れました・・・涙

>>397
復元してみた(JISのESCが抜けてただけ)

「数字に Dいて、インストールマニュアルの中に入っているはずだと思いま
すのでご確認をお願いいたします。」

…貴様、ネタだなっ！

４０７の神の方。

嬉しいです。
そういうことでしたか！！！
マニュアルとソフトが来たのですが、シリアルが無かったのです。
問い合わせての返信がこうだったのです。

助かりました。ほんとうにありがとうございます。
神と呼ばせて頂きます。
ありがとうございました。

ええはなしや

暗号じゃないけどね。

で、1はどこにいった？

>>395
>単に乱数列とXORするのに比べると多すぎると思うけど…
なんか話が循環するなー。
まず最初に、ただの乱数列と XOR する暗号は強力だが、
現実的な問題として正規の読み手だけに乱数列を渡すのが
むずかしいって前提があるだろ。
そのための代替案として、正規の読み手が "非公開情報" として
受け取っておくべきものを "鍵" だけに限定しましょうって
話になってくる訳だ。
ここでこの方法が、ただの XOR よりステップ数が多いという
批判は、上に書いた乱数列の配布の負担の問題をまったく無視した
話になっているのだが。
もしかして >>395 は、DES もただの乱数列との XOR より
ステップ数が多いから駄目だ、って言いたいの？

>だいいち、表全体から2つ選ぶくらいで「総当たり」とは言わない。
もし納得がいかないのなら、たとえば k の要素数が１０になった場合
を考えてみれ。たちまちその方法が使えなくなる事がわかるだろ。

>>395
>？？ a=rt[k1], b=rt[k2], c=rt[k3]だろ。
悪い、これは俺の読み違え。
>rt[i]=qをみたすiの一覧p[q]を作っておくのは簡単だよね。
ん？良く分からん。
それって、たとえば rt[]={0,1,2,0,2}; だったとして
p[][]={{0,3},{1,-1},{2,4}}; みたいな行列ってこと？

>>412

> まず最初に、ただの乱数列と XOR する暗号は強力だが、
> 現実的な問題として正規の読み手だけに乱数列を渡すのが
> むずかしいって前提があるだろ。

ほんとに循環するなー。

それは、暗号学的に安全な疑似乱数列(MD5とかを使ったもの)を
使えば良いんだから、乱数の種(128bit程度)だけ渡しとけば
良いってば。

>>414
>それは、暗号学的に安全な疑似乱数列(MD5とかを使ったもの)を
>使えば良いんだから、乱数の種(128bit程度)だけ渡しとけば
>良いってば。
今までに安全性が "証明された" 疑似乱数列ってあるの？

つーかさ、ずっと疑問に思ってたんだが、
MD5を使った乱数列って何だ？
MD5はバイト集合から安全なHash値を導き出すアルゴリズムじゃないの？

"安全な"Hash値って何？

>>417
しらん。
Secure Hash Algorithmって書かれてるから、
安全なHashアルゴリズムとしか考えられなかったんだけど、
他に何か適切な役でもあるの？

>>415
それを言ったら、無条件で安全性が証明された暗号もone time pad
以外にないだろう。でも皆DESやRC2を使ってる。

>>416
>>357

>>420
>>357はMD5が暗号であるとは書いてないが

s/暗号である/乱数である/

>>421

>>357のXnが疑似乱数列であることは文脈から明らかだと思うんだが…
この疑似乱数はRSA Security社のBSAFE Toolkitやsshなどで使われている。

>>419
そこで、俺の方法で作り出した st が疑似乱数列と呼べるか
どうかが問題になってくる訳。
もし、上で言ったように（総当たり以外で）うまく分解する方法が
無いのなら、この難しさは「ＮＰ完全レベルに相当する」って
証明できるんじゃないの？

>>424
疑似乱数なのは明らかだろ。

すでに全数探索より探索空間が狭くなることは示されていると思うが。
普通の全数探索だと
for i1=0..n
　for i2=0..n
　　for i3=0..n
　　　...
と探索しなければいけないところを、この暗号だと
for i1=0..n
　for i2=i1..n
　　for i3=i2..n
　　　...
ですんでしまう。もっとうまく(階乗進法などを使って)対称性を利用すれば、
鍵の長さがLのとき、探索空間は全数探索の1/L!になる。

>>425
計算量という物に対して根源的な認識の差があるな。

俺の知っている限りでは、世間一般では多項式時間で
解けない問題（Ｏ(2^n), Ｏ(n!)など）は全て十把一絡げに
"難しい" と見なしていると思っていたんだが。

まぁ、どうしてもそれが気に食わないというのなら、
上に挙げたように XOR じゃなくて、非対称な演算（表）を
使うって手があるけど、どうよ？

>>426

漸近的計算量は暗号の場合意味がないよ。
問題は鍵のサイズを固定したときにどうなるかだから。

ただ、RSA暗号みたいに計算的複雑性に頼っている暗号もあるけどね。
慣用暗号ではもっと基準が厳しい。

>>339の暗号は、対称性の欠点を取り除いて表を大きくすれば
たしかに周期の非常に長い多表式暗号として使えると思う。

対称性を取り除くには、例えば乱数列として
rt[k1]^rt[k2]^rt[k3]^rt[k4]
rt[k1+1]^rt[k2+2]^rt[k3+3]^rt[k4+5]
rt[k1+2]^rt[k2+4]^rt[k3+6]^rt[k4+10]
...
を使えば良いのでは。

また、鍵を陽に送るのではなくて、暗号化結果と元の鍵のXORを
次のブロックの鍵としてフィードバックすれば良い。(暗号関数
自身を疑似乱数発生器として使う。) そうすれば鍵を送るために
バンド幅を浪費せずにすむ(Cipher Feedback Mode)。

最後に、先頭のブロックが既知平文攻撃されるという欠点を除く
には、例えば「最小のブロックはでたらめな文字列を送る」と決めれば
良い。(そのためには別の疑似乱数発生器か、ハードウェアを使った
真の乱数発生器か、外部入力が必要になるけど。)

s/最小の/最初の/

>>427
>問題は鍵のサイズを固定したときにどうなるかだから。
必要なだけ鍵の長さを増やせば良いのでは？
（"テーブル長より長い鍵" ってのは抜きとして）
別にこの方法は鍵の長さを固定する必要はないのだし。

>対称性を取り除くには、例えば乱数列として...を使えば良いのでは。
個人的には演算表として、九九みたいな２次元配列 o[n][n] を作って
そこから表引きする事を考えていたんだけど。
ただ、この表を設計する時だけは慎重にならんとやばいと思う。

>たしかに周期の非常に長い多表式暗号として使えると思う。
だから周期なんてないんだって。
次のブロックの rt の組み合わせを決めるのは乱数だろ。

>そうすれば鍵を送るためにバンド幅を浪費せずにすむ(Cipher Feedback Mode)。
たとえば rt のサイズが 65536（小さいか？） として、k の要素のビット長
が 16 ビット、それを８個使ったとして１ブロックの鍵の長さは 128 ビット。
（実際に総当たりでどれくらい時間が掛かるかは計算してないけど）
これは演算を XOR でやった場合でも十分な強度を持つ鍵の長さだと思う。
で、この場合、暗号化すると 65536 バイト当たり 16 バイトのおまけが
くっつくだけだろ？
さすがに ＲＳＡ なんぞと比べるのは馬鹿らしいとしても、今日び通信エラーを
はじくのにもそんなせこい事は言ってないと思われ。
まぁ、どうでもいい部分ではあるが。

>最後に、先頭のブロックが既知平文攻撃されるという欠点を除く
いまだにこれが分からん（泣
一体何処に "既知平文攻撃される" 余地があるんだ？
たとえば行頭が From の場合でもいいし、上にも書いたように１ブロックの
平文がまるまる分かっている場合でもいい、攻撃方法を具体的に教えれ。
（分かっていると思うけど、説明の為に >>339 のコードの k の要素数はたった
２つになっている。上で挙げた " k の要素が８個の場合" で答えてくれると嬉しいな）

>>429
＞ 必要なだけ鍵の長さを増やせば良いのでは？
まあ、そうだけど、
1. 使い道が限られるね。パスワードやプロトコルでは上限が
固定のこともある。ハード化するときも困る。
2. bit数の下限は決めておく必要があるよね。そして、それが
「十分長い」ならば、それ以上にする必要はない。(ところで、
キーボードから入れた文字を直接使ったら、かなり弱くなるだ
ろうね。1文字あたりせいぜい6bitの情報量しかない。)

＞ だから周期なんてないんだって。
＞ 次のブロックの rt の組み合わせを決めるのは乱数だろ。
最初のブロックに使う乱数列について、「周期がない」のと
「1周するまで使わないようにする」のとは違うだろ。
有限の鍵だけから、周期のない乱数列をプログラムで生成する
方法はないよ。

＞ で、この場合、暗号化すると 65536 バイト当たり 16 バイトのおまけが
＞ くっつくだけだろ？
「効率100%」には劣るよね。乱数表に比べてブロック数を短く
した方が安全だし。

＞ 一体何処に "既知平文攻撃される" 余地があるんだ？
単に探索空間が狭くなるという話だけど？
crypt = x^rt[k1]^rt[k2]^rt[k3]^rt[k4]
で、xが分かっていたら、分かっていない場合より探索空間が
狭くなる。（全数探索より1/256になる。）
最初のブロックをランダムにしておけば、その心配はない。

>>430
>1. 使い道が限られるね。パスワードやプロトコルでは上限が
>固定のこともある。ハード化するときも困る。
現実に使用する際に長さを任意にしなければならない、といっているのではないよ。
（でも、そういう（アルゴリズム上、鍵の長さが任意に設定できる）暗号系って
"有名なやつ" があったと思うが・・・）
事実上総当たりが出来ない数以上の長さに設定する事が出来るって話。
アルゴリズム上、鍵の長さが固定されているものではそういう事は
できないけどね。

>有限の鍵だけから、周期のない乱数列をプログラムで生成する
>方法はないよ。
おい、一体どちらの乱数の事を言っているんだ？
rt を生成するのに使う乱数の事か？
それとも k を作るのに使う乱数の事か？
どちらにしろ、物理的に作った "真の乱数" を使えばいいって話で
決着がついたと思うが？

結局の所、k を使って作った rt の組み合わせを分解する
効率的な方法が無ければよい訳だろ。
ＲＳＡ は素因数分解を効率的に行う方法が見つかれば解けるよ
って話と全く同じ。

>全数探索より1/256になる。
んなもん、既知平文攻撃なんて呼ばんだろ、普通。
相手にしてるのはあくまでも "組み合わせ爆発" だぞ？

http://www.geocities.co.jp/SiliconValley-Sunnyvale/4822/QG.zip

なんか終わっちゃってるね〜
これで私の暗号が弱いかどうか検証してくれい
実ファなんでよろしゅ〜に
たのんま〜す

馬鹿をほざく主犯者再び(糞

>>431
既知平文攻撃とは、暗号文C1とその平文P1が分かってい
るとき、他の暗号文C2の平文を全数探索より少ない努力
で得る方法をいう。

339暗号では、暗号文と平文の組が1つ分かると、同じ鍵を
使った暗号文について、
最初のブロックについては平文が必ず分かってしまう。
残りのブロックについては、第2ブロック以降の鍵の生成
法(普通、鍵スケジュールと呼ぶ)に依存する。同じ初期鍵
について鍵スケジューリングが同じ鍵系列を生成するなら、
第2ブロック以降もすべて平文が分かってしまう。そうで
ないときも、全数探索に比べて1/256の努力で解読できる。

＞>有限の鍵だけから、周期のない乱数列をプログラムで生成する
＞>方法はないよ。
＞おい、一体どちらの乱数の事を言っているんだ？

339暗号は平文のバイトp0, p1, ...に対して
c0 = p0 ^ rand0
c1 = p1 ^ rand1
...
という形をしている。このrand0, rand1, ...のこと。

鍵を変えるまでは「周期がrtのサイズである乱数列」の一部
を使っている。もういちど言うが、「周期がない」ことと
「1周するまで使わない」ことは違う。

＞rt を生成するのに使う乱数の事か？
＞それとも k を作るのに使う乱数の事か？
＞どちらにしろ、物理的に作った "真の乱数" を使えばいいって話で
＞決着がついたと思うが？

rtについては良いけど、kの生成(鍵スケジューリング)は
そうはいかないだろう。339のプログラムには鍵スケ
ジューリングのコードが含まれていないが、実際には必要
だよね。

真の乱数をソフトウエアだけで得ることはできないので、
(特別なハードウエアナシでも、タイマ・HDDのへッドの位
置・他のプロセスの状態・I/O割り込みなどからランダムネ
スを得ることができるが、非常に低速)鍵スケジュールは
疑似乱数列で行わざるを得ない。(実行のたびに「真の乱数」
が毎秒何Mbitも手に入るというのは、都合が良すぎる。)

>>434
問題を解く際のオーダーは、依然として多項式時間には
なっていないだろ？ 何の意味も無いよ。

たとえば、ＲＳＡ で暗号化するとしても、
「平文１ブロックのうち上位３ビットが分かっていました（既知の平文）。
そのため、力技で解読するのに通常より１／８の時間で解けます。
故に ＲＳＡ は既知平文攻撃に弱いです。」とは言わんだろ？

>このrand0, rand1, ...のこと。
  rand0 = rt[k[n+0]]^rt[k[n+1]]...
だろ？ 結局は rt の乱数の性質にかかってくる。

>毎秒何Mbitも手に入るというのは、都合が良すぎる。
なして「何Mbit」も必要な訳？
・rt を 64k バイト
・k を ８個( 16 バイト)
・平文を 1T バイト
・１秒で送信
と仮定した場合でも、必要になる乱数の数は 16384 バイト／秒 だろ？
（計算間違ってたらスマソ）
まぁ、rt を最初のように 1M バイトにすれば、もっと小さくなるし、
しかもこれは最初に言ったように疑似乱数でかまわないと思うし。

>>432
終わったのではない。まだ何も始まっていないだけだ。

暗号化のアルゴリズム（＆ソース）を公開して、>>1の住所と電話番号（＆恥ずかしい写真）を
暗号化したものを公開（当然鍵は非公開でいい）すれば、祭りが始まる・・・

その勇気ある？（ｗ

>>434
>もういちど言うが、「周期がない」ことと「1周するまで使わない」ことは違う。
仮にこのアルゴリズムに周期があったとする。
周期があるとすれば、その周期の長さは rt の要素数しかないだろう。
で、その周期を利用して解読を試みる（とりあえずブロックの
最初の１バイトを対象とする）とすると、

  b[0]=t[0]^rt[k[0]]^rt[k[1]]...

の最初の t[0] の頻度に偏りがあり、かつ
rt[k[0]]^rt[k[1]]... も "周期" によって頻度に偏りが
生じていなければ、b[0] に偏りは現れてこない。

t[0]に頻度の偏りがあるのは自明だが、
rt[k[0]]^rt[k[1]]... については、k 自体が前のブロックとは
何の関わりも持っていない為、周期を生まなくなると思うのだが。

ソースと暗号化した＊＊入りファイルを公開！！
開発言語は見てくれればわかるでしょう
パスワードとキーファイルは未公開だけどね

http://www.geocities.co.jp/SiliconValley-Sunnyvale/4822/window.zip

↑の公開は０：３０を持って終了しますので
お早めに

なんだ。
ここにはRSAのことなら俺に聞けなやつはいないのか。

>>435
＞たとえば、ＲＳＡで暗号化するとしても、
＞「平文１ブロックのうち上位３ビットが分かっていました（既知の平文）。
＞そのため、力技で解読するのに通常より１／８の時間で解けます。
＞故にＲＳＡは既知平文攻撃に弱いです。」とは言わんだろ？

そうではない。良く嫁。
「ある暗号文に対する
平文１ブロックのうち上位3ビットが分かっていました。
その結果、＊別の暗号文についても＊解読に１／８の時間で解けます。」
なら「RSAは既知平文攻撃に弱いです。」と言える。（しかしそうではない。）

339暗号は、
「ある暗号文に対する平文１ブロックが分かっていました。
すると、＊別の暗号文についても＊平文１ブロックがそのまま分かります。
他のブロックも1/256の時間で解けます。」
だから「既知平文攻撃に弱いです。」

＞>毎秒何Mbitも手に入るというのは、都合が良すぎる。
＞なして「何Mbit」も必要な訳？
＞・rt を 64k バイト
＞・k を８個( 16 バイト)
＞・平文を 1T バイト
＞・１秒で送信
＞と仮定した場合でも、必要になる乱数の数は 16384 バイト／秒だろ？
計算がまちがってる。
平文64KB毎に16B(4KB毎に1B)の乱数が必要なら、
1T/4K=256MB/sの乱数が必要。
平文1MB毎に20B(50KB毎に1B)の乱数が必要なら、
1T/50K=20MB/sの乱数が必要。

>だから「既知平文攻撃に弱いです。
言いたい事はわかった。でもこれって暗号の弱さというより
鍵の転送方法の弱さだよね？
しかも、１／２５６ になったところで、それ以上の効率的な攻撃は
出来ないので、実際は痛くも痒くも無いし。

>計算がまちがってる。
すまん。朝っぱらで急いでたのでぼけていた。
でも現実に ＣＦＢ は役に立たないものとは思われていない様だが？

なんか、もうちょっと "致命的な" 欠点って無いもんかなぁ。

>>439
速すぎー（ｗ

>>443
激しく同意ー（ｗ

パラレルワールドの力を使う量子コンピュータができれば、
既存の暗号はほとんど無意味。

カオス暗号の論文を探しているんですけど、
どなたかご存じないですか?
どんなものでも良いんです。
知っている方がいたら、
ぜひ教えてください。
お願いします。

ここの>>1って
http://homepage3.nifty.com/allocation/software/q-ran.htm
こいつじゃねーか？
なんかショーもない暗号ソフト販売しようとしてるし

>>447
このホムペ, いたすぎ…w

表引きxor…
しかも、表の大きさで価値を決めようとしてるところから見て間違いない。

>>449
おいおい、俺は>>1とは別人だぞ。何か俺も>>1と同じ扱いされているみたいだな。
一言断っておくが、別に俺の方法は表の大きさで解読を複雑にさせようとしている訳ではない。
この方法の強度は一重に表の「組み合わせの多さ」に依存している。

・・・このままだとなんか悔しいので>>1の真似をやってみる（ｗ
これで違いが分かると思うが。

この暗号解いてみ〜〜
GP03DのCGは出てこないけど
解けたら誉めてあげまする〜

本場の的は私作の暗号アルゴが通用するかのテストだよん♪
当然ソースコード付き。鍵のみ非公開。しかもわざわざ解きやすくする為
以下のように随所に工夫を凝らしてあるよん。

・平文はS-JISの日本文（多少のASCII文字も含む。改行は 0x0D,0x0A ）。
内容は、まぁ、誰もが納得する標準的な文章。
・ブロック長はたったの256バイト。次へのブロックの鍵の生成には比較的単純且つ
標準的な方法を使っている。周期を利用して解読出来るならやってみれ。
・鍵長は16バイト。しかも符号化にはXORを使っているので、自ずと鍵の組み合わせが限られている。
・既知平文攻撃したい香具師の為に、平文の先頭64バイトは空白(0x20)である事が保証されている。
勿論ブロック暗号化なんてけちな小細工はしない。いわゆる単文字換字って奴。

http://tool-ya.ddo.jp/2ch/trash-box/contents.jsp?file=20020804114524000.lzh

>>450
ちゃうちゃう。
447のアドレスの暗号プログラムの名前と内容から
1 乱数
2 xor
3 巨大な表で価値を決定
という3つの要素が見て取れるから、>>1じゃないかって話。

>>451
あら、すまん。勘違いしたか・・・

でもせっかく作っちゃったから、
腕に覚えのある奴は香具師は是非とも挑戦してみてくれ。