[fix] TXT encryption broken

[mobad]

Describe the bug

Description:
If you use https://forwardemail.net/en/encrypt to encrypt a TXT record you'll notice that you only get a short base64 value no matter how long the input email is and that value gives errors when used as a TXT record.

I think the issue is

forwardemail.net/helpers/encrypt-decrypt.js

Line 26 in 2b6f50a

.toString('hex')

(Or at least part of the issue, not sure why the output is so short and doesn't include the '-' part after the IV)

Here it generates a random IV of length 12 then converts it to hex then takes the first 12 bytes, but since a hex string doubles the string length this only gets 6 actual bytes.
It also looks like createCipheriv expect a binary IV so providing hex would also reduce entropy.
Not sure if something similar isn't happening with the encryption key as well.

It looks like the gist used as an example has some issues that were addressed here https://gist.github.com/vlucas/2bd40f62d20c1d49237a109d491974eb?permalink_comment_id=4902700#gistcomment-4902700

Also the API has an incorrect cURL example https://forwardemail.net/en/email-api#encrypt
It should be -d "input=email"

[titanism]

We're taking a look

[titanism]

@mobad thank you for the report, this is now fixed per 092039c

please try again if you need anything else let us know

[mobad]

@titanism I just tried it out and it looks like it probably produces a proper string now but it still doesn't verify when I set it as a the TXT record.

Looking at the commit it looks like the encrypt function is still producing bad IVs as it's still converting to hex before slicing.
Check out https://gist.github.com/vlucas/2bd40f62d20c1d49237a109d491974eb?permalink_comment_id=4902700#gistcomment-4902700 for the updated example encryption code.

Also it looks like it switched from chacha to AES dunno if that was intended it was mentione to be chacha in a public discussions.

[titanism]

This is fixed, thanks, we had to add backwards compat support at 9bbc2de

[titanism]

And RE: chacha - yes this is intended, we had to rollback because of a bug with chacha (as you may see that encrypt-decrypt function helper is a mess right now due to this and having to add backwards compat support, but we'll improve in future)

[mobad]

And RE: chacha - yes this is intended, we had to rollback because of a bug with chacha (as you may see that encrypt-decrypt function helper is a mess right now due to this and having to add backwards compat support, but we'll improve in future)

The issue is that if the IV issue isn't fixed it weakens the encryption and will also make backwards compatility a pain.
Once it's fixed the IV portion in the TXT record will be a 32 byte hex string and will need to be converted from hex to binary but with the current implementation it's a 16 byte hex string that is directly used as the IV so to preserve backwards compatility with the current TXT record (which probably aren't being used currently so it would be fine to break imo) you'd need to detect the IV length and do different things based on the length.

Also just a minor suggestion since TXT records are limited to 255 bytes it probably makes more sense to make the TXT record:
forward-email=(base64ed raw binary IV)-(base64ed raw binary ciphertext)
(They need to be base64ed separately as the raw binary stuff can contain "-" though you technically could also just take the first X bytes as the IV but that would complicate things if the encryption algorithm changes.)

Converting everything to a hex string doubles the length and base64 adds another 1/3 while just base64ing the raw ciphertext only adds 1/3.
With the current implementation the max length of an email would be 79 characters before the TXT record goes over 255 but getting rid of the hex strings should roughly double that.

FYI one issue with regards to ChaCha is that it uses a 64 bytes block size vs the 16 byte block size meaning the output ciphertext will always be in multiples of 64 so once you give it a 65 byte email it would output 128 bytes which would also shorten the max input email length by a bit.