長期保存のためのPGPのセキュリティ
PGP/GPG暗号化メールはどのくらい安全ですか？
通常の電子メールシナリオではおそらく問題ないと思いますが、より長い期間（30年以上）にわたるセキュリティについてはどうですか？ GPGのRSAキーの4096ビット制限は問題になるのでしょうか（対称のみの暗号化を使用する方法がない場合）。また、私が誤解していない場合、GPGは暗号化テキストを認証しません（プレーンテキストにRSA署名するだけです）。
ここでの使用シナリオは、どこにでもアクセスできるようにするために、パスワードを自分のメールアカウントに（PGPで暗号化されたメールとして）保存したいというものです。ほとんどのアカウントでFirefox Syncを既に使用しています（これは かなり高度なスキーム を使用しています）が、1つのURLのユーザー名/パスワードの組み合わせしか保存していません。時々私はそれと共にいくつかの追加の詳細も保存する必要があるため、それ以外の点では素晴らしいものの、FF Syncを使用できません。
私が見る限り、メールの暗号化のためにPGPとS/MIMEに代わるものは他にありません。これは正しいですか？ （S/MIMEはオプションではありません。サポート方法を確認してください サポートが不十分 現在はThunderbirdが提供しています）
GPGのRSAキーの4096ビット制限は、RSAキーをクラックするための新しいより優れたより高速なアルゴリズムが発見されない限り、セキュリティの問題にはなりません。 。 RSAを解読するための新しいアルゴリズムは頻繁には発生しません。前回は1989年頃 General Number Field Sieve （80年代後半以降のGNFSの科学的進歩のほとんどは、GNFSの実用的な実装と多くの小規模な最適化に関するものですが、コアアルゴリズムです。その時以来変わっていません）。
非対称暗号化はsolve機密性の問題ではないことに注意してください。移動するだけです。秘密鍵をどこかに保存する必要があります。最終的には、パスワードを保存する問題については、「マスターパスフレーズ」で秘密鍵を保護します。これは対称暗号化です。パスワードでいっぱいのファイルに直接対称暗号化を適用することで、プロセス全体を単純化できます（GnuPG それをサポートしています ）。完全に非対称になるのは、秘密鍵にアクセスできず、パスフレーズを入力したくないマシンからの新しいパスワードを保存する場合にのみ（コンテキストでは）興味深いものです。
どちらにしても、[]に保存されているパスワードが問題になります。一部のシステムでは復号化を実行する必要があります。キーロガーがパスフレーズや秘密鍵（非対称暗号化を使用している場合）を取得するため、そのシステムにはマルウェアを含めない方がよいでしょう。理想的には、自分のデバイスからのみ行う必要があります。それは私が旅行するときに行うことです：
- 私のデバイスはLinux搭載ネットブックです。
/tmpディレクトリはメモリベースのファイルシステムです（そのため、ここに書き込んだファイルがSSDになることはありません）。- スワップは構成されていません（したがって、RAMの内容もSSDに書き込まれることはありません）。
/tmpのパスワードファイルを（対称的に）復号化し、パスワードを読み取って入力し、復号化したファイルを削除します。
もちろん、その時点で独自のデバイスがある場合、暗号化されたファイルをメールに保存する必要があるのはなぜですか？デバイスに直接保存できます。
（そういえば、メールは添付ファイルとして任意のファイルを保存できるため、メール固有の形式 OpenPGP および S/MIME に制限する必要はありません。これらのみを使用していくつかのコマンドラインツールに頼る必要がなく、復号化を実行するメールアプリケーションを期待できるという点で、物事はより簡単になります。しかし、コマンドラインツールはより多くの制御を提供すると主張するかもしれませんたとえば、RAMでバックアップされた/tmpファイルシステムなど）。
うまくいけば、トムが他のすべてをカバーしたと思うので、私はあなたの質問の最後の部分をもう少し詳細に議論するトピックから遠すぎないでください。
また、gpgが暗号文でMACを使用しているという兆候も見つかりませんでした。
最近、私は scryptユーティリティ を使用して、パスワードでファイルを暗号化しています（パスワードファイルとバックアップ用のtarファイルの両方）。私が認識しているWindowsビルドはありません（cygwinが機能すると思います）も、それが生成する特定のファイル形式をサポートする他のアプリケーションも認識していません。それは私が探していてあなたのために働くかもしれない他のユーティリティよりもまだ私が探しているものに近いです。意図的にいくつかのオプションがあります。 IMO、検証オプションを使用できます。現在、それを行うには/ dev/nullに復号化する必要があるためです。ドキュメントは素晴らしいものではありません。ソースディストリビューションのFORMATファイルを見て、実際に何が行われているかを確認する必要があります。これは、ランダムな256ビットソルトを使用してパスワードに対してscryptを実行し、2つの256ビットキーを取得します。1つはCTRのAES-256に使用されます。固定ナンスが0のモードと、HMAC-SHA256のもう1つ。また、-t引数で使用される推定時間は正確ではありません。 5秒のキー強化を取得するには、-t 25を使用する必要があることがわかりました。もう1つの厄介なことは、復号化出力をパイプでパイプ処理するのはまったく機能しないため、復号化出力を見たり編集したりするときに、復号化出力を格納する場所を見つける必要があります。私は、メモリファイルシステム（スワップがない、または暗号化されたスワップ、どちらにしろいいアイデアです）または暗号化されたホームディレクトリを使用しました。それは、openssl AES実装と、作成者の他の同様のユーティリティからコピーされたが、個別のライブラリとして構築されていない他の暗号コードを使用します（これは素晴らしいことです。主な利点は、基本的な「パスワードを強化してから暗号化してから認証する」ことをごく少量のコードで実行できることです。
私は以前に使用しましたが、お勧めしません seccure は、楕円曲線暗号に基づく公開鍵を使用し、パスワードから直接（残念ながらSHA256の単一ラウンドのみを介して）使用します。放棄されたように見え、破損したファイルが生成され、動作するにはロックされたメモリが大量に必要です。私はそれが何をしようとしているのかが好きで、その動作バージョンがあったらいいのにと思います。
「encrypt then MAC」と最新の暗号化機能が統合された、ファイルホールやUNIXのアクセス許可などを扱う優れたアーカイバーは見つかりませんでした。 Zip形式のアーカイブのみが必要な場合は状況は良いと思いますが、具体的な推奨事項はありません。
うまくいけば、今後数年で、現在のオプションほど複雑ではなく、現在の暗号化を使用する、この種のことを簡単に行う標準の広く利用可能なユーティリティが存在するでしょう。