色々書いてたら本文が長すぎるって怒られたorz

>>222
ラウンドについては調べてないが、おそらくその暗号を解くには、例えばAの式を解いてBの式を解いて、と手順を踏まなければならず
「最初の数個は逆計算が可能である」事に対し、「○○ラウンド目までは解析可能」という言い回しが使われるのかと。

ブロック暗号で言う128bitだのそういう値は、「鍵か何かから乱数を作るとその大きさになるから、その分まとめて暗号化処理してしまおう」という
発想じゃないかと。ストリーム暗号だとこれが1Byteとか1bitとか、もっと細かい処理単位になる。
ちなみに1Byte=8bitな。

暗号化方式によって多少異なるけど、殆どの暗号はまず、鍵か何かから乱数のようなものを生成して、
その乱数と平文との排他的論理和を取ったりして暗号文を作成する。だから、平文は全体的に暗号化されてます。
で、この時攻撃対象になりうるのが、例えば乱数のようなものを生成する関数。前までに出た値から次の値が予測できるとき、これは暗号強度に問題があるとみなされる。

>>223
＞鍵がわからなければ、「その暗号化の処理の仕組み、全ての知っている暗号化技術(ソフト)を作った開発者達」でさえ平文がわからない暗号化技術もあるのですよね‥？
というより、それが前提だと思うんだが。
鍵以外の情報は（暗号化方式や暗号文、あと非対称鍵暗号なら公開鍵も）全て相手に知らされている、という仮定の上で
鍵空間への全数検索をするより効率的に平文が復元できるか、という問題に対し、NOと言えるのが一般人が手に取る場所にある暗号化方法な訳で。

＞例え短い鍵でも、すごい複雑な乱数列発生させて平文を
＞(時間かけたりして)よりぐちゃぐちゃに暗号化するツールが理想‥？
短い鍵でも安全だとは言えない。短い鍵でも十分なら、今度は乱数の生成関数ではなく、鍵の方が攻撃対象になる。
鍵が十分に短ければ、それこそ一瞬で暗号は解かれてしまう。

＞＆漢字全てに別々の識別を持たせた(2ビットとかでの？)情報を与えることができる=8ビットで256種類とか、ブロック暗号なら128ビットで(2の128乗)の階乗？
あのな、計算があっているかは兎も角として、計算に階乗は使わないし、そんな長い鍵をいちいち生成できるなら、OTPやれよ。