[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Padding complexities

To: Dan McDonald <danmcd@Eng.Sun.Com>
Subject: Re: Padding complexities
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
Date: Thu, 22 Jan 1998 13:13:43 -0500
cc: dan_nessett@3mail.3Com.COM (Dan Nessett), ipsec@tis.com
In-reply-to: danmcd's message of "Thu, 22 Jan 1998 03:56:11 -0500". <199801220856.AAA08261@kebe.eng.sun.com>
References: <199801220856.AAA08261@kebe.eng.sun.com>
Sender: owner-ipsec@ex.tis.com

In message <199801220856.AAA08261@kebe.eng.sun.com>, Dan McDonald writes:
> 
> Existing implementations just feed in the message and let the algorithm's
> "Finish" routine close it out the way it sees fit.

Phrased another way, MD5 (and SHA1) are *designed* so that the internal
blocksize of the algorithm is irrelevant. Unlike DES-CBC, you can feed any
number of bytes into the algorithm, and get the correct result. MD5 and SHA1
have an effective (external?) blocksize of 1 byte, as I said previously.

Meta comment: when was this issue of "authentication algorithm blocksize"
introduced? As with many other changes in the last few months, it has added
needless complexity and confusion to the standard.

-- 
Harald Koch <chk@utcc.utoronto.ca>

Follow-Ups:

Re: Padding complexities

From: Stephen Kent <kent@bbn.com>

References:

Re: Padding complexities

From: Dan McDonald <danmcd@Eng.Sun.Com>

Prev by Date: Security Association Lifetimes in kbytes
Next by Date: Authentication Padding
Prev by thread: Re: Padding complexities
Next by thread: Re: Padding complexities
Index(es):
- Main
- Thread