問題は、さまざまなプラットフォームを扱うときに暗号化と復号化を行う際に、どのようなアプローチが最も望ましいかということです。
私の知る限り、そのようなシナリオで作業したいときはいつでも、特定のことを考慮に入れる必要があります。言うように、
確かに、使用したい暗号化/復号化アルゴリズムは両側で同じでなければならず、残りの 3 つのことについては同じことが言えると思います。
次のシナリオまたは類似のシナリオで作業しているときに従うべき手順を教えてください。
相互運用性に本当に関心がある場合は、CMS などのコンテナー形式を試して使用してください。これは、メッセージ構造のバイナリ エンコーディングである BER/DER でエンコードされた ASN.1 を展開します (メッセージのテキスト エンコーディングである XML に似ています)。残念ながら、すべてのプラットフォームにそのようなメッセージ形式が含まれているわけではありませんが、サポートされている場合は、メッセージをエンコード/デコードできることを合理的に確信できます。
PHP はトリッキーです。openssl ラッパーまたはひどい mcrypt ライブラリに依存しています。
バイト順を追加します (数字のリトルエンディアンとビッグ エンディアン) が、同じアルゴリズム (およびパラメーター) とデータ形式を選択する限り、1 つのプラットフォームで暗号化されたものは別のプラットフォームで復号化可能である必要があり、その逆も同様です。たとえば、これが今日の SSL のしくみです。
優れた相互運用性にとって非常に重要な側面の 1 つは、標準への準拠です。
優れた暗号化標準には、テスト ベクトルが付属しています。両端が同じ仕様を実装し、関連するテスト ケースが検証されている場合、相互に正常に通信できる可能性がはるかに高くなります。
たとえば、パスワードから AES キーを導出する必要があるとします。EVP_BytesToKeyopenssl を使用している場合は、common関数を使用したくなるかもしれません。残念ながら、これは標準の派生アルゴリズムではなく、openssl も持っていない場合、問題が発生することになります。PBKDF2 のような標準を使用する方が優れています。これは、ほとんどのライブラリが実装している、明確でよく知られ、広く普及している仕様 ( RFC2898 ) があるためです。
残念ながら、暗号化標準はプリミティブのみに焦点を当てる傾向があり、多くの場合、いくつかのプリミティブを一緒に移植する必要があります。「移植」は、相互運用性が崩壊する領域であることが判明する可能性があります。そのため、多少の複雑さを犠牲にしても、可能な限り幅広い標準化されたアルゴリズムを使用することをお勧めします。
たとえば、何かを暗号化したい場合は、CCM のような標準の認証モードを選択するとよいでしょう ( RFC3610などで定義されています)。一度に次の相互運用性を取得できます。