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

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

Re: Zeroization and compiler optimization

Show all headers | View raw

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

Back to comp.lang.java.security | Previous | Next — Previous in thread | Next 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