Cracking Triple Des

Welcome to Crypto. We hope you enjoy your visit.

You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free.

Join our community!

If you're already a member please log in to your account to access all of our features:

Cracking Triple Des
Topic Started: Oct 24 2005, 01:43 PM (312 Views)
Colly	Oct 24 2005, 01:43 PM Post #1
Unregistered	Does anyone know an easy way to crack triple des, providing you know a bit of the key. I was thinking I could crack the rest of the key using a brute force algorithm written in Java but how would I know when I have choosen the correct key to decrypt the ciphertext?
Unregistered


rot13	Oct 24 2005, 02:29 PM Post #2
Elite member Posts: 306 Group: Trusted Member Member #14 Joined: September 29, 2005	Colly Oct 24 2005, 01:43 PM Does anyone know an easy way to crack triple des, providing you know a bit of the key. I was thinking I could crack the rest of the key using a brute force algorithm written in Java but how would I know when I have choosen the correct key to decrypt the ciphertext? Do you have any idea what kind of format the original text was in? If it is ASCII text, for example, a simple test would be to make sure that the upper bit in each byte is 0. If you think it is some kind of text document but may contain bytes with the upper bit set (non-English letters, for example), you might try an Index of Coincidence test.



Donald	Oct 24 2005, 02:41 PM Post #3
Elite member Posts: 454 Group: Trusted Member Member #8 Joined: September 2, 2005	"colly" providing you know a bit of the key Before we get into how to recognize a correct decryption. How much of the key do you know? Is this an English Passphrase of 2 words and you figure you have the first one? (that would be pretty easy) Is it 3 or 4 words long and you still only have one. (Now it's getting difficult). Do you suspect they used mixed case? Is the passphrase likely to have misspelings, random characters, or numbers? Now brute forcing the passphrase, even if you have a nice hunk of it, starts to look very very unlikely. OR, are we not dealing with the pass phrase to be hashed? Do you actually have a few bytes of the actual key? Then we can easily calculate how practical a brute force attack would be. But unless you have a signifigant portion of the key, it's probably not a reasonable attack. Donald



Guest	Oct 24 2005, 03:41 PM Post #4
Unregistered	Colly Oct 24 2005, 01:43 PM Do you have any idea what kind of format the original text was in? No I have no idea. Quote: How much of the key do you know? I know that the key generator is weak and it produces keys which all follow a similar pattern. It looks like it would be quite easy to break using brute force. The problem with breaking it with brute force using Java is that how will I know what to ignore: For example: I can continuesly change the key but if I do this a million times then how will I know which output to actually look at? I have calculated the key lenght to be 120 bits, could that be correct? Actually I have just worked out that I will only have to try 65536 possibilities so it's easily possible, it's just a case of not having to look at the incorrect outputs, so how can I filter out the results when I try the wrong key?
Unregistered


insecure	Oct 24 2005, 08:43 PM Post #5
Elite member Posts: 381 Group: Trusted Member Member #10 Joined: September 9, 2005	"How will I know when I've finished?" is the perennial cry of the cryptanalyst. Even in those most rare of circumstances where the plaintext is straight ASCII and in English, it's hard enough. When the data is arbitrary binary "junk", it can be a lot harder, although there are certain binary formats which are easy enough to detect. If you know your plaintext is straight ASCII English text, I suggest you adopt a two-pronged approach - first, check that the first few bytes all have the top bit clear, as rot13 suggested. If they have, do a full decrypt for that key, and spell-check the result. (A spell-checking function is fairly trivial to write.) If the spell-check gives a result of, say, 35% or better, then you'd want to have a long hard look at that decrypt, wouldn't you? If your plaintext is a zip file, say, then you would do well to look for a start pattern of 504B (hex) at the start of the file - PK in ASCII. In fact, I looked at three zip files, and they all started with the byte sequence 504B03040A0000000000 - and only at that point did they start to diverge. The few JPEGs I looked at all started with FFD8FF and then continued with either E0 or E1. I do not claim this to be an exhaustive analysis. There are infinitely many formats. You have to have a rough idea of what you're looking for if you're going to stand any hope of finding it.



rot13	Oct 24 2005, 09:01 PM Post #6
Elite member Posts: 306 Group: Trusted Member Member #14 Joined: September 29, 2005	insecure Oct 24 2005, 08:43 PM If you know your plaintext is straight ASCII English text, I suggest you adopt a two-pronged approach - first, check that the first few bytes all have the top bit clear, as rot13 suggested. If they have, do a full decrypt for that key, and spell-check the result. (A spell-checking function is fairly trivial to write.) If the spell-check gives a result of, say, 35% or better, then you'd want to have a long hard look at that decrypt, wouldn't you? Instead of a spell-check, you might just do something like counting the number of vowels found vs. the number of alphabetic characters, and if it comes out to roughly 40% instead the expected ~19% (5/26), that's a good sign. Another thing would be to see if the letters in SENORITA occur about 60% of the time instead of the expected ~30% (8/26). Digital ciphers are kinda funny. If you're working with ASCII text, it's kinda hard to have a complete text with the high bit cleared and NOT have the correct key. You might have a block or two correct, but because of the way the bits get spread around, it usually messes up other blocks.



insecure	Oct 24 2005, 09:36 PM Post #7
Elite member Posts: 381 Group: Trusted Member Member #10 Joined: September 9, 2005	You're quite right, especially wrt DES and its variants, and other block ciphers in general, about high bits. But Unicode is becoming more prevalent, which is going to limit the usefulness of that rule of thumb in due course. I can see vowel counts giving problems with transposition ciphers. On the other hand, spell-checking kinda relies on spaces not being removed, doesn't it? No one method is going to guarantee success. The professional cryppies seem to have the attitude that "if it looks like a duck, quacks like a duck, and smells like a duck, then it's probably a duck", which I take to mean that if it starts PK it's probably a zip file. If it starts %PDF, it's probably a non-portable document format such as PDF. If it starts with .PNG it's probably a PNG file. If it has high bits clear throughout, it's probably ASCII text. And any other test you can think of. And if your test suite is sufficiently broad, and it fails all tests, it's probably junk. Indeed, if a frequency analysis looks pretty flat, the chances are good that it's junk. And that may be the best test of all.



Donald	Oct 24 2005, 09:46 PM Post #8
Elite member Posts: 454 Group: Trusted Member Member #8 Joined: September 2, 2005	"insecure" Indeed, if a frequency analysis looks pretty flat, the chances are good that it's junk. And that may be the best test of all Once again, insecure beats me to the punch. I was just about to post that with only 65536 possibilites, my first try would be to take a frequency count for each result and then look at the ones that diverge furthest from flat first, and work my way down. This should detect any kind of text or executables. It may have problems with compressed data. Zips, gifs, jpgs, mp3's etc should all look pretty flat. So if the frequency scan doesn't give you anything significant, start looking at header information. The below is NOT an optimal solution! You are using Java. Try reading in the files in various formats. Trap any errors and record each entry that doesn't give you an error. You should be able to read zips, gifs, and jpegs at least. I imagine support for mp3 and various other compressed formats should be out there for java somewhere. Donald



1 user reading this topic (1 Guest and 0 Anonymous)


« Previous Topic · General · Next Topic »