By the way, I figured out how to convert to a string. Thanks for all your help. I think I'm finally set! I wasn't aware of CodecSupport, which is very handy!
CodecSupport.toString(decrypted.getBytes()); Tauren On Tue, Apr 5, 2011 at 7:44 PM, Tauren Mills <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]>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 >>> >> >> >
