Zeroization and compiler optimization

Beloumi

unread,

Jan 4, 2015, 11:52:49 AM1/4/15

to

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... ?
And if so, would the following code prevent such optimizations?

Arrays.fill(input, (byte) 0);
boolean success = true;
for (byte b : input) {
if (b != 0) {
success = false;
break;
}
}
if (success == false) {
System.err.println("zeroization failed");
}

Lothar Kimmeringer

unread,

Jan 5, 2015, 7:36:44 AM1/5/15

to

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
--
Lothar Kimmeringer E-Mail: spam...@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

Beloumi

unread,

Jan 6, 2015, 6:55:31 AM1/6/15

to

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

Beloumi

unread,

Jun 12, 2015, 3:33:57 AM6/12/15

to

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

Mike Amling

unread,

Jul 6, 2015, 11:06:30 AM7/6/15

to

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

Beloumi

unread,

Jul 6, 2015, 5:24:37 PM7/6/15

to

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