Subject: pk-init-27 comments, part 2

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 26 Jul 2005 19:09:26 +0200

l27.6:	Why is asChecksum checksumed with a keyed checksum, using the
	key sitting next to it in the structure same. If someone gets
	inside your EnvelopedData(SignedData(ReplyKeyPack)) and
	modifies that keyed checksum. What will stop them from
	modifing the key at the same time ?

	This needs to be motivated better in the draft.

	To counter, I propose just to include the same value as in
	PKAuthenticator.paChecksum. This will bind the request to the
	responce, assuming the client checks it the same as the request.

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jul 2005 22:55:12 +0200 (MET DST)

> 	modifing the key at the same time ?

I admit that I don't understand the Kerberos-related aspects of this
question.

However in general, encryption-only would be extremely vulnerable,
in particular if the encryption algorithm that is being used
is something like RC4 (a stream cipher which is X-ORed with the
plaintext to produce the ciphertext).

If you have a larger blob of data which is RC4-encrypted, but not
integrity protected, then you could can easily modify those bytes
of the blob for which you know the plaintext to any particular other
values you like.  You do not have to break any keys, so it doesn't
matter what keylength is used (X-OR with the known plaintext,
and you get the original keystream byte, X-OR with your new plaintext
and you have correctly encrypted ciphertext to put back in).

Because of this RC4 characteristic, one should use keyed hashes
for integrity protection, *NOT* simply encrypted hashes over
plaintext or predictable data (because if the encryption is
RC4, that can be easily forged).

When a keyed hash is used, and the key is included in the encrypted
portion of the data, then you don't have a short-cut, even when
RC4 is used (provided that the key has strong random properties,
of course).

-Martin