ブロック長と圧縮率の関係は・・・

もっとブロック長を大きくして試してみたい
int型をbyte型に変換すればメモリは確保できるが・・・
処理は遅くなるし計算量も増える・・・＾＾；

処理速度を上げるには・・・
処理結果をメモリ上に一時保管し
アクセス速度を上げて・・・

って・・・確保したメモリを使用したら・・・TT
この際処理時間は考えずに・・・

たぶん・・・
終了を待てないだろうな・・・；；

なんか良い方法はないだろうか？？？

暗号の安全性は安全性は必ずしも鍵長で表されるわけではない

そこで同種の暗号はもとより異種の暗号に対しても
同一の評価尺度で安全性を示すようにしたのが等価安全性である

等価安全性は評価対象にする暗号に対して
最も効率的な攻撃法方を用いた時の解読計算量で表現される

では鍵長は何を表すのだろうか？
暗号はどんなに安全に設計しても
これ以上安全性を達成することは理論上ありえない
という限界を示している

つまり鍵長は安全性の上限を示しているのである
上述のように暗号アルゴリズムの脆弱性が発見されるたびに
安全性は低下しているので
同種の暗号であっても鍵長で安全性を比較することはできない

その他、実装に関して

アルゴリズムによっては
ある特定の鍵や方程式を使用した時に脆弱性がある場合も・・・

また実装攻撃に対する注意も必要である
これはアルゴリズムに関係なく
実装した製造物（ハードウェアやソフトウェア）に対する攻撃で
電力解析攻撃やタイミング攻撃、正規外の入力、モジュールの変形等がある

Java の int型 は符号付 32bit だから・・・

int i = (1 << 31)　は
i = -2,147,483,648　である

さらに -1 ってことは・・・
実行結果は

i = 2,147,483,647

正の数になってる・・・
16進数で考えると

int i = (1 << 31) は
i = 0x80000000 だし・・・

-1 は2の補数で 0xFFFFFFFF だから・・・

和を取ると最上位ビットが桁あふれして・・・

i = 0x7FFFFFFF となるから・・・
i = 2,147,483,647 となるのか

でも感覚的には・・・

int i = ~(1 << 31) のように

シフト演算の後1の補数(ビット反転)にした方が・・・
でも簡単な演算の場合
シフト演算より四則演算の方が速い・・・って
聞いたこともあるから・・・

どっちがいいのだろ？？？

デファクトスタンダード暗号技術の大移行
AESにより新たなブロック暗号が選定され、
AHSにより新たなハッシュ関数が選定されようとしている。

しかし、どんなに強度の高いアルゴリズムを使用しても
鍵管理がずさんであれば、解読されやすい。

毎回異なり推測されにくい鍵となると・・・
同じパスワードでも異なる鍵を生成するように
ソフト側で対応した方がいいんだようなぁ・・・

HPを更新しました。

レンジコーダのページの加筆と
数と符号のページの追加です。