[Cryptography] How should we encrypt external mail attachments

[Phillip Hallam-Baker]

On Mon, Aug 2, 2021 at 1:44 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.
>
>
I make an extensive proposal here (see EARL section), basically it is a URI
that combines a locator and decryption key so that the EARL is a bearer
token for the content.

It can be printed out as a QR code. So your gas bill can have a link to the
digital invoice, a patient chart has a link to their records, etc.

Decryption can be gated by additional factors through threshold crypto. So,
need the EARL plus authorized account.

Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint. (ietf.org)
<https://www.ietf.org/archive/id/draft-hallambaker-mesh-udf-12.html>

Algorithmically, it is just HMAC-KDF being used to generate the nonce, key
and the locator as separate outputs. The key is always 256 bits but the
work factor can be less if you want a shorter URI.

The URI is base32 encoded with separators every 4 chars for readability. I
can't remember what the code does now but it should be the canonicalized
URI goes into the KDF, not the decoded URI (base 64/32 decoders can leak
information through side channels).

I plan to replace/supplement the KDFs with KMAC at some point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210802/03ae8a6f/attachment.htm>