問題タブ [java-security]

指定された公開鍵と秘密鍵を使用して ECC 検証をテストする必要があります。ランダム キーを生成する方法は見つかりましたが、特定の公開/秘密キーのセッターはありません。公開鍵/秘密鍵をバイト配列として設定するには?

次のコードを使用して、128 ビット AES で暗号化された暗号テキストを復号化しています。

私の暗号化されたテキストは単純な 1 行のステートメントであり、次のキーと初期バークターを使用しています

次のシナリオを除いて、すべて正常に機能しました。

1) key を初期ベクトルとして使用し、初期ベクトルとキーを使用してプレーン テキストを暗号化します。BadPaddingException で復号化に失敗しました

2) キーをキー、初期ベクトルを初期ベクトルとして暗号化します。上記のコードは例外なく暗号文を復号化しますが、出力はガベージです。私が暗号化したものではありません。

3) 正しく暗号化された暗号文の上で (2 ステップで) 再度復号化し、正しいプレーン テキストに復号化されます。

私の質問は、ステップ 2 で復号化が正しい暗号文への復号化に失敗する理由です。

バイト配列から ECC 秘密鍵を作成しようとすると、以下の例外が発生します。公開鍵/秘密鍵と、C ライブラリー micro-ecc/uECC.h からの署名付き出力があります。C は secp192r1 曲線を使用しました。Java で C で生成されたキーを使用してデータを検証しようとしています。バイト配列を秘密鍵/公開鍵に変換するには?

また、私は使用しようとしました

ただし、上記と同じ例外がスローされます。

スロー

また

secp192r1 曲線を使用して ECC 公開鍵と秘密鍵を生成しました。パブリックの場合は 75、エンコードされたプライベート キーの配列の長さは 125 です。秘密鍵が公開鍵よりも長いのはなぜですか? 秘密鍵が公開鍵よりも 2 倍長くないのはなぜですか? secp192r1 のために秘密鍵が 192 ビット = 24 バイトではないのはなぜですか?

アプリケーションのさまざまな場所から呼び出されるカスタム LicenseManager を使用して、Java アプリケーションを保護しようとしています。

ライセンスマネージャーは次のようになります

もちろん、アプリケーションを「クラック」する簡単な方法は、LicenseManger をこれに置き換えて、クラスパスの先頭に追加することです。

したがって、LicenseManager にパッチが適用されないようにするために、LicenseManager.verify() を呼び出すアプリケーションのすべての部分に次のコードを追加しました。

これにより、基本的に、LicenseManager のコード ソースの場所と残りのアプリケーションのコード ソースが同じであることを確認できます。

これは理にかなっていますか？このアプローチで LicenseManager を「ハッキング」する方法はありますか?

編集:文字列の難読化とコードの IntegrityProtection にJava String ( https://jfxstore.com/stringer/ )も使用しています。これにより、アプリケーションの逆コンパイルが困難になります。

また、LicenseManager.verify() の呼び出しはアプリケーション全体 (何百もの場所!) に分散しているため、それらすべての場所を変更するのは大変な作業になります。

こんにちは、単純な sftp を試していますが、確立中にエラーが発生します。接続、https: //www.sshtools.com/en/products/java-ssh-client で入手可能なmaverick-legacy-client-all jar を使用してい ます。このコードはリリース 1.6.9 で正常に動作していましたが、更新時に失敗しましたそれを 1.6.17 にします。

また、jarの変更に関するドキュメントをここで調べてみました。私の例外であるDiffieHellmanGroupExchange Algo関連の変更に関するメモはほとんどありませんでしたが、明確に理解できませんでした。

例外ログ:

今日のJSchの最新の安定バージョンはどれですか? 公式サイトはjsch-0.1.53.jarダウンロードセクションに表示されます。

JSch バージョンの最新の安定バージョンを製品に統合する必要があります。

ただし、変更ログには jsch-0.1.53 に関する情報はありません
http://www.jcraft.com/jsch/ChangeLog

JSchの変更履歴 ============================================= =====================
最終更新日: Fri Jun 5 03:22:57 UTC 2015

バージョン 0.1.52 からの変更点:
- バグ修正: リモートによって開始されたキーの再生成により、セッションがクラッシュする可能性があります。
- 変更: ログジャム: 利用可能な場合は ecdh-sha2-nistp* を使用、
ecdh-sha2-nistp256、ecdh-sha2-nistp384、ecdh-sha2-nistp521

HTTPS サービスへの接続中に例外が発生します。

私は複数のフォーラムでクロスチェックを行い、サーバーで使用されているアルゴリズムが Java1.8 の標準に合わせて安全性が低い可能性があることを理解しました。

また、「Java\jdk1.8.0_51\jre\lib\security\java.security」ファイルの「jdk.certpath.disabledAlgorithms」プロパティにコメントを付けることで、無効なアルゴリズムを有効にすることができます。しかし、コメントアウトした後でも同じエラーが発生し、役に立ちませんでした。

その他の分析ポイント:

• 無制限の強度のローカル ポリシー jar ファイルを更新しました。
• 同じマシンからスタンドアロン プログラムでサービスに接続できます。
• 「jdk.certpath.disabledAlgorithms」プロパティが有効になっていても、スタンドアロン プログラムからサービスに接続できます。

私のコードは自己署名証明書を使用して HTTPS 接続に接続します。その証明書のアルゴリズムはデフォルトの Java プロパティを上書きしますか? 以下の例外の他の可能性はありますか?