On 5/27/2013 3:53 AM, Mark Rotteveel wrote: > On Sun, 26 May 2013 13:36:36 -0400, Jim Starkey <j...@jimstarkey.net> > wrote: > Read the fine print. To break a message, you need 2^30 encrypted > versions of a message containing a 256 byte constant block starting at a >> fixed position. Nice theoretical work, but it isn't a practical attack. >> >> Note the chaining algorithm used for AIS stream encryption has also been >> attacked. > Maybe I should have mentioned it explicitly, but I am also thinking of the > psychology of "it is new and they use something known to be broken?".
Think about that for a minute. RC4 has been around since 1987, has been in widespread use for about a decade and a half, wasn't successfully attacked until this year, and that attack requires 2^30 identical messages encoded with different keys. Anything "new" would require a decade or so rigorous vetting before it could be considered as remotely secure. It is axiomatic in crypto circles that is an algorithm isn't published and subjected to prolonged study, it has be considered as completely insecure. RC4 is based on a 256 byte vector of unique values. Each iteration generates a pseudo-random byte value and swaps two elements. The pseudo-random byte value is XORed with a byte of the cleartext to generate the ciphertext. It should be obvious that an analysis of a very large number of identical encryptions of the same cleartext will expose something about the original cleartext. There are really only three questions here. The first is how many encryptions of a fixed message are required, what is amount of computation necessary to do the analysis, and why would anyone knowing the nature of RC4 be so stupid as to serially encrypt the same message 2^30 times with different keys. If you follow the crypto world, you will find that they tend to get hyper-excited about things that normal folks would find inconsequential. For example, there was a major flap a decode ago when someone decided that if you knew the microsecond that a machine booted (used as a seed in a kernel random number generator) and the number of random numbers generated, you could predict a machine generated session key. All true but also all worthless. But that's what crypto guys are supposed to do, analyze algorithm and design attacks. But a successful attack doesn't mean that the algorithm is necessarily broken or even weak, just that it needs to be used intelligently. Like, say, everything else we use in the real world. > >> I initially implemented NuoDB (then NimbusDB) line encryption with 128 >> bit AES. The performance hit was about 85%, which just wouldn't fly. >> Substituting RC4 for AIS dropped this to about 4%. As a result, I left >> the flexible encryption in place but dropped both AES and plaintext as >> options, leaving only RC4. > Was that with or without the use of AES instructions like AES-NI > (http://en.wikipedia.org/wiki/AES_instruction_set ) I thought that with use > of those instructions AES actually outperformed RC4 (can't find a direct > comparison right now though). It was without -- I didn't have access to a machine with the instruction set. That said, I doubt that it would make a big difference. While the code implementation is going to execute out of the instruction cache and the "instruction" version out of microcode, the amount of computation is the same. The "hardware" would have a clear advantage if the AES algorithm could be parallelized, but a central feature of any crypto algorithm is that it can't. About three years ago I posted the source code for both RC4 and AES transforms for comparisons to firebird-architect. If you'd like to recode the AES transform to use the crypto instruction set compared to C++ version, I would be happy to see the results. I'd do it myself, but I, uh, sold my last implementation and have gotten around to re-implementing the transform library. I also posted Java implementations of SRP and RC4 that anyone working on the JDBC remote might find useful. >> I don't know what Firebird is now using for password validation, but I >> strongly suggest that somebody look closely at SRP (secure remote >> password) to generate session keys. SRP is immune to all but brute >> force attacks, doesn't require that a server store anything which, if >> compromised, would allow password (or surrogates) to be computed, and >> requires a single round trip for authentication. > Firebird 3 uses SRP. > > ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
