On Mon, Feb 2, 2009 at 10:38 PM, Ian G <iang(_at_)systemics(_dot_)com> wrote:
On 2/2/09 22:43, Peter Thomas wrote:
On Mon, Feb 2, 2009 at 4:58 PM, Daniel Kahn Gillmor
<dkg(_at_)fifthhorseman(_dot_)net> wrote:
I think the answer is not to pick a "new, better" hash function for a
revised spec, but to make the spec flexible enough to actually use
whatever "new, better" hash function comes along (and to be able to
deprecate the ones implementors/users feel are untrustworthy).
Of course :-)
<cough -:>
There are two poles of thought.
Pole One is "agility" which involves being able to switch between different
algorithms within packets and protocols. So if an algorithm goes belly up,
the market migrates by switching over that algorithm.
Pole Two is "the one true cipher suite." PGP 2 and so forth. The notion
here is that you design it well, you design it balanced, and you plan on it
lasting at least 10 years. If not 20 or 30. Then, you throw the whole lot
out in 10 years.
Whether you gravitate around Pole One or Pole Two depends on a whole host of
factors: economics, business, distributions, compatibility, structure of
players, law & barriers, engineers & polemicists, cryptoreligion, etc.
For my money, Pole Two delivers much more bang for buck. There has never
been in modern history a complete collapse of a well-designed suite. But
there have been huge, monstrous, embarrassing efforts spent and lost in
maintaining "agile" suites; if the OSS's sabotage manual were updated
today, it would almost certainly include a section suggesting much attention
paid to perfect agility.
</ahem>
iang
or we do a compromise of both approaches:
agility but with a few MUSTs
(of course, this leads to a few backwards-compatibility
overheads / undesirables, such as 3DES ending up as
a MUST with ECC)