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 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: References: <4knliqvbk6hc$.dlg@kimmeringer.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: Xref: csiph.com comp.lang.java.security:313 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