[Bug crypto/27849] getIV() call on cipher for DESede/CBC returns null

[raif at swiftdsl dot com dot au]

------- Comment #16 from raif at swiftdsl dot com dot au  2006-06-14 09:24 
-------
(In reply to comment #15)
> First a response to Raif's last comment... I agree about adding mauve tests, I
> will do so for all subsequent confirmed bugs I report, thanks for suggesting
> this.

making the test code you submitted into a Mauve Testlet was straightforward!


> Secondly, about the implementation of the patch without the addition to IMode:
> I had thought about that, but correct me if I am wrong, the name() method in
> IBlockCipher returns the canonical name, the common implementation for it 
> being
> in BaseMode which returns ModeName(CipherName). I can definitely parse out the
> mode name from this and do the check you mentioned.

that would be fine.


> I think adding cipherName()
> to IBlockCipher and modeName() to IMode may not be a bad idea.

i'm very reluctant to change the IMode and IBlockCipher interfaces.  i think we
can fix the bug without these changes.


btw.  going through the public API of the engineInit(int,Key,SecureRandom)
(JDK1.4.2_12) it is stated that we only need to check for the IV iff 'opmode'
is Cipher.DECRYPT_MODE or Cipher.UNWRAP_MODE.  if you can add this check to
your patch, that would be much appreciated.


> I remember
> talking about this with Casey about this on IRC sometime back and he agreed
> with it, it slipped my mind to add this. It would be nice to get Raif's
> approval as well. I can update the patch to reflect whatever you prefer pretty
> easily. 
> 
> The reason why I added the requiresIV() was because I wasnt sure if there is a
> chance that additional modes will be added in the future. If we will add more
> then hardcoding this logic into CipherAdapter may not be the best thing to do.
> If not, and ECB is the only mode we foresee to not require an IV then what 
> Raif
> suggested is just fine...

the traditional modes, except for ECB, require an IV.  but in general modes
require a set of "parameters."  in the future, i wouldn't be against a change
in IMode if it's generic enough to cater for any parameter.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27849