2016-03-23 16 views
1

64ビット符号化の3Desを使用して符号化されたテキストを使用している場合、暗号化キーを持つだけで十分ですか?ほかに何が必要な情報?64ビット符号化テキストの3Desを復号する

私は以下のエラーを試してみました。

javax.crypto.BadPaddingException:与えられた最後のブロックが正しくとりわけ

+0

申し訳ありませんが、私は暗号化されたコードから元のテキストを取り戻すことを指していました。現在私は暗号化されたコードとキーを持っています。私に与えられた情報として、彼らは '64ビットエンコーディングの3Des'を使用しました。 – Cooray

+0

おそらく、暗号化された3DES(トリプルDES)と、DESに3DESがない64ビットのキーを意味します。 – zaph

+0

TripleDES @zaphでのBASE64エンコーディング – Cooray

答えて

1
  1. DES、3DES、およびAESをパディングしないブロックサイファーは、それらがブロックサイズの倍数である入力データを有していなければならないことを意味している(8 DESのバイト数)。データが(常に)であることをブロックサイズの倍数にするか、パディング(PKCS#5)を使用してパディングバイトを追加および削除し、ブロックの複数の要件を達成します。
  2. 3DESを使用しないでください。新しい作業では十分に保護されていないため、AESによって置き換えられています。
  3. 3DESは168ビットのキー(24バイト)です。互換性のために、112ビットのキー(16バイト)が使用されることもあります。当初、各バイトは、各バイトのデータに対してわずか7ビットでパリティチェックされ、パリティチェックは一般的には行われなかったが、依然としてバイト当たり7ビットだけが使用されている。
  4. 正確なサイズのキーを提供することが常にベストです。
  5. CBCモードでランダムIVを使用するAESを使用する必要があります。
  6. 文字列キーを使用している場合は、PBKDF2を使用して正しい長さのキーを導出する必要があります。
  7. メッセージ認証MACも良い考えです。
+0

こんにちはzaph、お返事ありがとうございました。実際にこれは私のアプリケーションに解読して使用するために必要な古いデータです。だから私はそれを変更するオプションがありません:) はい、私はこの技術についていくつか読んできました。しかし、解読中にエラーに直面する。あなたはこれについて何か考えていますか?スレッド "メイン" javax.crypto.BadPaddingExceptionで 例外:最後のブロックを考えると、正しくcom.sun.crypto.providerでcom.sun.crypto.provider.SunJCE_f.b(DashoA13 * ...) で を埋めません。 SunJCE_f.b(DashoA13 * ..) – Cooray

+0

答えのポイント1。データがどのように暗号化されたかを正確に知る必要があります。しかし、セキュリティは問題ではないので、障害のある設計方法を使用しているブリッジ設計者のように、復号化するだけです。 – zaph

+0

指定された情報は '3Des + 64bitエンコードで暗号化されています'と使用されるキーです。 :)私は彼らが使用したパディングメカニズムが欠けていますか? – Cooray