ASCII to same-length ASCII encryption? I need to encrypt an ASCII string [a-zA-Z0-9:] to an ASCII [a-zA-Z0-9] string of the same length. It doesn't have to be unbreakable, it's sufficient that it won't be readable at the first sight.
The purpose is to encrypt my WiFi hotspot name with a key so that only my friends holding the key can decrypt a message from the hotspot name.

I might need XOR encryption that will guarantee that the output will be ASCII.
Or I can simply have a numeric key and add the corresponding key number to each ASCII code of the char of the hotspot name.

What would you suggest?
I need to encrypt an ASCII string [a-zA-Z0-9:] to an ASCII [a-zA-Z0-9]
  string of the same length.


The pigeonhole principle can be used to explain why it is not possible to encrypt every 15-character string from some set of sixty-three characters into an encrypted 15-character string from a set of sixty-two characters.


  I need to encrypt an ASCII string [a-zA-Z0-9:] to an ASCII [a-zA-Z0-9]
  string; it's OK if the encrypted string is slightly longer.


There are a huge variety of ways to do this.
Off the top of my head, I might consider:


replace each ":" in the plaintext with "_"
decode the plaintext string from "base64url" encoding into a series of octets (which probably include some unprintable octets)
encrypt the series of octets using practically any implementation of practically any encryption algorithm, using the secret key that you have (somehow) distributed.
encode the ciphertext octets using any "base32" encoding.
The result is ciphertext that only uses 32 printable ASCII characters, but is slightly longer -- six-fifths the size of the original text if you pick a "length preserving" algorithms, somewhat longer if you pick an algorithm like salted AES encryption with an authentication code.



  I need to encrypt an ASCII string [ A-Za-z0-9-_ ]
  to an ASCII [ A-Za-z0-9-_ ]
  string of the same length.


Forcing the ciphertext to be exactly the same length as the plaintext makes a system less secure than one that has room for an initialization vector, an authentication code, etc.

Ah, the "base64url" character set.
With a character set that is a power of 2,
you can use pretty much any implementation of any "length preserving" algorithm, including the Vernam XOR one-time-pad cipher you mentioned and the Vernam modular addition one-time pad.

To encode a string using a Vernam XOR one-time pad, pull a fresh never-been-used page from your one-time pad.
For each character in your message: decode the character into a 6-bit number 0..63,
XOR that character with the corresponding 6 bits from your one-time pad,
then encode the resulting number (which will also be in the range 0..63),
to the corresponding character in the 64-character set.
Then eat or burn that page from your one-time pad, forcing you to use a different page for your next message.
Other encryption algorithms don't require you to consume your secret key, and so are often easier in practice.


  I need to encrypt an ASCII string [A-Za-z0-9] to an ASCII [A-Za-z0-9]
  string of the same length. I need all these characters in the plaintext, and I can't use any other characters or punctuation in the ciphertext.


Forcing the ciphertext to be exactly the same length as the plaintext makes a system less secure than one that has room for an initialization vector, an authentication code, etc.

Ah, format-preserving encryption with a 62-character set.
Most encryption algorithms -- including Vernam XOR -- don't work with such a restriction.
However, a few stream ciphers including modular addition one-time pad can handle such a character set.

To encode a string using a Vernam modular addition one-time pad, pull a fresh never-been-used page from your one-time pad (or generate the next derived block from your stream cipher).
If your keyblock has been generated by throwing a pair of dice or flipping an array of 6 coins, cross out and ignore any values of 62 or greater,
so we have values 0..61 of equal probability.

For each character in your message: decode the character into a number 0..61,
add that character to the corresponding number 0..61 from your derived block --
subtracting 62 if the result is too big, so the final result is in the range 0..61.
Then encode the final result to the corresponding character in the 62-character set.
Then eat or burn that page from your one-time pad, forcing you to use a different page for your next message.
Other encryption algorithms don't require you to consume your secret key, and so are often easier in practice.

(The GROMARK and Gronsfeld ciphers resemble Vernam modular addition, except using a smaller range of values of 0..9 rather than 0..25 or 0..61, and so are less secure but much easier to use).

(The ROT13 cipher is even easier to use, but provides practically no cryptographic security).

p.s.:
Isn't a SSID typically 32 characters?