Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.java.security > #315

Re: Zeroization and compiler optimization

Show key headers only | View raw

Am 06.07.2015 um 17:06 schrieb Mike Amling:
> On 6/12/15 2:34 AM, Beloumi wrote:
>> Am 06.01.2015 um 12:55 schrieb Beloumi:
>>> Am 05.01.2015 um 13:36 schrieb Lothar Kimmeringer:
>>>> Beloumi wrote:
>>>>
>>>>> Sensitive data like keys and passwords should be zeroized immediately
>>>>> which is usually done by Arrays.fill(...).
>>>>> A compiler may treat this as dead code and it may be eliminated by an
>>>>> optimization.
>>>>> Does anybody knows if this is the case for common Java compilers like
>>>>> javac, ejc... ?
>>>>
>>>> You can try it out by giving the created byte-code to a decompiler.
>>>> I don't expect that to happen but would be a bit concerned about
>>>> the Hotspot during runtime. This might throw out that particular
>>>> part of the code since it's analyzed to be dead.
>>>>
>>>>
>>>> Regards, Lothar
>>>>
>>> Thanks for the hint. You're right. The bytecode compiler might not be
>>> the most problematic point for zeroization. The optimization in Hotspot
>>> might be “better” than others, but as I know all JIT-compilers can do
>>> dead code elimination. Is there also a way to figure out if they do?
>>> Beloumi
>>>
>> For those who are interested... a late update:
>> I checked javac and eclipse jar compiler by decompiling the code. They
>> do not eliminate Arrays.fill().
>> I then checked Hotspot by comparing the time with and without filling
>> large Arrays. The execution time without these fillings is significantly
>> shorter, so Hotspot also does not eliminate this code.
>> I also checked a code which was optimized by ProGuard (Obfuscator) with
>> this method and the arrays are still filled.
>> So, false alarm... As I can see redundant code like zeroization is not
>> eliminated in normal use cases.
>> Beloumi
> 
> There was no danger that javac was going to eliminate the call to
> Arrays.fill. javac could not guarantee that the java.util.Arrays that
> would be used at run time would have no side effects. The JITC is a
> different story.
> 
> Did you check using the circumstances where the JITC is most likely to
> eliminate the zeroing? I.e., where the zero values in the array can
> obviously never be used. I believe that would be
> A. a local array variable
> B. that is never passed as an argument to any constructor or method
> except Arrays.fill
> C. where Arrays.fill is obviously the last reference to the array before
> the array goes out of scope
> 
> We might note that calling Arrays.fill is less likely to be eliminated
> than a loop. So if you ever zeroize with a loop, you should check that,
> too.
> 
> We might also note that zeroizing is not the only alternative.
> Randomizing, although it has more overhead, is just as good.
> 
> Mike Amling
Yes, I checked it under these most likely circumstances.
And now I also checked Hotspot for the loop variant.
Just a simple manual test: Initializing a big array in a for loop,
filling it with any value, performing the loop and compare the time when
this array is then zeroized inside the loop or not.
Even for the loop variant of zeroization, there is a significant
difference.
It seems there is not such a problem in Java like in other programing
languages.
Beloumi

Back to comp.lang.java.security | Previous | Next — Previous in thread | Find similar

Thread

Zeroization and compiler optimization Beloumi <beloumi@riseup.net> - 2015-01-04 17:52 +0100
  Re: Zeroization and compiler optimization Lothar Kimmeringer <news200709@kimmeringer.de> - 2015-01-05 13:36 +0100
    Re: Zeroization and compiler optimization Beloumi <beloumi@riseup.net> - 2015-01-06 12:55 +0100
      Re: Zeroization and compiler optimization Beloumi <beloumi@riseup.net> - 2015-06-12 09:34 +0200
        Re: Zeroization and compiler optimization Mike Amling <mamling@chaff.us> - 2015-07-06 10:06 -0500
          Re: Zeroization and compiler optimization Beloumi <beloumi@riseup.net> - 2015-07-06 23:24 +0200

csiph-web