Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:51 ADT
Simon R Knight (srk@tcp.co.uk)
Mon, 22 Jun 1998 18:02:14 0000
On 19 Jun 98 at 16:02, Peter Gutmann wrote:
> The Win95 VxD version should work just as well under Win3.1, unless it uses
> Win95-specific tricks (which shouldn't be necessary on something that simple).
> I'm not writing the driver myself, just nagging someone who knows VxD's into
> doing it and then (assuming it's OK with them) releasing the result for others
> to use. No payment necessary, I think making it shareware would only
> discourage use due to the nuisance involved in paying for it.
>
> Depending on how far the soundcode.com work has progressed, I might put this
> one on hold, since it looks like they're doing the same thing anyway (their one
> sounds a lot more concrete at the moment).
>
> >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.
>
> Exactly. Win16 already has enough problems with any app being able to do
> global heap walks and whatnot, so that's a platform which really needs this
> sort of thing - having memory which isn't searchable via ToolHelp is a step in
> the right direction.
Peter,
Will the CryptLib library benefit from the drivers above, or is the
library well protected (unders Windows) in this respect ?
>From reading "random.pdf" and re-reading the CryptLib 2.0 docs.txt, I
have the impression that cryptographic security has been well
provided for. The techniques described are much more sophisticated
than those I had envisaged implementing within my own applications.
Given the admirable security that CryptLib 2.0 appears to provide, my
attention can now turn to other security considerations, which I need
to address; that is ... the issue of virtual memory in relation to
Windows edit controls. Although (for e.g.) I can encrypt the contents
of a control, there is every possibility for the original plain-text
to be written to a swapfile, while keys, key-states, and random
seed pool data are otherwise carefully protected. As these controls
naturally undermine cryptographic security, I am wondering if the
development of drivers which reliably lock data in memory may offer a
way around this ?
The visual component library (vcl) within Borland Delphi wraps the
controls which are found in Windows, annd although it is possible to
deal with the Windows API directly, I have no real idea how these
controls are implemented by Microsoft. In your experience, would it
appear to be a complicated task to allocated "secure" memory for such
controls, or comparatively straightforward ? If secure memory could
be allocated for them, then this same memory could be wiped
afterwards, which would be ideal. From my present perspective,
Windows controls may leak like a sieve in every direction making
modification of such controls unrealistic, but hopefully this isn't
the case ?
As a more general question, if you (or anyone) knows of any secure
Windows controls (or is that an unreconcileable contradiction ), then
I would be most interested to learn of them.
Thanks !
Simon.
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:51 ADT