FTP経由でTrueCryptボリュームをマウントする
FTP経由でTrueCryptボリュームファイルをマウントすることは可能ですか？
TrueCryptがローカルファイルでどのように機能するかを次に示します。
- ユーザーがボリュームファイルへのパスを入力し、パスワードを入力します
- TrueCryptはパスワードが正しいことを確認します（おそらくボリュームファイルの最初の部分を復号化することによって？）
- TrueCryptはボリュームファイルからディレクトリリストを読み取り、ボリュームをマウントします。 ただし、このステップでは、TrueCryptはボリュームファイル全体を処理しません。
- ユーザーはディレクトリリストを参照してファイルを開きます。
- TrueCryptは、ユーザーが必要とするファイルを含むボリュームファイルの部分のみを読み取り、それを復号化します。 繰り返しになりますが、TrueCryptはボリュームファイル全体を処理せず、その一部のみを読み取ります。
- ユーザーはファイルの一部を編集して保存します。
- TrueCryptは変更を暗号化し、ボリュームファイルを編集します。
FTP経由でボリュームをマウントできるはずだと確信していますセキュリティを損なうことなく、ボリュームの一部を読み取るためだけにボリュームファイル全体を転送する必要もありません。
これが私がそれを想像する方法です：
- ユーザーがボリュームファイルにFTPパスを入力し、FTPログイン情報を入力し、ボリュームにパスワードを入力します
- TrueCryptはボリュームファイルの最初の部分をダウンロードし、パスワードが正しいことを確認します
- TrueCryptは、ディレクトリリストを含むボリュームファイルの一部をダウンロードします。データはFTP経由で暗号化されて送信され、ローカルで復号化されます。
- ユーザーはディレクトリリストを参照してファイルを開きます。
- TrueCryptは、ユーザーが必要とするファイルを含むボリュームファイルの一部のみをダウンロードし、ローカルで復号化します。
- ユーザーはファイルの一部を編集して保存します。
- TrueCryptは変更を暗号化し、FTP経由でボリュームファイルを編集し、暗号化されたデータのみを転送します。
そのような機能は利用できますか？
FTPよりも安全なSFTPを使用する方が理にかなっているのではないでしょうか。
考えられる解決策は、SFTPをローカルにマウントし、SFTPマウントからTrueCryptボリュームをマウントすることです。 FTPを使用する必要がある場合は、SFTPの代わりにFTPをマウントできます。
私は基本的にあなたが求めていることをしましたが、Gitをバックアップファイルに統合しました： http://theo.cc/blog/2010/07/encrypted-git-repo-with-truecrypt-and-sshfs/
Truecryptは、バッキングストレージ（ファイルであろうとボリュームであろうと）をブロックレベルで暗号化します。ファイルレベルでは機能しません。 Truecryptの実装、デバッグを容易にし、信頼性に貢献するため、これはGood Thing（tm）です。
そのため、Truecrypt自体は、暗号化/復号化するストレージ内の「ファイル」を認識しません。これは、ファイルシステムドライバー（ntfs.sys、fastfat.sysなど）がその仲介役として機能し、ファイルの要求をブロックの要求に、またはその逆に変換する責任があります。
したがって、Truecrypt自体は、ファイルの名前やボリュームの「一部」を取得したり、独自にファイル操作を実行したりすることはできません。それを行うソフトウェアであるファイルシステム層は、Truecryptの一部ではありません。
質問で説明されている操作モードをサポートするものは何も知りません。他の人が指摘しているように、TrueCryptはファイルシステムドライバーの下にあるブロックデバイスドライバーを実装しています。 FTPサーバーとの間でブロックを透過的に転送する別のレイヤーをTrueCryptの下に挿入できれば、それは機能します。これで、Linux ループバックデバイス を使用してブロックの読み取りと書き込みをインターセプトできるかどうか疑問に思います。または、Windowsでは、 Virtual CloneDrive がISOイメージファイルをマウントされたディスクドライブのように見せるために使用するのと同じトリックですか？カーネルプログラミングはまだ必要だと思います。