4

JRE をインストールしている幅広いユーザーに配布する必要がある Java アプリケーションを作成しましたが、ほとんどの場合、JRE に JCR Unlimited Strength Policy jar ファイルがありません (これらは手動でドロップする必要があり、 JRE インストールにバンドルされていません)。

現在、いくつかの場所で、ライセンスの制限により、デプロイが必要なアプリケーションに JCE ファイルをバンドルすることはできず、手動でダウンロードして JRE にドロップする必要があることを読みました。これは本当ですか？もしそうなら、これらのファイルを発送する方法はありません! これを行う別の問題は、JRE のバージョンを追跡することです。JRE のバージョンごとに異なる JCE jar があるためです。そのため、JRE 1.4 から 1.7 までの JCE jar をバンドルする必要があるかもしれません (これが私のアプリのサポートです)。

JCE 無制限強度ポリシー ファイルに代わるものはありますか? BountyCastle にもこれらのファイルが必要です。これらのファイルで私が行っている唯一のことは、AES256 暗号化です。代替手段は役に立ちます。

ありがとう

4

2 に答える 2

3

Bouncy Castleプロバイダーはこれらのファイルを必要とし、これらのポリシー ファイルを使用する JRE に対してのみ必要です (ただし、それは Oracle であるため、行き詰まっていると思います)。

絶望的な状況では、Bouncy Castle 軽量 API (で始まるクラスorg.bouncycastle) を使用して暗号化することをお勧めします。もちろん、欠点は、書き直しが必要なこと、API がそれほど優れていないことです。軽量 API を使用して、JSSE (SSL) や CMS などの上位レベルのプロトコルの実装にプラグインすることもできません。

または、もちろん、制限されたルールの範囲内に保つこともできます。AES-128 は非常に強力なものです (実際、実用的な目的で AES-258 よりも AES-128 をデプロイする場合、どのような違いがあるのか​​疑問に思うかもしれません)。

于 2012-08-17T15:21:24.400 に答える
1

これらのファイルは、一部の国の輸入法で許可されているよりも高い暗号化をプログラムで実行するために必要です。

jreはデフォルトでは無制限のポリシーを持っていませんが、国のポリシーに応じて個別にダウンロードされます。

これを行う別の問題は、JREのバージョンを追跡することです。JREのバージョンごとに異なるJCEjarが存在するためです。そのため、JRE1.4から1.7のJCEjarをバンドルする必要があるかもしれません（これが私のアプリでサポートされているものです）。

あなたはそれをする必要はありません。自分のマシンにjreをインストールするユーザーは、適切なファイルもインストールし、JCA/JCEまたはJSSEを使用するコードは影響を受けません。

ターゲットシステムで実行する必要があるすべてで事前構成されたjreを実行するためのアプリケーションのライセンスの問題と、それが有効な代替手段であるかどうかはわかりません。

于 2012-08-17T14:01:46.387 に答える