Terrance Samson wrote:so theoretically the only way that it would be different is if it's padded with random data, which isn't necessary because all that I'm dealing with is divisible by the block size and the key size
And other than that, I don't want it to produce different ciphertext because the whole point is that I need to be able to encrypt something with either version of my program (C# or Java) and then decrypt with the other one.
I can't remove the IV because C# is using it, and I have to be compatible between the two programs, to produce exactly the same files.
But do you have any idea why I'd be getting different results in my two versions of the program?
Notice that I'm setting the key size to 256 and the block size to 128 in the C# version but I don't think I'm specifying it at all in Java. How would I do that?
In C# I'm using unsigned bytes, but Java doesn't seem to have that type, so I use the fixSign function declared at the bottom, which is intended to keep all of the bits the same, even if the number is technically different. Do you think that should work as is?
Stephan van Hulst wrote:You must prepend the IV to the encrypted data, en then during decryption reuse the prepended IV. This will work just fine even if you're decrypting with a different application. But like I said above, it's pointless because you're not using the feedback mode properly.
Stephan van Hulst wrote:Because your C# version uses ECB and your Java version uses CBC. CBC uses the IV. ECB does not.
Stephan van Hulst wrote:Java uses the size of the byte array that the key is in, so just use a 32 byte array. Setting the block size is pointless, because AES always uses 128 bits.
Stephan van Hulst wrote:I would argue that it's a mistake to use ints to represent binary data in the first place. Why are you storing your key in an int array?
Terrance Samson wrote:Oh, I see. So the whole point of the IV is the cram random data at the beginning so that if you keep xoring the blocks together then even the first actual data block will end up more random?
Alright, so the fact that I'm giving the C# version an IV to use doesn't necessarily mean that it's actually using it, but rather, it just holds whatever I give it, and in this case it's not doing anything with it at all?
Alright, so like with the IV, it's not actually making use of what I give it if it turns out to be irrelevant?
Because just for testing purposes until I get it working properly, I hard-coded the key into the code as a byte array in C# just for convenience, so I copied that into Java and it threw a fit, telling me that the bytes have values that are too large.
Stephan van Hulst wrote:Use hexadecimal literals. They are unsigned.
Paul Clapham wrote:I don't see anywhere that your code converts bytes to Strings -- that's about the only place where Unicode would come into play.
Terrance Samson wrote:I didn't convert them to strings, but I wrote it to a file and then opened it in Notepad, and that's where I saw the Chinese characters. Sorry that I wasn't clear about that.
Paul Clapham wrote:You're better off using a hex editor to look at files which don't contain text, instead of Notepad. And when you write non-text data to a file, make sure you use an OutputStream and not a Writer, otherwise you'll get your bytes converted to Unicode text.
Terrance Samson wrote:Let me make sure I'm understanding you. Are you saying that if I write bytes - not strings, but an array of bytes into a file - using any sort of writer instead of stream, then it will assume that it's text and change the bit in it, to make it Unicode compatible?
Terrance Samson wrote:However, I'd have thought that if a writer translated to Unicode then wouldn't that hold all of the Chinese characters, etc.? But then on the other hand, if all the bits are unrestricted then that would be all possible characters, though I'd expect to perhaps see a bunch of black squares or empty boxes signifying invalid characters or something. I don't know.
Terrance Samson wrote:I just got and installed Notepad++. It has a way to convert from ASCII to Hex and back, but it just prints it right there, with no spacing, which is fine, but I think that hex editor that you use looks great! Mine doesn't seem to have it though; is it something that I have to get separately?
Terrance Samson wrote:I had tried that but it wasn't on the list, despite it being a pretty long list of plugins.
Terrance Samson wrote:I think I've seen one kind of stream but it only handles bytes, and I really need to be able to write all sorts of primitive types.
Terrance Samson wrote:Even the specific characters are identical, even though I don't know what they mean!
We can walk to school together. And we can both read this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton