AES-CBC を使用して、存続期間の長いネットワーク データ ストリームを暗号化する必要があります。私は一度だけ呼び出して、その後の への呼び出しEVP_EncryptInit_ex()のために E を保存することを考えていました。次に、復号化側でも同様に行います。私が発見した最初の問題は、EVP_DecryptUpdate が常に 1 ブロック遅れることです。たとえば、32 バイトを暗号化すると、最初の復号化の更新では、32 バイトすべてを復号化したことがわかっていても、16 しか返されません。これは、すべての後に呼び出し、次の更新の前に iv をリセットする必要があることを意味すると思います。VP_CIPHER_CTXEVP_EncryptUpdateEVP_DecryptFinalEVP_DecryptUpdateEVP_EncryptInit_ex()
2 番目の懸念は、これらのストリームが何千もある可能性があり、メモリ フットプリントを最小限に抑えようとしていることです。sizeof(EVP_CIPHER_CTX)はわずか 168 バイトですが、1000 回の呼び出しの前後にメモリ使用量を照会するとEVP_EncryptInit_ex()、コンテキストごとに追加の 412 バイトが割り当てられているように見えます (これは、最初の呼び出しの後に 20K の上にあります)。
訂正、CTX あたり 168 + 412 ではなく 412 バイトと表示されます
インターフェイスは、AES_cbc_encrypt()私のニーズに対してはるかに優れているように見えます。固定の 260 バイトAES_KEY構造があり、さらに 16 バイトの IV を自分で維持する必要があります。ただし、私が理解していることから、AES-NI Intel ハードウェア アクセラレーションは使用されません。 https://security.stackexchange.com/questions/35036/different-performance-of-openssl-speed-on-the-same-hardware-with-aes-256-evp-an AES-NIを有効にする方法はありますかAEC_cbc_encrypt()インターフェイスで？EVP の 2 倍のメモリ要件は、API の単なる副作用ではなく、速度を向上させるために必要ですか? AES-NI を使用する OpenSSL の代替手段はありますか?