Thread: Encryption problem with CipherInputStream/CipherOutputStream

Any idea? I am about to give up...

...I was warned because of spoon-feeding

Why is this call spoon feeding? I coded it myself but couldn't find an answer, I posted in Stackoverflow and Google group no one knew the answer so I guess it is not a simple question?

cjbon
I believe you. Because I don't have the full code I try to optimize your code as following. Try it.

...
			out.write(salt);
			boolean pEncrypt = true;
			synchronized (buffer) {
				while (true) {
					int amountRead = in.read(buffer);
					if (amountRead == -1)  break;
					if (pEncrypt) {
						cos.write(buffer, 0, amountRead);
						pEncrypt = false;
					} else {
						out.write(buffer, 0, amountRead);
					}
				}
			}
                ....
		int b = bis.read(salt);
		if (b == -1) throw new Exception("No \"salt\" found");
		PBEParameterSpec spec = new PBEParameterSpec(salt, ITERATIONCOUNT);
		Cipher cipher = Cipher.getInstance(ALGORITHM2);
		cipher.init(Cipher.DECRYPT_MODE, key, spec);
 
		CipherInputStream in = new CipherInputStream(bis, cipher);
 
		boolean pEncrypt = true;
		synchronized (buffer) {
			while (true) {
				if (pEncrypt) {
					b = in.read(buffer);
					pEncrypt = false;
				} else {
					b = bis.read(buffer);
				}
				if (b == -1) break;
				out.write(buffer, 0, b);
			}
		}
...

and try to print the number of byte-read so that you can verify the validity?

Hey cjbon
have you noticed that qwerty.ret 616316 bytes (decrypted) is exactly about 28 characters (or bytes) shorter than qwerty.enc 616344 bytes (encrypted)?

The tail ±„w'çø]uX\œaQ2ËIõ“ܱõþËÜTN³' is something that you look at. Because I don't have an app to run your code so I suspect that this "tail" has to be something to do with the Key or it could be the key itself. Talking about tweaking. If you find out by comparing the key with this tail that this tail is the key then you know how to get rid of it. Normally I look into the sources (SDK) and verify my assumption. But my SDK is an old version

me again. I believe the problem of your "partial" encryption and decryption is the switch from pEncrypt from true to false or vice-versa. The encryption or decryption process normally takes care about the correct content (that is why you get the correct result. Now you suddenly switch from en/de to unen/unde the "caring process" is put aside...so you get the ugly tail

Very interesting, I tried adding 3 more qwerty word so:
qwerty.txt 616338 bytes
qwerty.enc 616362 bytes
qwerty.ret 616334 bytes

So it seems consistent, qwerty.ret is always 4 bytes short of the original. If it is more, I just have to discharge it... running out of brain juice...

Originally Posted by Voodoo

me again. I believe the problem of your "partial" encryption and decryption is the switch from pEncrypt from true to false or vice-versa. The encryption or decryption process normally takes care about the correct content (that is why you get the correct result. Now you suddenly switch from en/de to unen/unde the "caring process" is put aside...so you get the ugly tail

Yes, I also suspected this. That is why I can encrypt/decrypt correctly if I do not do partial encryption or if the file is smaller than 100000 bytes meaning it always encrypt fully. So this will never work or a possible tweak....

Originally Posted by cjbon

Yes, I also suspected this. That is why I can encrypt/decrypt correctly if I do not do partial encryption or if the file is smaller than 100000 bytes meaning it always encrypt fully. So this will never work or a possible tweak....

uh oh...if you know the consistence (4 bytes(txt or 28 bytes/Enc) then you can "shred" this tail Why not?

I can't shred because the decrypted one is 4 bytes less not more

I just did a log of the buffer read:
07-16 11:43:05.640: I/enctop(4914): 100000 -> first read, the encrypted part
07-16 11:43:05.709: I/encbot(4914): 516338 -> read the rest
07-16 11:43:08.510: I/dectop(4914): 100000 -> decrypt this part
07-16 11:43:08.560: I/decbot(4914): 516333 -> read the rest

Aha! The encrypted part seems ok but why is the "decbot" only 516333? Something is very wrong here.

qwerty.txt 616338
qwerty.enc 616362
qwerty.ret 616334

Now I realized another new thing, when I decrypt I do not have to decrypt exactly 100000 bytes, the CipherInputStream seems to have some mechanism to figure it out the encrypted data and decrypt correctly. But if I set it more than 100000 bytes (for experimenting) it will stop running.

Originally Posted by cjbon

Now I realized another new thing, when I decrypt I do not have to decrypt exactly 100000 bytes, the CipherInputStream seems to have some mechanism to figure it out the encrypted data and decrypt correctly. But if I set it more than 100000 bytes (for experimenting) it will stop running.

Hi cjbon
I took a look at the sources of CipherInputStream Source for javax.crypto.CipherInputStream (GNU Classpath 0.95 Documentation) and CipherOutputStream CipherOutputStream.java - Source Code Display - Jarvana and find it's very interesting. If you scrutinize the method int read(byte[], int, int) you'll see the read operation depend on the tag isStream = cipher.getBlockSize () == 1;...see it for yourself Probably you should check the cipher.getBlockSize () to see how big your cipher is...

cjbon
I studied the CipherInputStream and your code... I believe to know where the problem lies
Look at this piece of your code

...
bis = new FileInputStream(secretFile);
...
CipherInputStream in = new CipherInputStream(bis, cipher);

in is also based on bis. If you check the CipherInputStream class and its read(byte[], int, int) you see:
a) len = super.read(buf, off, len) by isStream = true, or
b) nextBlock() is invoked....
Now let look at this method you find byte[] buf = new byte[cipher.getBlockSize ()] and int l = in.read (buf)...then outBuffer = cipher.update (buf, 0, l). That means the outBuffer could be different to your 100000. These 2 lines confirm that:

...
int l = Math.min (outBuffer.length - outOffset, len - count);
System.arraycopy (outBuffer, outOffset, buf, count+off, l);
...

As I said, if you run into troubles that look weird you'd look at the JAVA sources and ponder...
Ciao

Hi Voodoo master,

These are cool stuff and a little too much for me to digest.. so do you think it is possible to get it working?

Hi Voodoo,

I have solved it!

I was thinking about the CipherInputStream and the salting/key that it might be left out during the switching.
So instead of encrypting the top 100000 bytes, I divide the files into block and only encrypt the very last block so I switch in CipherInputStream instead of switching out and it seems to works well.

=)

Originally Posted by cjbon

Hi Voodoo,

I have solved it!

I was thinking about the CipherInputStream and the salting/key that it might be left out during the switching.
So instead of encrypting the top 100000 bytes, I divide the files into block and only encrypt the very last block so I switch in CipherInputStream instead of switching out and it seems to works well.

=)

Hi cjbon,
glad to hear that you found out the solution for yourself. This time I "won't" spoon-feed you
That's what I also thought about. As I gave the hint about the CipherInputStream source + the in/bis relation (instead of "spoon-feeding!). The problem exist only when in was read and it could happen that some "more data than needed" was read and stored, then when you switch to bis and read bis the unread rest will be loaded. so you miss the "stored data" and get the gap of 4 or n bytes .
Ciao and have fun!

Thanks buddy, see you around!