Yep, the encrypted data coming out of the encryption algorithm is not "character" data, but essentially a string of random bits. If you put it into a String or char[] then someone somewhere's going to attempt to do some mapping that will muck things up quite properly. Keep the encrypted data in byte[], or (if needed, eg, for transmission) translate to base64 or some other reversible character representation of arbitrary binary.
(One thing to beware of is that there are several slightly different "base64" algorithms. You need to be sure that the same algorithm is used on both ends.) On Jan 5, 10:33 am, Jake Basile <jakerbas...@gmail.com> wrote: > I linked the code on an external site because it was longer than a snippet. > > I found the answer to my > question<http://stackoverflow.com/questions/4598873/how-to-handle-last-block-i...>, > though, through the help of some people on StackOverflow. > > First of all, I had an error with the key generation, but that was simply an > oversight. The actual issue was that I was encoding the ciphertext directly > from a byte[] to a String, which means I could lose data if the default > encoding didn't know what the byte in question was. I changed it so in the > string encrypt method, the ciphertext that is returned is encoded to Base64 > from the byte array, and in the decrypt method the ciphertext string is > Base64 decoded into a byte array. This means that data is no longer lost and > the code now works. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
