Would it make sense to enhance Shiro's encrypt and decrypt to handle all of these conversions internally? Basically, have a version of encrypt and decrypt that can accept and output normal Strings, base64 strings, byte arrays, etc.?
Having not needed to do much in the past with encoding or encrypting, dealing with this is not my strong point. I'm sure this is the case for lots of people out there. It would be nice if Shiro handled most of the work and made it even simpler to use the API. I would think that many people would have similar use cases to mine: * My key is pulled from persistence somewhere as a string * My user enters a credit card into a UI and I get it as a string * I encrypt the value with my key and want to store it as a string in the DB * I pull the string from the DB to decrypt it * I send a string of the card value to the card processor Thanks again, Tauren On Tue, Apr 5, 2011 at 7:34 PM, Tauren Mills <tau...@groovee.com> wrote: > Les, > > Ok, it's making a little more sense now. Thanks. > > Just to be crystal clear, what is the *right* way to get a String from the > value of decrypted in testBlockOperations? The unit test compares the byte > arrays to assert true, but never converts the decrypted value back to a > string: > > assertTrue(Arrays.equals(plaintext, decrypted.getBytes())); > > The following almost works, but strips all spaces and leaves garbage at the > end: > > System.out.println(new > SimpleByteSource(Base64.decode(decrypted.getBytes())).toString()); > > Thanks, > Tauren > > > On Tue, Apr 5, 2011 at 7:20 PM, Les Hazlewood <lhazlew...@apache.org>wrote: > >> > appkey and result1 are UTF-8-encoded Strings of base64-encoded byte >> > arrays: i.e. there are two levels of encoding going on here - one for >> > base64 and another encoding for the String itself. When you call >> > String#getBytes(), the JDK will return the bytes of that string using >> > the platform's default encoding character set. Shiro instead >> > explicitly uses UTF-8 for guaranteed behavior. >> >> To clarify this a bit more, think of it this way: >> >> Base64 really encodes (converts) byte arrays of any type into byte >> arrays with a limited byte alphabet. It is really a byte array -> >> byte array mechanism. That's encoding level 1. >> >> Once an encoding has been done, the resulting byte array output is >> guaranteed to representable in a simple character set. But Java needs >> to know the character set to use. So this is the byte array --> >> String mechanism. That's encoding level 2. >> >> Shiro uses UTF-8 for this 2nd level to guarantee the same behavior no >> matter what JVM it is deployed in. If you call aString.getBytes(), >> you bypass Shiro's mechanism and use whatever the platform's default >> character set is, which is likely to be incorrect. >> >> I hope that makes more sense! >> >> -- >> Les Hazlewood >> Founder, Katasoft, Inc. >> Application Security Products & Professional Apache Shiro Support and >> Training: >> http://www.katasoft.com >> > >
