対称鍵と非対称鍵を生成する方法
Beaglebone Blackベースのカスタムボードを使用しており、ファームウェアファイルの暗号化にハイブリッド暗号化を使用します。つまり、大きなファームウェアファイルの暗号化には対称、対称キーファイルの暗号化には非対称を使用します。ハイブリッド暗号化のアイデアについては、 this ブログを参照してください。
対称キーと非対称キー（主にBashスクリプト）の生成に関して、次の疑問があります。
対称キー
方法1：
openssl Rand 128 > sym_keyfile.key
疑問1：
キーの長さはどうですか？ 128、192、256は暗号化と復号化に影響しますか？暗号化と復号化に時間がかかるだけですか？
方法2：
cat /dev/urandom | head -n 128 > sym_keyfile.key
方法3：
cat /dev/random | head -n 128 > sym_keyfile.key
疑問2：
方法1と方法2のどちらがよりランダムな方法ですか？方法2は十分にランダムであると思う傾向があります。random, urandomのマニュアルページでは、不明な場合に備えてurandomの使用を提案しています。ただし、より安全な乱数を生成するのに十分なエントロピーがシードされています。
疑問3：
OpenSSLに/dev/urandomから乱数を取得するよう依頼できますか？
非対称鍵
秘密鍵の生成：
openssl genrsa -out keyfile.key 4096
秘密鍵からの公開鍵生成：
openssl rsa -in keyfile.key -pubout -out keyfile.pub
rsaに関するOpenSSLヘルプを読むと、次のように書かれています。
RsaコマンドはRSA鍵を処理します。さまざまなフォームとそのコンポーネントを印刷して変換できます。このコマンドは、秘密鍵の暗号化に従来のSSLeay互換形式を使用していることに注意してください。新しいアプリケーションでは、pkcs8ユーティリティを使用してより安全なPKCS＃8形式を使用する必要があります。
疑念4：
OpenSSLは、秘密鍵と公開鍵の両方を生成するため、または秘密鍵から公開鍵を生成するためだけにpkcs#8を使用することを提案していますか？
疑問5：
より安全な非対称キーを生成する他の方法を提案しますか？
OpenSSLとLinuxカーネルでデフォルトで使用されているPRNG（疑似乱数ジェネレータ））の比較研究を求めているようです。これはおそらく、数式でいっぱいのボリュームを埋めることができます。さらに悪いことに、OpenSSLとLinux PRNGは独立していない OpenSSLはデフォルトのシードとして/ dev/urandomを使用するため） 、そして代替案を提供するための進行中の作業がありますPRNG Linuxの場合（主題についてのStephanMüllerの作業を見ることができます here および there = linuxカーネルのメーリングリストでの彼の議論）.
ただし、ほとんどの場合、どちらも同じ長所と短所を共有します。
- 強度：どちらも成熟しており、十分に監査されたコードであり、一般に暗号化された安全なPRNGとして受け入れられています。
- 弱点：それらの名前が示すように、両方ともpseudo乱数ジェネレーターです。つまり、どちらも決定論的アルゴリズムであり、同じシードを指定すると、同じ出力を生成します。したがって、生成された数値の予測不可能性は、シードの予測不可能性に直接依存しています。
したがって、セキュリティに関して、ここでの主な関心事は、OpenSSLまたは/dev/urandomのどちらを使用するかではなく（特に、前者が舞台裏で後者に依存していることがわかっている場合）、シードの品質を確保することです。特に、あなたがしたい必要なのは、TRNG（True Random Number Generator）の1つまたは複数のソースです。暗号化に適した予測不可能なランダムデータを提供するために特別に設計された一部のハードウェアコンポーネント。
これにより、上記のアルゴリズムで使用されるシードの品質が、システムI/O、負荷などの外部要因に依存しないことが保証されます（使用可能な場合、これらのエントロピーソースは引き続き使用される可能性が高いですが、 TRNG入力）。ほとんどの状況で、これは2つの十分に確立されたPRNG実装から選択するよりも、全体的なキーの強度に大きな影響を与えます。
今あなたの疑問に答えるために：
疑問1：
キーの長さはどうですか？ 128、192、256は暗号化と復号化に影響しますか？暗号化と復号化に時間がかかるだけですか？
はい、そうです。鍵が大きいほど、暗号化と復号化に多くの計算能力が必要になります。これの背後にある考え方は、正しいキーを知っている正当なデバイスからのより多くの努力が必要になる一方で、潜在的な攻撃者からの「指数関数的に」より多くの努力が必要になるということです。
適切な長さについては、このウェブサイトでこの話題について多くの議論が見られます（ この素敵なテーブルのように ）。いくつかの一般的なケースといくつかの制約を考慮したもの（組み込みデバイスなど）非常に限られた計算能力）。
疑問2：
方法1と方法2のどちらがよりランダムな方法ですか？私は方法2は十分にランダムであると思う傾向があります。ランダム、urandomのマニュアルページでは、不明な場合はurandomを使用することをお勧めしています。ただし、より安全な乱数を生成するのに十分なエントロピーがシードされています。
方法3は、突然、不確定な時間の間ブロックする場合があります。これがあなたが望むものではない場合（そして通常はこれを望まない場合）、選択は確かに方法1と2の間です。
そこから、選択は単に個人的な好みの問題です。 OpenSSLを使用する構文は移植性が高く、簡単なので、headコマンドのパラメーターとして-n（バイト数）ではなく-c（行数）を使用してバグを回避できます。 ）））。
疑問3：
OpenSSLに/ dev/urandomから乱数を取得するように要求できますか？
これはデフォルトの動作ですが、このOpenSSLドキュメントがあなたの友人であることを確認したい場合は、-Randパラメータを追加することをお勧めします：
openssl Rand -Rand /dev/urandom 128 > sym_keyfile.key
疑念4：
OpenSSLは、秘密キーと公開キーの両方を生成するために、または秘密キーから公開キーを生成するためだけにpkcs＃8を使用することを提案していますか？
LvBコメントで述べたように、これはキーがstoredであり、生成されない方法です（これは、.Zip、.rarまたは.tar.gzアーカイブにファイルを格納するのと同じです）。
自由に選択できる場合は、OpenSSLは実際に、従来のSSLeay形式ではなく、最新の標準化された形式を使用することをお勧めします。
- PKCS8では、秘密鍵を1つの（おそらく暗号化された）ファイルに保存し、公開鍵/証明書を別の（プレーンテキスト）ファイルに保存します。
- PKCS12では、プライベートコンポーネントとパブリックコンポーネントの両方を1つのファイルにバンドルします（これはより現実的に見えるかもしれませんが、
.p12ファイルが暗号化されている場合、最初にファイルを解読しないとパブリック証明書も読み取れないことを意味します）。
実際には、選択は多くの場合、キーを使用するアプリケーションでサポートされているものにまで及びます。そのドキュメントでは、多くの場合、キーマテリアルをどこにどのように保存するかを指示しています。
疑問5：
より安全な非対称キーを生成する他の方法を提案しますか？
上記のTRNGデバイスについてはすでに触れましたが、成熟したよく知られているソフトウェア実装を使用して、既知の土地に留まることもお勧めします。貧弱なアルゴリズムまたは優れたアルゴリズムを実装しているソフトウェアですが、バグのある実装を使用すると、セキュリティを同等に破壊できます。
そして最後に、 間違いはどこでも発生する可能性があります なので、常に最新情報を入手してください。しかし、それらは、エキゾチックなソリューションよりも確立されたソリューションですぐに検出および解決される可能性が最も高くなります。
ハイブリッド暗号化を自分で実装するのではなく、openssl smimeサブコマンドを使用することをお勧めします。もう1つのオプションは、gpgを使用することです。これは、ファイルの署名と暗号化にopensslよりはるかに適しています。
openssl smimeとgpgは両方とも自動的にハイブリッド暗号化を行います。