2
$\begingroup$

Could anyone guide me on how to implement FPE (Format Preserving Encryption) for Email address masking?

For example: if my ID is [email protected] then it should be encrypted something like [email protected]

Preserving the format and datatype.

Improve this question
$\endgroup$
9
  • $\begingroup$ That's the requirement. $\endgroup$
    – user65343
    Jan 25, 2019 at 6:54
  • $\begingroup$ Hi, yes. I have gone through FPE algorithm from idealista. I need thids for java implementation. But I am only able to crack through integers and string. Not able to encrypt alphanumeric or ones with special characters.. $\endgroup$
    – user65343
    Jan 25, 2019 at 6:59
  • 1
    $\begingroup$ The first thing is to precisely define what's acceptable as plain and encrypted email address (and if we want to dive into that, what is considered significant). As pointed in an answer, it might be a good idea that the ciphertext can't be an actual email, e.g. always end in .invalid $\endgroup$
    – fgrieu ♦
    Jan 25, 2019 at 10:20
  • 1
    $\begingroup$ "I need to convert it to lowercase" is doubtful: on some email systems changing case on the left of @ leads to a different (often inexistent) mailbox. RFC 5321 prescribes: The local-part of a mailbox MUST BE treated as case sensitive. Fact is email address syntax is horribly complex, variable (in particular, RFC 6531 supports UTF-8); plus it often is not implemented as specified. Until you define with precision what's acceptable as plain and encrypted email address, this question is not answerable as a crypto question. $\endgroup$
    – fgrieu ♦
    Jan 25, 2019 at 12:44
  • 3
    $\begingroup$ I'm voting to close this question as off-topic because, as currently stated, it is a programming question (at elementary level as shown by a comment). How to define a custom encryption scheme matching constraints on the plaintext and/or ciphertext space might be on-topic, but the question should come with some specification of the valid plaintext and ciphertext space (or at least consistent clues about that), and that's missing. $\endgroup$
    – fgrieu ♦
    Jan 25, 2019 at 13:01

1 Answer 1

Reset to default
2
$\begingroup$

Preserving the format of an email address (see RFC 5322 § 3.4.1) when encrypting it is quite easy. All you have to do is encode the ciphertext in base64 and prepend it to something like @a.invalid if you want to make sure that it cannot be resolved even by accident. This results in emails like this:

3IPRr5/[email protected]

That is a technically valid email address for a non-existent and non-resolvable domain.

Note that this does not preserve the length of the plaintext. If you wish to do that as well, you could use a dedicated FPE mode of operation as per NIST SP800-38G. Unfortunately, that would likely result in an email address that is invalid due to the fact that the format specified in RFC 5322 is too complex for it.

While not strictly FPE, you may be able to get what you want by using a Vigenère cipher with the key generated by a secure stream cipher, such as ChaCha20. The set of characters in the Vigenère key must be valid for that atom of the address. You must of course skip the @. This will preserve the length. Note however that it requires a more complicated construction as fgrieu pointed out, notably due to the fact that the IV would need to be stored separately or a unique key must be used for each email.

Improve this answer
$\endgroup$
7
  • $\begingroup$ I like the idea of preventing the transformed email from being accidentally misused. However, caution: A) the encrypt part fo the question is treated too lightly. Vigenère cipher with a stream cipher is either insecure or sizably expanding (due to the necessary IV), and neither is considered good FPE. B) Many applications won't accept the suggested encrypted format because they make checks against some variation of this. At least the final dot will cause issue. I even met systems which won't accept a local-part shorter than 2 characters. $\endgroup$
    – fgrieu ♦
    Jan 25, 2019 at 10:17
  • $\begingroup$ @fgrieu The final dot just turns it into a fully qualified domain name. And the purpose is to make it technically a correct email format, even if many email services will reject it. And you're right that neither are FPE, but they do preserve the format hopefully in accordance with what OP wants. $\endgroup$
    – forest ♦
    Jan 25, 2019 at 10:21
  • $\begingroup$ @fgrieu Providing more information about how to encrypt it safely seems too complex to address though. Do you have any suggestions for improvement without detailing the safety requirements for different modes of operation and the like? Perhaps I should just add a simple disclaimer not to roll your own? $\endgroup$
    – forest ♦
    Jan 25, 2019 at 10:28
  • $\begingroup$ My reading is that letting aside the special meaning of the word invalid (defined in 1999 by RFC 2606), invalid. is not a syntactically valid domain on the right of the @ of an email address. Again I know [email protected] is rejected as invalid by some existing applications, but I think most that ignore RFC 2606 and do not make an explicit DNS check of the domain part will accept [email protected]. $\endgroup$
    – fgrieu ♦
    Jan 25, 2019 at 10:34
  • 1
    $\begingroup$ @user65343: "how do you skip @ here?" is a programming question and straight off-topic here. Considerations about what is a valid email also are off-topic, except when they require adaptation of FPE. We only accept crypto question ! $\endgroup$
    – fgrieu ♦
    Jan 25, 2019 at 12:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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