How would modern code breaking work? Codes can be so complicated
Author
How would modern code breakers work?
Like I made a text encryption program that converts it into heaps of numbers
for each character it converts it to ascii, then splits it into pieces adding junk numbers to it, while also say the letter "a" is five numbers, later on in the code it may be 12 numbers so theres nothing the same.
How would a code breaker find a pattern when its been so mixed up , with random numbers and lots of junk.
Ofcourse theres a pattern still, otherwise i couldnt decrypt it, but the pattern is way way out there, and when going through the code recently i couldnt remember whats what.
edit:
eg
for the word hello ive got:
4628012460978465790460406587428205987064160490060210687808200354310144
or
2655009371004065510079210478014801387110104568024941049633270651407119
or
3741041320689608300470506445372400465119484574026541026299520688106840
or
4761048060618686400334407831487203005093321787047440810266690114912557
how can u see a pattern in that
[edited by - johnnyBravo on November 13, 2003 12:33:58 AM]
I assume you''re talking about an encryption technique of your own design. Unfortunately, thats about all I could glean from your post. Perhaps I can be of more help if you can more accurately describe what your problem is and what method of encryption you''d used.
As an aside, many of the most secure encryption algorithms are fairly simple at heart. It is the mathmatical theory behind the operations that get complex (be it modulo arthithmetic, elliptical curves, or something else). Additionally, code breakers that aren''t brute force typically analysis the mathmatical structure of the code for weaknesses to be exploited. Google for "differential cryptanalysis" for more information on a popular method of cryptanalysis.
As an aside, many of the most secure encryption algorithms are fairly simple at heart. It is the mathmatical theory behind the operations that get complex (be it modulo arthithmetic, elliptical curves, or something else). Additionally, code breakers that aren''t brute force typically analysis the mathmatical structure of the code for weaknesses to be exploited. Google for "differential cryptanalysis" for more information on a popular method of cryptanalysis.
Author
my question is how would someone make a program to break codes?
even if they are using super computers or whatever. I think its easier to create codes than break them.
All you have to do is throw in a few things to scramble things up.
even if they are using super computers or whatever. I think its easier to create codes than break them.
All you have to do is throw in a few things to scramble things up.
What you suggests seems to be some kind of "security through obscurity" approach. A good encryption algorithm encrypts messages in such a way that only the proper key or a brute-force method can decrypt it (at a tremedous cost in computation time), even if you know exactly how the algorithm works. The popular RSA algorithm uses the fact that there is no efficient way to divide a large prime number into factors. The algorithm is very simple, but when something has been encrypted with it you either need the key or an array of supercomputers for a long time.
Would anyone be able to figure out any encrypted message once they knew how your algorithm worked? I think so, based on what you have posted so far.
Would anyone be able to figure out any encrypted message once they knew how your algorithm worked? I think so, based on what you have posted so far.
As Grul said, ''security through obscurity is not security at all''. When designing a security algorithm, you have to pretend everybody in the world knows the algorithm, because if you give them your program (or they take it), they do. If an algorithm is secure, it won''t matter if they have it or not, because it won''t let them decode the crypted text without the proper keys. Some algorithms leave lots of patterns, like just xoring text with a key, that can be analized statistically and then undone. Others, like RSA, do not leave many patterns. One of the most important roles of an encryption algorithm is to destroy any patterns that could be used to reverse engineer the plaintext from the crypted text.
Meant to post this last night but the forums were acting up. I've since been beaten to the punch, but here it is anyway:
While it is simple to create a code, its actually quite difficult to produce a "secure" code, where secure means there are no short cuts to finding the key.
A brief overview of how a code works:
Given code algorithm A(P,K), where inputs are plaintext P and key K, A(P, K) = C, where C is the resulting ciphertext.
For a very simple example, consider the classic substitution cipher, where input is a string of characters from A to Z, and the key is an array of A to Z called K(A..Z), where A <= K(i) <= Z for all values of i, and all values of K(i) are unique. The algorithm says to create our Ciphertext C, C(i) = K(P(I)).
Example:
Plaintext: HELLO
Key: K(A) = L,... K(E) = O, ... K(H) = J, .. K(L) = M, ... K(O) = Y, ... (most key values except those relevant to problem omitted).
Ciphertext: C(0) = K(P(0))=K(H)=J, C(1)=K(E)=O, etc...
Our final ciphertext is then C = JOMMY.
Cryptanalysis of this code is quite straightforward. Because only the symbols have changed, we can look at the frequency of letters in the ciphertext and make inferences about the plaintext. For instance, in English, 'e' is the most common letter, so the letter that appears most often in the ciphertext is likely to be the letter 'e', and so forth. Notice this requires a fairly large sample of ciphertext (100+ characters) so that the frequencies have meaning.
Note the above technique assumes we don't have a known plaintext and ciphertext pair (i.e. we only know C, not P and its resulting C). If we did, it would be trivial to construct the key, just by comparing characters in the two and seeing which characters mapped to which!
This is a very basic example, and cryptanalysis of codes is a very complex topic. It boils down to a lot of tricky math. In many cases, especially with modern codes developed by cryptography experts, no convincing flaws have been found in their algorithms; HOWEVER, this does not necessarily mean they are safe.
Most all widly used algorithms are based on mathematical problems that are infeasible to solve in any way other than brute force. For instance, the well known RSA algorithm relies on the difficulty of factoring huge numbers. While time has proven the best test of the algorithm's security, if someone were to come up with a way to factor large primes quickly (i.e. without using brute force), then RSA would be rendered useless.
I guess in conclusion it may be easy to come up with encryption algorithms, but proving its security is an impossible task. Proving how to break a given algorithm is a difficult task as well, but if an algorithm is fatally flawed, the common belief is that such a flaw will be found if the algorithm is open to public scrutiny.
So tell us your algorithm and we may be able to tell you how to break it.
Edit: Took out ezCode info so post would display properly.
[edited by - gibson on November 14, 2003 4:27:24 PM]
While it is simple to create a code, its actually quite difficult to produce a "secure" code, where secure means there are no short cuts to finding the key.
A brief overview of how a code works:
Given code algorithm A(P,K), where inputs are plaintext P and key K, A(P, K) = C, where C is the resulting ciphertext.
For a very simple example, consider the classic substitution cipher, where input is a string of characters from A to Z, and the key is an array of A to Z called K(A..Z), where A <= K(i) <= Z for all values of i, and all values of K(i) are unique. The algorithm says to create our Ciphertext C, C(i) = K(P(I)).
Example:
Plaintext: HELLO
Key: K(A) = L,... K(E) = O, ... K(H) = J, .. K(L) = M, ... K(O) = Y, ... (most key values except those relevant to problem omitted).
Ciphertext: C(0) = K(P(0))=K(H)=J, C(1)=K(E)=O, etc...
Our final ciphertext is then C = JOMMY.
Cryptanalysis of this code is quite straightforward. Because only the symbols have changed, we can look at the frequency of letters in the ciphertext and make inferences about the plaintext. For instance, in English, 'e' is the most common letter, so the letter that appears most often in the ciphertext is likely to be the letter 'e', and so forth. Notice this requires a fairly large sample of ciphertext (100+ characters) so that the frequencies have meaning.
Note the above technique assumes we don't have a known plaintext and ciphertext pair (i.e. we only know C, not P and its resulting C). If we did, it would be trivial to construct the key, just by comparing characters in the two and seeing which characters mapped to which!
This is a very basic example, and cryptanalysis of codes is a very complex topic. It boils down to a lot of tricky math. In many cases, especially with modern codes developed by cryptography experts, no convincing flaws have been found in their algorithms; HOWEVER, this does not necessarily mean they are safe.
Most all widly used algorithms are based on mathematical problems that are infeasible to solve in any way other than brute force. For instance, the well known RSA algorithm relies on the difficulty of factoring huge numbers. While time has proven the best test of the algorithm's security, if someone were to come up with a way to factor large primes quickly (i.e. without using brute force), then RSA would be rendered useless.
I guess in conclusion it may be easy to come up with encryption algorithms, but proving its security is an impossible task. Proving how to break a given algorithm is a difficult task as well, but if an algorithm is fatally flawed, the common belief is that such a flaw will be found if the algorithm is open to public scrutiny.
So tell us your algorithm and we may be able to tell you how to break it.
Edit: Took out ezCode info so post would display properly.
[edited by - gibson on November 14, 2003 4:27:24 PM]
and something to really piss someone trying to decript stuff, have it an evolving code. (WWII german code was evolving, as in first time A may have been z, but the next A was q or something)
If you really want to mess people up trying to decode your stuff, look up the averages of a character in written language, (Like E or something is most common letter in English) and you have the more common ones go on a rotating output, *each time they come put its a different thing for the same character* and have the really uncommon ones all poping up as something similar, so your uncommon becomes the common, and your common become uncommon, and people thing your code base is so much simpler and try to decrypt it as uncommon being common letters.
Now, first place prize goes to someone that can retype what I mean in an understandable fashion!
*Prizes from me have no physical or montary value*
If you really want to mess people up trying to decode your stuff, look up the averages of a character in written language, (Like E or something is most common letter in English) and you have the more common ones go on a rotating output, *each time they come put its a different thing for the same character* and have the really uncommon ones all poping up as something similar, so your uncommon becomes the common, and your common become uncommon, and people thing your code base is so much simpler and try to decrypt it as uncommon being common letters.
Now, first place prize goes to someone that can retype what I mean in an understandable fashion!
*Prizes from me have no physical or montary value*
Most ciphers these days are not one-to-one.. that is, the letter E does not get encrypted the same way each time. The ''key'' (or some other factor) used to encode changes as the data is run through the cryptosystem.
In other words, there is no token frequency in a modern cryptography algorithm. Every part of the output should look random.
Will
In other words, there is no token frequency in a modern cryptography algorithm. Every part of the output should look random.
Will
Author
quote:Original post by Talroth
If you really want to mess people up trying to decode your stuff, look up the averages of a character in written language, (Like E or something is most common letter in English) and you have the more common ones go on a rotating output, *each time they come put its a different thing for the same character* and have the really uncommon ones all poping up as something similar, so your uncommon becomes the common, and your common become uncommon, and people thing your code base is so much simpler and try to decrypt it as uncommon being common letters.
thats a very interesting idea, that would screw with people completely
Author
quote:Original post by gibson
So tell us your algorithm and we may be able to tell you how to break it.
oh i dont know...just kidding
this is how i actually made the decoder for it, by going thru each step.
its in vb
Dim i As Integer, counter As IntegerDim theDecode As StringDim theCode As StringDim aa As String, bb As Integer, cc As String, dd As Long, qq As String, ee As IntegerDim tt As String, yy As IntegertheCode = ""For i = 1 To Len(TInput.Text) aa = Mid(TInput.Text, i, 1) bb = Asc(aa) + i *5 yy = (Int(Rnd * bb \ 2) + Int(bb / 2)) ' + (Int(Rnd * 6)) * 10 tt = Format(yy, "000") rr = bb - tt theCode = theCode & Format(Int(Rnd * 9999), "0000") & CStr(Format(rr, "000")) & Format(Int(Rnd * 99), "00") & tt & Format(Int(Rnd * 99), "00")Next itheCode is the string that contains the so far code...
edit:
forgot declartion types
if u get it, tell me what this says...
7754019780588313690528505939800604170082609709020761089543500477408914203501267050884015000241229440910173713436251604905110982406013391452586450490110617928902254070629478049520748678330424006928
[edited by - johnnyBravo on November 15, 2003 3:52:34 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
