Share encrypted file

[markg85]

Hi,

As i understand the design, each file is encrypted with it's own key (derived from the master key).

Would it be possible in this mechanism to create a "share" function?

In public/private cryptography this would be as "simple" as encrypting that file's encryption key with someone else's public key.
That someone else then would place the encrypted file in it's own "securefs" folder. As the file would be encrypted against the "target public key", that folder - who can access the private key - should then be able to read the data from the shared file.

Now this share function is much described as how i know public=private key cryptography. It's not a thing in securefs a far as i know. But still, would it be possible to create a sort of share function with the cryptography it uses already?

Best regards,
Mark

[netheril96]

How do you plan the UX for this?

[markg85]

For this to make sense, some terminology first.
Say the "host" is the one having data to share.
Say the "op" (other party) is the receiving end of a share.
Say both "host" and "op" have a public/private keypair and both have their instance of securefs.

If the host wants to share a file (let's call it "cats.gif") it does this:
securefs share <file> <op public key>

Or more verbose:
securefs share cats.gif ~/.ssh/op.pub

This action should give "something" as data that the client needs to receive. So the "share" method in securefs is going to return a "data" blob.
Here you can go 2 routes:

1. The data blob is merely some metadata like publickeys of both parties, sign, and the encrypted filename as blob.
2. The data can be the file + additional metadata.

I'm picking option 2 for this example because it's easier transfer wise.

On the op side you'd do:
`securefs import

The op can decrypt it because the host encrypted it with the ops public key.

op now has a file called cats.gif and can view/use it however op wants.

Ideally cats.gif is never re-encrypted in this share mechanism. That would be possible if cats.gif is encrypted with it's own (but derived) AES key.

[netheril96]

You can do the same thing with gpg already. The only benefit of securefs in that scenario is to avoid re-encryption. But that is a very minor benefit given how fast encryption is, so I fail to see the appeal.

[markg85]

That is spread over multiple tools with quite a steep learning curve (gpg) to even consider using it.
Having it mostly all in one tool would make it much easier to use. The only part not in securefs would be the transferring from host to op or vise verse.

[netheril96]

The learning curve of GPG comes with the concept and the management of public/private key pairs. Moving that functionality to securefs does not lower the bar at all.