gpgの対称暗号時の警告をなくす
gpgで暗号化を手軽に使うためにパスフレーズだけによる対称暗号を使っているが、復号時に「gpg: WARNING: message was not integrity protected」という警告がでる。
次のようにするのが安全のようだ。
gpg -a -c --force-mdc < in.txt > out.txt
[参考: サービス提供終了のお知らせ http://www.alles.or.jp/~spiegel/200401.html#d08 ]
Beckyとgpgの接続方法？
gpgでは標準入出力で暗号化・複合化データをやりとりできるが、同時にコンソールからのパスフレーズ入力も受け付ける。
同様なことはsshでも行われているから、このテクニックが分かると、ちょっとしたツールを作るのにいいのではないか、などと思う。
標準入力がコンソールと結びついているか判定するにはisatty関数を使えばいいし、またコンソールデパイスから直接リードすることもできるので、この仕組みは実現できるのは分かる。
しかし、Beckyのプラグインからgpgを呼び出すとき、このパスフレーズの入力をどのように処理しているのか気になったので、ソースをダウンロードして眺めてみた。
GNU Privacy Guard Plug-in for Becky! 2 http://hp.vector.co.jp/authors/VA023900/gpg-pin/
このソースを見る限りでは、普通に標準入力のパイプにパスフレーズを渡しているように見える。
そうなると、gpgではデータとパスフレーズ入力を、どのように切り分けているのか疑問になってくる。
このbeckyプラグインでは暗号化・複合化データをファイルとしてgpgの引数に渡しているので、そのあたりは関係ないのかもしれないが、gpg側では区別する必要はないのだろうか？
あるいはUnix系とWindows系とでは扱いが違うところがあるのか。
いろいろ不明なことが多い。
後日談: GnuPGのオプションに --passphrase-fd (だったと思う)のようなオプションがあり、単に標準出力のファイルIDを指定しているだけだった。なお、プロセスをまたがってファイルハンドルの番号を共有するにはCランタイムライブラリにあるプロセス系関数を使う必要があるが、これだとCreateProcess等で開くときに指定できるウィンドウの非表示などの設定ができない。標準ランタイムライブラリももちろんWin32APIを使っているわけだが、非公開オプションを何か使ってファイルIDのやりとりをしていると推測される。
なお、どうやらGnuPGは16ビットアプリとして構築されているらしく、CreateProcessの第２引数(パラメータ側)に指定しないと起動さえできなかった。
