Prev: Parallel quicksort
Next: Using Java 7
From: markspace on 15 May 2010 17:42
rossum wrote:
> IIRC even if you switch the computer off
> if the attacker cen get its memory chips into a freezer quickly enough
> the memory may be recoverable for up to 20 minutes.


This is utterly bogus. There's no way any temperature change short of
(perhaps) absolute zero is going to have any effect on the minuscule
charge stored inside a d-ram. No way, no how.

And I sincerely doubt that "stand-by" retains any information at all,
unless it swaps memory out to disc.

From: Arne Vajhøj on 15 May 2010 18:19
On 15-05-2010 17:42, markspace wrote:
> rossum wrote:
>> IIRC even if you switch the computer off
>> if the attacker cen get its memory chips into a freezer quickly enough
>> the memory may be recoverable for up to 20 minutes.
>
> This is utterly bogus. There's no way any temperature change short of
> (perhaps) absolute zero is going to have any effect on the minuscule
> charge stored inside a d-ram. No way, no how.
>
> And I sincerely doubt that "stand-by" retains any information at all,
> unless it swaps memory out to disc.

http://en.wikipedia.org/wiki/Data_remanence#Data_in_RAM

I am still not that concerned over it for most usage.

But if the data contains the code to launch nuclear
missiles then I vote for better safe than sorry.

Arne

From: rossum on 15 May 2010 19:06
On Sat, 15 May 2010 17:06:38 -0400, "John B. Matthews"
<nospam(a)nospam.invalid> wrote:

>Is there some scope that could obviate the "mKey = null" step? The
>dispose() method would become erase(), effectively re-using the same
>storage for the life of the program.
The key does not change during a single run. I use dispose() to clear
the key before exiting. I definitely do not want to leave the
unmodified key on the heap.

rossum

From: rossum on 15 May 2010 19:10
On Sat, 15 May 2010 17:21:02 -0400, Arne Vajhøj <arne(a)vajhoej.dk>
wrote:

>I have two ideas:
>
>1) store the key in native memory and access it via JNI - you can
> much better control the C optimizer
I was trying to avoid that, but it was looking to be my next step.

>
>2) See if you can find confirmation or rejection for that:
>
>Compiler.disable();
>// your code
>Compiler.enable();
That looks interesting. I will investigate.

rossum

>
>actuall does what the names seems to indicate.
>
>Arne

From: Kevin McMurtrie on 15 May 2010 19:37
In article <hsn4gg$696$1(a)news.eternal-september.org>,
markspace <nospam(a)nowhere.com> wrote:

> rossum wrote:
> > IIRC even if you switch the computer off
> > if the attacker cen get its memory chips into a freezer quickly enough
> > the memory may be recoverable for up to 20 minutes.
>
>
> This is utterly bogus. There's no way any temperature change short of
> (perhaps) absolute zero is going to have any effect on the minuscule
> charge stored inside a d-ram. No way, no how.
>
> And I sincerely doubt that "stand-by" retains any information at all,
> unless it swaps memory out to disc.

Freezing DRAM has been proven to work. Some cells do require refreshing
every few milliseconds but most don't. Spraying the chips with coolant
slows the data loss enough to move them from one board to another with
very little loss. You can try this with DRAM video on an old computer.
Put an image on the screen. Jumper the CPU halt or enable line so the
system won't crash and reboot. Short the clock that drives the RAM for
a few seconds. When the clock resumes you'll see most of the image
return to the screen.

As for rossum's post, simple wiping can't be done in Java. The JVM
moves memory periodically to perform heap compaction. A native byte
buffer will help but it remains a fact that the only way to completely
secure data is through physical means. Don't let people get their hands
on the RAM chips.
--
I won't see Google Groups replies because I must filter them as spam
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Parallel quicksort
Next: Using Java 7