JanusDG で ascii armored ファイルを扱う際の問題

先日、akira さんからいただいたコメントに関連して。

akiraさんの要望は、「JanusDG に ascii armored モードを」というものでした。

以前、同趣旨の要望を他の方から頂きましたが、その際は消化しきれず、カスタムバージョンを別途用意する形でお答えするしかありませんでした。
同じ問題を、今も消化しきれずにいます。

今日はその説明を多少長めに。

JanusDGで、暗号ファイルを ascii armored にするのはたやすいことです。KageHinataのソースを軽く流用するだけ、いや、その必要までもなく、ちょちょっとソースを改造するだけで対応可能です。暗号化する側も、復号する側も、ファイルが ascii armored であるかどうかを気にする必要はありません。GnuPGが自動的に処理してくれるからです。

問題は鍵ファイルです。
鍵ファイルを ascii armored で export するところまではまだ容易です。
しかし、その鍵ファイル、受け取った側ではそのままではJanusDGで使うことができません。
JanusDGでは、相手から受け取った鍵ファイルをそのまま公開鍵として使用することで、鍵輪の概念を知らない人でも利用できるようにしてありました。これは鍵ファイルがバイナリ形式だから可能であったことです。
JanusDGの暗号エンジンであるGnuPGでは、ascii armoredの鍵ファイルは、そのまま公開鍵としては使えないようになっています。ascii armoredで受け取った鍵は、一旦バイナリ化する必要があるのです。

この制約のため、鍵ファイルを ascii armored 形式で運用するには「ascii armoredの鍵をバイナリ化するユーティリティをつける」あるいは「KageHinata同様の鍵管理機構を追加する」というような対策が必用になります。
別解として、「鍵ファイルについてはascii armored化しない」という手もあります。

これらの方策はそれぞれ欠点をかかえています。
「ascii armoredの鍵をバイナリ化するユーティリティをつける」というのでは、JanusDGが本来目指したシンプルさを否定する形になってしまいます。
「鍵管理機構の追加」というのも、ユーザーに新たに「鍵輪」の概念を覚えてもらう必要が出てくるので、やはりJanusDGの目指したものとは異なってしまいます。
「鍵ファイルはバイナリのまま」というのが、もっとも現実的だとは思うのですが、統一性がないのが気に入りません。

JanusDG2では、上のいずれかの流れに沿った回答を出さなければいけないのですが、まだ気持ちが揺れているというのが正直なところです。

ブログ気持玉

クリックして気持ちを伝えよう!

ログインしてクリックすれば、自分のブログへのリンクが付きます。

→ログインへ

なるほど(納得、参考になった、ヘー)
驚いた
面白い
ナイス
ガッツ(がんばれ!)
かわいい

気持玉数 : 0

この記事へのコメント

akira
2007年04月24日 00:48
エントリー建てていただいて恐縮です。
4/22のコメントにも書きましたが、
・KageHinataの今後の動向。
が私の要望のポイントになるのかな。と思います。
(なんか変な書き方ですが。)

「鍵ファイルはバイナリのまま」というのはOKで、問題はデータの部分なんですが、これもKageHinataが現状のままならそのままでいいかなと思っています。

KageHinataがもし別物に進化した時は、ぜひJanusDGが出力するデータに、従来のものの他に「ascii armored」の「選択肢」を追加して欲しいです。
kazuyoshikakihara
2007年04月24日 23:38
えーと、私の方針としては、
・KageHinataはどこかへ進化
・JanusDGには「ascii armored」機能を付加
というようにもっていきたいと思っています。

まあ、GnuPGを超える暗号化エンジンはまだしばらく出てこないでしょうから、もしかしたらKageHinataも正常進化を続けざるをえなくなるのかもしれませんね。

私がakiraさんに教えを乞いたいのは、なぜ「鍵ファイルはバイナリのまま」というのがOKなのか、その理由のほうです。
想像力が足りないせいか、鍵がバイナリで暗号ファイルがASCIIという運用形態がピンとこないのです。そういうニーズがありそうだなと薄々感じてはいるのですが、確信を持つにはまだ至っていません。
どのような使い方を想定されているのか、ご開示いただけないでしょうか。
akira
2007年04月25日 00:54
何度も恐縮です。
何か申し訳なくなってきました。

動機の一つは、職場のネットワークが今ひとつ信用できない。と言うのが発端です。

鍵ファイルバイナリOKというのは、開き直って「鍵ファイルはやりとりする相手に直接会って渡してしまえ。」というのが一つで、USBメモリにでも入れてこちらの手で相手のPCに直接送り込んでしまえ。というのもありかな。ということです。
(その際、JanusDG or KageHinataは私の手でインストール&簡単に使い方のレクチャーというのも含まれますが。(笑)

あと、暗号ファイルがASCIIでもOKというのは、暗号化の選択肢を増やしたい。と言うのが一つです。
akira
2007年04月25日 01:06
あと、職場のネットワークはバイナリの制限がきついので、拡張子gpgが通るのかと言う心配もあったのですが、先日試しにJanusDGで作った暗号化ファイルを職場のメールアドレスに送ったところ、あっさり通ってしまったので、なんか強く要望した割に現状でもOKという現実に会ってしまい、非常に申し訳なく感じてきた所です。(苦笑

ただ、ブログのエントリに、「KageHinataはGPGを使わない別の暗号ソフトに進化する」というのを見つけたので、ASCII形式出力を選択肢の一つとしてJanusDGに残しておいて頂きたいな。という要望を出したのです。
akira
2007年04月25日 01:21
あと、「鍵ファイル」はもちろんASCII形式でのやりとりも出来るにこした事はないのですが、「機能限定でシンプル・軽快に暗号化と復号が出来るJanusDG」というコンセプトは私も理解しますので、そこまでは。と言う気持ちです。

暗号ファイルのASCII形式を要望しておいて、この部分は矛盾するのかも知れませんが、そこは仕方がないかな。と思っています。
akira
2007年04月25日 01:35
ちなみに、「USBメモリで持ち運ぶデータを暗号化」というJanusDG本来の(?)使い方もさせてもらっています。
JanusDG本体と暗号データは別のUSBメモリに入れ、暗号データの入ったUSBメモリを持ち運ぶようにしています。
D&Dで簡単に暗号化復号化が出来るので重宝してます。
複数ファイルがある時はLHAやZIPでまとめてからJanusDGに掛けてます。
kazuyoshikakihara
2007年04月26日 00:09
akiraさん、お手数おかけしました。わざわざ解説いただいてこちらこそ恐縮です。
JanusDG次期版についてはまだ仕様取りまとめ中ですが、
・GnuPGベースの暗号ファイル
・シンプルさは堅持
・ascii armoredは何らかの形で採用
・複数ファイルの取り扱いが可能
といった点についてはお約束できます。
安心&期待してJanusDGの進化をお待ちください。

KageHinataについては、既存のJanusDGのユーザーがわざわざ乗り換える対象のソフトではないと思っています。乗り換えないことをお勧めします。

この記事へのトラックバック