Posts: 4
	Threads: 1
	Joined: Feb 2017
	
	
 
	
		
		
		02-10-2017, 11:44 AM 
(This post was last modified: 02-10-2017, 11:44 AM by decoding2017.)
		
	 
	
		I am a noob at des/3des.
I know that finding a des key for a random plaintext(hex):encrypted(hex) pair is 1/2^8 (64-56) chance, but is there any chance of having 2 keys in the same keyspace?
(like des(0x00, 0x88888888)=des(0x00,0x69696969)
Or is it certain that the key is unique?
	
	
	
	
	
 
 
	
	
	
		
	Posts: 5,232
	Threads: 233
	Joined: Apr 2010
	
	
 
	
	
		Do you mean having 2 different keys that produce the same CT out of the same PT? Sure, that's possible: 
https://twitter.com/hashcat/status/775345537210019841
	 
 
	
	
	
		
	Posts: 4
	Threads: 1
	Joined: Feb 2017
	
	
 
	
	
		That's 3des, not des... And how the heck did you do that in 85hrs?
That's what i was trying to accomplish... but with a 32-byte key not 48 (K1 K2 K1)
	
	
	
	
	
 
 
	
	
	
		
	Posts: 5,232
	Threads: 233
	Joined: Apr 2010
	
	
 
	
	
		Yeah right, it's 3DES, but the same would occur to DES, just with less "collisions". I just used that example because it was the only one I had. I was able to increase the speed of the BF because I could reverse the last DES transform in the 3des algorithm but that requires some kernel hack.
	
	
	
	
	
 
 
	
	
	
		
	Posts: 4
	Threads: 1
	Joined: Feb 2017
	
	
 
	
	
		so if i want all the occurences, i should have to exhaust the entire keyspace, not break at first occurrence.
Just out of curiosity, i was going to generate all the enc(plain, key1):dec(hash,key1) in several files, and des crack all those occurrences. (and i got 12.5 lifetimes)
How much time would it take to run all those 72.057.594.037.927.936 key pairs by your special kernel hack?
Also, additional question: best hardware for des/3des? CPU or GPU?
	
	
	
	
	
 
 
	
	
	
		
	Posts: 5,232
	Threads: 233
	Joined: Apr 2010
	
	
 
	
	
		Yes, you need to go through all of it, and that's your problem because you can't search a 2^112 bit keyspace no matter how fast the kernel is