Blake Ramsdell <blake(_at_)sendmail(_dot_)com> writes:
I still find myself somewhat annoyed by the MUST- SHOULD+ approach, though I
do understand that as a "clue for future revisions" it has some value.
I rather like it actually, I wish it had already been in use during the AES
transition to provide implementation guidance for pending changes.
Personally, I would upgrade 384 and 512 to SHOULD (no "+"). The semantic of
that is "there may exist valid reasons in particular circumstances to
ignore". If you can't do 64-bit easily or the performance makes you crabby,
then you can invoke that clause. I don't really feel strongly enough about it
to fight for this though.
I would argue strongly for just having a single algorithm to support, and
preferably the one that shows at least adequate performance (they're bad
enough on register-starved x86 already). The problem with making -512 et al a
SHOULD is that (a) you then have to support three different rather sizeable
blocks of code, and (b) as with AES, if you give them the option the plebs are
going to demand the -512 version because real crypto algorithms go to 11. If
there's strong demand for something other than -256, I'd say only have -512,
again using the AES precedent as an example: Cryptographers are happy with
AES-128, the tinfoil-hat/bigger-is-better brigade want AES-256, and no-one
cares about the in-between value. It'll be the same for SHA2.
Peter.