Re: IETF mtg discussion comments

Hi David,

No prob re email conspiracy accusation.  Apparently there was a
problem w/ the w3.org mailing list system over the weekend....

On to the technical stuff:

> My objection to pre-encryption is that even when it is not used, it
> requires potentially damaging changes to the MAC calculation (replacement
> of the inner hash key with a fixed value).  Aesthetic objections
> to "layering violations" aside, I don't believe it's wise to trade off
> protocol strength for server efficiency.

> And since Web containers being developed for other purposes (document
> protection independent of the transmission channel) have the side effect
> of providing the same efficiency gains, there is little reason to try to
> make pre-encryption "invisible" to clients by trying to disguise
> Independent Data Unit Protection as session protection, weakening the
> session protection in the process.

Pre-encryption does *not* require that you replace the inner hash key
-- pre-MAC'ing does.  We can have pre-encryption without pre-MAC'ing.
Or pre-MAC'ing without pre-encryption.  These are *independent* ideas,
and I fear that many of the IETF attendees missed this fact.

Web containers may be useful for other reasons, but unless there's a
protocol hook there is no efficiency gain, since the containers will
have to be sent encrypted (so plaintext data is doubly encrypted).  If
the containers are pre-encrypted data and the key simply is
transmitted over the TLS-provided channel, then that key will only
have an effective key-length equal to the minimum of the length of
that key and the length of the TLS-channel key.  Depending on how much
fixed headers there are in the container format, it may or may not
help to increase the multiplicity distance (it changes the entropy in
the source, but w/o container specs it's hard to tell), and if the
container-key is transmitted as TLS-channel data, this is still an
important consideration.

Now, maybe I misunderstood and you want to send the container over an
unencrypted channel, but have the associated key sent over a separate,
TLS-protected channel?  In that case, the above comment about the
effective key strength still holds; it also complicates the data
delivery, in that two communication channels (with different security
properties) are required -- and it's not just a single click anymore
(though I suppose you -could- have the container include an URL to the
key as a hack, and have the MIME helper talk to your browser for the
key fetch [ick].)

Anyhow, I have been arguing that pre-encryption, unlike pre-MAC'ing,
does NOT necessarily weaken the protocol.

(It of course would allow weak systems with bad configurations which
permits pre-encryption with ROT-13 over an otherwise 56-bit DES
encrypted channel; but I'd rather ignore stupid configurations -- I
assume that the pre-encryption strength is acceptable to both sides.)

Note also that the multiplicity distance concept applies to public key
systems as well, with some suitable modifications to the definitions
to move away from a strictly information theoretic viewpoint.
Hastad's low exponent attack against RSA may be viewed within such a
framework -- low exponent (e.g., 3) RSA encryption has a multiplicity
distance (in messages rather than bytes) equal to the value of the
exponent, since chinese remaindering of that many ciphertext messages
permits message recovery.

Paul, as for your comment about the possibility that the
pre-encryption key delivery mechanism might break, this was why I
originally argued for the use of a strong cryptosystem for
pre-encryption key delivery (aka key management cipher) in lieu of an
ad-hoc hash-based stream cipher.  As long as the pre-encryption keys
are -not- made available to the client program (and the whole point
was transparency), I don't see it as a real export control problem --
but I have never played an export control lawyer on TV.

(This is still certainly better than the IPSEC proposed ESP transforms
re ITAR.)

-bsy

--------
Bennet S. Yee		Phone: +1 619 534 4614	    Email: bsy@cs.ucsd.edu

Web:	http://www-cse.ucsd.edu/users/bsy/
USPS:	Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114

Received on Tuesday, 2 July 1996 15:24:24 UTC