Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!us.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Mike Amling Newsgroups: comp.lang.java.security Subject: Re: Zeroization and compiler optimization Date: Mon, 06 Jul 2015 10:06:35 -0500 Organization: A noiseless patient Spider Lines: 59 Message-ID: References: <4knliqvbk6hc$.dlg@kimmeringer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 6 Jul 2015 15:05:04 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="38d032940e3ee42ed772258374725480"; logging-data="32062"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18I78FIn+zmcEco6hk3RvA0" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: Cancel-Lock: sha1:EFa+7s+POygd4xyZEioYFEuy4Hk= Xref: csiph.com comp.lang.java.security:314 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