Vinnie,
Hmm, so, are we taking the salt and ic value from the key object for
decrypt mode?
If yes, then the if-cond checking on line 214 will have to be deferred
to a later point where we checked both key and the parameters.
Do we check for consistent values of salt and ic if both key and
parameters supply them?
Depending on the mode, i.e. encrypt or decrypt, we will have to take
different actions when either salt and ic isn't supplied.
Also, I think it'd be good to set aside the salt and ic checking code,
i.e. lines 257-260 + lines 262-265, to a separate static utility method
for both code-reuse as well as readability.
Thanks,
Valerie
On 04/26/13 09:59, Vincent Ryan wrote:
Please review the following fix for:
4634141: PBE Cipher should have the ability to use params from PBE Key
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4634141
Webrev: http://cr.openjdk.java.net/~vinnie/4634141/webrev.00/
This problem is that the parameters required by PBE-style ciphers may be
supplied in the PBE key object directly or in the PBE parameters object.
For PBES1 ciphers parameters supplied in the key are ignored.
This doesn't happen for the new PBES2 ciphers available in JDK 8 so
this fix will ensure that the behaviour is consistent across all PBE ciphers.
The fix examines the PBE key for the salt and iteration count parameters
when no PBE parameters object has been supplied. If parameters are not
present at either location then the cipher generates the necessary parameters
itself, as before.
Thanks.
