Converting Ciphertext to a Number in RSA I've been looking into RSA and the attacks against weak implementations of it, such as when $e$ is small and there's no padding. On Wikipedia, the following attack is outlined for small $e$ values:


  When encrypting with low encryption exponents (e.g., $e = 3$) and small values of the $m$, (i.e., $m &lt; n^{1/e}$) the result of $m^e$ is strictly less than the modulus $n$. In this case, ciphertexts can be easily decrypted by taking the $e^\text{th}$ root of the ciphertext over the integers.


What I'm confused about here though is how do you carry out mathematical operations on ciphertext? I'm aware that all characters have numerical values, but what I'm unsure on is do you construct a single number from a whole ciphertext as you would for plain text to be encrypted (ie, convert each character to an integer then construct the number with the rightmost digit being most significant) and then carry out the operation on this number, or do you act on each individual number in the ciphertext? If it's the former, how do you determine to reconstruct the single number into a sequence of numbers that create the original plain text?
The ciphertext of RSA is actually just a number in the range 0..N that has been encoded to an octet string (another name for byte array) of the same size as the minimum modulus N. To be precise, the ciphertext is an unsigned, statically sized, big endian integer.

The PKCS#1 standard defines it this way, both for PKCS#1 as well as OAEP padding:


  Convert the ciphertext representative c to a ciphertext C of
          length k octets (see Section 4.1):  
  
  C = I2OSP (c, k).


Where I2OSP - integer to octet string primitive - is defined here. I2OSP is just a mathematical way of defining how the number is encoded as described in the first section of the answer. Stupid implementations actually perform these kinds of calculations, most implementations require some resizing / reversing (in case little endian is used internally) and smart implementations already keep the numbers in the correct format in memory.

Now for textbook RSA, you can, of course, argue that pointing to the PKCS#1 specification is unfair because textbook RSA is not defined in that standard, and textbook RSA isn't required to follow the conventions specified in it. However, the fact that the ciphertext is just an encoded number remains. Sometimes the minimum length and / or little endian encoding is returned and of course, some implementations will simply return the number without performing encoding at all. However, in all cases, it should be easy to get the numeric value of the ciphertext - which is just the result of modular exponentiation with the public exponent after all.

Note that many languages - notably the C language - unfortunately handle bytes and characters as being the same type; they are not. The bytes generated by encoding a number can have any value and may not be printable. If you need a printable text that contains these bytes you will have to encode the bytes to a string, e.g. base 64 or hexadecimal encoding. Some libraries allow you to specify this as output size, and some bad ones even default to performing an encoding over the ciphertext bytes. To convert those back you need to first decode back into bytes and then perform the bytes-to-number conversion.

Despite the possible output values, you should never ever have to perform calculations on the individual bytes unless you cannot load any kind of library that does this for you and you will have to define your BigNum yourself (and yes, I have been there). Usually the cryptographic libraries themselves contain this kind of library; they need the functionality after all. They are quite often in the "hazmat" part of the library or not directly present in the API however.