Hal Finney wrote:
I'm not happy about adding a cipher with a 64 bit block size in this day
and age. Putting it into the spec seems to be an implicit endorsement to
some degree. We took out ElGamal signatures because of the difficulty of
using them securely, and I think we should continue to demand that we only
add algorithms to the spec if they provide acceptable levels of security.
I think of it as a chess game. Advancing a pawn
into line of attack of the queen is not a good
strategy, for the pawn, and perhaps we should
take away the pawn from the game's rules?
By putting GOST into OpenPGP we are offering
a product that conforms to "the rules." That
means those rule-takers are more likely to use
OpenPGP than another product.
Not only is the other product likely to be more
insecure (any arguments there? ;) it won't also
come with AES, etc. All OpenPGP products these
days come with a lot of other nice strong options;
these are the knights covering the pawn's move.
The rule-takers that we are talking about are
notoriously poor at following the spirit of the
rules.... For the most part, "we use OpenPGP
and OpenPGP has GOST" is probably sufficient
to get a pass.
I don't know the details of GOST but it is often called the "Russian
DES" and we certainly wouldn't want to add a DES-strength cipher now.
GOST has a much larger key so it is not quite the same but overall it
seems like an old cipher whose time has passed.
For those who want to use it, would an acceptable alternative be
a short informational RFC which specified an algorithm ID from the
private/experimental range?
If it is specified it shouldn't be in the private/
experimental range. That range should be for
stuff that isn't specified, by definition.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/