2013-02-18 15 views
6

私はこのコードをhttp://www.ravenblast.com/index.php/blog/android-password-text-encryption/から手に入れましたが、それは機能しますが、十分に安全ではないという疑いが増えています。他のソースから必要と思われる初期化ベクトルはありません。このAES暗号化は十分安全ですか?

public static String encrypt(String toEncrypt, byte[ ] key) throws Exception { 
    SecretKeySpec skeySpec = new SecretKeySpec(key, "AES"); 
    Cipher cipher = Cipher.getInstance("AES"); 
    cipher.init(Cipher.ENCRYPT_MODE, skeySpec); 
    byte[ ] encryptedBytes = cipher.doFinal(toEncrypt.getBytes()); 
    String encrypted = Base64.encodeBytes(encryptedBytes); 
    return encrypted; 
} 

public static String decrypt(String encryptedText, byte[ ] key) throws Exception { 
    SecretKeySpec skeySpec = new SecretKeySpec(key, "AES"); 
    Cipher cipher = Cipher.getInstance("AES"); 
    cipher.init(Cipher.DECRYPT_MODE, skeySpec); 
    byte[] toDecrypt = Base64.decode(encryptedText); 
    byte[] encrypted = cipher.doFinal(toDecrypt); 
    return new String(encrypted); 
} 
+2

あなたはIVとMACを必要としています。攻撃者が攻撃を受けた場合、MACをencrypt-then-macスキームに置くか、特別な認証された暗号化を使用することは非常に重要です。それ以外の場合は、攻撃者があなたのメッセージを解読するようにあなたを誘惑する可能性があります。パディング・オーケーは実用的な攻撃です。これがECB(これを見るにはAPIに慣れていない)の場合は、より良いモードに切り替える必要があります。 – CodesInChaos

+2

'getBytes()'を使うことは、プラットフォーム/カルチャに依存するエンコーディングを使うので、悪い考えです。代わりにUTF-8を使用してください。 – CodesInChaos

答えて

9

はい、あまり安全ではありません。 ブロックチェインがないのでIVがありません。

AESアルゴリズムでは、キーのサイズに関係なく、128バイトのブロックしか暗号化できません(無関係です)。それらのブロックがどのように連鎖しているかは別の問題です。最も簡単な方法は、別々のメッセージであるように、他のブロックとは別に各ブロックを暗号化することです(ECB mode)。私がリンクしているWikipediaの記事は、いつ、なぜこれが安全でないのかを教えてくれます。他の方法(つまり、CBC mode)が好まれます。

Cipher cipher = Cipher.getInstance("AES");を実行すると、ECB modeにAES暗号が与えられます。そこには即時の危険はありませんが、あなたのメッセージは、定期的なパターンを持っている場合、これは、次のような状況につながることができます:

オリジナル:enter image description hereは暗号化:encrypted

関連する問題