Re: Zeroization and compiler optimization

Path	csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!weretis.net!feeder4.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED!not-for-mail
From	Beloumi <beloumi@riseup.net>
Newsgroups	comp.lang.java.security
Subject	Re: Zeroization and compiler optimization
Date	Fri, 12 Jun 2015 09:34:04 +0200
Organization	news.netcologne.de
Lines	36
Distribution	world
Message-ID	<mle214$4ca$1@newsreader4.netcologne.de> (permalink)
References	<m8br50$a9j$1@newsreader4.netcologne.de> <4knliqvbk6hc$.dlg@kimmeringer.de> <m8gifi$l9e$1@newsreader4.netcologne.de>
NNTP-Posting-Host	cable-78-34-25-140.netcologne.de
Mime-Version	1.0
Content-Type	text/plain; charset=windows-1252
Content-Transfer-Encoding	8bit
X-Trace	newsreader4.netcologne.de 1434094436 4490 78.34.25.140 (12 Jun 2015 07:33:56 GMT)
X-Complaints-To	abuse@netcologne.de
NNTP-Posting-Date	Fri, 12 Jun 2015 07:33:56 +0000 (UTC)
User-Agent	Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
In-Reply-To	<m8gifi$l9e$1@newsreader4.netcologne.de>
Xref	csiph.com comp.lang.java.security:313

Show key headers only | View raw

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

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