Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Are there any encryption (decryption?) libraries that take advantage of the Windows GPU API?

share|improve this question
    
I don't think it would be much advantageous - normal stream encryption/decryption is not that much parallelizable, which is the main strength of a GPU. It would help for breaking (brute-forcing) cryptographic algorithms, though. –  Paŭlo Ebermann Nov 5 '11 at 16:18
    
@PaŭloEbermann I'm interested in learning about this brute force parallelization so I can have first hand knowledge / examples to show the business as I argue for stronger encryption. Do you have any pointers? –  makerofthings7 Nov 5 '11 at 16:33
    
I have highlighted the key sentence in @Ninefingers' answer - this could be useful for you. –  Rory Alsop Nov 7 '11 at 10:09
add comment

2 Answers

up vote 7 down vote accepted

As Paulo quite rightly says in the comments, many encryption operations do not lend themselves well to parallelisation. For example, consider the two AES modes ECB and CBC. ECB consists of applying the AES transforms to each data point using various elements of the key schedule according to the position of the data modulo the key schedule length. Essentially, once you've generated the key schedule, you could easily parallelise AES in ECB mode.

Except that ECB is not a great mode of operation security-wise, because for larger amounts of data you begin to reveal patterns in your ciphertext. Wikipedia explains all of this much better than I can.

CBC mode can basically be described as "take the output of the last operation, xor it with the plaintext and encrypt the result". Typically, you start by xor-ing the first plaintext with an IV. For encryption, you must calculate each block at a time and so the operation is not at all suitable for parallelisation; however, for decryption, you can parallelise the process since a pair of blocks are all that are required to decrypt a block (i.e. if you have block 1 and block 2, decrypt block 2 according to its position in the key schedule and xor with block 1).

These are just some examples; some algorithms do lend themselves to parallelisation. Consider you want to try many passwords against some hashed password you have. Each hash calculation is hard to parallelise, since each block must be fed into the hash function by turn; however, what you can do is to do many hash operations at once - imagine setting off a thread for each hash attempt. Graphics processors are good at this kind of work as they're essentially designed to transform whole sets of co-ordinates in 3D space according to a mathematical result - basically, to do 3D graphics.

A good paper on this topic is Cuda compatible Gpu as an efficient hardware accelerator for AES. Bruce Schneier covers speeding up password cracking. Distributed hash cracking tools have also been studied and google turns up a number of implementations.

I expect that as more work is done, more and more methods will be found to take advantage of parallelisation, both in terms of cryptanalysis and in terms of cryptography. I am not a cryptographic researcher, however, so you'll have to take that with a very large dose of wariness.

share|improve this answer
    
Great information and links! Thanks Ninefingers –  makerofthings7 Nov 7 '11 at 14:35
add comment

I've just open-sourced the code that performs AES encryption in ECB and CTR mode and AES decryption for ECB, CBC and CTR mode. The GPU specific code uses Direct3D 10 API (not DirectCompute).

On a GeForce GTS 240 I achieved ~300 MB/sec for CBC decryption with 256 bit key.

You can check out the project page here: http://code.google.com/p/amclibrary/

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.