[Cryptography] Cryptographic archive format

[Phillip Hallam-Baker]

[Yes, I have researched ZIP, yes, it is easier to chuck away the legacy and
start from scratch, no, it is not useful to discuss these design
parameters.]

So, one application for the Mesh is to enable people to exchange 'encrypted
ZIP files'. The encryption here being threshold encryption.

So Alice (@alice) is working on a project, she creates a callsign for the
project @groupw and encrypts a bunch of files.

meshman dare archive /out=secrets.dar
meshman dare append secrets.dar file1.txt
meshman dare append secrets.dar file2.txt

At this point, nobody can read them, not even Alice, she wants to share the
data with Bob so she adds them both to group W:

meshman group add @groupw @alice
meshman group add @groupw @bob

Bob now has access to the files and can decode them. But only so long as he
is a member of the group. If Carol replaces Bob on the team, Alice can
remove Bob from groupW and replace him with Carol.

The trick here is that Bob and Carol can access the files they have been
authorized to access at any time. Alice doesn't need to be online. They can
read any file that has been encrypted to group W without any changes to
that file. The cloud service running the key server cannot decrypt any file
ever. That is only possible if an authorized user also defects.

So assume this is integrated into Word, Powerpoint, Excel, etc. Alice, Bob
etc. can all do their work using encrypted documents and share them with
exactly the same ease of use as for unencrypted. The only constraint being
that Alice has to agree.

[NB, this is only confidential document control, not full CRM. If Bob can
decrypt a document, he can also create a copy for Mallet. but that is a
separate problem]

The key service is a minimal trust service but not zero trust. The reason
it is not zero trust is that 1) the service is trusted to grant access to
Bob when authorized, 2) the service is trusted to deny access to Bob after
he has left the group and 3) we will almost certainly want to add
accounting and velocity controls to the key service to implement additional
controls beyond basic access.


OK so that is why I need a new format, it is simply not worth the effort to
back-haul the necessary changes into an existing scheme and the systems
won't be compatible anyway. Another difference is that the new format is
not a compression format for good reasons I won't go into here. the TL;DR;
is that compression is better applied at the application file level these
days. There is no value to compression in an archive format when people are
archiving bundles of JPGs. It might make sense to automatically encode HTML
in Brotli but for most purposes the value is likely small.

Now the (hard) question:

What precautions do I need to take in recording file paths in the archive?

The risk here is that someone crafts a malicious file path and sticks it
into an archive so that the files end up overwriting the system files.

So I have been compiling a list of dangerous file paths.

~<anything>
/<anything>
\<anything>
a:<anything>
<anything>/../<anything>
../<anything>
<anything>/..

Any I am missing? The plan here is to ban these for the format itself so
these are prohibited on Windows and Linux and OSX.

Of course, this means there will be files that can't be encoded but that is
a secondary issue.

The type of attack I am concerned about are malicious paths like:

~alice/.ssh/authorized_keys
c:/Windows
//./com1

And so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20201221/c5291218/attachment.htm>