Slashdot Mirror
New RC4 Encryption Attacks Reduces Plaintext Recovery Time
msm1267 writes: Two Belgian security researchers from the University of Leuven have driven new nails into the coffin of the RC4 encryption algorithm. A published paper, expected to be delivered at the upcoming USENIX Security Symposium next month in Washington, D.C., describes new attacks against RC4 that allow an attacker to capture a victim's cookie and decrypt it in a much shorter amount of time than was previously possible. The paper "All Your Biases Belong To Us: Breaking RC4 in WPA-TKIP and TLS," written by Mathy Vanhoef and Frank Piessens, explains the discovery of new biases in the algorithm that led to attacks breaking encryption on websites running TLS with RC4, as well as the WPA-TKIP, the Wi-Fi Protected Access Temporal Key Integrity Protocol.
It don't work that well ?.
The problem is that if you have a heavilly threaded process wanting to do encryption, say a web server, all the threads are in a different state.
So the data is different, different sizes, but also the connection state, some threads are waiting for input, some halfway through sending. To use a video card (which can run the same algorithm over different data efficiently) you'd have to synchronize the threads - costing you more performance than you'd gain.
Attacking doesn't have that issue, same data, 6000 different keys, just do it.
did everyone got used to it so no one wants to comment? :)
The answer is that it varies - GPUs are anywhere from mediocre to useless at "normal" crypto.
It depends on whether the particular encryption algorithm/mode in use is parallelizable or not. For example, CBC is not parallelizable - you have to encrypt each block of data serially. GPUs are useless at CBC mode encryption. More modern modes like GCM and XTS are parallelizable to an extent, as you can encrypt multiple blocks at once, but there is still a serial dependency in the process (there is no real way of completely getting rid of all dependencies while keeping the algorithm usefully secure), so you still need to do some pre or post-processing of the data in a serial fashion. And even then, you're limited by bandwidth in/out of the GPU.
Public-key crypto (RSA, DSA, and ECDSA) isn't really parallelizable either as it only deals with small data sizes. And typical hash algorithms like SHA-1 and SHA-256 are also not parallelizable in their construction.
Thing is, CPUs these days have hardware AES encryption acceleration, making this mostly a moot point. GPUs are good at doing the same thing many times in parallel, which is what breaking encryption requires, but not regular usage.
Bwuhahahahahahaha
what better encryption is the available???
Is there any further value in studying an encryption scheme that is widely considered completely and irreparably broken? At this point isn't it like discovering a house with a completely open front door can be broken into by smashing a window?
RC4 is already not recommended as a cypher for many applications.
It's old, it's pretty much done for, and preceded by many better protocols (some of which have also been seriously damaged since, like RC5). It starts to sound a bit like kicking a dead horse.
Why would any sane admin use RC4 for SSL/TLS instead of using a more secure algorithm like AES?
GPUs can do a subset of the formulas for encryption, as well as do some operations that aren't related to the normal encryption process but are related to attacking weaknesses in the encryption algorithm or even factoring for primes.
There is a bit of bit shuffling and different rounds that are required for more encryption algorithms. A GPU can do these, but not really any faster than a CPU. As the order of operations matters a great deal and it is not easily parallelized. If it were, then it would be even easier to break.
You should check out OpenCL or CUDA programming for a bit, now that relatively inexpensive graphics cards are capable of using it, of course the more money you spend the faster it goes, but for learning you can go cheap on this. The only cost is your own time.
And even then, you're limited by bandwidth in/out of the GPU.
Heh, if that's the thing limiting your ability to handle encrypted data, I envy your internet connection. I've been fortunate enough to get to play with direct-to-Internet 10Gbps before but DAMN, son. 10Gbps is an ant fart compared to PCIe gen 3 x16...
I still can't quite believe that today, with four K80s per U, you could get 100TFs of double precision and half a petaflop of float (~25u), AND a 100Gbps network (4u?), AND 200TB of raid-1'ed backing store (8u) into a single cabinet. The power cable would be the size of a bodybuider's forearm and you'd have to install it in a wind tunnel, but even so...
"All Your Biases Are Belong To Us"
FTFY
Set your phasers on "funky"!
That's all I'm really interested in. Will it make cracking the neighbor's WiFi practical again? Nobody uses WEP anymore, and almost all the routers with WPS seem to have been upgraded to prevent the very nice Reaver attack which was so cool a few years ago.
I used to get Internet access anywhere by simply cracking some nearby WiFi. Nowadays, I usually need to use my phone's data connection, which is painfully slow and not usable in other countries because of roaming charges. I keep an open WiFi at home for passersby, but nobody else seems to be doing that for me.
See subject: Grow up idiot, stop impersonating me.
APK
P.S.=> Get a life & get over your obsession with me too please... apk
"GPUs are good at doing the same thing many times in parallel, which is what breaking encryption requires, but not regular usage." - by marcansoft (727665) on Thursday July 16, 2015 @11:11PM (#50125895) Homepage
See subject & that quote from you (says it all) - it's key & perfect for my understanding of this & WHY vidcards aren't used over CPUs (others noted how that's built into CPUs now too which also helps explain the 'why' of them NOT being used for actual valid encryption processing speedups).
* This I understand from normal programming using threads, & it makes sense, ala
This not gaining (due to C having to wait out the results of A first - thus, no point in using diff. threads of execution on A, B, & C):
A = B+C
B = 1
C = A + B
Perhaps not the best example here, but it helps make my points with an illustration... this sounds ALMOST that way regarding encryption and the rest of WHAT A GPU DOES (doing same thing many times in parallel) does the rest...
APK
P.S.=> Thanks - as I said, I learned something here today & "it's not a wasted day when you learn a new thing"... apk
See subject: For me to invest time in a new tech (for me), I have to have an idea to apply it to 1st - to keep me interested basically by having an "end goal" in place that's practical for solving a problem for myself, FIRST, & then possibly, others also.
* I had no idea HOW fpga's or vidcards work really, but NOW I do (doing the same thing many times in parallel from what others stated)... that alone, helps me loads.
(Understanding of the mechanics of their processing is key of course, first - this turned out worth asking to me, since I learned some new principles at least...)
APK
P.S.=> Still, see subject - nothing like "hands on" for that as you said... apk
PCIe 3.0 has 126.032 Gbps of bandwidth available on an x16 bus. (Source: Wikipedia)
It only takes 13 of those 10 Gbps connections to fully saturate PCIe 3.0 x16. That's what, $50? Psssh.
Oddly, Google still uses RC4, according to Qualys test. They also still allow SSLv3 and have not yet moved to SHA2 signed certificates.