<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 2, 2021 at 1:44 AM John Levine <<a href="mailto:johnl@iecc.com">johnl@iecc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">When you send e-mail messages, you can attach files, which are normally<br>
base64 encoded and included in the message.  That doesn't work very well<br>
when people try and attach gigabyte videos, so the usual workaround is<br>
to put the attached file on a web server and include the URL in the message.<br>
<br>
It turns out that back in the 1990s MIME defined message/external-body in<br>
RFCs 2017, 2046 and 2912, which lets you include the pointer and metadata<br>
like the size and an expiration date, and treat the external file as though<br>
it was part of the message.  We're trying to resuscitate it<br>
and make the semantics as close as possible to an attachment in the message itself.<br>
<br>
A colleague had the bright idea to include a hash of the file, to<br>
optionally encrypt the file with a symmetric key, and put the hash and<br>
the key in the message. That keeps the existing semantics that if you<br>
have access to the message, you can read its contents.  The hash<br>
avoids games where a malicious sender pointsto a file which<br>
is benign when the message is received and the anti-malware runs,<br>
later replaced with something malicious which the user then retrieves.<br>
<br>
We already have PGP and S/MIME and STARTTLS to deter snooping on mail<br>
so there's no need to reinvent them.<br>
<br>
My question is what algorithms to use? The file can be anything up to<br>
several gigabytes so they should be reasonably fast. It's OK if the hash<br>
and key are fairly large, since a few hundred or even a few thousand<br>
bytes in a mail message is not a big deal these days.<br><br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default"><br></div><div class="gmail_default">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.</div><div class="gmail_default"><br></div><div class="gmail_default">Decryption can be gated by additional factors through threshold crypto. So, need the EARL plus authorized account.</div><div class="gmail_default"><br></div><div class="gmail_default"><a href="https://www.ietf.org/archive/id/draft-hallambaker-mesh-udf-12.html">Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint. (ietf.org)</a><br></div><div class="gmail_default"><br></div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I plan to replace/supplement the KDFs with KMAC at some point.</div><div class="gmail_default" style="font-size:small"><br></div></div></div></div>