From daw@guaymas.CS.Berkeley.EDU Thu Dec  7 16:39:59 PST 1995
Article: 26441 of hks.lists.cypherpunks
Path: hks.net!daw
From: daw@guaymas.CS.Berkeley.EDU (David A Wagner)
Newsgroups: hks.lists.cypherpunks
Subject: Re: Still more on the Digicash protocol
Date: 7 Dec 1995 20:55:09 GMT
Organization: University of California, Berkeley
Lines: 45
Message-ID: <4a7kbd$r7e@old-bb.hks.net>
References: <Pine.3.89.9512071804.A21520-0100000@unicorn.com>
NNTP-Posting-Host: guaymas.cs.berkeley.edu

In article <Pine.3.89.9512071804.A21520-0100000@unicorn.com>,
Rev. Mark Grant <mark@unicorn.com> wrote:
> I think he means you shouldn't use a stream cipher like RC4 that XORs the
> plaintext with the generated keystream, since if you know part of the
> plaintext, you can XOR those bytes with (the id you want) XOR (the id
> being sent) and change the encrypted data so that the payment goes into
> your account and not theirs.

Right.

RC4 encryption doesn't provide message integrity.

And I should mention that block ciphers like DES in chaining modes
like CBC don't provide message integrity either -- it's a bit harder,
but an active attacker can still tamper with the ciphertext to modify
the plaintext in a predictable way, like with RC4.

I admit it's a more difficult to mount this attack against a block
cipher in chaining mode, and the success probability may go down
(depending on the circumstances), but hey! paranoia is your friend;
and my point remains valid:

	Don't count on encryption to give you message integrity.
	If you need message integrity, use a MAC.

If you want a citation for this basic crypto design principle, I'll
be happy to provide one.

>                              This is a tough, but potentially feasible
> attack if you use that kind of encryption scheme. 

Tough!?  It's trivial for an active attacker, in the stream cipher case.
He just xors some bits: no clever cryptanalysis needed.  (Or did you mean
it's tough to mount an active attack?  I agree: that requires significant
knowledge or motivation.)

> Is there anywhere that you could use a similar attack on SSL ?

Not in SSL v3.0; it explicitly uses a (cryptographically strong) MAC
(message authentication code) on each message to prevent tampering
and modification.

Dave Wagner, speaking for himself,
but thankful for all those behind the scenes who are helping
to improve and open up Digicash communications.


