Re: Re; Locking physical memory (RAM) under Windows

Simon R Knight (srk@tcp.co.uk)
Thu, 18 Jun 1998 23:47:54 0000

• Next message: jcaldwel@iquest.net: "Re: tempest monitoring of key bit flips"
• Previous message: Vin McLellan: "Ron Rivest posts RC6 - New cipher for AES Sweepstakes"

Peter Gutmann wrote:

> I looked at this in my 1998 Usenix Security Symposium paper (referenced in
> Bruce's paper) which is available via the Usenix archive at
> http://www.usenix.org/publications/library/proceedings/sec98/ or from
> http://www.cs.auckland.ac.nz/~pgut001/pubs/random.pdf.

What a coincidence ... I downloaded this document last night, and I
opened it for the first time just a couple of minutes before
receiving your email. This must be some kind of secret CodherPlunks
syncronicity !

 : )

> The paper goes into
> various techniques for ensuring things don't get paged out or leaked, and also
> examines the effectiveness of various strategies, including why some things
> which should work (eg VirtualLock, if you believe the docs) don't.

Great ! ... that's the kind of info I'm looking for.
 
> Jim Adler <jadler@soundcode.com> added:
>
> >To that end, we are currently developing a set of drivers for Win95 and WinNT
> >that will allocate non-swappable memory. The drivers will be released into
> >the public-domain in the hope of putting this issue to rest, on Windows at
> >least.

It is really good to hear that drivers are planned by
<soundcode.com>, to address this issue. I imagine that these drivers
could provide a solution to the virtual memory problem for many
commercial encryption products, so it is a nice suprise to see that
they will actually be available for free.

> I've been looking at this too (with the same goal in mind), but if
> you're already doing it I'll leave it up to you. In case anyone's
> interested, the idea was to create a very simple driver which would
> just allocate and free a given number of locked 4K pages mapped into
> the callers address space (suballocation is done by the user, it's
> much easier to let the caller handle it than to build a full memory
> allocator inside a kernel driver).

I understand from an earlier email that <soundcode.com> are not
planning a 16 bit version of these drivers, but I am wondering if a
shareware version might be a considered ? If you have considered
writing a 16 bit driver Peter ... then this ( even a simple one)
would be most welcome.

My reason for enquiring, is that although it will be a happy day when
I only have to write 32 bit applications, I presently write 16 bit
versions also. As long as there is a demand for 16 bit versions of my
programs, then I will supply them, however it does introduce certain
difficulties (challenges) where security is concerned.

Simon.

• Next message: jcaldwel@iquest.net: "Re: tempest monitoring of key bit flips"
• Previous message: Vin McLellan: "Ron Rivest posts RC6 - New cipher for AES Sweepstakes"