|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
To: "Richard Basch" <basch@lehman.com>
Cc: cvs-krb5@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: Your message of "Thu, 16 May 1996 13:36:59 EDT."
<199605161736.NAA28744@badger.lehman.com>
Date: Thu, 16 May 1996 15:31:08 EDT
From: Marc Horowitz <marc@MIT.EDU>
In message <199605161736.NAA28744@badger.lehman.com>, "Richard Basch" <basch@lehman.com> writes:
>> Larger confounders don't hurt... and it helps when it comes to the SHA
>> algorithm, so that there is less chance you will be able to do splicing
>> or replays. For 3-DES CBC, 8 bytes was sufficient, and that was why I
>> had originally chose that value. But for the SHA piece, 24 bytes probably
>> improves the SHA digest that is encrypted within.
Richard, you're playing amateur cryptographer again. Unfortunately,
that's all I can do in response. Really, none of us should be making
changes like this at all without consulting a Real Cryptographer.
Larger confounders mean more overhard. 3des-sha with a 24-byte
confounder (and a 20 byte checksum, padded) would mean 48 bytes of
overhead per encryption. (That's almost a whole ATM frame! :-) This
is way too much.
The checksum which is encrypted within is there to make sure that the
encrypted block was not tampered. If you can splice or otherwise
arrange to have differnet plaintext, then you're obviously able to
deal with the encryption in real-time, in which case it's all over,
anyway. Can you describe an attack which actually makes use of the
shorter confounder? I think eight bytes is fine.
Marc
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |