[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: raif at swiftdsl dot com dot au
Subject: [Bug crypto/27849] getIV() call on cipher for DESede/CBC returns null
Date: 14 Jun 2006 09:24:35 -0000

------- 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]