W3C home > Mailing lists > Public > ietf-tls@w3.org > April to June 1996

Re: pre-encrypted files

From: Bennet Yee <bsy@cs.ucsd.edu>
Date: Tue, 28 May 1996 11:55:39 -0700
Message-Id: <199605281855.LAA24889@work.ucsd.edu>
To: Phil Karlton <karlton@netscape.com>
Cc: ietf-tls@w3.org

Hi Phil,

In message <31AACE90.167E@netscape.com>, Phil Karlton writes:
> [ ... ]
> A more straightforward approach would be to add another SSL handshake
> message: set write key. Since the two ends already share a 128-bit
> master key, the originating end could use a new salt together with the
> current master key to compute a hash and an XOR offset from the desired
> new encryption key. This could be used by either end and would take
> effect when the next ChangeCipherSpec message was sent. It has the
> advantage of not leaking a subsequent key when the previous was
> compromised. (Keeping the appropriate (according to U.S. export rules)
> amount of entropy in the new key is left as an exercise to the reader.)

Yes, having explicit key management messages to set the key using the
master secret (nee master key) is good.  However, what you are
proposing is basically an ad-hoc cipher: use the master secret to
select a one-way function (function generated/selected via hashing &
pseudo-currying); compute the image of a stream of plaintext "salt"
values under this one-way function, which is then used as a stream
cipher pad to encrypt the new bulk data encryption key.  The use of a
more standard cipher that has undergone scrutiny (e.g., 3DES) is more

Yeah, the export control question is a real icky one.  We'll need to
be careful wrt APIs to make sure that the user can not easily control
the bulk data encryption key and thus use the key management mechanism
to send encrypted messages (rather than a real key).


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, 28 May 1996 14:55:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:58 UTC