Re: Why is blowfish so slow? Other fast algorithms?

At 02:00 AM 1/22/96 -0500, David Mazieres wrote:
>Failing that, can anyone suggest other secure, preferably unpatented,
>shared-key encryption algorithms that could encrypt at ethernet speeds
>(1 MByte/sec) without using most of the CPU on a fast Pentium or
>equivalent processor?

RC4 is of course unpatented and faster than anything else.
Of course the name RC4 is trademarked, so you could simply 
call it "the well known algorithm" in your documentation 
and give the algorithm explicitly.

RSA's present legal gimmicks seem to me to be based on the "trade secret"
that RC4 really is the well known algorithm, so if you refrain from 
using the name "RC4", you should be OK.  (I am not a lawyer.)



T


>
>Thanks a lot,
>David
>
>
 ---------------------------------------------------------------------
              				|  
We have the right to defend ourselves	|   http://www.jim.com/jamesd/
and our property, because of the kind	|  
of animals that we are. True law	|   James A. Donald
derives from this right, not from the	|  
arbitrary power of the state.		|   jamesd@echeque.com

In article <199601221601.IAA14610@mailx.best.com> "James A. Donald" <jamesd@echeque.com> writes:

> From: "James A. Donald" <jamesd@echeque.com>
> Date: Mon, 22 Jan 1996 19:56:43 -0800
> X-From-Line: jamesd@echeque.com  Mon Jan 22 10:59:02 1996
> X-Sender: jamesd@best.com
> X-Mailer: Windows Eudora Version 2.1
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Lines: 32
> 
> At 02:00 AM 1/22/96 -0500, David Mazieres wrote:
> >Failing that, can anyone suggest other secure, preferably unpatented,
> >shared-key encryption algorithms that could encrypt at ethernet speeds
> >(1 MByte/sec) without using most of the CPU on a fast Pentium or
> >equivalent processor?
> 
> RC4 is of course unpatented and faster than anything else.
> Of course the name RC4 is trademarked, so you could simply 
> call it "the well known algorithm" in your documentation 
> and give the algorithm explicitly.

The problem with RC4 is that it works in OFB only.  If I need data
integrity in the face of known plaintext, I will need to compute a MAC
in paralell with the encryption which could significantly slow things
down.  With a block cypher in CFB, I can just re-encrypt the last
block of data.

That said, OFB has the advantage that I can overlap computation of the
RC4 stream with I/O, which might be a win for me.  Are there any MACs
significantly faster than say ~50 cycles per byte?

Thanks,
David

-----BEGIN PGP SIGNED MESSAGE-----

In article <199601221851.NAA16938@amsterdam.lcs.mit.edu>,
David Mazieres <dm@amsterdam.lcs.mit.edu> wrote:
> The problem with RC4 is that it works in OFB only.  If I need data
> integrity in the face of known plaintext, I will need to compute a MAC
> in paralell with the encryption which could significantly slow things
> down.

If you want authentication, you must use a crypto-strength MAC.
Encryption (be it RC4, DES, etc.) is not enough.

>        With a block cypher in CFB, I can just re-encrypt the last
> block of data.

False.  CFB has limited error propagation, so if I modify any block
before the next-to-last, it will not show up with your method.



This seems to be a really common error.
If you want message integrity guarantees, you must use a MAC.  Always.
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBMQV+LioZzwIn1bdtAQF7pgGAm6GnmZqPSElx8mVyonD9BqScefdZLhul
fv/qU/bsEDM2YyKuBpoFWyKMwIH0jyzx
=Bp2Q
-----END PGP SIGNATURE-----