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

[iaik-ssl] DES(3) and IV

I found the following thread in the iaik-jce mailinglist archive. In my
opinion this issue is a big problem for the current iaik-ssl implementation.

The iaik-jce provider does not reset the IV after the doFinal call for a
CBC-Cipher object. So if the same Cipher object is used twice without
calling Cipher.init in between, the second operation does not use the
initial IV. 
This behavior is different in other implementations like Sun and Aba.
The current isasilk implementation uses the read_cipher and write_cipher
object in the handshaker twice without calling Cipher.init in between. So if
a SSL server based on isasilk uses the iaik-jce provider and the client uses
a different jce provider, the handshake will fail, since the decryption will
give different results.
What about the compatibility between isasilk based ssl implementations and
other products?

Any suggestions?
Michael Schlüter

Michael Schlüter
Security Networks AG       		Tel   : +49(2054)123-223
Im Teelbruch 116           		Fax   : +49(2054)123-123

D-45219 Essen              		E-Mail: schlueter@secunet.de


Yes, we discovered this difference recently. However, it was not fixed
for compatibility with previous versions and because it is generally not
a good idea to use IVs or secret keys more than once anyway. It has not
been decided how we will handle this in the future.

 Andreas Sterbenz              mailto:Andreas.Sterbenz@iaik.at

-----Ursprüngliche Nachricht-----
Von: <wplaner@eunet.at>
An: <iaik-jce@iaik.tu-graz.ac.at>
Gesendet: Mittwoch, 25. Oktober 2000 15:43
Betreff: [iaik-jce] DES - Implementation of IAIK and IV

> There is a little difference between  IAIK and  Sun in the Implementation
of DES
> in CBC - Mode:
> - after a doFinal () Sun resets the IV to the value set in engineInit
> - IAIK reuses the actual value of the IV
> The difference becomes a problem when one single cipher - object is
used to
> encrypt multiple blocks of data in
> CBC - mode with the same initial IV
> A simple but not efficient workaround is to subclass
> and to keep track of the parameters
> used in engineInit. A separate boolean instance variable keeps track of
calls of
> engineDoFinal(). if this varaible is set when
> entering either engineDoFinal () or engineUpdate(), engineInit () is
> again to reinitilize the cipher, resulting in some
> runtime overhead
> My question is: will this difference be fixed or will there be any
future method
> to reset only the IV
> without reinitilizing the whole cipher ?

Mailinglist-archive at http://jcewww.iaik.at/mailarchive/iaik-ssl/sslthreads.html

To unsubscribe send an email to listserv@iaik.at with the folowing content: UNSUBSCRIBE iaik-ssl