You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Alec Swan <al...@gmail.com> on 2012/11/11 02:13:52 UTC
Wicket 1.5 migration: AbstractCrypt#decryptByteArray(..) throws IllegalBlockSizeException
Hello,
After we migrated from 1.4.x to 1.5.x my
CachingSunJceCryptFactory.newCrypt().decryptUrlSafe(encodedStr)
started returning null. In 1.4.x the same encodedStr parameter was
decrypted without problems. We did not change the Java version and are
still on 1.6.20.
I debugged into AbstractCrypt#decryptSafeUrl(..) and found out that
inside of it decryptByteArray(..) call is now throwing the following
exception:
"javax.crypto.IllegalBlockSizeException: Input length must be multiple
of 8 when decrypting with padded cipher"
How can we fix this?
Thanks,
Alec
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket 1.5 migration: AbstractCrypt#decryptByteArray(..) throws
IllegalBlockSizeException
Posted by Sven Meier <sv...@meiers.net>.
Nothing I can think of.
A testcase for 1.4 and 1.5 would help pinpointing the problem.
Sven
On 11/15/2012 06:52 PM, Alec Swan wrote:
> Does anybody have thoughts on this? Was this broken on 1.5?
>
> On Sun, Nov 11, 2012 at 4:39 PM, Alec Swan <al...@gmail.com> wrote:
>>> what is the salt that you use?
>>> because we use the session specific key, but that can also already be used
>>> like that in 1.4 is it maybe a different default so that you now use a
>>> session key as salt?
>> We did not change the encryptionKey in cryptFactory = new
>> CachingSunJceCryptFactory(encryptionKey). Is this what you are asking
>> about?
>>
>>> does the database have enough room voor the encrypted? is it not truncated?
>> This used to work in 1.4.x which means that we stored encrypted
>> strings in the database correctly.
>>
>> Any other thoughts?
>>
>> Thanks!
>>
>> Alec
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket 1.5 migration: AbstractCrypt#decryptByteArray(..) throws IllegalBlockSizeException
Posted by Alec Swan <al...@gmail.com>.
Does anybody have thoughts on this? Was this broken on 1.5?
On Sun, Nov 11, 2012 at 4:39 PM, Alec Swan <al...@gmail.com> wrote:
>> what is the salt that you use?
>> because we use the session specific key, but that can also already be used
>> like that in 1.4 is it maybe a different default so that you now use a
>> session key as salt?
> We did not change the encryptionKey in cryptFactory = new
> CachingSunJceCryptFactory(encryptionKey). Is this what you are asking
> about?
>
>> does the database have enough room voor the encrypted? is it not truncated?
> This used to work in 1.4.x which means that we stored encrypted
> strings in the database correctly.
>
> Any other thoughts?
>
> Thanks!
>
> Alec
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket 1.5 migration: AbstractCrypt#decryptByteArray(..) throws IllegalBlockSizeException
Posted by Alec Swan <al...@gmail.com>.
> what is the salt that you use?
> because we use the session specific key, but that can also already be used
> like that in 1.4 is it maybe a different default so that you now use a
> session key as salt?
We did not change the encryptionKey in cryptFactory = new
CachingSunJceCryptFactory(encryptionKey). Is this what you are asking
about?
> does the database have enough room voor the encrypted? is it not truncated?
This used to work in 1.4.x which means that we stored encrypted
strings in the database correctly.
Any other thoughts?
Thanks!
Alec
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket 1.5 migration: AbstractCrypt#decryptByteArray(..) throws IllegalBlockSizeException
Posted by Johan Compagner <jc...@gmail.com>.
what is the salt that you use?
because we use the session specific key, but that can also already be used
like that in 1.4 is it maybe a different default so that you now use a
session key as salt?
does the database have enough room voor the encrypted? is it not truncated?
Op 11 nov. 2012 17:04 schreef "Alec Swan" <al...@gmail.com> het volgende:
> When a user submits a form we take all parameters, encode them and
> store encoded string in the database. When the users want to see which
> values they submitted we pull the encoded string from the database,
> decode it and show values to the user.
>
> Encoding is done with cryptFactory.newCrypt().encryptUrlSafe(str)
> Decoding is done with cryptFactory.newCrypt().decryptUrlSafe(encodedStr)
> Where cryptFactory = new CachingSunJceCryptFactory("xxxxx");
>
> So, the encoded string was stored in the database with Wicket 1.4.19
> and used to work when decoded with 1.4.19. However, now we are on
> 1.5.9 and we get the following exception during decoding of string
> from the database:
>
> org.apache.wicket.util.crypt.AbstractCrypt - Error decoding text:
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> at
> org.apache.wicket.util.crypt.AbstractCrypt.decryptByteArray(AbstractCrypt.java:150)
> at
> org.apache.wicket.util.crypt.AbstractCrypt.decryptUrlSafe(AbstractCrypt.java:66)
> ...
> Caused by: javax.crypto.IllegalBlockSizeException: Input length must
> be multiple of 8 when decrypting with padded cipher
> at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
> at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
> at com.sun.crypto.provider.SunJCE_ab.b(DashoA13*..)
> at
> com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(DashoA13*..)
> at javax.crypto.Cipher.doFinal(DashoA13*..)
> at
> org.apache.wicket.util.crypt.SunJceCrypt.crypt(SunJceCrypt.java:94)
> at
> org.apache.wicket.util.crypt.AbstractCrypt.decryptByteArray(AbstractCrypt.java:146)
> ... 63 more
>
> Thanks,
>
> Alec
>
> On Sun, Nov 11, 2012 at 5:21 AM, Sven Meier <sv...@meiers.net> wrote:
> > Where is encodedStr coming from? Are you using Cryptomapper?
> >
> > Please give us a stacktrace.
> >
> > Sven
> >
> >
> > On 11/11/2012 02:13 AM, Alec Swan wrote:
> >>
> >> Hello,
> >>
> >> After we migrated from 1.4.x to 1.5.x my
> >> CachingSunJceCryptFactory.newCrypt().decryptUrlSafe(encodedStr)
> >> started returning null. In 1.4.x the same encodedStr parameter was
> >> decrypted without problems. We did not change the Java version and are
> >> still on 1.6.20.
> >>
> >> I debugged into AbstractCrypt#decryptSafeUrl(..) and found out that
> >> inside of it decryptByteArray(..) call is now throwing the following
> >> exception:
> >> "javax.crypto.IllegalBlockSizeException: Input length must be multiple
> >> of 8 when decrypting with padded cipher"
> >>
> >> How can we fix this?
> >>
> >> Thanks,
> >>
> >> Alec
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket 1.5 migration: AbstractCrypt#decryptByteArray(..) throws IllegalBlockSizeException
Posted by Alec Swan <al...@gmail.com>.
When a user submits a form we take all parameters, encode them and
store encoded string in the database. When the users want to see which
values they submitted we pull the encoded string from the database,
decode it and show values to the user.
Encoding is done with cryptFactory.newCrypt().encryptUrlSafe(str)
Decoding is done with cryptFactory.newCrypt().decryptUrlSafe(encodedStr)
Where cryptFactory = new CachingSunJceCryptFactory("xxxxx");
So, the encoded string was stored in the database with Wicket 1.4.19
and used to work when decoded with 1.4.19. However, now we are on
1.5.9 and we get the following exception during decoding of string
from the database:
org.apache.wicket.util.crypt.AbstractCrypt - Error decoding text:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
at org.apache.wicket.util.crypt.AbstractCrypt.decryptByteArray(AbstractCrypt.java:150)
at org.apache.wicket.util.crypt.AbstractCrypt.decryptUrlSafe(AbstractCrypt.java:66)
...
Caused by: javax.crypto.IllegalBlockSizeException: Input length must
be multiple of 8 when decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.SunJCE_ab.b(DashoA13*..)
at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(DashoA13*..)
at javax.crypto.Cipher.doFinal(DashoA13*..)
at org.apache.wicket.util.crypt.SunJceCrypt.crypt(SunJceCrypt.java:94)
at org.apache.wicket.util.crypt.AbstractCrypt.decryptByteArray(AbstractCrypt.java:146)
... 63 more
Thanks,
Alec
On Sun, Nov 11, 2012 at 5:21 AM, Sven Meier <sv...@meiers.net> wrote:
> Where is encodedStr coming from? Are you using Cryptomapper?
>
> Please give us a stacktrace.
>
> Sven
>
>
> On 11/11/2012 02:13 AM, Alec Swan wrote:
>>
>> Hello,
>>
>> After we migrated from 1.4.x to 1.5.x my
>> CachingSunJceCryptFactory.newCrypt().decryptUrlSafe(encodedStr)
>> started returning null. In 1.4.x the same encodedStr parameter was
>> decrypted without problems. We did not change the Java version and are
>> still on 1.6.20.
>>
>> I debugged into AbstractCrypt#decryptSafeUrl(..) and found out that
>> inside of it decryptByteArray(..) call is now throwing the following
>> exception:
>> "javax.crypto.IllegalBlockSizeException: Input length must be multiple
>> of 8 when decrypting with padded cipher"
>>
>> How can we fix this?
>>
>> Thanks,
>>
>> Alec
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket 1.5 migration: AbstractCrypt#decryptByteArray(..) throws
IllegalBlockSizeException
Posted by Sven Meier <sv...@meiers.net>.
Where is encodedStr coming from? Are you using Cryptomapper?
Please give us a stacktrace.
Sven
On 11/11/2012 02:13 AM, Alec Swan wrote:
> Hello,
>
> After we migrated from 1.4.x to 1.5.x my
> CachingSunJceCryptFactory.newCrypt().decryptUrlSafe(encodedStr)
> started returning null. In 1.4.x the same encodedStr parameter was
> decrypted without problems. We did not change the Java version and are
> still on 1.6.20.
>
> I debugged into AbstractCrypt#decryptSafeUrl(..) and found out that
> inside of it decryptByteArray(..) call is now throwing the following
> exception:
> "javax.crypto.IllegalBlockSizeException: Input length must be multiple
> of 8 when decrypting with padded cipher"
>
> How can we fix this?
>
> Thanks,
>
> Alec
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org