[Cryptography] How should we encrypt external mail attachments

Ron Garret ron at flownet.com
Mon Aug 2 09:07:10 EDT 2021


On Aug 1, 2021, at 11:59 AM, John Levine <johnl at iecc.com> wrote:

> When you send e-mail messages, you can attach files, which are normally
> base64 encoded and included in the message.  That doesn't work very well
> when people try and attach gigabyte videos, so the usual workaround is
> to put the attached file on a web server and include the URL in the message.
> 
> It turns out that back in the 1990s MIME defined message/external-body in
> RFCs 2017, 2046 and 2912, which lets you include the pointer and metadata
> like the size and an expiration date, and treat the external file as though
> it was part of the message.  We're trying to resuscitate it
> and make the semantics as close as possible to an attachment in the message itself.
> 
> A colleague had the bright idea to include a hash of the file, to
> optionally encrypt the file with a symmetric key, and put the hash and
> the key in the message. That keeps the existing semantics that if you
> have access to the message, you can read its contents.  The hash
> avoids games where a malicious sender pointsto a file which
> is benign when the message is received and the anti-malware runs,
> later replaced with something malicious which the user then retrieves.
> 
> We already have PGP and S/MIME and STARTTLS to deter snooping on mail
> so there's no need to reinvent them.
> 
> My question is what algorithms to use? The file can be anything up to
> several gigabytes so they should be reasonably fast. It's OK if the hash
> and key are fairly large, since a few hundred or even a few thousand
> bytes in a mail message is not a big deal these days.

First, I think this is a fantastic idea.  It’s an idea I’ve toyed with in the past but never gotten around to actually implementing.  Kudos and good luck.

Second, as to which algorithms to use, I would strongly recommend not making this choice, but rather to include this information in the meta data and allowing users to choose.  Algorithms come and go but standards are forever.  You could define a set of preferred alternatives, but hard-coding a crypto algorithm into a communications standard is generally a bad idea.

Personally, I’m a big fan of NaCl (i.e. Salsa20 and SHA512) but of course AES and Blake are commonly used and good choices as well.  There are probably others I don’t know about, I haven’t really been keeping up with the state of the art.

One thing strikes me as a little odd about your question: you say you want symmetric encryption, but also that it’s OK for the key to be large.  Symmetric keys are never large.  256 bits is the biggest you will ever see.  Anything more than that is serious overkill and indicative of a bad design.  (Asymmetric keys are a whole different matter, of course.)

rg



More information about the cryptography mailing list