アップロード前にすべてのファイルを暗号化するということは、クライアント コンピューターで行う必要があることを意味します。したがって、これは別のプログラム (GNU PG など) を使用するか、ブラウザ( Javascript 経由の AES (または同じことを行う Java アプレットや Flash) など) で行う必要があります。
SSH 経由で転送するためにファイルを暗号化する必要はありません。プロトコルは既に暗号化を行っているからです。ただし、ファイルは「ネットワーク上」では安全ですが、受信者のマシン (およびサーバー) にアクセスできる人なら誰でもファイルを読み取ることができます。それが問題になる場合は、ファイルを暗号化する必要があります。
最大の課題は、暗号化キーを送信者から受信者に安全な方法で伝達することです。これは完全に自明ではなく、間違って実行すると、多層暗号化と大量のソルトの追加のプロセス全体が役に立たなくなります。たとえば、受信者が (SSH 経由で) ファイルをダウンロードするサーバーに暗号化キーがある場合、サーバーへの十分なアクセス権を持つ人 (管理者または侵入者) は、そこに保存されているキーを使用してファイルを復号化できます。すべての暗号化は役に立ちません。公開鍵暗号は、その問題を解決する 1 つの方法です。以前に GNU PG について言及しましたか?
「ソルト」に関しては、これは間違った用語です。おそらく「初期化ベクトル」を意味していました (ソルトはハッシュ関数用であり、暗号化用ではありません)。
「個別の IV が必要」という要件の解決策はかなり簡単です。nanotime
クライアント コンピューター上で 1 つまたは 2 つのブロックに相当する疑似乱数データを生成します (実際の乱数またはランダムではなくバリアント データを追加することもできます)。 . AES の場合、2 つのブロックは 32 バイト (256 ビット) になり、これは最近のいくつかの暗号化ハッシュ関数の出力サイズになります。
これにより、たとえば、10 ~ 20 個の疑似乱数文字 (貧弱なジェネレーターからでも) をSELECT RAND();
、近くの SQL サーバーからのナノ秒のタイムスタンプ、サーバーが応答するのにかかった時間、およびブラウザーの履歴から最後に表示された 5 つのサイトに連結することが可能になります。そのすべてを SHA-256 にフィードし、出力を実質的に予測不可能な初期化ベクトルとして使用します。
ファイルが受信者に転送された後、ファイルを復号化し、最初の 32 バイトを無視します。