7

URL文字列の一部を難読化する単純な文字列エンコーダーを実装しようとしています(ユーザーがそれらをいじるのを防ぐため)。JCA ガイドのサンプルとほぼ同じコードを使用していますが、次の点を除きます。

  • DES を使用する (AES よりも少し高速で、必要なキーが小さいと仮定)
  • 文字列を Base64 でエンコード/デコードして、URL に対して安全であることを確認します。

理解できない理由により、出力文字列は改行で終わりますが、これはうまくいかないと思います。何が原因なのかわかりません。読みやすい他のリソースへのポインタや、同様のものに関する提案はありますか? 私はすべての暗号化の参照が少し頭を超えている（そしてやり過ぎている）ことを発見していますが、単純なROT13実装は機能しません。なぜなら、より大きな文字セットを扱いたいからです（そして、私が考えもしなかったあいまいな文字に問題があります）。

入力例 (改行なし):

http://maps.google.com/maps?q=kansas&hl=en&sll=42.358431,-71.059773&sspn=0.415552,0.718918&hnear=Kansas&t=m&z=7

サンプル出力 (以下に示すように改行):

GstikIiULcJSGEU2NWNTpyucSWUFENptYk4m5lD8RJl8l1CuspiuXiE9a07fUEAGM/tC7h0Vzus+
jAH6cT4Wtz2RUlBdGf8WtQxVDKZVOzKwi84eQh2kZT9T3KomlnPOu2owJ/2RAEvG+QuGem5UGw==

私のエンコードスニペット:

final Key key = new SecretKeySpec(seed.getBytes(), "DES");
final Cipher c = Cipher.getInstance("DES");
c.init(Cipher.ENCRYPT_MODE, key);
final byte[] encVal = c.doFinal(s.getBytes());
return new BASE64Encoder().encode(encVal);
4

4 に答える 4

8

Base64 エンコーダーは通常、最大行 (チャンク) の長さを課し、必要に応じて改行を追加します。通常はそれを構成できますが、それは特定のコーダーの実装に依存します。たとえば、Apache Commonsのクラス にはlinelength属性があり、それをゼロ (または負) に設定すると、行区切りが無効になります。

ところで：今日、DESはほとんどお勧めできないという点で、私は他の答えに同意します。さらに、「難読化」しているだけですか、それとも本当に暗号化していますか? 鍵を持っているのは誰？全体が私にはあまりいいにおいがしません。

于 2012-04-23T14:41:11.423 に答える
4

android.util.Base64 をインポートします。

...

新しい BASE64.encodeToString(encVal, Base64.NO_WRAP) を返します。

于 2016-06-08T10:48:53.813 に答える
1

実際の質問とは関係ありませんが、DES は一般に(少なくともソフトウェアでは) AESよりも遅いため、キーを小さく保つ必要がない限り、AES の方がほぼ確実に適しています。

第二に、暗号化 (DES または AES) が出力に改行文字を生成することは完全に正常です。それらを使用せずに出力を生成することは、完全に base-64 エンコーダー次第であるため、明らかにそこを確認する必要があります。

ただし、base-64 が出力に一定の間隔で改行文字を挿入するのは特に驚くべきことではありません。base-64 エンコーディングの最も一般的な用途は、生データを電子メールの本文のようなものに入れることです。この場合、非常に長い行が問題を引き起こします。これを防ぐために、データは通常 80 列以下 (通常はそれより少し少ない) の断片に分割されます。ただし、この場合、改行は無視する必要があるため、メモリが機能する場合は、改行を削除するだけで済みます。

于 2012-04-23T14:42:07.847 に答える