03-09-2013, 09:03 PM
Hi,
I know that this topic has been discussed a lot and many people have requested atom to add support in oclHashcat-plus for passwords of length greater than 15.
While all that is good, I have not seen any specifics from a cryptography point of view about how does limiting the plaintext length to 15 help in speeding it up?
I read somewhere a post by epixoip where he mentioned that one of the reasons oclHashcat-plus is so fast is because of this limitation. It does not perform all the iterations involved in the algorithm and skips a few.
So, I would like to understand this in more depth.
As an example, I have taken MD5 algorithm.
MD5 operates on blocks of data (each block having a size of 64 bytes or 512 bits). Even if input data is lesser than this size, padding will be done to bring the total length up to 512 bits.
4 Rounds are involved in MD5.
In each Round, 16 operations are involved.
Each operation in each Round is performed on the 32 bit word of the Input Data in sequence like:
Round #1: Operation 1 on the 1st 32 bit word of the Input Data.
Round #1: Operation 2 on the 2nd 32 bit word of the Input Data.
and so on ...
Similarly in the second round and the remaining rounds, Operations are once again performed in sequence on 32 bit words of the Input Data (starting once again from the first 32 bit word of Input Data)
Now, coming to oclHastcat-plus's limitation of 15 character passwords.
15 character password (considering ASCII) would mean an input data size of 15 bytes (120 bits). Please correct me if I am wrong.
So, the remaining 328 bits are padded with (10000....) so that length is 448 bits.
And the last 64 bits are filled with the 64 bit representation of the length of input message (120 bits)
so, essentially we are once again going to operate on 512 bits of data.
Are some operations in each round not calculated to help in speeding up?
Since many of the 32 bit words of the input data would consist of only 0 bits as a result of padding?
Which operations in each round are being ignored to help in speed up?
Please note that I am only trying to understand this from a cryptography point of view and not as a feature request (which has already been put here by others many times).
Any help in understand this would be great. Because to me, it looks like, even if we are restricting the length of the input plain text, the resulting MD5 is being performed on 512 bits (which is greater than the length of input data, plain text password in our case).
I know that this topic has been discussed a lot and many people have requested atom to add support in oclHashcat-plus for passwords of length greater than 15.
While all that is good, I have not seen any specifics from a cryptography point of view about how does limiting the plaintext length to 15 help in speeding it up?
I read somewhere a post by epixoip where he mentioned that one of the reasons oclHashcat-plus is so fast is because of this limitation. It does not perform all the iterations involved in the algorithm and skips a few.
So, I would like to understand this in more depth.
As an example, I have taken MD5 algorithm.
MD5 operates on blocks of data (each block having a size of 64 bytes or 512 bits). Even if input data is lesser than this size, padding will be done to bring the total length up to 512 bits.
4 Rounds are involved in MD5.
In each Round, 16 operations are involved.
Each operation in each Round is performed on the 32 bit word of the Input Data in sequence like:
Round #1: Operation 1 on the 1st 32 bit word of the Input Data.
Round #1: Operation 2 on the 2nd 32 bit word of the Input Data.
and so on ...
Similarly in the second round and the remaining rounds, Operations are once again performed in sequence on 32 bit words of the Input Data (starting once again from the first 32 bit word of Input Data)
Now, coming to oclHastcat-plus's limitation of 15 character passwords.
15 character password (considering ASCII) would mean an input data size of 15 bytes (120 bits). Please correct me if I am wrong.
So, the remaining 328 bits are padded with (10000....) so that length is 448 bits.
And the last 64 bits are filled with the 64 bit representation of the length of input message (120 bits)
so, essentially we are once again going to operate on 512 bits of data.
Are some operations in each round not calculated to help in speeding up?
Since many of the 32 bit words of the input data would consist of only 0 bits as a result of padding?
Which operations in each round are being ignored to help in speed up?
Please note that I am only trying to understand this from a cryptography point of view and not as a feature request (which has already been put here by others many times).
Any help in understand this would be great. Because to me, it looks like, even if we are restricting the length of the input plain text, the resulting MD5 is being performed on 512 bits (which is greater than the length of input data, plain text password in our case).