My name is Philipp C. Heckel and I write about nerdy things.
This tiny post is meant as a loose collection of DOs and DON’Ts I’ve come across when I implemented the cryptography concept for Syncany, my open source file sync software. I’m not a cryptography expert, so take my advice with caution — and correct me if you know more than I do.
If you have a little bit of cryptography know-how, you’ve heard of GCM, EAX and other Authenticated Encryption with Associated Data (AEAD) block cipher modes of operation. If you haven’t, AEAD modes not only encrypt data, but also authenticate it so that the ciphertext cannot be tampered without detection. In addition to that, AEAD modes can addionally authenticate additional (unencrypted) data — header data for example.
Java’s cryptography interface abstracts the underlying cipher very neatly. If you don’t have any associated data, using an AEAD mode is just like using a mode that doesn’t protect ciphertext integrity: Independent of the actual cipher and mode you are using, the Cipher class behaves identical once it has been initialized. For stream processing, the JDK additionally offers a CipherOutputStream and CipherInputStream. Input and output streams are very easy to nest so that one can compress, encrypt and sign data just by chaining different streams.
So far so good. So what’s the problem? The problem is that the CipherInputStream is terribly broken when used with an AEAD mode. In this post, I’d like to demonstrate how.
Recent Comments