Actually, I don't think we use AES in authenticated mode, here is how it is called, using the BouncyCastle library:
Code:
public static byte[] aesEncrypt(byte[] plaintext, byte[] key) {
try {
byte[] iv = new byte[16];
secureRandom.get().nextBytes(iv);
PaddedBufferedBlockCipher aes = new PaddedBufferedBlockCipher(new CBCBlockCipher(
new AESEngine()));
CipherParameters ivAndKey = new ParametersWithIV(new KeyParameter(key), iv);
aes.init(true, ivAndKey);
byte[] output = new byte[aes.getOutputSize(plaintext.length)];
int ciphertextLength = aes.processBytes(plaintext, 0, plaintext.length, output, 0);
ciphertextLength += aes.doFinal(output, ciphertextLength);
byte[] result = new byte[iv.length + ciphertextLength];
System.arraycopy(iv, 0, result, 0, iv.length);
System.arraycopy(output, 0, result, iv.length, ciphertextLength);
return result;
} catch (InvalidCipherTextException e) {
throw new RuntimeException(e.getMessage(), e);
}
}
try {
byte[] iv = new byte[16];
secureRandom.get().nextBytes(iv);
PaddedBufferedBlockCipher aes = new PaddedBufferedBlockCipher(new CBCBlockCipher(
new AESEngine()));
CipherParameters ivAndKey = new ParametersWithIV(new KeyParameter(key), iv);
aes.init(true, ivAndKey);
byte[] output = new byte[aes.getOutputSize(plaintext.length)];
int ciphertextLength = aes.processBytes(plaintext, 0, plaintext.length, output, 0);
ciphertextLength += aes.doFinal(output, ciphertextLength);
byte[] result = new byte[iv.length + ciphertextLength];
System.arraycopy(iv, 0, result, 0, iv.length);
System.arraycopy(output, 0, result, iv.length, ciphertextLength);
return result;
} catch (InvalidCipherTextException e) {
throw new RuntimeException(e.getMessage(), e);
}
}
Hm, the security argument depends on the fact that the whole encryption scheme is IND-CCA secure, and CBC does not ensure that. I have even a concrete attack idea with CBC in mind but that would require some additional thinking... (and I prefer to think about countermeasures.
). The general problem is similar to the one with the duplicates. Instead of just duplicating a ciphertext, P2 can try to duplicate and change it such that it decrypts to something similar not exactly the same plaintext. Because it is not exactly the same plaintext, the duplicate check does not help here. A later peer then sees that there are two related plaintexts.IND-CCA provides exactly the property that you cannot change the ciphertext in a meaningful way. If you try to change it, it does not decrypt at all (decryption error) or it decrypts to garbage, which is not related to the original plaintext anymore.
Note that the signing that you've described does not help either, because the attacker is one of peers and not just in the network.
The safe choice is to use GCM mode, which is available in BouncyCastle. Probably you just have to replace CBCBlockCipher by GCMBlockCipher but I haven't read the docs.
Actually I think you assume that it is obvious the secret key cannot be given to everybody, however there is not basis for this assumption.
Okay, my point was the other way: I assume it's not obvious that it is okay to give out the secret key. Indeed, if you look at the description of NaCl, the security model section (http://nacl.cr.yp.to/box.html) and the referenced paper do not claim that the message stays secret in a situation where the senders's secret key is known, even if the recipient's secret key is not. Still, publishing the sender's key seems to be for that NaCl scheme, and everything else would surprise me, but I haven't looked at it in detail...