Fix issue #6 I think; for me (running on MacOS X) the bug would happen with any larger amount of data (more than a 512 bytes, probably due to CipherInputStream buffer).  When doing the lookahead byte, it is working on the higher-level InputStream, and that operation does not affect the lower-level rawOutputStrem, so there is no need to call reset() on it.  Until the last buffer, the rawOutputStream would never actually get written to until that one-byte read() call due to buffers in higher-level streams in the chain, and therefore the reset() call would clear it out, meaning that no bytes whatsoever from the encrypted stream were ever written to the Mac until the (partial) last block, meaning that (of course) the Mac verification failed.  I added a test case which encrypts 50k or so which demonstrates the bug (though it would probably manifest on 1k in my case).  The behavior might be different on different platforms, as it's probably dependent on the CipherInputStream implementation (and perhaps the Cipher provider).  Simply removing the reset() call lets the new unit test pass.
It occurred to me that using a simple FilterInputStream subclass to update the Mac directly would remove the need for the TeeInputStream and the ByteArrayOutputStream manipulation.  This to me seems simpler and more efficient.

This also has the effect of fixing Issue #6, since there is no reset() needed anywhere.

The only apache-commons dependency in the main code is now a couple of IOUtils methods; it might be worth implementing those locally and removing that dependency.
Merge branch 'SimplerInputStreamChain' of https://github.com/carllindberg/JNCryptor into carllindberg-SimplerInputStreamChain
Removed unused field.
Listed Carl Lindberg as a contributor.
Next release will be 1.1.0 due to new features (input streams).