日記緑ログ

2006/05/04 ~ 2006/05/27

目次

戻る

Blog

TrueCryptで情報を守れ

[Create: 2006/05/04 17:58] [LastUpdate: 2006/05/04 18:20]

社内情報、機密情報、個人情報がだだ漏れでやばい。そんな状況が最近続いている。別にファイル共有ソフトを使ったからとか、ウィルスに感染したからではない。そんなレイヤーをつぶすようなadhocなその場限りの解決策ではなにも解決になっていない。

数年前にも大規模な漏れというのがあって、どっかのサイトだかのサーバーのある階層にアクセスすると丸見えとかなんかノートPCを紛失したとかいうものが結構ある。紙の束を落としたら情報は丸見えだがノートPCを落としたりしても大丈夫になる方法はあるものだ。

情 報漏れの根本的解決策は情報を動かさないことだ。社員教育というものが徹底すれば大丈夫だというのだが学校時代あたりで、因数分解が分からんとか過去分 詞ってなにとか係り結びが憎いとか分数は何でひっくり返して掛けると割り算になるん? とか義経が死んだのは何年だか覚えられないとかあるでしょう。いや 自分自身に無くても学級の中には居るでしょう。それも居なかったならあなたはずいぶん不幸な生活をしていたことになりますのでこれ以降は読まなくて結構で す。

話がずれたが、要するにいくら教えても人が増えると統制を取りにくくなるし、教えたところで実際にどのぐらいやれるかは分からないのだ。徹底 した教育をするとなるとやれ日勤教育だとかデスマーチ……は違うがマスコミ沙汰になったりするし、今は学校でも殴ったら駄目とか言う馬鹿げた風潮もある。 分からないなら体に教えるしかないと思うのだが……(なんならヨーロッパでもみてみろ)。

で、教育でも追いつかないとなるとやっぱり情報 を使わせないことが一番になる。バッチ処理を起動するだけで情報には触れないとかいうことでもいいのだがやはり情報を使わないとできないことはある。幹部 クラスだけ……とか言っても今時分の幹部クラスには○○が多いのでそんなのは無駄である。

段々本題に近づいてきたが、要するにフェイルセーフの考えだ。人的ミスがあったときには機械的に二重三重に安全策をとればいい。

まず情報を勝手にコピーできなくする体制をとる。社内PCから持ち出したりできないようにするわけだ。

どうしても持ち出したいときは特別な社用ノートPC等を利用する。

社用PCのユーザーアカウントはできる限り制限をかけておく。一般ユーザーでも権限が高すぎる。Admin権限などもってのほか。制限Userに重ねて制限を掛けるぐらいの気持ちをもつこと。

USBメモリ等軽軽しく使えないようにする。

USBキーというものがあるが、紛失したら終わりだし、どうせ両方持って歩くことになる。せめて指紋キーぐらいはやらないと駄目。

ディスクを暗号化する。OS標準の方法だとまあUser文書は微妙に守られるが単なるアクセス制限だとPCをばらして他のPCのAdminで一発なのでもっと激烈に暗号化する必要がある。

というわけでTrueCrypt。 ディスクを暗号化するというよりは暗号化ディスクを構築する。暗号化ディスクの実体はファイルで暗号化されて保存されるわけだ。これを使うときだけマウン トする。まあ実際どのぐらい使ってあとはアンマウントとなるかは難しいのですが少なくとも起動と同時にオートマウントしなければPC自体を紛失してもそれ がなんだか解読不可能な状態にはなるのでlostしてもleakは防げる。実際にはeraser等でワイプ処理して実体の残骸をノーマルディスクに残さな いように注意する必要があるがこのぐらいするとよほど安心である。

まあマウント状態でコピーすると漏れるわけだがそういう処理をできる限り抑える設定にしておく管理者さえばっちりいればそうそう漏れるものでもない……と思う。最低限の教育と懲罰は必要ですがね。

むかしむかしのHTMLと今の4.01やらXHTML 1.0、1.1あたり

[Create: 2006/05/09 20:03] [LastUpdate: 2006/05/09 20:24]

あまり古いのは知らないがちょと昔の雑誌の切り抜きに『ホームページ製作講座』というのがあった。『ホームページ』とはできる限り言わないようにしている私だがそれはどうでもいい。

そのころはHTML3.2のころだと思う。タグリファレンスなども雑誌についてきたりして重宝したものだ。

そのころの記事を見ているとBODY直下にテキストべた書きでBRで改行している。

これは規格上も間違っていないはずだ。HTML 4.01 Transitionalあたりでもできたような気がする。

CSSなんてものは無いからBODYにCOLORとかの属性を埋め込んでみたりイメージを張り付けたりFONTタグで修飾したりと今ではどれもまずい世の中になっている(このぐらいならまだまだ生きているが)。

古いソフトやら古い書籍ではまあこういうものだということになっているはずなのであまり参考にしないほうがいいと思うが、実は私はそっちのほうが好きだ。

文 書としてXHTML(1、1.1どちらも)レベル(HTML 4.01 Strictもほぼ同じ)は実によろしい。基本的に一つのHTMLを一枚の紙として、一枚の紙で一文書が完結するスタイルだ。これはTeXあたりでもそう で、文書としては実にいいのだ。H[1-6]タグを正確に使わず適当にDIVで誤魔化すようなことはせず、正確に構造を構築するようにできているのだ。 HTMLはワープロの文書とは違うが3まではどちらかといえばそれに近いスタンスで動いていた(主にNSと後にMSが)。カラフルで見た目に鮮やか、派手 なスタイルに待ったがかかったわけだ。

HTML+CSSというスタイルは結構よろしくて好きだが、迷うのがあまりグローバルでないスタイル付けや ら完全ローカルなIDのスタイル付けだ。インラインでstyle埋め込め坊や。というヤツはちょっと気合を入れなおしてあげるとしてHTMLのヘッダ部に 入れるのは美しくないし、メインのCSSに入れるのは嫌だ。かといってばらばらにしても数が増えて鬱陶しいし一つにすれば膨れて困る。まあそんなことは めったに無いのだが。

で、とりとめも無い話で締めも何も無い。まあそれだけの話だ。

何か言うとしたらIE2のころはBGCOLOR指定しないとバックは灰色だったと。だから雑誌でもみんなBGCOLORとCOLORの属性は指定していたんですね。

AdobeのAjaxページ作成フレームワークSpry

[Create: 2006/05/12 18:55] [LastUpdate: 2006/05/12 19:10]

Adobe、Ajax対応ページ作成用の「Spry」公開

とりあえず飛びつく。

ライセンスはBSD。

SpryData.jsとxpath.jsをinclude(というかscriptタグで指定)して使う。

.jsでGPLですというのはいかにもあほ(そもそもソースは丸見えなので意味が無い)ですがBSDということはページ内にcopyright表記をしとということでしょう。多分。いやトップページにでも書けばいいのか。

チュートリアルっぽいドキュメントや、妙なサンプルも付属していますからチェックしてみるといいと思います。

prototype.js以外の選択肢として結構有力でしょう。

#JavaScriptはブラウザ間の互換性に厳しい部分があるのでこういったフレームワークを積極的に使ったほうが大抵いいのでライセンスに納得できない場合や、一から構築したい症候群、暇で仕方が無い人以外は使いましょう。

庄屋様

[Create: 2006/05/14 10:37] [LastUpdate: 2006/05/14 10:51]

4日ぐらいまえからだろうか。庄屋の家の解体をしている。いつから立っていいたのか分からないが庄屋だけあってでかかった。ちなみに同級生というか幼馴染みたいなやつがいて昔は結構一緒に遊んだものだ。

この柱が太い。一般の家庭では十センチ角(3寸)ぐらいが普通だと思うが6寸×9寸だとかそのぐらいだろうか。

ど うでもいい話だが庄屋とその周りの人々は恐らくそう遠くない血縁関係がある連中ばかりのはずだ。ここらあたりの集落(実際町のあれにも部落とか書いてある が誤解を招きそうなので以下集落と言おう。差別階級の意味ではない。ここらあたりでは昔は知らないがそういった文化は皆無である。)にはほぼ7割が同じ苗 字である。というか回覧版とかまわすときにたまーに違う苗字があるがおまえらどこからきたのや?ぐらい。もちろん私も同じ苗字なわけで土着しすぎとかそう いった気持ちもある。なにせ小学校でも依然として3割は同じ苗字なのだ。佐藤鈴木山田のようなスペシャル的苗字はいない。佐藤が二人いたがその五倍はわれ らが苗字でこれは必然的に伊達の力なのか。

今では庄屋とは親類ではない状態だし、べつに血縁はどうでもいいのだがここまで増えてくるとちょっと面白い。

締 めにはまあ関係ない話かもしれないがこの庄屋という言葉なのだ。辞書を幾つか見たのだが庄屋というのは関西地方の呼び名で関東では名主、北陸とかそっちで は肝煎などと呼ぶらしい。らしいというだけで家は東北だぜ? みたいな。実際どこに行っても名主だとか肝煎等と呼ぶ者はおらず庄屋一本なのだがわれらの苗 字が西のほうからきた人物と関連するとかいう歴史上のあれなのかもしれない。詳しくは知らないし調べてもいないのだが。

圧縮?

[Create: 2006/05/21 19:26] [LastUpdate: 2006/05/21 20:00]

ぱっと閃いたのだが256×256の配列を用意して直前のオクテットで切り替えてあげて、後続の一オクテットを予測というか確率でソートしてあげると

01234567

というのがあったときに0の次に来る確率は1が高いから

data[0][0] == 1;

data[0][1] == 0;

data[0][2] == 2;

とかまあそんな感じで1が一番高いから一番インデックスが小さいとかそんな具合にしてあげたとしてやるとゴロム符号でよく縮みそうな気がした。

確率でソートするとかそういうのってPPMとかの範疇なのかね? よく分からん。

面倒なので一回でたら一つ前にシフトするようにして適当に遊んでみた。

結果。膨れる(爆笑)。

あれですよ。初期化がまずい。いぜん出てきていない値はエスケープしてそのまま出力しているのだが、エスケープは256。ゴロム符号じゃ膨れるわな。

ああ、じゃあ配列をLZWみたいに初期化しておいてエスケープが出ないようにしてみよう。…イマイチ。収束に時間がかかって無理。

多分動的でやってるのがまずいのだろうが動的でないとどうよ? 64kも辞書になってしまうのでうまくない。

ゴロム符号をunaryでなくすると(そこそこ一様に並ぶようにするというあれ)場合によって縮んだりするし、テキストだと半分ぐらいになったりもするので気持ちとしては間違っていないと思うのだが一つはソートともう一つは誠実さだろうか。

直 前の256個で予測しなくとも常に次が何か(何がでやすいか)予測すればエントロピー符号化できそうな気がしないでもない。というかオクテットだと何らか わらない。次は20%の確率で0が来る。10%で1が来る。直前のデータで変化させなければこの%を(多分)全体の出現率でふることになるので多分ハフマ ンぐらいのものになる。

直前のあれで振り分けるのがコツなのであってその予測値を一種の距離として一番可能性が高いものから短い符号を割り当てるだけだ。要するにこれってエントロピー符号と似たような思想なのね。

実際の考えでは直前のほにゃららでも予測のほにゃららでもだがLZ法の辞書にできるのではないかと考えている。

つ まりはそういうわけだがLZ法との違いは予測される確率によって同じ単語でも符号が変化するということだ。静的な方法では辞書は固定されてしまうからそれ は無いが、動的だとそうでもない。次に例をあげたいのだが簡単のために直前辞書は256個の配列としてオクテット値そのものと考えよう。

直前単語辞書

0予測辞書

1予測辞書

2予測辞書

となることになる。

ここで0の予測辞書が

1

123

211

011

のようになっていたとする。

次に以下のようなデータがあるとする。

0211211

0を読み込んで流したとして次は211があるからそのインデックス値である2を流す。動的に辞書を変化させるから確率を変動させ、その結果辞書が次のようになるとする。

1

211

123

011

すると次は1を流すことになる。

別に難しくは無いので問題はないのだが、ゴロム符号だと距離が短い(数値が小さい)程、少ないデータ量で現せるのでよさそうな気がした。気がしただけで確率でかわるんなら普通のエントロピー圧縮でいいじゃない? とかそんな気もする。

ともあれ実験は終了である。とかこんなことをやって過ごしていてねたが無いので更新をサボっていることがばればれなのだが。

圧縮? その2

[Create: 2006/05/22 17:23] [LastUpdate: 2006/05/22 19:03]

全然縮まないよー。ふあー。

という前回の話をさておいてどのぐらい予測?できているか出力して確かめてみた。

前回のあれだと駄目だと思うのできちんと確率でソートするようにした。しかし動的にやっているのでこれまたイマイチなのだが。

ある実行ファイルの例。

00: 1139164

01: 284581

02: 178572

03: 134899

04: 109151

05: 93876

06: 83119

07: 73868

もう一つの例

00: 1139164

01: 284581

02: 178572

03: 134899

04: 109151

05: 93876

06: 83119

07: 73868

ど ちらも頭8つだけだが、個人としては予想以上に予測というかまあ0の出現が多くできていると感じた。ゴロムだとこのぐらいフラットな状態だと縮まないので Rangecoderだとどうだろうということでやると膨らまないが縮まない。まあそこそこ当然かもしれないが出現率を考慮してうまくコードを振らないと 駄目ね。あと255で打ち止めとかしているからね。本当はもっと縮みそうね。

で上のほうの1~255までの合計が2915977で下は655332。どちらも3分の1ぐらい0になっていて実はそこは嬉しいのだ。

これをLZの辞書にすると縮むんじゃないかとか思うのだがやる気はあまり無い。というかこれってやっぱりPPMなのだろうか。

という遊びをしておしまい。

Java用のLHa書庫操作ライブラリ

[Create: 2006/05/23 22:23] [LastUpdate: 2006/05/23 22:37]

DANGAN's HomepageにLHA Library for Javaという物が公開されています。

JavaでLHa書庫を操作する事があるかどうか分かりませんが知っておくと何かと役に立つかもしれません。

ソースも公開されておりライセンスは明記されていてライセンス名は明記されていないのですが修正BSDライセンスだと思えばいいと思います。

LHa関連でソースがオープンなのはオリジナルの2.11があります。これはライセンスはうるさくない(そういう時代なのだ)のですがなにぶん古いのでよほどライセンスにこだわる必要が無い限り使う必要は無いでしょう。

もう一つLHa for UNIXもオープンソースですがこちらはGPLであり(やはりライセンス名が無いのだが……)、やや注意が必要かと思います。

そもそもナニして組み込むような事はめったに無いと思いますが。

鼻水と喉の痛みとくしゃみが酷い

[Create: 2006/05/27 21:28] [LastUpdate: 2006/05/27 21:29]

くさめくさめ。

この時期はいつもぐったりします。普段も夜はろくに眠れませんがこの時期は輪をかけて眠れません。

どのぐらいかは想像にお任せ。