RE: Finding encrytion algorithm
hi, I get the idea,thanx. Regards Data. can u pls explain how they have statistical signatures,pls- may be using SPN's, i have tried ANSI X9.17 key generation with GOST-it did have a negligably small skew-it makes me wonder what statistical signature they have.The negligable skew is a weakness but not high enough to compramise the security of the key used from the ANSI x9.17 key gen method. pls explain. thank u veru much. You're on the right track. Take several encryption algorithms of your choice, then use a fixed IV, and the same sets of keys, and encrypt blocks of 0's. For each algorithm, compute several sets of staticstics (a la NIST or DIEHARD). With 100 blocks of 10 Megabytes (100 different keys) you should see some interesting differences. Remember, your question originally was how can you tell which algorithm, not how do you find the key. Let us know what you find out :-) --yes :) Patience, persistence, truth, Dr. mike __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: Finding encrytion algorithm
Perhaps a simpler example. Let's look at a 'fair' coin and what that means in the real world. A normal coin (or any nDx for that matter [1]) for short sequences is random. In other words if you record a game sequence and then replay the game the die sequence won't have any statistical correlation. Knowing what happened last time won't help you this time, the 'window of opportunity' with respect to statistical bias isn't large enough, so the game is 'fair'. But!, if you throw that coin once a second for a billion years you will find that -no- coin is really -fair-. This goes back to k-sequences and Knuth. Go back and then start throwing it again, and if your sequence is long enough you can use this known bias from the first experiment to increase your percentage of 'hits' in the second sequence. In other words you can now prove experimentaly the coin isn't fair and what that bias is. This is related to 'Hypothesis Testing'. It's rather strange, but I happen to be rereading a book, The Mathematical Sciences: A Collection of Essays (LoC# 69-12750) put out by some group called COSRIMS in about 1969. I remember the book because somebody gave it to me (I was about 9 or 10 at the time) to read, and it has an insane bright yellow cover. I recently came across it again in a used bookstore for $10 so I bought it. It's basically a bunch of chapters on various issues of math research with the intent of focusing high school and undergrads to pursue mathematical careers by giving examples of what you might be working on. The chapter Statistical Inference (by J. Kiefer) uses an example of a coin and a 3-run sequence to determine the actual bias of the coin (the example is very simple, the coin is very biased). You should be able to still find the book in public libraries and college libraries. I'm sure more modern texts on hypothesis testing will be just as relevant. The vast majority of RNG's that we use are really PRNG's, we just don't collect enough data on them to be able to demonstrate that. Or the sequence of interest is so short we dont' care. [1] A coin is a 1D2, two coins would be 2D2, for example. Who said wargaming was worthless ;) On Sat, 13 Jul 2002, Mike Rosing wrote: On Sat, 13 Jul 2002, gfgs pedo wrote: can u pls explain how they have statistical signatures,pls- may be using SPN's, i have tried ANSI X9.17 key generation with GOST-it did have a negligably small skew-it makes me wonder what statistical signature they have.The negligable skew is a weakness but not high enough to compramise the security of the key used from the ANSI x9.17 key gen method. pls explain. thank u veru much. You're on the right track. Take several encryption algorithms of your choice, then use a fixed IV, and the same sets of keys, and encrypt blocks of 0's. For each algorithm, compute several sets of staticstics (a la NIST or DIEHARD). With 100 blocks of 10 Megabytes (100 different keys) you should see some interesting differences. Remember, your question originally was how can you tell which algorithm, not how do you find the key. Let us know what you find out :-) Patience, persistence, truth, Dr. mike -- When I die, I would like to be born again as me. Hugh Hefner [EMAIL PROTECTED] www.ssz.com [EMAIL PROTECTED] www.open-forge.org
Re: Finding encrytion algorithm
A RNG is a character or string generator whose generation algorithm prevents prediction of the next output if one knows all the previous outputs and the algorithm. In other words if you know everything there is to know about the generator your odds of predicting the next output state are even - pure luck - 'Fair'. A PRNG is one that fails the RNG test. Read Knuth, you should also check out, Exploring Randomness G.J. Chaitin ISBN 1-85233-417-7 Has some interesting insite on randomness, some of his propositions are not exactly same old same old. Interesting read. On Sat, 13 Jul 2002, gfgs pedo wrote: hi, eer..I think we need a defenition of an Rng Prng that every 1 should agree on. would this help? RNG PRNG 1:A RNG has an infinite period where as a PRNG has a defenite period after which the sequence will repeat. Atmospheric noise,Radiation decay are examples of RNG's.(Difference) 2:An RNG PRNG should pass a series of radomness tests. (Similarity) 3:For the same set of input parameters,a RNG always give a different output. A PRNG always gives the same set of outputs for the same input parameters (Difference) would any 1 also like 2 review http://www.ircsuper.net/~neo/prng.html thanx. Regards Data. -- When I die, I would like to be born again as me. Hugh Hefner [EMAIL PROTECTED] www.ssz.com [EMAIL PROTECTED] www.open-forge.org
Re: Finding encrytion algorithm
hi, thanx Mr Jim. Data. __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: Finding encrytion algorithm
On Thu, 11 Jul 2002, gfgs pedo wrote: suppose a cryptanalysis only has encrypted data-how is going 2 know which is the encrytion algorithm used 2 encrypt the data ,so that he can effeciently cryptanalyse if 1:he has large amount of cipher text only 2:has large amount of plain text and corresponding cipher text. There r so many encryption algorithms,how does he know which algorithm was used? Depends on how they got the source. They may know it's one of 5 possible choices because of the person who sent (or received) it. If it's just found on a disk in a garbage dump with no connections to anyone, it's a bit tougher. But every algorithm has some statistical signature and if you've got enough cipher text you can compare that signature with known algorithms to home in on fewer choices. I'm not sure having the plaintext helps much more, but you could use random keys to create several ciphertexts with known algorithms and compare the statistics just to see if they compare better. It's definitly challenging :-) Patience, persistence, truth, Dr. mike
Re: Finding encrytion algorithm
* Mike Rosing [EMAIL PROTECTED] [020711]: Depends on how they got the source. They may know it's one of 5 possible choices because of the person who sent (or received) it. If it's just found on a disk in a garbage dump with no connections to anyone, it's a bit tougher. But every algorithm has some statistical signature and if you've got enough cipher text you can compare that signature with known algorithms to home in on fewer choices. Do you have any references for this? A quick google search was less than revealing. Thanks in advance. Patience, persistence, truth, Dr. mike -- All that is not strictly forbidden is now mandatory.
Re: Finding encrytion algorithm
Mike Rosing wrote: On Thu, 11 Jul 2002, gfgs pedo wrote: suppose a cryptanalysis only has encrypted data-how is going 2 know which is the encrytion algorithm used 2 encrypt the data ,so that he can effeciently cryptanalyse if 1:he has large amount of cipher text only 2:has large amount of plain text and corresponding cipher text. There r so many encryption algorithms,how does he know which algorithm was used? Depends on how they got the source. They may know it's one of 5 possible choices because of the person who sent (or received) it. It may not matter much. Suppose it could be one of a hundred algorithms, a dozen of which you know how to break. If it is important and you have the resources, you just try all twelve breaks. If one works, then you know the algorithm. If not, you don't care; you know it's one you cannot break, so details are not important. Doing this is only at worst 12 times harder than breaking a single known cipher. If some of your 12 breaks are easy, then total effort is much less than 12 times the hardest cipher. When we're talking about 2^40 steps to break a laughably weak cipher and 2^100 for a good one, making it 12, or 1000, times harder is not a very interesting difference. If it's just found on a disk in a garbage dump with no connections to anyone, it's a bit tougher. Then you've no reason to think it is important enough to be worth breaking. You can still try. But every algorithm has some statistical signature No. Any good algorithm should produce output that looks /exactly/ like random noise, hence they should all look like each other. This may not be precisely true, but all decent algorithms will look random enough to make distinguishing quite difficult. and if you've got enough cipher text you can compare that signature with known algorithms to home in on fewer choices. I'm not sure having the plaintext helps much more, but you could use random keys to create several ciphertexts with known algorithms and compare the statistics just to see if they compare better. It's definitly challenging :-)
