Re: Avoiding C++ Templates In Cipher Implementation

From: JR (rosennej_at_qsm.co.il)
Date: 05/31/03 

Date: 31 May 2003 08:14:56 -0700

I am indeed concerned about debuggers etc., but there is little I can
do
about them apart from specifying they shall not be on the production
machine, except make certain that secret data stays in memory for as
short
a time as possible.

Uncontrolled heap data can be swapped to the disk and remain there for
a
long time. RAM wipe will not help in this case. I try to place my data
in non-swappable memory.

Jony

pausch@saaf.se (Paul Schlyter) wrote in message news:<bav4j5$1iia$1@merope.saaf.se>...
> In article <pan.2003.05.26.20.33.39.443663@yahoo.co.uk>,
> Phil Carmody <thefatphil_demunge@yahoo.co.uk> wrote:
>
> > On Mon, 26 May 2003 22:47:28 +0200, JR wrote:
> >
> >> My difficulty with C++ is the hidden temporary variables. They could
> >> end up with secret data all over the place.
> >
> > Do you quiver in fear of debuggers, breakpoints, and single-stepping
> > interrupts too?
>
> On a production machine which contains genuinely sensitive data,
> there should be no debuggers available, since debuggers are a
> security risk. Any software run on such a machine should have been
> thoroughly debugged BEFORE being taken into production on that
> machine. And the debugging should take place on another machine,
> using only insensitive test data.
>
> Another thing to be careful about on production machines containing
> sensitive data is virtual memory. Preferably virtual memory should
> be turned off, and enough RAM should be installed in that machine so
> that virtual memory is never needed. Doing so will prevent this kind
> of attack: turn off the power to the computer containing the
> sensitive data, open it up and steal its harddisk. On some other
> computer, search the entire harddisk with the assumption that a
> secret key may have been written there during some swapping
> operation. Search the entire harddisk, including unallocated disk
> space. Even if the harddisk is hundreds of gigabytes large, you will
> effectively have narrowed your equivalent key space to less than 40
> bits, if the key you're looking for happens to reside somewhere on
> that disk.
>
> Genuine security is about much more than just selecting a secure
> crypto algorithm with a key long enough....

Relevant Pages

  • Re: Avoiding C++ Templates In Cipher Implementation
    ... >> end up with secret data all over the place. ... > Do you quiver in fear of debuggers, breakpoints, and single-stepping ... sensitive data is virtual memory. ... open it up and steal its harddisk. ...
    (sci.crypt)
  • Re: Fortran memory management, error handling, and efficiency
    ... >> relying on bounds checking at production time anyway. ... performance cost which is worth paying on a debug run but not on a ... If a particular production run highlights a bug then ... debuggers are also useless because some bugs ...
    (comp.lang.fortran)
  • Re: Fortran memory management, error handling, and efficiency
    ... >> relying on bounds checking at production time anyway. ... performance cost which is worth paying on a debug run but not on a ... If a particular production run highlights a bug then ... debuggers are also useless because some bugs ...
    (comp.lang.fortran)
Quantcast