Secure Erasing is actually harder than that...

Sampo Syreeni decoy at iki.fi
Fri Feb 23 04:20:44 PST 2001


On Thu, 22 Feb 2001, Ray Dillinger wrote:

>If your application can read and write an encrypted drive without
>specifically providing the keys, then a trojan on your system can
>read and write an encrypted drive without specifically providing
>the keys.

I think it is not sensible to include trojans in the threat model, here.
After all, it does not matter how deliciously secure your application seems
to be if you assume there can be a keyboard sniffer there, somewhere.

>These workarounds can only work by "hiding" key management from
>the application, and thus from the user - which means key
>management gets done badly if at all.  Good crypto can't be
>tacked on - it has to be designed in.

Why is this? To me it seems that key management at the system level is far
more likely to be securely implemented than the personal blend of a given
app coder.

>Another problem with an encrypted drive is that an encrypted drive is
>infrastructure that someone is likely to not have in place when they
>first discover a real need to encrypt.

The same does go for encrypt capable applications as well, only there's
considerably more hassle in trying to setup many of those in a row than in
simply relying on an encrypted backing store.

>Applications that write to (and more importantly, which read from) the
>encrypted drive should themselves be crypto-aware and do proper key
>management.

Could you elaborate a bit on why system level key management isn't enough?
I'm afraid I might be missing something here...

Sampo Syreeni <decoy at iki.fi>, aka decoy, student/math/Helsinki university





More information about the cypherpunks-legacy mailing list