bug-classpath
[Top][All Lists]
Advanced

[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: csm at gnu dot org
Subject: [Bug crypto/27849] getIV() call on cipher for DESede/CBC returns null
Date: 11 Jun 2006 21:23:07 -0000


------- Comment #10 from csm at gnu dot org  2006-06-11 21:23 -------
Subject: Re:  getIV() call on cipher for DESede/CBC returns null

On Jun 11, 2006, at 1:21 AM, raif at swiftdsl dot com dot au wrote:

> ------- Comment #9 from raif at swiftdsl dot com dot au  2006-06-11  
> 08:21 -------
> (In reply to comment #8)
>> Subject: Re:  getIV() call on cipher for DESede/CBC returns null
>> On Jun 11, 2006, at 12:45 AM, raif at swiftdsl dot com dot au wrote:
>>> ------- Comment #7 from raif at swiftdsl dot com dot au  2006-06-11
>>> 07:45 -------
>>> what if the two ciphers are running each in a separate VM?
>>>
>>
>> Transfer the IV in some fashion between the processes/computers.
>>
>> I'm seriously disinterested in squabbling over crap like this. The RI
>> specifies a behavior that we don't support. That. Is. A. Bug.
>
> you're totally missing the point:
>
> a. we're not arguing about whether to fix the fact that the getIV() is
> returning null.
> b. we're arguing about whether this default IV should be random or  
> not.
>

I'm trying to avoid arguing over this. My point has always been that  
we have to follow the behavior of Sun's RI, because that is the what  
people using Java will reasonably expect. Whether or not we think the  
RI's behavior is good or not is beside the point.

Anyway, Sun's 1.5.0_06 RI (for DESede and AES) appears to use a  
random IV. We should do the same.


-- 


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





reply via email to

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