Best modern cipher for morse code? I am looking for a modern cipher to encode morse code, ie. input is [A-Z 0-9] (base36 as I learned in the comments below) and output is the same, one character at a time. The old enigma does a good job at doing this, but is obviously broken.

The cipher doesn't necessarily have to be usable "by hand" (as the "classic ciphers" per definition do), yet it would be interesting if it would.

Is there such a cipher that maps input to output 1:1 and which keeps the output within the above bounds (or maybe ASCII 7bit)?

Of course I know about base64 and codegroup, yet the first uses small letters and the latter doesn't map 1:1.

If such a cipher doesn't exist or is not feasible I'd be interested in "why" - why can't we map 1:1 and why can't the output stay within certain "bounds"?
The other answer correctly explains how we could make a modern stream cipher, with a public random IV at the beginning of ciphertext used (together with the key) in the setup of a keystream generator, restricted to the range $[0..35]$, and using addition modulo $36$ (Beaufort cipher) to encipher each character.

Here is a more detailed description of such a system, built from AES-128 in CTR mode. Encryption goes:


Randomly generate an IV of 12 bytes using 24 hexadecimal dice throws (some of the first hexadecimal digits can be replaced by a public message number, origin/destination if that's public, the date.., but enough randomness must remain so that the IV is unique with overwhelming odds); the IV will form the beginning of the ciphertext;
Initialize the counter $N$ to the IV followed by 32 zero bits (that will be a 128-bit quantity), and $\text{available raw keystream}$ to empty;
While there is a character $p$ to encipher, converted to an integer in range $[0..35]$ per some public table;


Repeat ..


If $\text{available raw keystream}$ is empty


(optional) stop with plaintext too long if the rightmost 32 bits of $N$ are all ones; that will occur after over 33 billion characters have been enciphered.
Set $\text{available raw keystream}$ to the 8 bytes formed by encrypting $N$ using AES-128 and an agreed secret key;
Increment (the low 32 bits of) the 128-bit $N$

Get the leftmost byte $b$ of $\text{available raw keystream}$, and remove it;

.. until $b&lt;252$ (that's $2^8-(2^8\bmod36)$);
$b\gets b\bmod36$; that's our uniformly distributed keystream character in the range $[0..35]$;
$c\gets p+b\bmod36$, output that ciphertext character (converted per the public table);



Decryption works as:


Acquire IV as the beginning of the ciphertext, over the first 24 symbols;
Initialize the counter $N$ to IV followed by 32 zero bits (that will be a 128-bit quantity), and $\text{available raw keystream}$ to empty;
While there is a character $c$ to decipher, converted to an integer in range $[0..35]$ per the public table


Repeat ..


If $\text{available raw keystream}$ is empty


Set $\text{available raw keystream}$ to the 8 bytes formed by encrypting $N$ using AES-128 and the agreed secret key;
Increment (the low 32 bits of) the 128-bit $N$;

Get the leftmost byte $b$ of $\text{available raw keystream}$, and remove it;

Until $b&lt;252$;
$b\gets b\bmod36$; that's the same uniformly distributed keystream character in the range $[0..35]$ that was used for encryption;
$p\gets 36+c-b\bmod36$, output that plaintext character (converted per the public table).





This is modern; academically secure from a confidentiality standpoint; and answers the question as worded; but has serious operational drawbacks:


The message is not authenticated; an adversary can replace the ciphertext by one that will decipher to another message, and if the original plaintext is known, the adversary can make the substitution decipher to whatever the adversary wants, without knowing the key.
That works, to a degree, with partial knowledge of the plaintext. If for example the adversary knows that a 19-character messages is of the form AMOLEFT123REPEAT123, and the digits are encoded to 0..9 in the public table, and the number encoded is in range [000..299], then increasing the 8th and 17th character of the ciphertext by 2 (modulo 36) will increase the transmitted number by 200, perhaps giving the impression that there is ample amo, when really there is shortage.
If the IV does not contain the date, there's an even simpler attack: replay an old message from a past day where the amo stock was high.
Any error in the IV makes the whole ciphertext undecipherable (that can be fixed by sending the IV thrice, a primitive form of Forward Error Correction).
Even an accidental error in the ciphertext can go undetected.
A slip in the ciphertext (loosing synchronization between sender and receiver) makes the message following the slip garbled (this can often be detected and largely fixed using the redundancy in the plaintext);
If the ciphertext is transmitted in morse code, even though it has (within the constant overhead of the IV) the same number of characters as the plaintext, it is significantly longer to transmit than the plaintext, because frequent symbols in the plaintext use short morse sequences, but that optimization is lost for the ciphertext.


Therefore, a good modern system (say, engineered to comply to rules of a contest or ancient treaty stating that messages must be sent using morse code by human operators, but not banning computers for anything else) will work quite differently:


The plaintext will be compressed as the first step of encryption. One possible way to do this is to use e.g. gzip, with constant public fixed prefix to the plaintext consisting of public dummy plaintext with the same characteristic as the real plaintext (same character set, frequent words and sentences), and the constant compressed header resulting from this suppressed from the gzip output; this will give fair compression, and adapt easily to any alphabet and usage pattern. A caveat is that using infrequent words and sentences in the actual plaintext will lower the compression ratio, which will be detectable to some degree from the length of the ciphertext.
The resulting compressed plaintext bytestream will be enciphered using a scheme also providing message integrity. If we stick to symmetric crypto, AES-GCM comes to mind. With integrity insured, replay can be made detectable by putting a sequence number (or UTC date/time) in the message. Or we could move to asymmetric crypto (with the advantage that if the enemy fully compromises a sending station, that still does not allow decryption); if done right (hybrid encryption), it will add very little overhead.
The resulting ciphertext will be re-encoded to morse code using a method optimized for the medium at hand (with frequency of output symbols inversely proportional to their transmission duration; thus more E encoded as " . " than there are 0 encoded as " — — — — — "), and providing some degree of forward error correction. Techniques like Hufffman or arithmetic coding, and Reed–Solomon error-correction (or some ad-hoc system), will be used.


All in all, even for short messages, the ciphertext will transmit faster than for the previous system, while insuring message integrity; and for large messages the ciphertext will transmit several times faster than the plaintext would have.