Re: Generate a one-time pad from say a 256bit key?

Unruh wrote:
Look up where I work, the workstations JUST moved to 100mbit [the HPC
centre has much higher bandwidth stuff though].

You'd probably be surprised at the amount of 10 and 100mbit stuff still
lying around.

Of course there is a lot of 10 to 100Mbit stuff around. There are also
millions and millions of 500MHz PIII and Pentuim machines around. YOu took
the highest level processor, linked it to slow outdated network and disks,
and said-- See AES can more than keep up. IF you want to use old network
and disk speeds, use old processor speeds as well-- that is my point.

It's a lot cheaper to get a fast processor than a fast disk array.

Sheesh. 30-40% t encrypt, 30-40% to decrypt and you have your whole
processor in use just to copy a file. That level should be down at a max of
1%.

How often are you moving files from encrypted volumes? Maybe you
should re-consider your crypto deployment? Also if they are encrypted
with the same master password/key you could just literally move the
file. Why would it not be decryptable on the other end?

Of course I also disagree with the general deployment of encrypted
volumes. People over deploy it then think "I can do anything I want
[such as run windows] because obviously I'm secure now."

Point is, if you design cryptosystems for a Pentium 3 then you have a
very small niche market. On my box RC4 gets 223390K/sec and AES-128
gets 142393K/sec. Sure RC4 is faster, but I'd be damned to see my RAID
array sustain 142393K/sec.

No, if you design it for quad core processors you have a very small niche
market. 500MHz or slower processors are by far the majority out there.

Um, the only place you see <500MHz processors in wide deployment are
ARM and MIPS in which case you can work in a crypto core to get faster
than RC4 rates anyways. Besides, you don't need a 2P 285 Opteron box
to get this. Any 2.6Ghz AMD64 will get those rates. Certainly, it's
easier and cheaper to buy a high end Athlon64 then it is a disk array.

So if you were really worried about performance you could easily move
the bottleneck to the I/O subsystem.

But this line of thinking is ludicrous. Windows standard? O RLY? So
you mean my Win3.11 applications will work flawlessly in Vista? I
certainly have X11 applications from the early 90s that still work in
2006.

There are standards which are set by standards bodies and standards which
are set by the marketplace. Both are important.

Yes, and no. If you are making a NEW design generally it's best to
take from standard bodies as much as possible.

Oh I get it, I'm making a new product totally unrelated to TLS and
Windows, but because TLS has RC4 [as well as AES] and the NT hash is
MD4 I should base my product on RC4/MD4. Clearly that's a well thought
out design decision.

:-)

Face it, RC4 had its time but it's just moot for all but the simplest
homebrew applications.

Tom

.