# Secure symmetric encryption algorithm for any-size base62 data

I am searching for a secure algorithm to encrypt base62 (or any other base) data for ids in urls.

It should feature:

• No blocksize etc, limiting the length of the message to a factor of n
• If you have the decryted and the encrypted message you should not be able to guess the key
• An avalanche effect
• Any size of charset, not only 256 like in AES, DES etc.
• High performance on modern CPUs

This is not required:

• Streaming, it is only for small data

Is this possible?

• I have a few ciphers like that, BUT they each have a very specific block size (35, 40, 42, 48 bits) and have i/o in 5 or 6-bit character sets, their purpose to be a secure permutation for URL generation from a counter Commented Nov 16, 2014 at 11:23
• Pastebin uses 8 base62 characters for his IDs. Does Pastebin uses random IDs which are also stored in the database?
– user18296
Commented Nov 16, 2014 at 11:32
• are you looking for format preserving encryption ? Commented Nov 16, 2014 at 14:52
• they probably do not store the counter used to generate it, it is not a necessity. i do not know the precise method that pastebin and imgur use, or if it is cryptographically secure Commented Nov 17, 2014 at 2:49
• So, important question: is it required that the result remains the same size or is the ciphertext allowed to be larger than the encoded URL? Commented Jun 6, 2015 at 14:38

If you define your encryption to be $C=E_{62}(E_k(D_{62}(P)))$ and your decryption to be $P=E_{62}(D_k(D_{62}({C})))$ where $P$ is your encoded URL then you've brought back your problem to finding an encryption function for $l$ bits, where $l$ is the size of $D_{62}(P)$. After that you can "just" look for a Format Preserving Encryption primitive for those $l$ bits. If the encrypted URL is allowed to be larger than the unencrypted URL then you could use CTR mode with a nonce of 8 random bytes.

• An 8-byte random nonce has a birthday bound of only $2^{32}$, which doesn't offer a lot of margin unless encrypting very few items. I would be more comfortable with either a counter value or a 128-bit nonce.
– otus
Commented Jul 7, 2015 at 11:37
• Also, would you mind defining your operators?
– otus
Commented Jul 7, 2015 at 11:38
• $E_{62}$ is encoding of data, $D_{62}$ is decoding, while $E_k$ is the encryption transformation using the FPE or the CTR cipher. I thought these functions would be clear. The 8 byte IV is the absolute minimum which indeed carries a risk. This risk could be worth it if the amount of data is small ("it is only for small data" can either be read as small packets or a minimal amount of data). Of course if there are many packets then the IV/nonce should be larger as the chance of a collision of the counter rises with the amount of blocks due to the birthday "paradox". Thanks for the warning @otus. Commented Jul 7, 2015 at 17:55

If I'm understanding things right you want something that can encrypt data at abritrary size with high speed. You have several options here:

• CTR mode. This turns any block cipher into a stream cipher allowing you to encrypt arbitrary amounts of data at high speeds. (cipher would be AES-128)
• a dedicated streamcipher like Salsa20 or ChaCha. They are high-speed and can encrypt arbitrary amounts of data

The only thing you'd need is an unique IV

• CTR mode with truncated output has collisions Commented Jun 6, 2015 at 3:38
• @RichieFrame, Indeed if you truncate the output of the encryption of the counter it has indeed collisions after $2^{64}$ blocks and without the truncations collisions will occur after $2^{128}$ blocks. But the OP stated that's only for small amounts of data and hence collisions shouldn't be a problem if CTR is used as a proper stream cipher. Commented Jun 6, 2015 at 10:15