Clearing sensitive in-memory data in perl

[Jerrold Leichter]

[Moderator's note: forwarded on Jerry's behalf -- he's having mail problems.]

| >>So wouldn't the world be a better place if we could all agree on a
| >>single such library? Or at least, a single API. Like the STL is for C++.
| >>
| >
| >
| > Yes, absolutely, but who is going to do it?
|
| One could argue it has already been done.
|
| There exists a widely available, freely available, well-implemented
| example of something just like the STL for C++.  It is called
| "the STL for C++".
|
| a) Writing in C++ is easier than writing in C.
|
| b) Porting legacy C to C++ isn't rocket surgery.  It can be done
| incrementally.

And the STL is safer than C ... in what sense?  STL iterators are modeled on C
pointers - warts and all.  An STL iterator can point to random memory just as
easily as a C pointer.  An indexing operation into an STL vector or similar
data structure is subject to exactly as much range checking as a C indexing
operation.

Yes, there exist implementations of the STL that check such things - just as
there exist implementations of C that check such things.  None appear to be
widely used.  And, of course, while no standard *forbids* such checks, none
*require* them, so (a) availability is spotty; (b) compilers typically contain
no optimizations aimed at making such things efficient.

RISKS had a large number of messages on this topic back in 2002.  I wrote one
long commentary (in RISKS 21.85 - see http://catless.ncl.ac.uk/Risks/21.85 for
one on-line source) that I stand by to this day.  Very little has changed.
(Actually, there has been a *bit* of improvement:  Microsoft submitted a
proposal for a set of new string - and related - functions for standardization
in the C library.  They differ from the classic functions in always having an
explicit output buffer length.  Personally, I find the particular API typical
of Microsoft - butt-ugly and a pain to use - and I *think* that the standards
groups may be re-working them.  But one way or another, after all these years,
we may eventually have safe alternatives - once we work throught the
standardization process and get the stuff out there (I'd guess another 2 years
at least before you can safely assume that it'll be available).

 							-- Jerry



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com