# Encryption using ASCII instead of bits and bytes (clarification in the body)

I am new to cryptography and I am trying to understand something. I searched it on the internet, though the question is probably a simple one, couldn't find an answer. So, please don't judge me by that. Here is my question: Without considering the efficiency, speed, or optimization:

Can everything that can be encoded by other encoding methods (such as using binary or bits and bytes or Unicode) is also encoded by using ASCII?

• Please clarify or close the question! The second paragraph has a grammatical error ("Can everything that.. is."); has "other encryption methods" without reference to another encryption; and uses "encrypted by using ASCII", when an encoding performs nothing. Perhaps we should read: "Can everything (that can be encrypted) alternatively be encrypted into ASCII"? The response to that is a clear yes, and it's common practice. One of the best known is re-encoding ciphertext produced by some public encryption method into ASCII, e.g. using Base64.
– fgrieu
Sep 10 '21 at 20:48
• Hi, I really appreciate your answer. Sorry that I couldn't express myself clearly. I was trying to ask ""Can everything (that can be encrypted) alternatively be encrypted into ASCII"?" and you already answered it. Also, thank you for warning me first instead of directly reporting. Sep 10 '21 at 21:15

Can everything (that can be encrypted) alternatively be encrypted into ASCII?

Yes. And it's common practice. The general technique is to encrypt, which for most modern cipher will output apparently random bits, which can be called "binary". Then re-encode that into ASCII, e.g. using Base64. That's built into some encryption software like PGP/GPG, which calls the re-endocing ASCII armor.

Such binary to text encoding is not specific to cryptography. It's used in email for content using characters that do not exist in ASCII, and attachments like images.

Such encoding increases the size. By a factor of $$2$$ for hexadecimal (which encodes 4 bits into 1 character then represented as 8 bits), $$4/3\approx1.33$$ for Base64 (which encodes 24 bits into 4 characters then represented as 32 bits). For this reason, and also because any format change has non-trivial computational cost, it's typically not used for large payloads, like video.

When a string like "Hello World" is encrypted, do the algorithms convert this string into binary or ASCII?

Well, the answer depends on whether you're talking about historic or modern cryptography.

Historically, encryption methods typically did take the string as a series of characters, and transformed them that way. Sometimes they did an internal mapping, say, "A" -> 0, "B" -> 1, etc, however that was generally done internally to the algorithm. They generally didn't convert the characters to binary (which back then would have been seen as an odd choice), and certainly not to ASCII (which didn't exist back then).

On the other hand, modern encryption algorithms generally [1] take strings of bits or bytes as inputs, and generates a string of bits or bytes as an output. To encrypt a string, you would convert it into such a string (whether using ASCII, Unicode, or EBCDIC, the algorithm wouldn't care), and the algorithm worked on that.

Also, if this is a file, can ASCII still be used to encrypt data?

Well, a file of ASCII characters can be viewed as a string of bytes, and so modern encryption algorithms would handle it just fine.

[1]: One exception: Format Preserving Encryption schemes, which generally look at the input as a base-$$b$$ string, where $$b$$ might not be a power of two.

• I really thank you for kindly answering my question, but I have one more question to ask. If we can convert something to a string of bytes, we can convert it to ASCII as well, right? So, everything that can be encrypted by other methods can also be encrypted by using ASCII, right? Though in that case, it would be wise to consider efficiency and optimization. Sep 10 '21 at 19:28
• ASCII is just a way of converting various characters (and controls) into values between 0 and 127 (or 0 to 255 if you use "extended ASCII"). If we assume that the string we give crypto is "extended ASCII", well, yes (assuming that the string is a multiple of 8 bits long - it usually is); however it's unclear what advantage that gives us. Sep 10 '21 at 21:24

ASCII is an encoding, not an encryption method. ASCII turns certain characters (the English alphabet, some symbols, and some non-printable control characters like "tab" or "line feed") into 7-bit binary values. This is usually done encoding each ASCII character into one 8-bit byte, and setting the most significant bit of that byte to 0.

Some ancient computer systems (mostly found only in museums or in the collections of retrocomputing enthusiasts) didn't support ASCII or 8-bit bytes, and instead encoded data differently. EG the IBM 1401 mainframe from 1959 encoded data using 6-bit characters in a special Binary Coded Decimal scheme. This is really only of historical interest.

Modern computer systems mostly don't use ASCII, but instead use Unicode, often in the UTF-8 encoding. This also uses 8-bit bytes, but the most significant bit need not be 0.

Any encryption method that operates on bytes can operate on ASCII data, since ASCII data is composed of bytes.

Any encryption method that operates only on the subset of bytes allowed by ASCII can operate on arbitrary bytes by first encoding those arbitrary bytes with a scheme that maps bytes to the ASCII subset of bytes, such as Base64.

Thus, anything that can be encrypted by other (modern, secure) encryption methods can also be encrypted by a method that only accepts ASCII characters.