Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.security > #307 > unrolled thread

Zeroization and compiler optimization

Back to article view | Back to comp.lang.java.security

Contents

  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

#307 — Zeroization and compiler optimization

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");
}

[toc] | [next] | [standalone]

#308

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: spamfang@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: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#309

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

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#315

Am 06.07.2015 um 17:06 schrieb Mike Amling:
> 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
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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.security

csiph-web