Archived

This topic is now archived and is closed to further replies.

johnnyBravo

How would modern code breaking work? Codes can be so complicated

Recommended Posts

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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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*

Share this post


Link to post
Share on other sites
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


Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 Integer
Dim theDecode As String
Dim theCode As String
Dim aa As String, bb As Integer, cc As String, dd As Long, qq As String, ee As Integer
Dim tt As String, yy As Integer

theCode = ""
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 i


theCode 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]

Share this post


Link to post
Share on other sites
Your code cannot be reversed, either by a malicious hacker or by its intended recipient.

The reason for this is the following code:

yy = (Int(Rnd *bb\2)+Int(bb/2))
tt = Format(yy, "000")
rr = bb - tt

Every other step you perform is reversible. However, by using Rnd, you will get a different output each time the algorithm is run, even if the inputs are identical. Thus without knowing the random seed, someone else cannot go from code to plaintext reliably.

Also, your obfuscation at the end is cryptographically insignificant (i.e. because of the way it is formatted, I know that characters 5, 6, 7, 15, 16, 17, 25, 26, 27 and so on are part of the code and everything else is just random garbage, so I just examine characters (i, i+1, i+2) for all i such that i = 10*k + 5 and i < Len(input) for k=0, 1, 2, ... and ignore everything else.

[edited by - gibson on November 15, 2003 2:40:23 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by gibson
Your code cannot be reversed, either by a malicious hacker or by its intended recipient.



well this code decrypts it

theCode = TDecode.Text
theDecode = ""
i = 1
counter = 0

Do While i < Len(theCode)
counter = counter + 1
cc = Mid(theCode, i + 4, 3)
dd = Val(cc) - counter
ee = dd + Mid(theCode, 9 + i, 3)
qq = Chr(ee)
theDecode = theDecode + qq
i = i + 3 + 2 + 4 + 2 + 1 + 2
Loop
TInput.Text = theDecode



or are you trying to say something else...sorry if you are...


[edited by - johnnyBravo on November 16, 2003 8:41:55 AM]

Share this post


Link to post
Share on other sites
Confusion over code breaking is because you''re forgetting the different kinds of codes

public key: super computers trying to factor the number. (hard)

One Time Pad: uhhh.. act of god.

secret key or algorithm: frequency analysis, and other things.

Share this post


Link to post
Share on other sites
I would have found these facts interesting back when i was first studying this.

First the RC4 algo its essentially (not mine. ripped. and not copyrighted)

while (length--) {
x++; sx = state[x]; y += sx;
sy = state[y]; state[y] = sx; state[x] = sy;
*data++ ^= state[(sx+sy)&0xFF];
}


Youll note most things modern dont actually exchange letters to numbers persay. They xor the byte for the letter by something "secret" then give the stream of bytes out as encrypted. The above is essentially the way your browswer xors things when it needs to encrypt data for transfer. Its not too complicated. You can cook book some simplier home made versions pretty easy.


And then theres "well what should i xor my letters by thats secret" Thats where keys come in.

And the most common algo for that is:
quote:

RSA is the name of the most prevalent public/private key algorithm. It is also the name of the company (RSA Security) that originally held the patent rights to this system. It was invented in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman.
Details: In order to generate the keys:

First, some random data is generated. Most of the successful attacks against RSA implementations have been against this step.
Two large primes are randomly chosen. This can be a time consuming step as the computer randomly generates numbers and tests to see if they are prime. These two numbers are traditionally called p and q.
The two numbers are multiplied together, n = pq. We will be publishing n as part of the public-key. The security of RSA lies in the fact that it is computationally too difficult to factor n back into p and q. (However, somebody may in the future discover a way to easily factor large numbers, in which case all of today''s cryptography will be rendered useless in one fell swoop).
A number e is chosen, where e is less than n and "relatively prime" (no common factors) to (p-1)(q-1). The public-key will consist of the pair (n,e).
A number d is chosen, where (ed-1) is divisible by (p-1)(q-1). The private-key consists of the pair (n,d). Usually, the original prime numbers p and q are discarded after this step.
The numbers n, e, and d are of interest because they serve as fields within digital certificates.
Details: In order to encrypt/decrypt something using RSA, the following algorithm is used.

Start with the original message called m. Note that in reality, we''ve already encrypted the real message with a randomly generated symmetric key, and we really are just encrypting this key to send along with the encrypted message. Public-key cryptography is generally used for key-exchange because it is too slow for general-purpose encryption. Therefore, m is really just a small 128-bit key rather than the entire message.
Create the ciphertext c using the equation c = me mod n, where (n,e) are the public-key.
Send the ciphertext message c.
Upon reception, use the equation m = cd mod n, where (n,d) is the private-key and m is the decrypted message. (Again, this is usually just the symmetric key that we will use to decrypt the actual message).



Now thats a bit harder. But still prolly the simpliest explanation ive ever seen.

Now that were on the same page. The question might be: ok lets say i use public key/private key then i shake it up with my own special blend of pure chaos how would anyone figure it out?

Its a good question but i suspect pattern matching would eventually crack it and reduce it to a key problem depending on what you were hiding.

NOTE:
the quotes are from:
http://www.robertgraham.com/pubs/hacking-dict.html
(dont worry mods its not a thinly vieled site designed to show you how to run scripts. Its legit.)



Share this post


Link to post
Share on other sites