On Mon, 1 Nov 1999, Arnold G. Reinhold wrote:
> Key lengths are perhaps the easiest parameter for a manufacturer to
> change at a later date. Incorporating a useful and usable
> cryptographic architecture is much harder. Apple deserves credit for
> taking a serious stab at the later.
I realize this, and I also realize that once a piece of software gets
out and widely used, its a real pain in the ass to get everyone to
switch; meaning if we laid down a 56-bit crypto architecture, and the
export regs vanished the world over 10 years from now, after our arch
had taken off .. we'd still have to live with weak crypto for a number
of years just to maintain backward compatibility.
The other problem I have with this is that it legitimizes 56-bit
crypto. When big name companies put out security packages, people trust
them .. on name recognition. Walk up to the average guy and ask him
if he'd trust an e-commerce solution by IBM or Counterpane and he'd
likely choose IBM. Most people reading this would probably choose
Counterpane.
People will believe that 56-bits is fine.. and then we'll never get the
damn export regs changed, and it will only get worse .. once the people
believe that 56-bits is ok, and that they don't need 128-bits .. 128+
can easily get outlawed "Why do you need a tank, guys? A hunting rifle
is good enough." .. its a persuasive argument to lots of people.
Now, IF corporations like IBM, MS and Apple were at the forefront of
battling the export regulations, then I'd change my tune. If they
sold 56-bit solutions, all the the while battling export laws in court,
or at least making it publicly known they favor change and expressing
that in their docs and ad campaigns, then that sends a different message
to Joe User.
> >Our goal: 256-bit crypto, worldwide, NOW!
>
> Just having 256 bit keys does not mean that a program is secure.
> There are many other vulnerabilities that have to be addressed. Also,
> how many users are prepared to memorize and use a 256-bit strong
> passphrase (e.g. 20 Diceware.com words)?
Sure. Security is always more than just the crypto.. and whether 256
bit passphrases are usable is irrelevant: the day will come when we
need to key at least 128 bit ciphers, and even that is beyond the
memory of most.. so we'll need another method of passphrase generation,
or, another way of getting secret entropy from the user.
There are schemes other than mere words.
> On the specific complaint that seems to have started this thread, the
> lack of a wipe option in the file encryption, I would just like to
> point out that wiping the original file when you encrypt it is
> nowhere near enough. Many popular applications, such as MS Word,
> create temp files all over the place. A better approach is to wipe
> all disk free space regularly. This can be easily automated in the
> MacOS using shareware utilities and Applescript.
This approach works reasonably well. I like an encrypted filesystem.
Basically everything encrypted. Much of the OS, temp directories, the
whole nine yards. If someone sits down at the machine, or steals it, not
only don't they get your data, they don't even know what apps you were
running.
I run Linux. I have a minimal non-encrypted partition with the kernel
and enough stuff to get booted, /tmp, /usr and everything else sit on
an encrypted volume (sysadmin enters key). User home dirs are individually
encrypted by the user if they choose (there are only 3 users, of which
I am the primary). If the machine is stolen or whatever, the only thing
they learn is that I run linux. They won't know even know what apps I have
installed. Though they can make a good guess that /usr/bin/perl exists..
:)
Michael J. Graffam ([EMAIL PROTECTED])
"Let your life be a counter-friction to stop the machine."
Henry David Thoreau "Civil Disobedience"
