 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic Page: 1 2 »» |
Last Thread Next Thread |
| Basic Encryption |
|
 |
Anonymous Poster |
|||
 Posted - 12/15/2001 11:31:12 PM |
||||
| Since when was an integer only a bit? I think you ment 32 bit encryption as every integer that is being used in the key is what determines the 'bit' of the key, not how many elements of the key there are. Correct me if I'm wrong Otherwise, great article  I think I'll play around with it a bit, maybe using MOD in there as well. Perhaps I could use every two characters as members of a vector and use a matrix to transform the values... see what you've done, now I'm thinking... stop, it's hurting me... ahhh no...Cheers D |
||||
|
||||
|
Jonnie Member since: 12/10/2001 From: USA |
|||
 Posted - 12/16/2001 11:24:29 AM |
||||
| And that's all I have for you on encryption. There are a few other things you will need to figure out before you use this commercially or privately. I doubt this would be used commercially. This is similiar to a method called padding. and the keys are plain text. All a cryptanalyst has to do is get the key and perform the operation (grab your decryption system "executable") on the cypher text to get the plain text message. In commercial applications, It is assumed that the cryptanalyst has access to the cryptosystem, the key and the cipher text. The algorithm is usually open source. the key and the message are both exnrypted using something similiar to a one way hash functions. Usually the only way to break such keys are to factor them. and that can take millions of years on keys that are extraordinarily long, such as 256 bit keys. XOR ROT13 |
||||
|
||||
|
kurifu Member since: 9/18/2000 From: Canada |
|||
|
Posted - 12/16/2001 11:33:45 AM |
||||
| Hah, I just finished writing and submitting an XOR based encryption article to gamedev.... you are spying on me! ADMIT IT! Anyway, it is in C / C++ for those who are more accustomed to that. Gamedev's AI Auto-Reply bot. |
||||
|
||||
|
LOWORBIT Member since: 5/13/2001 From: USA |
|||
|
Posted - 12/16/2001 12:58:21 PM |
||||
| Just a quick note about public display of encryption methods, the US gov is very nervous about the idea, for "national security" reasons. Even though the concept of implementing encryption is extremely easy, about as easy as decoding a dvd. But I believe there are strict rules about using 128 bit encryption, just a word of warning so you may want to do some more research on the subject before using it. added: http://www.epic.org/crypto/export_controls/regs_1_00.html Edited by - loworbit on December 16, 2001 1:00:46 PM |
||||
|
||||
|
kermitdfrog Member since: 12/16/2001 From: Ireland |
|||
 Posted - 12/16/2001 1:37:32 PM |
||||
| Excellent article on beginning encryption, thanks. Small note on the code: adding an integer determined by (rnd*30) to the ascii value means there is a 1 in 30 chance that the value will be unchanged - rnd*x returns a rumber between 0 and x-1. What you need is int(rnd * 30) + 1 Good work! |
||||
|
||||
|
TerranFury Member since: 2/19/2001 |
|||
|
Posted - 12/16/2001 1:55:31 PM |
||||
| I wrote a simple encryption program in about 15 min. This is how it worked: Input a string (the key) and a filename. The program then does the following: - Treats the string as a base-256 number and stores it in an unsigned long. It would never fit even into an unsigned long; however the repeated overflow does mean that each and every byte, not just the first 4, matters. - Call srand with the above value - XOR each character in file by key[charnum % keylength] and then again by (rand() % 256) The end! Encryption and decryption are exactly the same; as we all know if X^Y=Z, then Z^Y=X and Z^X=Y. Now how do more advanced algorithms work? Edited by - TerranFury on December 16, 2001 1:58:47 PM |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 12/16/2001 2:09:34 PM |
||||
| This article is a good place for people to start for learning encryption, however... Any encryption system based on the standard random number generator is fundamentally flawed. it is a really poor generator with a short period. each bit by its self is not really very random (try drawing a grid of 256x256 with rand()%2 or rand()&1 if you prefer) if you do some reading, you will find that many people have tried using simple random number generators for encryption (1), and that if you encrypt something that is perhaps 1meg, it will only take a few minutes to break the 'encryption', and they don't need your source either. If you are going to use simple encryption based on a random number generator, then at least use a good one. You may want to try the Mersenne Twister Random number generator. http://www.math.keio.ac.jp/~matumoto/emt.html It has a theoretical period of 2**19937-1... etc. and even though it is far better than rand(), they say it is not secure for encryption. also, some of you may use the option in .zip programs to 'encrypt' data. Even that method of encryption is flawed, and any .zip file can be opened in a matter of seconds. If I am wrong about any of this then please tell me and I will correct what I have said. (1) http://web.mit.edu/prz/essays-SnakeOil.shtml There is some good information about PGP around there too. |
||||
|
||||
|
GoofProg Member since: 2/11/2000 From: Las Vegas, NV, United States |
|||
|
Posted - 12/16/2001 2:18:50 PM |
||||
| XOR is the easiest encryption to do because you just need to XOR the value once to encrypt it and XOR it twice to have it return to it's starting value. XOR is a basic encryption and can be easily cracked. Commercial encryption used in PGP and SSH have plenty of mathematical algorithms that will make it harder to discover. |
||||
|
||||
|
Anonymous Poster |
|||
 Posted - 12/16/2001 2:26:11 PM |
||||
| Just for clarification, this would not be a commercially feasible algorithm. It is, just as the title states, basic encryption and is only to be used as a starting block. I don't recommend using it in any commercial programs but you can mess around with it and improve on it all you like. Now I will say that it is not 128-bit encryption, in actuality it is 128-integer encryption or 512-bits. I have had this pointed out numerous times I am just too darned lazy to correct it, plus I submitted this to GameDev like 2 months ago so I can only imagine how long it would take to change. Now as far as the United States' stand on distributing encrypted files. You can freely display the source code to any type of encryption algorithm you have created, and you can show it to anybody in any other country. Where it starts getting sticky is when you send encrypted files to other people in other countries, this can tip of the feds to maybe start watching you more closely but there isn't too much you can do. The big thing that is illegal is sending commercial or even independent encryption software to other countries, without The United States' permission. If you have constructive criticism please send it my way, but remember this is only basic encryption only meant to be a starting block to get you going if you have never messed with encryption before. If people are interested in working on this algorithm to make it more secure and possible commercially viable please contact me and maybe we can fix it up. - Matt Recker |
||||
|
||||
|
Askadar Member since: 11/25/2001 From: Berlin, Germany |
|||
|
Posted - 12/16/2001 3:45:00 PM |
||||
| What about a follow up with more advanced algorithms? Maybe something about encrypting a stream so you don't have to worry about hacks in you multiplayer games? |
||||
|
||||
 |
DavidRM Staff Member since: 7/16/1999 From: Tulsa, OK, United States |
|||
|
Posted - 12/16/2001 4:04:46 PM |
||||
| To learn about encryption, this book is one of the best around: "Applied Cryptography", by Bruce Schneier ISBN 0-471-11709-9 DavidRM Samu Games |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 12/16/2001 4:51:57 PM |
||||
| I will definitely look into making a more advanced follow-up article. I will be busy for the next few months, but I will try to fit it in when I have time. - Matt Recker |
||||
|
||||
|
fakemind Member since: 10/16/2001 From: USA |
|||
 Posted - 12/16/2001 10:10:25 PM |
||||
| "Applied Cryptography", by Bruce Schneier, is perhaps the best book to get started into cryptography. "Now I will say that it is not 128-bit encryption, in actuality it is 128-integer encryption or 512-bits." 128 bytes is not equal to 512 bits. first off i assume the article is intended to encrypt only small size plaintext, and that is in its advantage. if you try to encrypt anything large then it would be quite simple to decrypt the ciphertext without even knowing the randomly generated key. for the same reason that XOR'ing plaintext with the same repeated key is easily broken. in generating the key, since you multiply the random value (which has already been stated isnt that good a random number generator) by 30, we already know that the keys are going to be multiples of 30. (side note: i couldnt understand because of contradictions in what was said and what was in code whether you multiplied by 9 or 30) in fact, multiplying the random number by any number and then sticking it in a byte actually reduces the number of combinations from 256 to a smaller value. the multiplication shouldnt be there as it hurts the algorithms security. but if perhaps i misread the code and you were trying to create an array of 128 values ranging from 0-30 then that is still bad. 30^8 different combinations instead of 256^8. also, if indeed you were using 128 values ranging from 0-30, it would would also hurt the security if you tried to only encrypt text. ("...so you can have a working text encryptor..." ) as you could gain quite a bit of information about the key from the ciphertext. ie. if in the ciphertext there was a value of 'A' i would know the key for that letter was '0'; and so every 128 byte after such would not be encrypted at all. such deductions would give away information about the key and the plaintext. i find the description: "Covers the essentials involved with encryption" not to be correct. there were no "essentials" in the article. while the algorithm should protect against the "kid sisters" out there, security-wise its not secure and should definately not be used in anything commercial or if the information you tend to keep secret is of any value. remember that a good encryption algorithm does not need to hide its inner workings; its security lies in the key and not the implimentation. and in fact the algorithm posted actually has no "inner workings" but rather only a key. it reminds me of the classic "repeated key XOR" that so many people use. i apologize if i sound too negative, but creating a encryption algorithm takes quite a bit of skill involving high maths and knowledge in the field. the article does not even begin to get into the basics of cryptography other than the fact that its good to encrypt using a key. - jeremiah http://fakemind.com Edited by - fakemind on December 16, 2001 10:15:21 PM |
||||
|
||||
|
Thr33d Member since: 6/24/2000 From: Portland, OR, United States |
|||
|
Posted - 12/16/2001 11:34:04 PM |
||||
| Hey, nice article, I'd probably had written one if I weren't so lazy (like everyone else) or / busy. I just wanted to request you add a note on how to seed the random number generator. (ie; rnd -1 .. randomize (seed)) I think that would be a nice addition. Also, you might think about writing an XOR based version, maybe even info about vb's random number generator (check it up on microsoft's site). I haven't figured out a decent algo yet, but you might consider looking into public + private key one way encryption and writing something up on it.. I'd be interested in it. -Michael |
||||
|
||||
|
fakemind Member since: 10/16/2001 From: USA |
|||
|
Posted - 12/16/2001 11:56:46 PM |
||||
| i just glanced through the article and noticed that you created a 128 array of integers between 0-9, and you stated it was 128-bit encryption. this simply shows your ignorance in the field of cryptography. 128-bit encryption is simply that, 128 bits, 128 1's and 0's ... not 128 digits between 0-9. ignorance is not necessarily a bad thing, but you should not be writing articles where you write as if you have knowledge in the field. its like the blind leading the blind. i would suggest reading the article posted by the anonymous poster, http://web.mit.edu/prz/essays-SnakeOil.shtml. encryption is definately a lot harder to get into and get good at then you can get out of one article. what would have been a much better article would have been to show the good in other public and proven algorithms. you are hardly adequate to write your own -- and neither am i. as ive already said, it requires high maths and knowledge in the field. something that you just cant get in a simple tutorial or article. - jeremiah http://fakemind.com |
||||
|
||||
|
Putrid Stench Member since: 12/16/2001 From: New Zealand |
|||
 Posted - 12/17/2001 2:08:49 AM |
||||
| Something felt very wrong with that article. Perusing previous posts I am happy to see people are able to detect the authors erroneous statements. I feel rather distubed by the statement 128 bit encryption especially. No doubt the word BASIC certainly is no misnomer for the title. I feel an encryption method is only any good if its one where you know how it works but even so can't break it anyway. Public key encryption being a good example. The article seems to say that 128 permutations are good enough for commercial encryption, however as previous posts say that is just wrong. Encryption has been round for thousads of years, Early encryption was simple substitution, which worked really well especially with peoples with high illiteracy percentage. These days of course people are more sophisticated ... they can read and they can count for a start. In WW2 one reasons the Germans got trounced in the end was because the British broke their encryption method. German mathmaticians were so adamant that this was false the Nazis ignored reports by people in the field... who promptly found themselves waking up dead. The Germans made the mistake of repeating in succession the first letter in there encrypted transmissions and the Brits used these repeated patterns to crack it. The plain fact was the Germans used their encryption method wrong. Okay what method did the Germans use you may cry in fustration... (or not if you already know) well they had invented a device called the Enigma Machine. Sounds like something from batman I know. What they used was a set of reels which they lined up. A machine with 3 reels say and 37 characters (26 letters, 10 numbers and a blank) would have an inner reel a middle reel and an outer reel. Each time a letter was used the outer reel would turn one step. Once it completely wnt around the loop it would turn the middle loop one step and so on similar in action to a clock. The reels would be read by matching the inner reel (say at the 12 Oclock position) to the outer reel then the letter found there is matched to the middle reel which is then matched back to the outer reel again. The net worth of permutations being 37*37*37 before repeating the process again. Leave it to say the more reels you add the more permutations and the harder it is to get a repeating pattern. This is not to bad if you lived before the modern computer. Okay now days they use public key encryption see http://developer.netscape.com/docs/manuals/security/pkin/contents.htm for details. The appropriateness is dependent on your program though. Tons of stuff on encryption and cryptography are in bountiful supply on the web. Everyone is pretty much safe with this until we get quantum computers (whose encryption methods are said will be unbreakable but whose processing power would make mincemeat of todays encryption) or some one figures how to find factors of prime numbers (that statement seems wrong... nevermind) A good story you might be interested in is about the problems people face in implementing encryption. Take your encrypted tv stations for example. One method they use is they use aforementioned random number to slice each line of the picture up into half and wrap around the screen, The result... streaks of colour and sound but no movie. I have heard of people cracking this. They didn't bother with the random number generator though. Instead they came up with a better idea... what they did is realise that in any picture the colour of the pixel next to it is usually the same so they recorded the junk off the movie channel then wrote a program to run some matching percentage alogorithm to get the best picture and got themselves a mostly flawless picture. For the most part the best thing you can do if you want to encrypt game data is to write an encryption algorithm thats too annoying to crack and feels like a waste of effort for the cracker... eg make a wall too high to jump and not worth the prize behind it. Another good idea is to write your own version of a compression algorithm. Not only do you encrypt data this way but you get smaller files. Excuse my prattle, I have a tendency to get side tracked, not a good trait in a programmer really. Please do not read this sentence again. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 12/17/2001 2:58:20 AM |
||||
| Don't you guys get the idea of a basic tutorial? If you know nothing about encryption it is supposed to get you started. It is under no circumstances commercially feasable or secure as I have said A MILLION TIMES!!! Catch a clue. If you have background in encryption then the article probably isn't for you, the sole purpose of this article is to help someone who has never thought of encryption before break into it and it offers them an easy method. It uses BASIC algorithms, nothing advanced, and it isn't efficient for large files, or effect for binary files. IT IS JUST A STARTING PLACE FOR NEW PEOPLE! If you could just grasp that concept maybe you would understand what I am trying to accomplish with this article. If you don't like it fine, but don't make it sound like putrid trash to the beginning programmer that wants to learn encryption. Come on, I hate getting worked up over this and if you want to help in writing a new, more advanced, tutorial I am open to suggestions. Just email me and let me know and I will be more than happy to take any input you have. However, slamming my article without even conversing with me to find the scope of the article is unfair and unprofessional. - Matt Recker |
||||
|
||||
|
Vex Member since: 10/23/2001 From: England, UK |
|||
 Posted - 12/17/2001 7:48:36 AM |
||||
| Unfornutely your article reads as if you know a lot about encryption techniques. But it's plainly obvious that you don't. There are plenty of good websites and books on cryptography, I recommend you read some. A particularly good book on the history of cryptography is.. http://www.simonsingh.com/codebook.htm Though this isn't a programming book, it's very interesting. Vex / Aeonian.net Developer --------------- http://www.Rock-Nights.com eonian |
||||
|
||||
|
CheeseGrater Member since: 6/21/2001 From: Worcester, MA |
|||
|
Posted - 12/17/2001 9:28:15 AM |
||||
Let me sanity sheck with some simple combinatorics. 128 single digit numbers, base 10 makes 1280 possible keys, since there are 10 digits. 1280 is between 2^11 and 2^12, so this is actually a 12 bit encryption algorithm. 12 bits is, of course, pathetically easy to brute force, but it does have the advantage of being well below the United State's munitions standard, so this algorithm would be freely exportable. Then again, we can go up to 40bit without even thinking about munitions, so why stop at 12? I'm sorry, but this article is outright incorrect and is also misleading to the beginner, especially since these techniques really aren't *basic* encryption techniques. That would be something like XOR against a static key. This just describing do it yourself crypto that really doesn't work that well. This article would be better called 'Naive Encryption.' Peer review is a well-established and important to the encryption community. People who are pointing out flaws in your article aren't 'unprofessional' - we're just trying to help correct problems in the article, as well as prevent people who don't know better from mistakenly believing this is a strong crypto technique. |
||||
|
||||
|
Anonymous Poster |
|||
 Posted - 12/17/2001 9:52:07 AM |
||||
| it is not 1280 possible keys (128 * 10), it is 10^128. Just to clear things up. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 12/17/2001 9:53:28 AM |
||||
| it is not 1280 possible keys (128 * 10), it is 10^128. Just to clear things up. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 12/17/2001 10:41:37 AM |
||||
quote: Read the article again. quote: Sure looks like 128 choices of 10 to me. 1280. |
||||
|
||||
|
darookie Member since: 9/17/2001 From: Mannheim, Germany |
|||
 Posted - 12/17/2001 11:11:39 AM |
||||
| think again, AP! it really is 10^128! look: an array of say 2 numbers (base 10) can hold 100 keys (if you don't believe me, use a simple calculator and type "99"  )so this means an array of 3 number can hold 1000 keys aso. the biggest representable number within a grade 128 polynome(that's what it actually is) is n^128. since the base is 10 (or 0 to 9) it is 10^128 (don't try to do that with a simple calculator BTW. using your calculus, a 32 bit binary would only be able to hold 64 numbers -> 32 choices of 0 or 1 Edited by - darookie on December 17, 2001 11:18:20 AM |
||||
|
||||
|
En3my Member since: 10/1/2000 From: Sweden |
|||
|
Posted - 12/17/2001 11:34:13 AM |
||||
| hehe! i can't believe that some people totally trash this basic encryption tutorial... i didn't know anything at all about encryption prior to reading it, but after reading the article i got hungry for more so i went to amazon and ordered a book... thanks for writing the article! |
||||
|
||||
|
Page: 1 2 »» All times are ET (US) |
Last Thread Next Thread |
|
