Re: Stream Cipher Transform -- revisited

[John Gilmore <[e-mail]>]

I advise against making *any* design decision that trades off security
or privacy for MIPS (beyond hitting the sweet spot in the market:
running broadly useful data rates on cheap up-to-the-minute hardware).
It's absolutely clear that the short-term, medium-term and long-term
trends all tell us we will have plenty more MIPS whenever we want
them.  But we won't have plenty of security or privacy; both are up
for grabs and there's no predictable outcome.  Why give up something
scarce to get something plentiful?  Particularly when designing an
architecture that will last for a decade or more.

It's hard for people to think about the consequences of exponential
factors like chip feature sizes.  People told Richard Stallman he was
crazy to build a compiler that needed more than a megabyte to run, or
a text editor that kept the whole file in memory.  He was right, they
were wrong.  "Eight Megabytes And Constantly Swapping" EMACS is pretty
tame stuff on a 48-meg Pentium laptop, which has to do full-screen
video to work up a sweat.

Legacy systems that support a hundred users without encryption can't
always have their speed doubled as easily as last year's clone.  But
an external encrypting gateway, built cheaply with this year's
technology, can burn all the new MIPS, and hand the same old stuff to
the legacy system.

Exportability of solutions from the US is *NOT* very important this
year.  Last year, last decade, sure.  We played that game and it was a
losing game.  We can keep losing or we can play a different game.  RSA
has noticed this; that's why they're making global alliances to build
strong crypto worldwide.  The IAB and IESG have noticed this.  I hope
the IPSEC working group knows it solidly, too.  Note that by playing
the new game well, the old game resolves itself (the gov't gives up),
which could never happen while we continued to play by their rules.

	John Gilmore
	(An equal opportunistic encryptor.)