Re: ANNOUNCE: SHA-224 in Digest::SHA
From: Mark Shelor (mshelor_at_comcast.removeme.net)
Date: 12/31/03
- Next message: Paul Rubin: "Voynich manuscript a hoax?"
- Previous message: Paul Rubin: "Re: Delivering on talk"
- In reply to: Tom St Denis: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Next in thread: Tom St Denis: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Reply: Tom St Denis: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 31 Dec 2003 00:38:49 -0700
Tom St Denis wrote:
> No it makes sense to specify the protocol on the bit level. So if you
> really NEED it you can use it.
So then, you're disagreeing with the earlier poster who would want to
disallow (or did he instead rather ambiguously say "bother to allow"?)
bit-level digest computations on a PC? Not that it matters, I suppose,
since neither you nor he nor I set the standards for these things. The
real question is whether you're producing an implementation that allows
all capabilities specified by the standard, or just making rather
dubious excuses for not having done so.
> 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.
Praising motherhood and apple pie isn't the point. The question is:
does a given implementation allow all the computations envisioned by the
standard, or does it impose certain artificial restrictions?
The purpose of standards is to promote interoperability. The NIST SHA
standard allows peers to compute digests for partial-byte data such as
bit vectors. So, if someone sends you a SHA-1 fingerprint for a
particular non-byte-aligned bit vector (in full accordance with FIPS
180-2), the real consequence of what you're saying is that you will NOT
be able to verify the fingerprint since your implementation is only
capable of handling byte-oriented data. However, the sender will
rightly argue that you're in violation, since the standard allows
bit-oriented inputs. You lose.
Pressing your argument to its full, untenable conclusion, implementors
could begin deciding to omit whole parts of standards simply because
they're deemed too complex, or too dangerous for security. One might be
sorely tempted to do this with specs such as ASN.1/BER/CER/DER/PER, but
the unfortunate consequence is loss of interoperability. A standard is
a standard is a standard.
> We're [well at least myself] not saying you're wrong to code it. It's just
> not a good idea.
I advised you earlier that you might want to leave metaphysics to the
philosophy classroom. There's very little consensus out there on what a
"good idea" is, but people generally recognize when code is effective,
and when it's not. So, if you can make a compelling point which is
either demonstrable or measureable, then please do so.
Mark
- Next message: Paul Rubin: "Voynich manuscript a hoax?"
- Previous message: Paul Rubin: "Re: Delivering on talk"
- In reply to: Tom St Denis: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Next in thread: Tom St Denis: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Reply: Tom St Denis: "Re: ANNOUNCE: SHA-224 in Digest::SHA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]