I need help, again!

So here's my code, which is still broken:
def trashy(message, move):
  message2 = ""
  for i in message:
    x = ord(i)
    message2= message2+chr(x+move)
  print(message2)

print("How much do you want to shift your letters by?")
numbermove = int(raw_input())
print("What is your message?")
something = raw_input()
trashy(something, numbermove)

What's wrong with it this time? The raw_input function has been renamed to input in python 3, so why didn't it work earlier?

Hi,

@CarterTemm: yeah, didn't know that topic and thus didn't know this Python 3 thingy. I got both versions installed and tried with Python 2, which didn't work, thats why i replaced it and voilla.
Didn't mention the ascii range though, this code looked like some tutorial or class homework thing and I guessed he'll have to cover this topic next. Thanks for clarifying anyway .

Best Regards.
Hijacker

The ASCII thing can be explained simply with an example, as below:
How much do you want to shift your letters by?
35
What is your message?
hi
‹Œ
There's your problem. The problem with this code is that you don't enforce an ASCII range limit; so someone could, say, shift by 3500 characters and result in a strange, weird UTF8 mess. Even worse, you can shift by negatives:
How much do you want to shift your letters by?
-200
What is your message?
hi
Traceback (most recent call last):
  File "t.py", line 11, in <module>
    trashy(something, numbermove)
  File "t.py", line 5, in trashy
    message2= message2+chr(x+move)
ValueError: chr() arg not in range(0x110000)
The above value error is Pythons built-in Unicode enforcement; values converted with chr() must be within the range 0-1114112 (0x0-0x110000). However, that range, for the purposes of this cipher project, is far greater than what you need; a cipher that wraps around after it has reached the end of the ASCII table is fine enough. To solve this problem, determine if the ordinal of the character your scanning (and moving) results in an ordinal either greater than 126 or less than 32 (to avoid control characters.)
As for your other question: a byte rotation (also known as a circular shift) is a (easy to break, but fine for this purpose) algorithm where you have a list of (in this case) bytes (which, in the usual case, is in a tuple, but a string will suffice). In the algorithm, you take all the entries (bytes) in that tuple (string) and rearrange them such that the last entry (byte) in the tuple (string) is moved (rotated or shifted) to the first position and all other entries (bytes) are moved into the next sequential position in the tuple (string). So, take the string "hello". If you perform a circular shift on that string, o is moved (shifted) to the position of h, and h, e, l, and l are moved (shifted) such that they fill the remaining space of the string, thereby creating the string "ohell".
To aid you, I'll leave you with the following nugget of info: a circular shift (byte rotation) is a permutation s of the n bytes in the string such that either the sigma of i is identical to (i+1)%n, for all bytes i=1, n; or the sigma of i is identical to (i-1)%n, for all bytes i=1, n. The algorithm is repetitive, which I'll demonstrate twice below. If your implementation is correct, it should follow the following steps (though obviously this is heavily dependent on the string your passing it), assuming 'abcd' is your string:
* Input: abcd
* abcd becomes dabc
* input: dabc
* dabc becomes cdab
* input: cdab
* cdab becomes bcad
* input: bcad
* bcad becomes abcd (original input)
As such, if this is a homework assignment, and if your teacher uses the string "hello", and repeatedly applies your implementation to the string, something like the following should happen:
* teacher passes in "hello"
* "hello" becomes "ohell"
* "ohell" becomes "lohel"
* "lohel" becomes "llohe"
* "llohe" becomes "elloh"
* "elloh" becomes "hello" (original input)
Hope this helps!

if you never want to care about going out of range, just take the input move number and mod it by 94 and then ad 32. I would just also take x as the new ASCII value stop adding move to it all the time.

x = ord(i) + move
move = (x % 94) + 32

Post 9, yeah... I should stop with that, point noted. I'll try and write less repetitive code in the future.

The affine cipher is a type of monoalphabetic substitution cipher. The way it works is as follows:
* You pass the cipher a string
* Each letter in an alphabet (i.e. the base64 or base32 alphabet) is mapped to its numeric equivalent
* That numeric equivalent is encrypted with a simple mathematical function
* That (now encrypted numeric equivalent) is then converted back to its alphabetic form
The formula used in the cipher means that each letter than is encrypted maps to one other letter and back again, meaning the cipher is a standard substitution cipher with a rule governing which letter maps to which. That also means that it has the same weaknesses of a substitution cipher. The simple mathematical function used to encipher (encrypt) each letter is (ax + b) mod 26, where b is the magnitude of the shift.
In other words, mainly mathematical:
* The letters of an alphabet of size m are first mapped to the range 0,m-1 (that is, 0 to the size of the alphabet minus one).
* Modular arithmetic is then employed to map each plaintext letters' ordinal to its encrypted equivalent. That function is e(x)=(ax+b)%m, where modulus m is the size of the alphabet (determined in the first step) and a and b are the keys to the cipher. The value a must be chosen such that a and m are coprime (that is, the only positive integer (factor) that divides both of them is 1).
* To decrypt the encrypted plaintext, you first get the encrypted letters ordinal, and employ the mathematical function d(x)=a^-1(x-b)%m, where a^-1 is the modular multiplicative inverse of a modulo m, i.e. it satisfies the equation 1=a(base a)^-1%m.
The Caesar cipher is one such example of an affine cipher with a=1 since the encrypting function reduces to a linear shift.
I know you asked for a simple explanation, but I elaborated on the cipher in case you needed it. If your going to be writing one, you'll need all that I have provided here. As for your other problem, ROT-13 can be implemented in 1 line in Python, 3 if you split it across lines for ease of readability. As a hint, look in the bytes module (automatically imported). I also just ran your code through Python, and the implementation isn't correct. When running the method I'm hinting at and giving it 'Hello world!', I get 'Uryyb jbeyq!'. When I run it through your method though, I get 'UryyC KCFyq!'. So your close, but not quite there.

Oh, no, I had fun writing all that. No bother, it was fun to see someone interested in learning about programming and cryptography.

Yeah, you messed up, and I'm honestly not sure where you went wrong with this one. I think, however, that you are over-complicating things. When I run your cipher and add a chr() call, I get back bytes (yes, literal Unicode sequences).
Edit: actually, your quite close. A source I found used a string of characters to hold all the translatable symbols, and did something quite similar to what your doing. They didn't constrain it to the alphabet, either: they constrained it to the characters " !"#$%&'()*+,-./0123456789:;<=>[email protected][\] ^_`abcdefghijklmnopqrstuvwxyz{|}~". Furthermore, they scanned the keys used, and aborted if either (1) the first key was one, (2) the second key was zero, (3) the first or second keys were less than zero or the second key was greater than the size of the symbol table minus one, or (4) the key and the size of the symbol table were not relatively prime. (All of those are weaknesses and measures should be in place to forbid them.) Furthermore, instead of dividing the key into two separate parameters, the version I'm looking at split the two keys into two separate, distinct entities, then analyzed those halves. During the encryption process, the version looped through the message, determined if it was in the symbol table, and encrypted it. If it wasn't, it did something a bit different. During the decryption process, the version located the mod inverse of the first part of the key and the size of the symbol table, iterated through the enciphered message, and inverted the encryption if and only if the character that was examined was in the symbol table. Finally: as you don't need this method, I'll disclose what the version also did: it allowed you to generate a random, secure key. It did this by (1) infinitely generating key portions between the range 2-length of symbol table, (2) determining if the first key portion and the size of the symbol table were relatively prime, and (3) if they were relatively prime, it returned the first key times the size of the symbol table plus the second keys portion. If they didn't match, it continued generating a key until it returned a relatively prime result. I'm not giving any code like you asked, if you want to implement such a mechanism yourself.

@Ethan, could you explain how to undo the modulus opparator using numbers please? I'm still in algebra, so forgive me for not being able to keep up with you. heh. I also seem to grasp things quicker and or better if you give me an expression with numbers, Rather than a bunch of theory.
As to your post 17, interesting... We'll see if I will need to re-code the entire thing. My hope is not to, but oh well... we all fail time to time.
On another note, what does the ^ operator do? mathematically, I mean?