Just my 0.02€ http://ianix.com/pub/chacha-deployment.html
ChaCha20 is in TSL and OpenSSH etc. and mainly because it is secure and it is fast. -Tee- On Thu, Aug 20, 2015 at 2:26 PM, James Starkey <j...@jimstarkey.net> wrote: > > > 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 > >
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
