Cipher auth modes require interoperability docs

[mikeboers]

The following is paraphrased from an emailed report.

---

I am using the EAX mode with the AES cipher and I'm seeing some weirdness. I'm not sure if this is due to the py wrapper or tomcrypt or if the error is elsewhere, but I get different results in Java than in python.

I'm using the following:

def decrypt(pw, iv, buf) :
   return cipher.Cipher(key=pw, iv=iv, cipher='aes', mode='eax').decrypt(buf)
def encrypt(pw, iv, buf) :
   return cipher.Cipher(key=pw, iv=iv, cipher='aes', mode='eax').encrypt(buf)

k = "614394e525e9b8ecec706ea7762197da6d0a32785028cad6d60fa015d9349232".decode('hex')
iv = "41414141414141414141414141414141".decode('hex')

If I encrypt(k, iv, "test") I get hex 42d9efc5. If I decrypt that I
get back test. When I try to decrypt that in Java I get an exception:

javax.crypto.BadPaddingException: mac check in EAX failed

If I do the same encryption in java I get hex 42d9efc52cc19ac1da7031c6 which in java decrypts back to test. If I try in python decrypt(k, iv, "42d9efc52cc19ac1da7031c6".decode('hex')) I get back testm\x0er\xa5\xa6$\xcd\x85.

Is there a special mode I need to try to use in python to get the mac and the mac check that is compatible with java? Is this an inherent difference between tomcrypt and java? (I've never used native tomcrypt.)

FWIW, I'm using BouncyCastle (actually SpongyCastle) in Java with the following encrypt/decrypt function:

protected static byte[] crypt(int opmode, byte[] K, byte[] IV, byte[] x) throws Exception {
    Key k = new SecretKeySpec(K, "AES");
    IvParameterSpec iv = new IvParameterSpec(IV);
    Cipher c = Cipher.getInstance("AES/EAX/NoPadding", "SC");
    c.init(opmode, k, iv);
    return c.doFinal(x);
}

---

It turned out that the used needed to call the .done method on the Cipher in order to get the MAC, and the Java library was expecting that MAC to already be concatenated.

Ergo, two things need to happen: 1) The documentation regarding cipher auth modes needs to be expanded (this ticket), and 2) we should introduce one-off encryption methods on cipher descriptors (another ticket).