Cipher transformation that outputs non-padded plaintext final partial block

Question

I have written some Java code to read from and write to an existing data format that encrypts its data using a known symmetric key. It appears to be using the "AES/ECB/NoPadding" transformation / algorithm for all blocks, except for the final block, if the final block is a partial block. Any partial final block is just written out plaintext. When I use an "AES/ECB/NoPadding" Cipher in a CipherInputStream or a CipherOutputStream to read from or write to such a byte stream, respectively, everything works fine, except that any partial final block is omitted, as is expected from what I know of the behavior of "AES/ECB/NoPadding".
(FYI, all of these questions relate to the Oracle JDK 7u2. For classes whose source is not included with this JDK, e.g., com.sun.crypto.provider.AESCipher, I looked at the source from the OpenJDK 7u2. I only looked at the default crypto provider included in the JDK, which I assume is the SunJCE, but I may be wrong.)
1) Is there any other transformation that will properly decrypt / encrypt all the full blocks, but read / write, respectively, a partial final block as plaintext? (I assume not, but I also assume that it won't hurt to ask)
2) Is there any way to obtain the buffered partial final block's data from Cipher? I can get the length of the leftover data from getOutputSize(0), but I haven't found a way to get the content. (I assume that this is done intentionally, to keep the Cipher-related classes as secure as possible)
If I knew the length of the input, I could just determine the index of the end of the last full block, but I'd like this code to work with any arbitrary InputStream, and there's no way to know the length of an InputStream (without reading until you receive a -1, of course).
I will probably wind up using a wrapping InputStream / OutputStream that always buffers the last partial block read from / written to it, respectively, until it's received a -1 from a read, or a flush call, respectively, but I wanted to avoid this if I could possibly use the crypto API more effectively.
As an aside, I investigated exposing a partial final block's data by creating a wrapper class for one or more of the crypto classes. This appears difficult since many of these classes are final. Some other non-final crypto classes have final methods that use non-exposed private members, so those might be difficult, if not impossible, to wrap properly. The best plan that I devised is to create a CipherSpi subclass that wraps around a Cipher, and then use a Cipher subclass that wraps around both the wrapping CipherSpi subclass and the original Cipher. This appears convoluted, so I haven't yet thoroughly investigated its feasibility.
I don't think that I can plug in a new mode or padding implementation to the existing SunJCE classes, since com.sun.crypto.provider.CipherCore seems to limit the potential implementations to those of which it is already aware.
Please let me know if I've overlooked or misunderstood anything (this is the first time that I've used the crypto API).
Thanks.

Answer 1

Ross wrote:
It's an existing data format from a huge company. I can't change it, so I cannot switch to CBC or any other mode that is not compatible with ECB for all but a partial final block. If the existing data format is not binary then you have another problem. Ciphertext is binary and storing binary in a 'char' or 'varchar' column is likely to corrupt the ciphertext and in order to reversibly convert it to ASCII or one of the other character encodings then you are going to have to encode it as Base64 (approx 33% inflation), Hex (100% inflation) or ASCII85 (approx 25% inflation).
I'm just trying to read and write from it. I don't care about security, since the data is on my computer, and it's not sensitive data (at all; it's data about music files). I don't understand this. If it's not sensitive then why are you considering encrypting it? Seems to me to be a pointless requirement!
I will never transmit the data anywhere, and, even if someone got hold of the data, I wouldn't care in the slightest.Again, why encrypt it then?
>
You're definitely right about it being a major security bug, though, so thanks for the recommendation. I just want a nice programmatic interface to read and write the data. I understand why the crypto API would want to make it difficult to obtain partial final block info, but was just wondering if there is any easy way to obtain it anyway. You could use one of the stream ciphers or one of the techniques that turns a block cipher into a stream cipher resulting in one byte per byte. To make it secure you will still need to use a random IV (or something similar) so there will still be an inflation. You can normally get away with just 8 bytes for the IV. The output is still binary bytes and will need to be encoded (Base64, Hex or ASCII85) if you are going to try to store it in a 'char' or 'varchar' which will result in further inflation.
I just wrote the cyclic buffer & associated input & output streams, so I'll probably just use those since I probably won't be able to extricate the partial final block from the crypto classes.I don't understand this.
Note - pretty much every time one encrypts data one ends up with ciphertext longer than the cleartext. This is fundamental to encryption and is nothing particularly to do with Java. One can often use compression of the original cleartext prior to encryption but this does not guarantee to result in smaller ciphertext than cleartext.
Note 1 - it seems to me that all you are trying to do is obfuscate the data so why not just use a simple insecure substitution cipher? This way you end up with ciphertext of the same length as the cleartext and using the same character set so nothing in the database structure has to change.