Would you call this Encryption?

Bored one night, started coding and ended up kind of making my own kind of encryption. Im not a professional PHP programmer, ive been self teaching myself for about a year

This is how it works

It takes the a string and a key, and returns what seems like loads of random numbers so
"dreamviews" returns:
3360849-19044811-4481132-0-13443396-23525943-8962264-4481132-24646226-20165094

using the key "lucid"


To decrypt it, you need to use the word "lucid" to get back to the orginal "dreamviews".

I know its probably really nooby but is that a good thing to do for someone who is 18 and been self teaching theirself?

To answer your question, Yes, that's encryption.

To answer your second question: Cool, it's better than what I can do...

Looks like a variation on your standard cryptogram, since the patterns for each letter repeat (check the e positions). With a long enough string of text, this could be broken by hand through pattern recognition.

It might be interesting to follow the first step up by removing the dashes and running the numbers through a Vigenère Cipher using your key, maintaining a modulo 10 property for each digit--obviously.

Knowing from experience how difficult it can be to break a well done Vigenère Cipher (when only text is involved, at that), you might have something useful on your hands.

It would probably save you time if you researched some popular encryption algorithms before investing too much time into creating your own.
Some to note: Cesarean cipher, XOR encryption, AES encryption
(from simplest to most secure)

And remember, an encryption algorithm's credibility should rest with what key is chosen; not with what encryption method is used.

If you're interested in that stuff, you should read "The Code Book" (by Simon Singh). It's a really well-written book, and it gently explains encryption, both historically and technically. It's a really great read.

@Reci & Replicon - I'll check them out

Here is a C# version of it, tell me if you think it's any good please

http://staff.passion4web.co.uk/ben/BENcrypt.exe

Nobody wants to run a random executable someone posted. I'm sure folks will be happy to look over the source code though. Remember: A good encryption algorithm is good even if the code is known (e.g. relies on factoring very large numbers, which means it's easy to write a program to break it, but completely impractical because of how many millenia it would take to run hehe).

[C#] Benzilla04 Encryption - Pastebin.com

As I said, it's pretty basic

Cool thanks for posting the code. There's a couple of interesting things about it that are worth calling out:

1) in generateKey, you're building a potentially huge number (what if your key that was used, instead of being "lucid" was actually "000000000000000000000000" or something). Then you're calling Convert.ToInt32 on it. I don't know how that behaves because I don't know C# and leave looking it up to you. It might throw an exception right then and there. Or it might return a signed integer, which is bad because then the values you compute will have minus signs in it, which wouldn't jive well with your encrypted format... or it would just return an unsigned, which I guess is fine, since you don't care about the actual number.

2) Also in generateKey, you divide by z.length twice. Is this for any particular reason? Are you just shortening the value? If so, you'll probably get better results by modding it with a prime number that's close to your maximum desired value.

3) Again for generateKey... why didn't you just go "return x.GetHashCode()" for it, or implement one of the known good hash codes for strings?

Finally, in general, it looks like you're doing a lot of work for something very simple. What I mean by that is, you're basically grabbing your numerical key and applying it to every character uniformly (multiply to encrypt, divide to decrypt). In practice, what this amounts to is a basic substitution cipher, where, given the key, every letter is mapped to another symbol, consistently.

If someone were trying to break your system by looking at the input you've provided so far, they'd guess at least this much, because "dreamviews" has two e's in it, and sure enough, the ciphertext shows the same value (4481132) in the exact place where the e's would show up. So, if I were given a much longer message, I could probably just run it through a frequency analyzer and fairly quickly decode the substitution (without knowing about how you generated the key).

To make substitution ciphers a little bit more robust, you need to do something like use a multi-tiered substitution (many layers), where after each letter, the layers shift in some way, so the overall substitution from start to finish looks pretty random if you don't understand the mechanism. This is how the German enigma machines worked in World War 2. Even those were eventually cracked by Alan Turing and friends. They've even built devices called Bombes to automate the cracking.

Another really simple encryption scheme is basic single-bit encryption which is also sucky (in that it's really easy to crack) but good for learning purposes. All you need is a key, and then you xor the bits in your string directly with those of the key. The same operation will unencrypt the string. Since you were so kind as to paste your code, I hacked together a simple example of it: [Java] Single-bit encryption demo - Pastebin.com

Code:

---

java LameSinglebitEncryption Encrypt lucid dreamviews
Encrypting [dreamviews] using key [lucid]
8-7-6-8-9-26-28-6-30-23

java LameSinglebitEncryption Decrypt lucid 8-7-6-8-9-26-28-6-30-23
Decrypting [8-7-6-8-9-26-28-6-30-23] using key [lucid]
dreamviews

---

Amusingly, because the "c" from lucid lands on the "e" from dreamviews both times, you get the same thing (where both e's map to 6). However, that changes if I change the length of my key a bit:

Code:

---

java LameSinglebitEncryption Encrypt lucid2 dreamviews
Encrypting [dreamviews] using key [lucid2]
8-7-6-8-9-68-5-16-20-26

java LameSinglebitEncryption Decrypt lucid2 8-7-6-8-9-68-5-16-20-26
Decrypting [8-7-6-8-9-68-5-16-20-26] using key [lucid2]
dreamviews

---

This second time around, there's still a repetition (the two 8s), but they don't correspond to the same letter, so whatever. Then you can go nuts.

Code:

---

Encrypting [farnsworth_fry_leela_bender_zoidberg_amy_scruffy] using key [futurama_rocks_my_sox]
0-20-6-27-1-22-2-19-43-26-48-5-25-10-0-1-28-58-31-14-39-4-16-26-17-23-19-50-27-48-27-11-1-14-1-56-50-24-50-10-48-11-5-7-1-19-20-24

Decrypting [0-20-6-27-1-22-2-19-43-26-48-5-25-10-0-1-28-58-31-14-39-4-16-26-17-23-19-50-27-48-27-11-1-14-1-56-50-24-50-10-48-11-5-7-1-19-20-24] using key [futurama_rocks_my_sox]
farnsworth_fry_leela_bender_zoidberg_amy_scruffy

---

Also, notice that a key consisting of a single letter (or a string of just the same character over and over) basically degenerates into a basic substitution cipher:

Code:

---

java LameSinglebitEncryption Encrypt QQ jeepers_creepers
Encrypting [jeepers_creepers] using key [QQ]
59-52-52-33-52-35-34-14-50-35-52-52-33-52-35-34

---

Look at all those 52s :)

Back in 1999, I read somewhere that AIM (you know, AOL's shitty IM) was using this kind of method to store their passwords. Weak, weak, weak... I bet it's still in use all over the place. Right after finding that out, I looked at some encrypted string in a website cookie from a site that was using a popular chat client (I think it was called iChat, and no it's not an apple product), and wondered if they were using that. Sure enough, I created a LONG username, xored it to the cookie string, and then I tried out that key against my regular-length-username cookie string, and there it was. "<username>::<password>::<some_other_crap>" or something like that. So whenever people were having tech troubles with their computers on there, I'd tell them to send me that string (cause... well... "it gives me info about what version of windows you're running" or something), and then I eventually had a huge amount of passwords. It was a dick thing to do (and I never used the passwords for anything), but it was fun and educational. Especially the social engineering. So easy haha.

have fun!

Quote:

---

and then I eventually had a huge amount of passwords. It was a dick thing to do (and I never used the passwords for anything), but it was fun and educational. Especially the social engineering. So easy haha.

---

Dam. Sneaky sneaky. I'm still pretty much a noob with C#, PHP e.t.c. I mean, I'm pretty good for my age (I guess) but still.. not quite at the level I want to be. :/

I think it's awesome that you're playing with this stuff if you like it. Never too early to discover your passions. Keep at it!

Quote:

---

Originally Posted by Replicon

If you're interested in that stuff, you should read "The Code Book" (by Simon Singh). It's a really well-written book, and it gently explains encryption, both historically and technically. It's a really great read.

---

Good book, I read that in high school.

Yeah, there are plenty of good encryption algorithms out there. PGP (or anything that has to do with multiplying two large primes together) is practically unbreakable, at least until quantum computers start being used.

Nice. As long as that algorythm is one way only, it's encryption :)
If you made it all up from scratch, I'm really impressed :)

It's two way and i made it from scratch

Quote:

---

Originally Posted by Oros

Nice. As long as that algorythm is one way only, it's encryption :)
If you made it all up from scratch, I'm really impressed :)

---

Actually that would be a hash function, not encryption.

Oh, true. xD My bad.