Bruteforcing 3des support!!

[t3st3r10]

Hi guys

not shure if this is the correct forum for this but i am planning to do something here.. it might be easier then factoring big RSA numbers i don´t know.

here is my ideia

i had a 3des tool for 3des encryption, and this tool had a 3deskey hardcoded on it.

so i used it to encrypt 128bits of data, by simply inputting 128bits data, and encrypting this data with 3des 128bits tool using the hardcoded 128bits 3des encryption key stored on tool.

my main problem is that unfortunatelly i had to format the machine and lost my tool and sources, so now i don´t have the 3des hardcoded key to decrypt the encrypted 128bits data used.

but in return i do have the 128bits encrypted data and the 128bits plain decrypted data.


so i am thinking if its possible to create a bruteforce tool using the 2 seeds 128bits data keys the plain key decrypted, and the 3des encrypted data.

So i would need to use the 3des decryption ECB method.

using as reference the = 128bits plain key to be checked as final result key.

use the 3des encrypted 128bits data as the data input to be decrypted.

then use a bruteforce mechanism 3des decryption ECB using as seeds keys from :

key 3des test decrypt key1= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

so if 3des test key1 decrypt sucessfull and result equals to 128bits plain key, save 3desdecrypt key and finish execution.

if 3des testkey decrypt fail, move on to 2nd key 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 and so on all the way up to last key FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF.

So my question now is this doable

i have made some maths figures and it looks like we have here 6,568408355712891e+18 different possible combinations for a 3DES key

So i am wondering if this is a doable project and whar sort of time could this take to estimate a 3des decrypt key.

[R.D. Silverman]

Originally Posted by t3st3r10

Hi guys

not shure if this is the correct forum for this but i am planning to do something here.. it might be easier then factoring big RSA numbers i don´t know.

Golly. You don't know. So what compels you to post here? Do you
have a strong desire to exhibit ignorance to the world?

Ignorance is curable. Except perhaps for the willful ignorance that you
exhibit. Why don't you try <gasp!> DOING SOME BACKGROUND READING?



You are not sure if this is the correct forum? Can you READ?
What is the name of this forum? Why do you post your off-topic drivel here?

here is my ideia

i had a 3des tool for 3des encryption, and this tool had a 3deskey hardcoded on it.

so i used it to encrypt 128bits of data, by simply inputting 128bits data, and encrypting this data with 3des 128bits tool using the hardcoded 128bits 3des encryption key stored on tool.

my main problem is that unfortunatelly i had to format the machine and lost my tool and sources, so now i don´t have the 3des hardcoded key to decrypt the encrypted 128bits data used.

but in return i do have the 128bits encrypted data and the 128bits plain decrypted data.


so i am thinking if its possible to create a bruteforce tool using the 2 seeds 128bits data keys the plain key decrypted, and the 3des encrypted data.

You are joking right? You don't know if it is possible to create a brute
force tool? Have you ever heard of <gasp!> writing a computer program???

So my question now is this doable

i have made some maths figures and it looks like we have here 6,568408355712891e+18 different possible combinations for a 3DES key

Wrong. Care to try again? Do you even have a clue as to how many bits
are in a 3DES key?? If you don't then WHY DIDN'T YOU LOOK IT UP?
If you did, then WHY CAN'T YOU DO BASIC ARITHMETIC?

So i am wondering if this is a doable project and whar sort of time could this take to estimate a 3des decrypt key.

Can someone really be this stupid as to be unable to estimate the time
needed to brute force a 3DES key??? It is pre-secondary school arithmetic.

[Mini-Geek]

No, it doesn't appear that 3DES (assuming it was implemented right and used keyring option 1 or 2) is practically vulnerable to either a known-plaintext or a brute force attack.

If it were vulnerable to either of these, it would not be a very secure encryption scheme.

Time estimate: way too long.

You'd have better luck trying to recover the key from your formatted hard drive, especially if the data hasn't already been overwritten.

[R.D. Silverman]

Originally Posted by Mini-Geek

No, it doesn't appear that 3DES (assuming it was implemented right and used keyring option 1 or 2) is practically vulnerable to either a known-plaintext or a brute force attack.

If it were vulnerable to either of these, it would not be a very secure encryption scheme.

Nowhere in the original post will you find the word "practical".

[retina]

Originally Posted by t3st3r10

So my question now is this doable

Yes it is.

Originally Posted by t3st3r10

So i am wondering if this is a doable project and wha[t] sort of time could this take to estimate a 3des decrypt key.

Let's see. The time is long. Really long. You just won’t believe how vastly, hugely, mind boggling long it is. I mean you may think it takes a long time to walk down the road to the chemist's, but that is just peanuts compared to how long this will take ...

With apologies to Douglas Adams

[R.D. Silverman]

Originally Posted by retina

Yes it is.Let's see. The time is long. Really long. You just won’t believe how vastly, hugely, mind boggling long it is. I mean you may think it takes a long time to walk down the road to the chemist's, but that is just peanuts compared to how long this will take ...

With apologies to Douglas Adams

Is the OP really so totally stupid that he/she can't estimate how long it will
take?

Hint:

(1) How many possible keys are there?
(2) How long does it take to do one encryption?
(3) DIVIDE!

Is he/she too <blanking> lazy to investigate the answer to (1)?????
Hint: GOOGLE.

If he/she can't estimate (2) is he/she so totally lazy and unmotivated that
he/she can't write code to do it then perform <gasp!> a benchmark????

[jyb]

Originally Posted by R.D. Silverman

Is the OP really so totally stupid that he/she can't estimate how long it will
take?

Hint:

(1) How many possible keys are there?
(2) How long does it take to do one encryption?
(3) DIVIDE! MULTIPLY!

FTFY

[R.D. Silverman]

Originally Posted by jyb

FTFY

Depends whether (2) is expressed as a rate (so many per second) or as
time per encryption.

[VBCurtis]

Originally Posted by R.D. Silverman

Depends whether (2) is expressed as a rate (so many per second) or as
time per encryption.

Well, you phrased it as "how long does it take?". When someone asks me how long it takes to get to my house, I do not reply with "you can do it three times in one hour."

[R.D. Silverman]

Originally Posted by VBCurtis

Well, you phrased it as "how long does it take?". When someone asks me how long it takes to get to my house, I do not reply with "you can do it three times in one hour."

If one reads crypto related publications one will find that speed of
encryption is most commonly expressed in terms of bandwidth, e.g.
GB/sec rather than sec/byte or sec/block. The latter is quite rare.

[jyb]

Originally Posted by R.D. Silverman

If one reads crypto related publications one will find that speed of
encryption is most commonly expressed in terms of bandwidth, e.g.
GB/sec rather than sec/byte or sec/block. The latter is quite rare.

Of course it's rare. Nonetheless, that's how you expressed it. The answer to "How long does it take to do one encryption?" is quite unequivocally an amount of time. Why not just acknowledge the completely inconsequential (though amusing, given the context) mistake, rather than trying to pretend it was somehow correct?