[Cryptography] How should we encrypt external mail attachments

[John-Mark Gurney]

John Levine wrote this message on Sun, Aug 01, 2021 at 14:59 -0400:
> 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.

You might want to look at IPFS[1], which already deals with something
similar, that is, a single hash used to identify a larger file.

The base hash algorthim should be SHA-512/256 or SHA-3 or blake2.  How
they are used is another question.

For hashing large files, using a Merkle tree to allow both parallel
hashing (allowing multiple cores to process the file at the same time)
and partial verification (say seekable mp4 video file) would be good,
but other than the IPFS mechanism, I don't know of a standard that talks
about how to do this.

But at the same time, most d/l speeds are significantly slower than any
hash algorithm, as they are all in the multiple 100MB/sec range on modern
processors, so the speed of a hash isn't that big of an issue.

Another option would also be to use a .torrent file, but the issue w/
BitTorrent is that it uses SHA-1, so would not satisfy the security
requirement you have.  It does look like there is a new BitTorrent
v2[2]
that updates the hash to sha-256 to address this.

I did just find THEX[3], but it likely isn't widely used.

[1] https://docs.ipfs.io/concepts/content-addressing/
[2] https://blog.libtorrent.org/2020/09/bittorrent-v2/
[3] https://adc.sourceforge.io/draft-jchapweske-thex-02.html

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."