Could I use Java or c#? [was: Re: re-writingcollegebooks]

[ljknews at mac.com (ljknews)]

At 10:55 AM -0600 11/15/06, Wall, Kevin wrote:
> Larry Kilgallen wrote:
> > At 8:18 PM -0600 11/14/06, Wall, Kevin wrote:
> >
> > > That makes a Java inappropriate for a lot of
> > > system-level programming tasks. Simple example: There's no
> > > way in pure Java that I can lock a process in memory. Wrt this 
> > > list, that has a lot of security ramifications especially on
> > > shared processors. Sure makes hiding secrets a lot harder.
> >
> > Please explain that issue.
> >
> > Is there some multiuser operating system that does not clear 
> > memory before retasking it for another  process ?

> I wasn't referring to the OS not clearing memory between use by
> different processes. Instead consider a case where there's a secret
> such as an encryption key, password, etc. in a chunk of memory that
> has been paged out to a swap device (*nix) or pagefile.sys (Windows).
> The process them terminates abnormally because of a signal, abrupt
> power outage, etc. From a security POV, this is a bad thing since
> now your secret is somewhere on the hard drive.

But a cryptographic secret should not be in user-readable memory in the
first place, due to the risk of a trojan horse.  That belongs in OS memory
dedicated to the user but protected from them (i.e., inner mode) and at
that point the operating system can mark such memory as not being subject
to dumping.

The user might enter a password to _unlock_ that secret key, and some
trojan horse (or wiretap) might intercept that password and use it in
a malicious fashion, but the trojan horse cannot export the secret key
to another machine.  (By secret key, I mean the secret half of a public
key pair.)

> Overall, I find these types limitations with Java or C# more frustrating
> than I do with the performance issues.

A native compiler should have no problem calling any system service.
It would seem your objection is really to the bytecode engine version
of Java rather than to the language itself.
-- 
Larry Kilgallen