web-dev-qa-db-ja.com

/ dev / urandomの代替

ハードディスクをランダムなデータで上書きしたい。

ソースとしての/ dev/urandomは遅すぎるため、妥当な時間内に大量のデータを上書きすることができないため、優れた代替手段を探しています。

これら2つのオプションは私の速度要件を満たしています。

（1）openssl with AES

openssl enc -aes-256-ctr -pass pass:"$(tr -cd '[:alnum:]' < /dev/urandom | head -c128)" -nosalt </dev/zero | dd bs=64K ibs=64K of=/dev/sdX status=progress

（2）細断処理

shred -vn 1 /dev/sdX

私が正しく理解していれば、細断処理 ses ISAAC PRNG /ストリーム暗号。

私の質問は次のとおりです：どのオプションがより良い（疑似）ランダムデータを生成しますか、またはこれら2つは等しいと呼ばれますか？

linuxaesdevrandomchacha20cryptoshredding
3
dev_new

ISAACは、RC4に基づいている（RC4よりも優れているとしても）と述べているため、AES-CTRはより安全です。プレーンなRC4は、正当な理由により、すべての安全な通信で許可されていません。また、RC4はわずか0.460GB /秒/コアですが、高速であっても使用しないでください。

私のラップトップでは、AES-128-CTRは4.8 GB /秒/コア（openssl speed -evp aes-128-ctr）で実行でき、ChaCha20は2.5 GB /秒/コア（openssl speed -evp chacha20）で実行できます。理論的にはChaCha20の方が安全ですが、どちらも目的に応じてランダムです。

私のLinux 5.0.0カーネルは、ChaChaを使用しているにもかかわらず、/dev/urandomから0.161 GB /秒/コア（一度に1MBを読み取る）を読み取ります。以下の調査。

ディスクにはブロックの再マッピングがあり、SSDディスクには非常に複雑なガベージコレクションがあり、ユーザーが表示できるブロックを上書きするだけでは不十分な場合があります。したがって、ディスクのファームウェアの「安全な消去」機能を使用してみてください。たとえば、一部のディスクは、ユーザーによって有効にされていなくても、実際にAES暗号化を使用します。これは、ディスクに格納されているデータの1と0の数がほぼ等しいことを確認するためです。次に、AESキーだけをクリアすると、すべてのデータが消去されます（キーが本当にクリアされていることを確認する必要があるだけで、複雑になる可能性があります）。

Linuxの動作を確認するためにperfを試しました。

      - 99.83% read
         - 99.81% entry_SYSCALL_64_after_hwframe
            - do_syscall_64
               - 99.81% __x64_sys_read
                  - 99.81% ksys_read
                     - 99.80% vfs_read
                        - 99.77% __vfs_read
                           - 99.26% urandom_read
                              - 90.55% extract_crng
                                 - 89.44% _extract_crng
                                    - 39.99% chacha_block
                                         chacha_permute
                                      2.85% _raw_spin_lock_irqsave
                                      1.46% _raw_spin_unlock_irqrestore
                                   0.53% _raw_spin_unlock_irqrestore
                                4.63% copy_user_generic_unrolled
                              - 1.62% __check_object_size
                                   0.77% check_stack_object
                                0.76% _copy_to_user

_ extract_crng は、 rdrand （ Arch_get_random_long と呼ばれる）の待機にすべての時間を費やしています。

chacha_permuteは、40％未満の時間で、何らかの理由で ベクトル化されたバージョン が使用可能な場合、低速な ベクトル化されていないバージョン を使用します（そしてAVX2バージョンも）。モジュールchacha_x86_64の読み込みは助けにはなりませんでした。私の推測では、ランダムなcharデバイスドライバーは汎用chacha実装にリンクされており、モジュールとしてではなくカーネルにリンクされてビルドされている場合にのみ、高速chacha実装を使用しますが、ベクトル化されたchachaで5.3.0カーネルをコンパイルした後（ CONFIG_CRYPTO_CHACHA20=y、CONFIG_CRYPTO_CHACHA20_X86_64=y）サイコロなし-urandomはまだスローチャチャを使用しています。理由はわかりません。

4
Z.T.