What encryption algorithms profit most from hardware implementations

[foges]

Don't know if this is the right forum, but the Security forum seemed to be a worse fit.

Anyways, my university is allowing us to design our own ASIC and will have it produced for us. So I'm trying to come up with an idea for what I could make and I was thinking it would be fun to make an ASIC that through brute force tries to find the password to something (ie. one that tries to decrpyt a unix password). The first algorithm that came to mind was AES, but the thing is AES doesn't profit very much from a hardware implementation (maybe a factor of ~3), so I'm looking for suggestions on encryption algorithms that profit more from a hardware implementation?

On a separate note, how would one go about trying to brute force decrypt some sort of a message if one has no idea about the encrypted text. If you assume that the encrypted text is human conversation, then you could look for a certain regularity and number of characters between spaces, but this doesn't seem like an implementable method for any information in general..

Thanks

Disclaimer: this is purely for educational/research purposes.

 

[TuxDave]

I was under the impression that once Intel added AES hardware to the Westmere family of processors that the gains were stupidly good. At least that's what some benchmarks showed.

 

[foges]

Did a quick search and this is what I found http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/

"AES-NI can be used to accelerate the performance of an implementation of AES by 3 to 10x over a completely software implementation."

I've read other places that hardware implementations yield a bit over 3 times speed increase, I'm assuming that the 10 times is under some sort of optimal conditions...

One of the advantages of AES is that it is fast both in hardware and in software implementations (http://tektalkin.blogspot.com/2008/09/types-of-encryption.html). I once read a book on the AES and the competition set up by NIST to chose the successor of the DES and I remember reading that there were other methods more secure than the Rijndael algorithm, but they were all slower (can't remember if this was referring to a hardware or software implementation).

On the other hand, implementing the Viterbi algorithm in hardware rather than software leads to a speed increase in the order of 30 times, I was hoping to find an algorithm that would also give such an increase.

 

[iCyborg]

On a separate note, how would one go about trying to brute force decrypt some sort of a message if one has no idea about the encrypted text. If you assume that the encrypted text is human conversation, then you could look for a certain regularity and number of characters between spaces, but this doesn't seem like an implementable method for any information in general..

Only if it's some kind of a substitution algorithm which can be broken with frequency attacks. Something like AES doesn't work on individual characters and won't leave such easily noticed patterns.

I just checked and there are some theoretical attacks on AES i.e. better than brute force, but not enough for a practical attack, but I doubt you can do much along those lines...

I don't really have any recommendations either.

 

[esun]

Hardware AES is a good idea, as it a Viterbi decoder. Another even better option might be a LDPC decoder or a Turbo decoder, as those are generally more computationally intensive than Viterbi (depending on the properties of the code of course).

 

[uclabachelor]

Don't know if this is the right forum, but the Security forum seemed to be a worse fit.

Anyways, my university is allowing us to design our own ASIC and will have it produced for us. So I'm trying to come up with an idea for what I could make and I was thinking it would be fun to make an ASIC that through brute force tries to find the password to something (ie. one that tries to decrpyt a unix password). The first algorithm that came to mind was AES, but the thing is AES doesn't profit very much from a hardware implementation (maybe a factor of ~3), so I'm looking for suggestions on encryption algorithms that profit more from a hardware implementation?

On a separate note, how would one go about trying to brute force decrypt some sort of a message if one has no idea about the encrypted text. If you assume that the encrypted text is human conversation, then you could look for a certain regularity and number of characters between spaces, but this doesn't seem like an implementable method for any information in general..

Thanks

Disclaimer: this is purely for educational/research purposes.

Probably the one that has the most widespread use. My guess would be AES-256

 

[foges]

Thanks for the replies.

Only if it's some kind of a substitution algorithm which can be broken with frequency attacks. Something like AES doesn't work on individual characters and won't leave such easily noticed patterns.

I just checked and there are some theoretical attacks on AES i.e. better than brute force, but not enough for a practical attack, but I doubt you can do much along those lines...

I don't really have any recommendations either.

I was more referring to how you would spot that you have decoded the text correctly given that you don't know what the decoded text should look like?

 

[iCyborg]

I see, you didn't word it well then. It depends on what it is then, for text files it's a dictionary approach which will work well for a lot of other types too as most have some human readable strings here and there. Or use specific knowledge: audio/video streams have certain headers, executables follow PE/COFF spec etc. Presumably you should know something about the possible format of the message.

 

[foges]

You're right, I wasn't very clear. Thank you for your response, I guess I will have to spend some time thinking about a possible implementation.

 

[Bootleg Betty]

A lot of ciphers are easier in the hardware (DES for example, thanks to permutations - which have no cryptographic purpose and are there probably just to screw with people doing SW implementation) while some are easier in the software (RC4 I think).

About the ASIC, well ... you'd need quite some power. Take a look here: http://www.copacobana.org/ it's a 120 (I think) Spartan 3 machine that can break a 56 bit DES in roughly a day.