Re: ANNOUNCE: SHA-224 in Digest::SHA
From: Tom St Denis (tomstdenis_at_iahu.ca)
Date: 12/31/03
- Next message: Jean-Luc Cooke: "Re: Delivering on talk"
- Previous message: Mark Shelor: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- In reply to: Mark Shelor: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Next in thread: Mark Shelor: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Reply: Mark Shelor: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 31 Dec 2003 02:49:17 GMT
"Mark Shelor" <mshelor@comcast.removeme.net> wrote in message
news:esqdnQOmYeMpqm-iRVn-iw@comcast.com...
> Simon Johnson wrote:
>
> > I suspect that the reason that SHA can handle bit streams is because
> > it's designed to be used in hardware too.
>
>
> Not really. There are plenty of software protocols and formats that use
> partial-byte data which can be authenticated or fingerprinted by means
> of message digests. This allows digest values to be unique regardless
> of how padding is done, thereby guaranteeing that only the meaningful
> (and not incidental) parts of the data are being authenticated.
Generally though in crypto you hash the entire message and since you can't
send partial bits over a network you have to pad anyways. So really the
argument is moot.
> > I wouldn't bother allowing it to handle partial-byte data on a PC
> > platform.
>
>
>
> Unless you have compelling arguments that alledge to cover how anyone
> and everyone could possibly use a PC, I believe that such a
> pronouncement is untenable. There's a reason why NIST specified the SHA
> standard the way they did, and why they've gone to the effort to have a
> validation program for PARTIAL-BYTE implementations.
The point we're trying to make is that limiting to multiple of bytes has yet
to be proven a problem. Huge standard protocols like SSL are specified for
whole bytes[octets,etc].
> > It adds extra complexity to the code for very little
> > additional function - this extra complexity could be the source of a
> > security bug - that might seem pedantic but we have to have that mind
> > set if we're talking about security.
>
>
> I'm not sure that NIST would consider this to be a convincing reason to
> countermand their spec, or to put such arbitrary limits on its
> implementation. Indeed, you make a good general point: security bugs
> are a concern (with ANY software), and need to be very carefully
> addressed. But, it's premature and unnecessarily cautious to begin
> imposing artificial restrictions simply under a free-floating sense of
> fear, uncertainty, and doubt. The only logical destination of that path
> is to shut off the machines.
No it makes sense to specify the protocol on the bit level. So if you
really NEED it you can use it.
The point we're making is that simplicity is bliss in crypto. When you have
many working parts you want to make each part simple.
For instance, in a recent program I worked on [for $$$] I had to use my ECC,
SHA-256, AES, HMAC and prng code. The ECC code alone touches probably 65 or
so different functions [specially on the math side]. Having each function
of the support libraries as simple as possible has led to code that has
proven to be very useful [and quite a few of my LT users would agree with me
on this].
We're [well at least myself] not saying you're wrong to code it. It's just
not a good idea. So is using heap within functions if you can avoid it...
Tom
- Next message: Jean-Luc Cooke: "Re: Delivering on talk"
- Previous message: Mark Shelor: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- In reply to: Mark Shelor: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Next in thread: Mark Shelor: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Reply: Mark Shelor: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
