[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MD5 versus SHA
> From email@example.com Tue Mar 28 09:01:47 1995
> To: touch@ISI.EDU
> Cc: firstname.lastname@example.org
> Subject: Re: MD5 versus SHA
> From: "Steven M. Bellovin" <email@example.com>
> The following was forwarded at Bill Simpson's request.
> MD5 (orig) MD5 (opt) SHA DES (de
> Sun 10/51 34 Mbps 37 Mbps 19 Mbps 20 Mbps
> Sun 20/61 36 Mbps 38 Mbps 23 Mbps 29 Mbps
> Sun 20/71 54 Mbps 57 Mbps 29 Mbps 37 Mbps
> So in speed:
> MD5 > DES > SHA
> But we know that DES can be done at at least 1Gbps in hardware. One of
> the points of the draft that was circulated a while back was that MD5
> was *inherently* unable to run at that speed. Or am I missing something?
Well, there are a few points to be made:
a) if you can do hardware, DES is fine, and MD5 is not.
b) the IP security community has (as far as I have read from RFCs)
stated that software is preferable for several reasons:
- compatibility with existing hardware base
- agility (ability to change the algorithm if the need arises,
e.g., someone cracks DES :-)
c) my argument against MD5 in IPv6 is that the requirements state
that IPv6 should run at least as fast as IPv4.
"At least as fast" presumes the existing hardware;
I can do IPv4 at 75 Mbps with no real effort, and 120 Mbps
with some effort (i.e., user-level protocols sharing a
That's in software on the existing hardware.
If I ran IPv6 on the same hardware, it'd have to be
an all-software implementation, which would slow it to
around 40 Mbps.
What we probably need to ask is the following:
- do we want a fast hardware or fast software solution?
these aren't necessarily mutually exclusive,
but in comparing DES and MD5 they are
- what level of security is appropriate?
If it's in software, we have about 2-4 instructions
per 32-bit word. MD5 uses 45. Can there even
exist a reasonable hash function that
follows these rules:
- 2-4 instructions per 32-bit word
- "working set" of words is small (8? 16?)
- uses only RISC instructions
NO ROTATE (can take 3 opcodes to emulate)
NO ONE's COMPLEMENT ADDITION (2 opcodes)
NO MULTI-INPUT FUNCTIONS THAT
CAN'T BE TABLE-IZED
(these are just my observations, not hard-and-fast rules)