On Thursday, August 20, 2015, Michal Kubecek <m...@mk-sys.cz> wrote: > On Wed, Aug 19, 2015 at 02:55:33PM -0400, Jim Starkey wrote: > > > > The best alternative to RC4 is AES-128. It is "more" (but not > > measurably) secure but also a couple of hundred times as expensive to > > compute. If you don't believe me, run your own numbers. > > I did... > > > So it looks like "couple of hundred" means 6-8 when calculating AES in > software and 1.25-1.35 when using in-CPU implementation (in this case, > AMD FX-8150 from 2012). > > Anyway, I agree with most of the rest. > > > Interesting. The tests I ran were "in situ" in early NuoDB, which encrypts all message traffic, including quite significant replication traffic. The RC4 was one I coded myself. The AES implimentation was from the open source Tom's Crypt Library. The overhead compared with unencrypted traffic was about 86% for AES-128 and about 5% for RC4. Perhaps much of the difference was in the qualities of the implementation.
RC4 operates on a 256 byte state table, swapping two entries per operation XORing one with the next byte of the clear text. AES-128 operates on a 4 x 4 matrix of bytes, performing 10 rounds of four matrix operations per round. That said, much of the efficiency of AES is dependent on the key schedule algorithm computed at initialization time. I have no argument against AES, used properly, or RC4, again used properly. AES/ECB, aka simple AES, in some applications is more vulnerable than RC4 as used in WEP. But AES-128 and RC4 with pseudo random keys that are never reused are each unbreakable. If the press had latched onto the ineffectiveness of AES/ECB for encrypting an image, AES would be in the same dog house as RC4. AES/CBC XORs each input block with the encrypted output of the previous block, solving the problem. If you were starting over in a world when most servers had the AES instruction set, it would be a no brainer to use AES/CBC. But that isn't an argument switching with an installed base, though it does recommend an architecture where the choice of algorithm is a connection parameter. Anyway, you've convinced me to think about an overhaul of the encryption architecture of AmorphousDB. Thanks for pointing out my shameless exaggeration. -- Jim Starkey
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
