[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 755] Re: [b-free 889] Re: 暗号化ファイルシ



         =?ISO-2022-JP?B?GyRCJTklRiVgGyhC?=
In-Reply-To: Your message of "Thu, 30 Oct 1997 09:58:40 +0900"
    <9710300058.AA22465@clare.ohsaki.meidensha.co.jp>
References: <9710300058.AA22465@clare.ohsaki.meidensha.co.jp>
X-Mailer: Message Editor Version 1.5.4
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

ども。Akiです。


 In "[b-free 889] Re: 暗号化ファイルシステム" with Takanori Hayashi ,
 (09:58:40 AM +0900 in October 30,1997)
 - takanori wrote.

| 林です。
|
|In message <199710291116.UAA32544@b-free.orient.co.jp>
|   "[b-free 886] Re: 暗号化ファイルシ"
|   "H1Suzuki@bridgew.edu (Hideaki Suzuki)" wrote:
|H1Suzuki> 僕は、最近の54ビットかなんかの暗号が組織的な処理で PC でも
解けたとか、そう
|H1Suzuki> いったニュースとか、極初歩の暗号論理しか知らないのですが、B
-free って公開され
|H1Suzuki> ちゃう訳で、そうすると、どんな暗号が考えられるんです? それ
とも、暗号化され
|H1Suzuki> た file-system は、file-system ごと、非公開にするのでしょう
か?
|
| 普通、現在の暗号化システムでは暗号化のアルゴリズムは公開します。
|そしてキーだけ秘密にします。アルゴリズムを公開しなければ第三者が
|暗号の強度を測れないので暗号に信頼を置けないからです。ちなみに、
|キーが短いと(暗号の方式によらず)総当たり検索によりキーを発見する
|ことができます。54bitの暗号解読は暗号化方式に依存する探索空間の
|限定をやっているので総当たりではないですが、それに近い力ずく検索
|による解読のようです。

なるほど。
アルゴリズムが分かっても、暗号になると言うのは面白いですね。
5次以上の代数方程式の解を求めるような物かな。<必ず解があると分かって
いても代数的に解けない(因数分解できない)。
もしくは、乱数の生成法を公開にし乱数の種を秘密にした乱数表を使うとか。
<話のレベルが違う気が強くする。^^;


|# ちなみに前のメールで書いた「単純なセクタダンプでは読み出せない
|# ように」というやつは暗号でも何でもありません。読む気があれば
|# 簡単に読み出せますから。でもそれでも意味はあると思っています。

これは、僕もそういうつもりでいました。
例えば、1-bit shift するだけでも、大分違いますが、そういった話ですよね
?


| ファイルシステムの暗号化で問題となるのは、一つにはキーをどこに
|保持しておくかです。人間が覚えておくのでは忘れるとおしまいだし、
|ディスクに書き込んでおくと暗号の意味がないし。まあ忘れなければ
|良いという話ではありますけどね。
| 暗号化のもう一つの問題は、OSの認証のような自由度を持てないこと
|です。OS認証ではファイルごとにユーザやグループを設定して、ある
|ユーザだけが書き込めてあるグループのメンバだけが読めるファイル
|というものを設定できますが、暗号化ではそうはいかない。現状では
|マウント時に認証する程度の単純なものしかできませんね。

うーむ。これは、ファイル毎(例えばMOとかで)持ち運んだ場合の話でしょ
うか?

これはやっぱり、Hardware の領域じゃないのかなぁ。
# 解析しようとすると、ショートして焼けるとか。^^;