Is there any algorithm capable of encrypt securely (symmetric) N numeric digits in a numeric message of M digits (N < M)? I am especially interested in a specific case in which N = 10 and M = N + 3. I tried the most famous algorithms, like DES and AES, but they did not get success. Does anyone know a way to encrypt messages with limitations like this?

  • $\begingroup$ I'm having a hard time understanding your question. Could you post an illustrative example? $\endgroup$ – mikeazo Dec 2 '15 at 13:18
  • $\begingroup$ Sure. For exemple, I have the 10 digits numeric data [0123456789] and want to encrypt (reversible) it in a message with the maximum size of 13 digits, like [9876543210321]. This exemple illustrate one case of N=10 and M=N+3. $\endgroup$ – John Smith Dec 2 '15 at 13:33

One way of doing this is using a Format Preserving Encryption method.

This is a symmetric encryption method that is designed to convert (potentially) small messages into encrypted messages of exactly the same size. For example, it may take strings of 13 decimal digits, and encrypt them into strings of 13 decimal digits.

One such method would be the FF3 method from NIST SP 800-38G; if you set radix=10, then it can encrypt a string of 13 digits, giving you a string of 13 digits (which is exactly what you want).

Here is how you would use it in your example: you would take your $N=10$ digit number, and extend it to $M=13$ digits by appending 3 0's. Then, you'd hand your string of 13 digits (and the key) to the FPE algorithm to encrypt, and it'll give you another string of 13 digits; that's your ciphertext. Decryption is the the opposite; FPE decryption of the 13 digits, and then strip off the last three 0's (and, if they're not 0, then the ciphertext was invalid)

There are existing techniques for encrypting messages that can't be expressed in an even number of radix digits; however since your messages can, there's no reason to involve those.

All three methods in 800-38G can handle radix=10; I suggest FF3 because the pseudocode listed for FF1 in the NIST draft is wrong (their decryption code isn't an exact inverse of their encryption code; yes, NIST knows this), and FF2 has known (academic) weaknesses.

| improve this answer | |
  • $\begingroup$ "you would take your N=10 digit number, and extend it to M=13 digits by appending 3 0's" Ignore these three digits would not decrease security in relation to the possible potential taking them into account? $\endgroup$ – John Smith Dec 2 '15 at 17:16
  • $\begingroup$ @JohnSmith: the security of the system I proposed lies entirely in the security of the FPE system (and the key, of course). The FPE system maps 13 digit values to 13 digit values; because your plaintext is 10 digits, we need to map those to 13 digits first before running the FPE system. As the security of the system doesn't rely on the mapping, it is easiest to use a trivial mapping (such as adding three constant digits). $\endgroup$ – poncho Dec 2 '15 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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