I have a gentleman over here who is working on this problem as well, he is a little more versed in Java, and here is his summary of what is going on:
Here's sort of a run down of some of the things we've tried: * Handled NullPointerException that was originally being thrown due to hashedKey being passed to EncryptedMapDecorator.decrypt() as null * This leaves us with debugging our original problem: javax.crypto.BadPaddingException: Given final block not properly padded. Possible causes for this include: o Ciphertext being corrupted (we believe we've eliminated this as being a possibility by using a different approach and still getting the same error) o Key used to decrypt is not the same as what was used to encrypt (which may be as a result of hashedKey being null) The last thing I was looking at was the Initialization Vector (IV) being used in the encrypt/decrypt methods to see if perhaps it may have been getting changed or re-generated between encryption and decryption. The main question I have or problem I've been chasing after today is why EncryptedMapDecorator.get() or .put() is receiving a null key that is returning a null hashedKey that is then being passed to decrypt()? This question assumes that the same is not happening with encrypt() but may be worth investigating as well. Is it due to a communication issue with EncryptedMapDecorator not being able to read from the same decoratedMap between CAS servers, etc? As far as the original exception goes, "Given final block not properly padded" is what our main issue is and sources say it has to do with what is ultimately being fed to cipher.doFinal() ---------------------------------- Mark St. Laurent Web Systems Administrator Yavapai College (928) 717-7654 http://www.yc.edu -----Original Message----- From: Misagh Moayyed [mailto:[email protected]] Sent: Friday, November 15, 2013 6:30 PM To: [email protected] Subject: RE: [cas-user] ClearPass with Load-Balanced CAS Lets remove other variables: what happens when you test without the salt and the secret key from all nodes, relying on the defaults? > -----Original Message----- > From: St Laurent, Mark [mailto:[email protected]] > Sent: Friday, November 15, 2013 1:23 PM > To: [email protected] > Subject: RE: [cas-user] ClearPass with Load-Balanced CAS > > Yes, there are only two hosts in the cluster and their clearpass- > configuration.xml files are identical. > > ---------------------------------- > Mark St. Laurent > Web Systems Administrator > Yavapai College > (928) 717-7654 > http://www.yc.edu > > -----Original Message----- > From: Marvin Addison [mailto:[email protected]] > Sent: Friday, November 15, 2013 12:00 PM > To: [email protected] > Subject: Re: [cas-user] ClearPass with Load-Balanced CAS > > > I added the exception stack to the gist. > > Root cause: javax.crypto.BadPaddingException: Given final block not properly > padded > > I believe you can get that failure mode when attempting to decrypt ciphertext > with the wrong key. I'm certain it could happen in the case of data > truncation, but that's seems less likely that a deployment problem. Since > this is a clustered situation, I would think "wrong key" is a more likely > cause. Did you take care to sync the one and only key to all hosts in the > cluster? > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to [email protected] as: > [email protected] To unsubscribe, change settings or access > archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
