Re: Context sensitive encryption
Anonymous (nobody@tjava.com)
Thu, 15 Feb 1996 14:21:03 -0600
<FLAME MODE=ON INTENSITY=CRISP>
A version of David Sternlight, but without the clue, wrote:
> Does not have to, already PGP is able to send binaries such as ZIP files
> as ASCII and to determine on decrypt that it was a ZIP file. There is no
> reason that this could not be extended to graphical formats or anything else.
No reason why it could not, but plenty of reasons why it should
not.
As any person who has examined PGP knows, these determinations are
hacks, based entirely on heuristics. For recognizing text and ZIP
files, PGP does an OK job (though it's easy enough to fool it if you
try), but for a large spectrum of multimedia types, it's completely
hopeless.
On the other hand, there is already commitment for, support for,
and implementation of the use of MIME to solve exactly this problem.
> CCMAIL already has the capability to extract a file extension from an
> attachment, examine the WIN.INI definitions, and launch the appropiate
> application just as has been incorporated in the Macintosh for years.
Great. Let's standardize the whole world on WIN.INI.
> In fact a hierarchial approach is possible today - an attachment with
> a .PGP extension would automatically launce the decoder which would need only
> to request a passphrase, which in turn would automatically launce
> the desired application.
This is exactly what we need - let's launch a couple of
applications and type a passphrase for every single message in our
mailboxes.
> The fact that it is not done today does not mean that it cannot be done or
> would even be particularly difficult.
> Warmly,
> Padgett
It is even easier to implement things that are less broken than
what you suggest, for example dispatch based on MIME types and a
mailcap configuration file. This _has_ been done, and experience shows
that it doesn't work very well.
> ps looks like I will be able to attend on Wed. if the crik don't rise.
What a shame. I was hoping that there would be a high level of
technical competence at the conference.
</FLAME>