Question

I have a pool of immutable encryption helper objects which contain instances of the java JCA Cipher and MessageDigest objects:

AlgorithmInstance( Cipher encCipher, Cipher decCipher, MessageDigest digest ) { ... }
private BlockingQueue< AlgorithmInstance > pool = new ArrayBlockingQueue< AlgorithmInstance >(poolSize);

Various threads in my application, needing encryption or decryption, contend for AlgorithmInstance objects by accessing a pool. Each thread uses them to encrypt or decrypt, and then returns them to the pool when they are done. Threads don’t synchronize on any of JCA objects since there is no concurrent access. Decrypt works roughly the same way.

public byte[] encryptMessage( byte data[] ) { ...
 try {
  AlgorithmInstance inst = pool.take();

  inst.digest.reset(); 
  byte[] digest = inst.digest.digest(message);

  inst.encryptCipher.init( Cipher.ENCRYPT_MODE, m_currentKey, ivParams );
  inst.encryptCipher.doFinal( messageBuffer );
 }
 finally {
  pool.put(inst)
 }
}

This works 99.99% of the time; and 100% of the time in unit tests. However, once in a blue moon, I get a message whose computed digest does not come out right — normally this indicates message tampering or network errors; but sender and receiver are on the same machine (in different processes).

Q: Is there some internal state for a Cipher or Digest which can suffer from memory consistency effects — I’m on a 2 core windows box so I don’t see how I could even suffer from memory consistency effects. I re-initialize the cipher and digest each call so it should not matter.

Q: Is there any way I could have ended up with a padding mode that sometimes fails based on the message length? The decryptor and encryptor use exactly the same algorithms (AES/CBC/Pkcs5Padding + SHA-256, and a key size of 128).

Answer 1

I changed the code so that I synchronize on the AlgorithmInstance while I use any of its contained objects. I have not seen this problem since; however its not clear why; since the queue.put() and queue.take() operations should form EXACTLY the same happens-before relationship formed by the monitor unlock:

synchronized (inst) {
 ...
 // do crypto opperations
}

The only other possibility I can come up with is that the IVParamSpec is modified during the Cipher.init() computation and then restored at the end. Since the ivParams are assumed read only and shared across all objects in the pool, if true, this could lead to un-synchronized access and possibly MCE.