Which symmetrical encryption algorithm to use to encrypt e-mail address(short message)?

Question

Which symmetrical encryption algorithm to use to encrypt e-mail address(short message)? I would like to have ciphertext to be comparable in length to paintext.

Answer 1

I would suggest looking into PGP.

Answer 2

ROT13 or a substitution cypher might work (keys can be changed or exchanged). Encryption with keeping the original text length is...not really that good.

Bobby

Answer 3

According to Little known features: Symmetric encryption with PGP/GPG:

A little known feature of both PGP and GPG is that they can also do symmetric encryption. Just a passphrase is needed- no public or private keys are involved. It’s a quick and dirty way to get strong encryption that even a novice can use.

To encrypt a file with symmetric encryption, the syntax is:

pgp --symmetric filename

gpg --symmetric filename

The result is a binary file with the same name as the original and ".pgp" or ".gpg" appended.

If the encrypted file must be pasted into the body of an e-mail message (instead of added as an attachment), you’ll want to use the plain ASCII form of output:

pgp --symmetric --armor filename

gpg --symmetric --armor filename

The result is a plain text file ending in ".asc"

Decryption is performed using the usual "-d" switch:

pgp -d filename

gpg -d filename

But I'm not sure this is what you're looking for. Maybe you can clarify your question.

Answer 4

To have cypher results comparable with plain text is not a good idea, having differents lenghts is a part of what encryption is about.

I will suggest you one of the most secure encryption algorithms today: AES

But forget about having comparable sizes!

Answer 5

If you really want to have the cipher text comparable in length to the email address, you can use a block cipher in a mode like CFB or OFB that allows encryption of one byte at a time.

However, I don't recommend it, because that gives an attacker a little information about what the message is (how long is the message?). Using an algorithm like 3DES or AES with 16-byte blocks in CBC mode with PKCS #5 padding, most email addresses will be encrypted in two blocks.

Answer 6

I see there is a bit of confusion about lengths of plaintext/ciphertext. Actually, those lengths are quite similar if you use a symmetric encryption algorithm.

Consider a block cipher (e.g. AES). It encrypts 128-bit blocks into 128-bit blocks. So if your plaintext is exactly 128 bits (or its multiple), AES in any mode of operation will produce the ciphertext with the same length. If your plaintext length is not a multiple of 128 bits, then it will get padded to the full block and the ciphertext will be slightly longer (by at most 127 bits). You still can avoid that by using some tricks like ciphertext stealing.

If you use a stream cipher, the encryption process is just XOR-ing bits (or bytes) of the plaintext with bits (or bytes) of the keystream and then the length of the ciphertext is by definition equal to the length of the plaintext.

To answer directly your question, if you don't need any specific format of the encrypted email, just use AES. If you want the encrypted email to be also in the format of an email, you may want to check how Format-Preserving Encryption works.

@Bobby: ROT13 is NOT an encryption algorithm.

Answer 7

Symmetric block ciphers produce the same length as the input, in multiples of block size (usually 8 bytes or 16 bytes for AES). Because the output is always multiple of block sizes (in fact the output is always the same size as the input and the input must be multiple of block sizes) then you cannot know the original size of the plain text. Common encryption schemes solve this by adding a padding scheme, like PKCS, ISO 10126 or ANSI X923. These schemes place information about the original clear text length in the last block.

If the clear text size is multiple of 8 (16 for AES) then one more block is added to the encrypted text. If the original size is not multiple of block size, then the encrypted size will be rounded up to the next multiple block size.

To this you should add a salt value for each record. A salt (or initialization vector, to be correct) has the same size as a block. Usually is stored in front of the encrypted block.

And finaly you should sign the encrypted value for validation, so you should add a SHA digest, another 20 bytes, otherwise you cannot know for sure if the decrypted value is correct.

So the overall size is (considering AES): 16 bytes (salt) + (clear text size + 20(hash) ) + (16 - (clear text size + 20)%16).

So for [email protected] (lenght 22) the encrypted size will be 16+22+20+(16-10)=64. To decrypt you take the first 16 bytes as salt, decrypt the remaininf 48, the output is lenght 42, you digest SHA the 42-20 = 22 bytes and compare the digets with the last 20 bytes of the decrypted text for validation.

I know is maybe more than you bargained for, but every step in this scheme has a justification.