Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need efficient way(possibly as strong as AES or AES itself) to enrypt (only) aplhanumeric data and get out only alphanumeric data, using some known library (i don't want and intend to implement AES myself).

share|improve this question

closed as off-topic by NULLZ, TildalWave, Adi, Scott Pack, Gilles Jul 6 '13 at 20:45

  • This question does not appear to be about Information security within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

Could you encrypt it using AES and then base64 the result? That'll give you alphanumeric data as the result. – Joshua Jul 5 '13 at 20:28
@Joshua Base64 produces 2 (or 3 if you count padding) special characters. So it might not fit the alphanumeric requirement. – CodesInChaos Jul 5 '13 at 20:32
This question appears to be off-topic because it is about Crypto and would better fit our sister site – NULLZ Jul 5 '13 at 20:59
@CodesInChaos, very true and a very good point. I was treating alphanumeric as printable characters and not strictly as [a-z0-9]. – Joshua Jul 5 '13 at 21:28
up vote 3 down vote accepted

Encode the input as some bytes, encrypt that, and encode the encryption output in hexadecimal, which is, by definition, alphanumeric. This is simple enough to implement and will piggyback on an existing implementation of AES or whatever encryption system you envision.

Now this will imply some growth in size, because:

  • Encryption will need some IV (characteristics depend on the mode of operation with which you use AES) and that IV will have to be made part of the output (that which you convert in hexadecimal) because it will be needed for decryption.
  • Depending on the mode of operation, some padding may have to be applied, so that the input data length is a multiple of some value.
  • Proper symmetric encryption also includes some sort of MAC, because most situations where encryption is warranted also need, in practice, some protection against active attackers; and that MAC will again increase the length.
  • With hexadecimal, each byte becomes two characters.

Some of these growth elements can be mitigated. For instance, if the encryption mode you use is GCM or EAX, then there will be no need for padding, the extra size for the MAC part will be limited (16 bytes)(and a very nice property of GCM and EAX is that they take care of the MAC in a cryptographically sound way, contrary to most homemade constructions) and the IV needs only be unique, not random, and thus can be a simple counter (which could be encoded over four bytes or so, depending on the context). Also, you could replace hexadecimal with Base64, which implies less growth (note that raw Base64 uses both lowercase and uppercase letters with distinct meanings; also, it uses two extra non-alphanumeric characters '+' and '/'; but a Base62 encoding which uses only digits and letters would not be hard to design and implement).

If the output must have the same size as the input, then things become a lot more tricky. You won't be able to reuse an existing library, or even AES at all. This is the realm of Format Preserving Encryption, which is more a research area than a tool ready for production, unless you are a trained cryptographer and you know what you are doing, in which case everything I wrote above was trivial (for you) and you needn't read it.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.