Codebreaking - Taking the First Step? 83
Master Spy asks: "Here's something that the Slashdot community might be able to help with. If you receive a message in code how do you take the first step? Back in the days of WWII it was easier. The codebreakers at Bletchley Park already knew that the messages were encoded using an Enigma machine so all they had to do was work out the positions of the rotors using brain power, the Bombe or later the Colossus machine. American codebreakers also knew the basic details about the methods the Japanese used but now however things are more complicated. Suppose you are listening to a transmission and you receive the following: 'sdjek dYqkP 1Nt$% GGl9) MHrYD +++' How do you know how the message has been encrypted? It could be an Enigma machine, it could have been XOR'd with a second message or a one-time pad or it could use some form of software encryption such as Blowfish or DES. Before you start ripping the message apart for decoding how do codebreakers find out what method has been used to encode the message?"
Medium (Score:4, Insightful)
Ie if were over the net, look at the wrappers.
If over the radio, look at the spectrum.
It's whats around the message that will break the message
Look at it. (Score:5, Insightful)
'sdjek dYqkP 1Nt$% GGl9) MHrYD +++'
this is not going to do you much good, but if you have reams of encoded / encrypted data just stare at it for a while, look at it in a way that you look through it (like those hidden picture things) and after a while you will recognize patterns and have something with which to work.
There is a fine line between the high quality software engineer and mild autism. Ever watch 'Rain Man' or 'A Beautiful Mind' and think - hey that guy would be a BAD ASS developer
Helps to be able to think in 6+ dimensions when you are cracking codes, and a photographic memory helps too.
I should probably post this as an AC - last thing I need is the CIA / NSA figuring out what I am capable of
Re:Look at it. (Score:1)
how (Score:5, Informative)
As to how it's done, that has to do with analysing the text, frequency analysis of 1-grams 2-gram etc. Simple substitution will exhibit one fingerprint (though different languages will obviously be different), something like a playfair or Venegere (sp) square will have another, and DES encypted text a completely different structure. Obviously on a small enaugh sample there may not be enaugh information to latch into...
But with a larger sample, it's mostly a combination of good tools, experience, and guesswork
I dunno... (Score:2)
Re:I dunno... (Score:1)
Re:I dunno... (Score:2)
Nope.
As we discussed above, if the key length is less than the message length there will be some difference between pure noise and your signal.
Yup. But that doesn't matter. Not being random is entirely different from not being random in a manner that we can detect. An encryption algorithm that is *detectably* nonrandom is pretty poor.
I assure you, you cannot tell the difference between, say, DES-encrypted data and random data.
That's pretty much definitionally what a good encryption algorithm is.
Sure, given a computer with infinite resources, any crypto algorithm except one-time pads can be broken. The point is that we don't *have* computers with infinite resources. That's why non-one-time-pad crypto is used.
Re:how (Score:3, Informative)
Additionaly, any ciphertext that was encrypted by a well-designed cipher (and I'll include DES in this example, despite its relatively small keysize by modern standards) will NOT be much harder to decrypt simply because the cipher is unknown. Even if you had LOTS of ciphertext and tried against every known published cipher, along with billions of variants (ie, additional rounds for each one, etc.) the extra workload would be modest to minute, compared to the work of actually searching the keyspace (and in the case where there is no known plaintext, analyzing the de-ciphered text for probable plaintext).
Most modern protocols go well out their way to advertise the ciphers used to encode messages, precisely because that bit of information is of no real extra security as long as the key is kept secret (and is well chosen). To not do so would make deploying things a nightmare.
So I think, in the end, few experts would argue that using the most commonly known good cipher, with a well-chosen key, is any less difficult to 'break' than using an obscure and secret cipher. Especially if that cipher is not one that is also widely deployed as a secure cipher. The real hard work is in finding the key. And the fun work is in finding ad-hoc ciphers that people think are secure because the method is secret.
Re:how (Score:2)
know your tools (Score:2, Insightful)
Re:know your tools (Score:2, Funny)
I've been working years on this message sent to me in 1983.
Please help if you can.
Here is the message with quotes:
'T'
Thanks
I've seen that. (Score:5, Funny)
Yeah, 'sdjek dYqkP 1Nt$% GGl9) MHrYD +++' showed up on my SETI@home screen too.
This is clearly the signature of the Grays from Cygnus Prime. You don't want to communicate with them.
They Grays of Cynus Prime are evil. They will put chips in your head.
They will use the chips to make you do bad things. Like posting to Slashdot.
Re:I've seen that. (Score:2, Funny)
No way man... (Score:1)
Re:I've seen that. (Score:2)
This is clearly the signature of the Grays from Cygnus Prime. You don't want to communicate with them.
How do you know that, did they reset their modems?
Step 1: statistical analysis (Score:2, Informative)
Good luck
Step One: (Score:4, Informative)
When you have less data then a smallish key (and that message has no more then 28 * 8 = 244 bits, probably much less), the data can (most likely) decrypt to anything at all with the proper key. If that's all you really have, then you need to pursue non-code-breaking methods of finding out what that is.
And of course what to do next depends on the characteristics of that more data. A lot of cyptoanalysis assumes you have knowlege of the encryption method; this is because it's "easy" to obtain by reading code, but "easy" is a relative term. It's easier then just guessing, but still hard. Without knowlege of an algorithm, you need to luck out and hope they used one with a distinct signiture. If they didn't, you're probably basically out of luck on a single person's resources, because all of the "good" algorithms should be effectively indistinguishable from noise after encryption.
encryption breaking (Score:3, Funny)
I transmit a polite reply saying, "No, I am NOT interested in being your love monkey no matter how much you lust after me." Gee whiz! The things people say when they think nobody is listening!
Well... it all depends... (Score:3, Informative)
If you think of things mathematically, you're looking to find a plaintext p in the set of all possible plaintexts P and some function f from the set of all ciphertexts to the set of all plaintexts where f(c)=p. These means both f and p are unknown, and while multiple solutions may exist they are likely of "measure zero" in 2 very large spaces. (let's asssume we have a suitable measure for such things, and not worry about the real details.)
To a mathematician, finding a general solution to the above would be a Field's medal winning sort of thing. The reality is that you need more information. If you got a large message you should start checking letter/symbols counts, following by the counts of various character pairings, etc. The goal is often to come up with a statistical model to see if you can build a plausible f. Another thing is to try common functions (xor with various values, etc.) on the stream and see what happens. Sometimes that'll give you a clue. But most of time it involves a little luck, a little intuition and a lot of perseverance.
how to perform cryptanalysis (Score:5, Informative)
2. Learn statistics (and basic number theory). You can discover a lot about a message by its statistical properties.
3. BREAK LOTS OF CODES. Without experience, you are lost. Start by breaking substitution and Caesar ciphers (easy with statistics), then Vigenere/Gronsfeld ciphers (harder but still "crypto for dummies"), then try XOR ciphers (they can be solved easily in an interesting way)... then try to understand how WEP is broken... DeCSS
4. If you become advanced enough, you can start reading papers on cryptanalysis. Many of them are surprisingly easy to understand once you understand number theory. However, it is much more difficult to *discover* some of the stuff these guys come up with, it's pretty amazing.
Anyway, to summarize, understand the statistics involved and PRACTICE until you can just look at a substition cipher and understand what it says... just by the letter frequencies! If you are trying to break a simple code you need lots of ciphertext to analyze.
And don't forget: sometimes you don't need to break a code at all. As a poster above wrote, sometimes context is enough. Sometimes an external clue will give the code away. How do you know what to look for? Experience!
Re:how to perform cryptanalysis (Score:5, Informative)
If you're a math god, start with the Handbook of Applied Cryptography [uwaterloo.ca] by Menezes, van Oorschot, and Vanstone.
If your math isn't quite as godly, start with Thomas Barr's "Invitation to Cryptology". It's an excellent starter book for anyone with even a little bit of mathematical skill. You really don't need much but some high school math, maybe a bit of first-year algebra and stuff, and a willingness to do the chapter problems.
Re:how to perform cryptanalysis (Score:2)
I don't think Schneier's book is the best place to start. It's a fine book, no doubt, but it says very little about real cryptology from a theoretical standpoint, or from the point of view of teaching you to develop or break codes."
Uh, are we all talking about the same "Scneier's Book"? Applied Cryptography is exactly about real cryptology, etc. Are you referring to Secrets and Lies, perhaps?
Re:how to perform cryptanalysis (Score:2)
He gives some insight into the workings of the algorithms, by eg. explaining how the S-Boxes and stuff work. But it doesn't really teach you how to do cryptanalysis. And it doesn't really teach you how to make your own algorithms.
The books I've suggested are less practically-oriented. The Handbook goes into the mathematics of it all quite nicely. It's a good introduction to the field, and those who can get through it will have a very solid background for more advanced study. The Invitation book is aimed at maybe second-year students or first year students with some knowledge of linear algebra. It gives you a taste of what cryptology is like, and starts you off on the right path early in your education.
Additional education required (Score:2)
I am not an expert, but... (Score:1, Redundant)
What you are referring to however is a situation where you don't know the encryption method. This is extra security through obscurity, which we know doesn't work very well. Many encryption schemes are very, very good, and you won't able to attack them easily even with knowledge of what they are. Usually, for example, you need to know a bit of the message, in addition to the cipher to be able to break it. For example, a bunch of emails may start with "From: xxxxx." If you have a lot of emails, encrypted similarly, you may be able to mount a reasonable attack, depending on the method used.
-Sean
Reading Material (Score:4, Informative)
If you are interested, I would suggest that you start by reading The Code Book [simonsingh.net] by Simon Singh [simonsingh.net]. It gives a good overview of the history of the battle between cryptography and cryptanalysis, and how ciphers have evolved to defeat methods of codebreaking. It's an interesting and entertaining read and you might gain some insight on how you would approach this particular cipher.
BTW, I have a truly marvellous solution to your cipher which this textarea is too small to contain.
thoughts on the subject (Score:2, Interesting)
It also helps if you have a basic idea of what's encrypted, ie what kind of plaintext message you're dealing with. A .doc has a different signature than a jpeg or flat ascii or html, etc. some encryption software relies on headers or footers to the encrypted data in order to sanity check for decryption. again, look also at the medium that the message is transmitted through -- tcp/ip traffic to port 443 speaks volumes about what algorithms are being used. transmissions received in the 2.4 Ghz wavelength also speaks volumes about what algorithms you may be dealing with. finally, never trust the developer to do the 'right thing' with algorithmic selection -- look at adobe's algorithm selection for its ebooks. look for a pattern in what you're dealing with. it can't hurt to generate a dictionary of known ciphertext file patterns a la the *nix 'file' command. lacking a certain amount of information about what you're dealing with(message length, source of the ciphertext, etc), though, you're SOL.
anyway, I haven't had to deal with much of the kind of encryption that protects data from a government, mostly just the kind that delays your kid sister, so ymmvg...
Simple (Score:5, Funny)
First you djc,s dk%33R +++ (110), then you sD##N KDL:: Ds03k -332+. From there, it's a trivial matter of just 3!Wop mclDI a002g a!22# with the sklj3 V3iia aq@@1 +1867 -5309.
Duh.
Re:Simple (Score:2, Interesting)
"what does this say?"
qv7qrc77qrrx777qrrrs7777qrrrrg77777qrrrrrbv7bqrbck bqqbvkbqrgkbqhskbqpckbqbqvmr
rcmhhgmjjbgmppyctbqbivayrpga7bbhjbqbxmawhhbqawwqx7 77kbqbrjhrbvaprkatrkhrca
aamwhmwhwhwhwhwhrapkqrmpkqc7bhbhwgawiiqwiqbv
Always starts in the same place (Score:2, Informative)
The folks who cracked the Enigma started the same way. The Polish started the process, sent info to England where it was completed.
A code fragment that short, though, would be darned impossible to crack unless you get more.
But you can already see patterns: word length, multiple "+" characters (maybe an indicator of end-of-phrase or something?).
But that's -- basically -- how you do it. Educated guesses and grunt work (either by you or computer). Unless it's Quantum encryption which is spoiled as soon as you intercept, so you can't decode it.
Check out The Code Book [amazon.com] for some great -- albeit basic -- information about methodology and history.
Re:Always starts in the same place (Score:1)
They just used the monster computers to EMULATE the 12 rotor Enigma's that they did not have, and some other higher level machines.
As far as I know they only had 3 and 4 rotor machines and they used the computer to emulate the bigger, badder Enigma's....
Homeland Security (Score:3, Insightful)
It might sounds silly... (Score:1)
Think about the machines they used to decode messages in WWII... the paterns came from somewhere. I think the same applies today to a degree.
Learn about the traffic. (Score:4, Insightful)
Once you have this information, you'll be much better equipped to figure out what the basic structure underpinning the cipher is. For instance, if the data is part of a realtime encrypted stream, I'd think "stream cipher" and look at RC4 or SEAL. If the data's part of a pen-and-paper arrangement with all values mod 26, I'd think "Solitaire". If the data's a pen-and-paper arrangement meant for communicating between two deep-cover espionage agents, I'd think "one-time pad". If the data's something pulled off a disk drive, I'd think of Matt Blaze's ECB+OFB algorithm. Etc.
What it boils down to is, this question is pretty arbitrary. Very rarely will you have no metainformation about the plaintext. Seek out as much metainformation as you can, and use the metainformation to make educated guesses, cribs, etc.
Code breaking (Score:3, Interesting)
(1) there is always the possibility that you simply won't. In fact, a properly used one time pad cipher is indistinguishable from noise. It's also a major pain in the ass to use, because you must somehow transmit as many bits of key as you want to send bits of message, and your one-time pad is only as good as your method of transmitting the key.
(2) If there is some kind of message in the signal and a cipher is involved other than a one-time pad or something isomorphic to one, then there will be some degree of redundancy in it. This is a theorem of information theory. Statistical measures will eventually reveal that the redundancy exists.
(3) At that point, there are lots of approaches. A good readable and interesting introduction to these, along with the history of such things, is David Kahn's The Codebreakers. [amazon.com] Bruce Schneier's Applied Cryptography [amazon.com] is a good, more technical introduction for the computer geek. I've also heard good things for Handbook of Applied Cryptography [amazon.com] as well, but I don't actually know the book.
But as someone notes above, it's an inherently hard problem to simply identify the cipher, and modern ciphers like RSA are, as far as we know, computationally intractable because the only known attack requires factoring a very large prime number.
(4) You give up and hire a pretty young woman to talk the marine guards into letting you at the code room. (Details of this approach are left as an exercise for the interested reader.) Sometimes the old fashioned ways are best.
I agree with most of that, except.... (Score:1)
> computationally intractable because the only known
> attack requires factoring a very large prime
> number.
I believe you meant to say breaking RSA requires factoring a very large *composite* number.
Re:I agree with most of that, except.... (Score:1)
Re:Code breaking (Score:1)
illuminate me. thanks.
Re:Code breaking (Score:1)
Note though that compressed files often have 'standard' headers or other sections, and that is very vulnerable to attack.
Re:Code breaking (Score:1)
Similarly, an encrypted signal should appear to have very little redundancy, because the closer to "white" it looks, the less statistical information there is to attack.
Your point about the code table is also good. We tend to forget as computer geeks that there is another kind of encryption besides a cipher, which is a good old fashioned code. That is, the construction of an ARBITRARY table of correspondences between some random code group and some desired message. This would be like
(It used to be in Europe that you could tune across the shortwave and find a voice reading five-digit code groups out in German for just hours. I don't know that I ever heard authoritatively what that was, but it's odds-on that it was traffic from the East German stazi or from the Soviets to "moles".)
Obviously, a real code has the possibility of very great compression
If you were to, say, Huffman-compress a message and could transmit the code table separately (and securely) the result would be pretty hard to read directly. (That still wouldn't make a good code, because it would be too easy to use statistical information about letter distribution in English to work backwards.)
You already know what I'm going to tell you (Score:3, Funny)
If you receive a message in code how do you take the first step?
You do what everyone else here does when they come across a problem that may or may not full under the category "News for Nerds. Stuff that Matters": you submit it to Ask Slashdot, of course! Don't worry: they'll print it. They'll print anything and it doesn't even have to be in the form of a question!
GMD
There's no such thing as code-breaking today. (Score:5, Interesting)
Chances are, if you are intercepting an encrypted stream, you are intercepting an unbreakably encrypted stream.
Perhaps you are thinking that if only you knew what protocol the stream is using, you might look online and see if that protocol has been cracked.
Don't waste your time.
The chances are approximately 0 that the stream you are intercepting is using a protocol that has been cracked, or that it is using a keyspace you can brute-force for under a few hundred thousand dollars, or in under a matter of years.
Sorry -- you have a higher chance (almost infinitely higher -- as I said, the chance you will succeed in what you are asking to do is approximately 0) of port-scanning the machine at the source or the destination and 0wning it than you do of breaking the stream.
I don't say this to mean you should give up -- just that you're phrasing your question wrong. Don't discount the 0wning venue of attack.
For every million desktop machines communicating over TCP/IP, only a matter of a few dozen will have 0 exploitable security weaknesses. (However, most security weaknesses are unknown.)
Find out what kind of machine is at the source and the destination, then 0wn one of them. Chances are almost overwhleming that it's possible, if not with a remote exploit, then through social engineering. (Send an attachment that will be opened on either end of the communication, or induce either end to visit a web page in a browser that is exploitable (=, basically, every browser except Lynx).
If they browse with Netscape or Internet Explorer, chances are almost overwhelming that they can be owned.
It's not that hard to get someone to browse to a certain page, if you know anything at all about who that person is.
Back to your original question: gone are the days that protocols were breakable by any hotshot think tank. Today only implementations are, and rarely at the level you're trying to address. Don't break the code -- break into the system.
Hope this helps.
Social engineering solution (Score:5, Funny)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
An old man lived alone in southern Idaho. It was early spring, and he wanted to spade a garden plot to prepare it for planting potatoes. But it was very hard work and he just didn't have the energy.
You see, his only son, who would have helped him, was in prison.
The old man wrote a letter to his son and mentioned his predicament.
A week later, he received a note back, which said, "For heaven's sake, Dad, whatever you do, don't dig up that section of the garden! That's where I buried the GUNS!"
The next morning, bright and early, a dozen police showed up and dug up the entire garden, without finding any guns.
Looking out the kitchen window, the old man thought "Now, what in the world is going on here?" Confused, he wrote another letter to his son telling him what happened, and asked him for advice.
Another week passed and his son's reply arrived in the mailbox. The old man carried the letter up to the house, sat down at the kitchen table and read, "Now plant your potatoes, Dad. It's the best I could do for you under the circumstances."
jdfh8^*&3 fdsh+++ (Score:1, Offtopic)
echo /dev/urandom /dev/ttyS0 (Score:4, Funny)
NO CARRIER
Damn line noise...
Good old memories!
Re:echo /dev/urandom /dev/ttyS0 (Score:2)
Re:echo /dev/urandom /dev/ttyS0 (Score:1)
cat >
or if you're wanting to stay old school...
Re:echo /dev/urandom /dev/ttyS0 (Score:1)
*sigh*
I'm not posting to this again, no matter WHAT! I've already wasted enough bandwidth.
It wasn't easy during WWII (Score:3, Interesting)
I think you're simplifying these first steps too much.
When the UK first intercepted a message like 'sdjek dYqkP 1Nt$% GGl9) MHrYD +++' , they had little idea what it was. Encryption? Only part of a transmission?
It took them months (years?) to work through the encryption system. In the beginning, they didn't even know there was an Enigma machine. They broke the code by brute force: Many people trying many different methods. If the Nazi's changed the key, you had to start all over from the beginning.
It took a long time for the codebreakers to figure out that there even was an Enigma machine, find a machine and figure out how it worked. It took time and effort, people died retreiving the machine.
Once the codebreakers had used Enigma for time, it sometimes became really simple to determine out if a transmission was Enigma (or other encryption) code.
If it wasn't cleartext, it was code. You knew certain things about the code: The key was transmitted first, the key was 6 characters long.
Some code had fingerprints: One guy always transmitted 'HIT#@!', where #@! = 'LER', and so you used "HITLER" to break the rest of the code. Someone else always used a German women's name (Maybe his girlfriend) said "GRE$$!" where $$! = "TTA", so "GRETTA".
So take a step back, if you can't determine the nature of the code you are seeing, it will be very hard to crack.
Re:It wasn't easy during WWII (Score:3, Interesting)
And they didn't break the codes by brute force. They exploited both misuse of the Enigma and flaws in the machine's design. If they had to brute force it, the war would've been long over by the time they were done.
The Code Book, by Simon Singh has more details on Enigma and the code breakers at Bletchley Park.
The point is this: you are much better off getting the information from another source rather than analyzing the data. And, your best chance of cracking a code lies in human error: flawed use of crypto.
Re:It wasn't easy during WWII (Score:2)
But the UK was trying to break German code long before war broke out, before the Pole provided their intelligence. I think it was clear to some within the UK military that war with Germany was inevitable.
But I'll have to read that book by Singh, I keep hearing good review.
You need background .. (Score:1)
* Charachter range (alphanumeric - other)
* Length
* Special charachters found much in the encryption
It needs background, if you have seen the type before, you can distingiush it a bit.
And then there is the context the code is brought in.
Anyway, code breaking is usually used for malcious stuff nowadays I guess.
If it's a good cipher, it's really, really hard (Score:2)
As others have pointed out, the way this is done in practice is by looking at who sent the message to whom and the circumstances around it.
That said, it's worth pointing out that cryptographers take a keen interest in the more academic form of this question, and their defined criterion is that a cipher is only good if it's not feasible to distinguish ciphertext from uniformly distributed random data. Stated slightly more formally: if you can find a way to distinguish ciphertext from random data with probability p > .5 (keeping in mind that guessing at random will make you right half of the time, assuming half of the messages you're presented are ciphertext and half are random) then the cipher is considered broken. This means that even if you can only correctly pick out every one-millionth ciphertext, and you have no clue what that message is, or what key was used, the cipher is still "broken".
Re:If it's a good cipher, it's really, really hard (Score:1)
Re:If it's a good cipher, it's really, really hard (Score:2)
Can you reference this for the rest of us?
I could probably dig something up, but let's see if this doesn't address your confusion first: In my "informal" statement I mentioned that the distinguisher must be "feasible", rather than "possible", but in my "slightly more formal" statement I neglected to make this clear.
it sounds kind of unlikely for information-theoretic reasons
It's impossible for infomation-theoretic reasons. Once you get past the unicity distance, there's always a way to distinguish random data from ciphertext: try decrypting with every possible key and see if one of them gives you recognizable plaintext, right?
However, this brute force attack is infeasible if the keys are sufficiently large and if there are no other weaknesses. A publication of a more efficient algorithm that can distinguish ciphertext from random data with p > .5 would be considered a break.
If this still doesn't make sense, respond and I'll try to dig up some references to papers that have used this concept.
Re:If it's a good cipher, it's really, really hard (Score:1)
Hrmph.. (Score:4, Funny)
sdjek dYqkP 1Nt$% GGl9) MHrYD +++ (Score:5, Funny)
this is obviously perl code
Re:sdjek dYqkP 1Nt$% GGl9) MHrYD +++ (Score:2)
Code broken! (Score:2, Funny)
'I send you this file in order to have your advice'
After many hours of work... I've got it! (Score:2)
translates to
"Enlarge your penis in 5 easy steps!"
How did I get this? I think it's because that's the e-mail I get most nowadays. So it's most likely to be that. QED
For more information... (Score:1)
- RR
Re:For more information... (Score:1)
It's garbage (Score:5, Insightful)
Two things give it away:
The spaces are too regular. You'd be quite hard pressed to form a coherent sentence with any character occuring every 5n character.
So then perhaps the spaces are irrelevant. Then the next questionable aspect is the last three +++'s. Now, if your code didn't atleast work in groups of three, the mathematic likely hood of three +++ occuring would be small.
So then, what would make most sense is some kind of consistant bit manipulation at least in cycles of three characters. Then you double GGs and unique character (%$) make that unlikely too.
So what makes the most sense? Just random typing.
Look at the first set of characters:
sdjek
Just type it a few times... It's quite natural. You might have well used asdf (I bet your typing style isn't perfect... you probably favor your right hand).
If you examine each other character grouping, you'll see that none of them are very hard to reach.
Also, it gets the KIS approval which in most circumstances, is the winning vote.
Are you so sure? (Score:2, Funny)
Re:It's garbage (Score:2)
> The spaces are too regular. You'd be quite hard pressed to form a coherent sentence with any character occuring every 5n character.
Dividing into groups of five characters is a classic technique for simple substitution ciphers - it prevents someone guessing that 'buubdl bu oppo' is 'attack at noon'.
> Then the next questionable aspect is the last three +++'s.
Could mean end of line, end of message, anything. Just because it's unlikely to come up at random doesn't mean that it couldn't have been put there.
Here, here's some practice for you in recognizing 'random' typing vs. ciphertext:
* wked ik sir ewjsk ao e dkso slo rjdic s akkdo
* narfs lrcqy athba qabnk opnuu irbpw enfui xlrip pesji ilouh +++
One of these means something. The other... doesn't.
Re:It's garbage (Score:2)
Impressive.
Cryptosystem identification literature (Score:3, Informative)
How to start. (Score:3, Informative)
- Try to get more text coded with the same cryptosystem (and preferably the same key). Cracking anything based on 25 bytes of ciphertext is going to be hard.
- Look for statistics. Run character-statistics. Do they look like normal text, only with different symbols ? If so you have a monoalphabetic substitution-cipher, crackable in 5 seconds by a computer or 5 minutes by hand. Repeat for digraphs or trigraphs. Any result different from "all combinations equally likely" (or close) gives you a hint.
- Try to xor the text with a copy of itself shifted various places left and rigth. Observe how many nulls you get with various displacements. If you get a jump in nulls for a certain shift, you're likely dealing with a periodic substitution-cipher. Again easily crackable if the period is not too long and you have enough ciphertext. (enough here is something like 20 times the period. So if the period is 50 you'd need a kilobyte of ciphertext to easily attack it, more or less.)
If the text looks completely random under all statistical analysis you can think of, and stays that way even when xored with itself shifted various ways odds are you're dealing with something a bit more serious, and you'll need more expertise than you can gain from a "ask slashdot" article to crack it.Good luck !
Try this... (Score:2)
Code breaking (Score:1)
Anyway, there are a number of ways to go around your problem... The problem is that you need 4 things to decipher the code:
1. Message Format (has the message been split into multiple parts and rearranged?)...
2. Used algorithm (DES etc.).
3. Key length.
4. The language of the message.
If these are not known you have the following option: Aquire a number of PC's and either code breaking software (if you can get hold of it) or write it your self. Using these machines set each of them to try breaking the message using different algorithms. The best software doing this have access to a number of dictionaries inorder to check whether it is on the wrong track. This will take some time regarding on the machines... Have fun!
Try CrypTool (Score:1)
I would start like this:
- Try to compress (zip/gzip) - compressibility is a sign for bad crypto.
- Have a look at the auto-correlation - if you see a comb pattern then it is probably something like XOR, Vigenère, addition mod 256 or similar. CrypTool can break those algorithms automatically.
- Have a look at character frequency, 2-grams, n-grams
- Apply some tests for random data - good crypto should produce data undistinguishable from random data
- If the data looks random you might need some hints on the algorithm.
All the tests suggested can be performed with CrypTool. If the crypto is strong you will need some more insight, but in many practical cases bad crypto is used, e.g. in Psion Word.CodeBrakeing (Score:1)