[8913] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: crypto flaw in secure mail standards

daemon@ATHENA.MIT.EDU (Charlie_Kaufman@iris.com)
Mon Jun 25 12:04:14 2001

To: cryptography@wasabisystems.com
Message-ID: <OFE7DA36B5.ABCF6D30-ON85256A76.0055788C@iris.com>
From: Charlie_Kaufman@iris.com
Date: Mon, 25 Jun 2001 11:36:12 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

>In fact, every secure e-mail
>protocol, old and new, has codified na=EFve Sign & Encrypt
>as acceptable security practice.  S/MIME, PKCS#7, PGP,
>OpenPGP, PEM, and MOSS all suffer from this flaw.

Actually, that's not true. The encrypted and signed email
functionality contained in Lotus Notes encrypts only body
fields and attachments, but signs the To:, From:, CC:,
Subject:, and TimeSent fields as well. And Lotus Notes predates
most if not all of the "standard" protocols.

I wouldn't call this a cryptographic flaw. I'd call it a flaw
in cryptographic engineering. And it's not a flaw borne out of
ignorance. The designers of the standard protocols knew about
the problem (I was there for some of them), but didn't think
their proposed standard would be acceptable if it "committed
layer violations" by extending signature coverage to data not
contained in their "layer". This is a classic example of
something a competent engineer can get right, but which a suite
of committees can't.

           --Charlie Kaufman
           (ckaufman@iris.com)

p.s. Ironically, Lotus Notes is transitioning from its
proprietary email format to S/MIME and trying to figure out how
to make it clear to customers that when they use the new
format, they don't get the protection they may have gotten used
to.

=





---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com

home help back first fref pref prev next nref lref last post