[messaging] Two-party consensual file access

[B Da Bahia]

Thank you Ian and others. And apologies for the understatement of the
problem. Let me try one more time.
The whole idea is to allow consensual creation and reproduction of
confidential content.
Both Alice and Bob could create content involving both of them (contracts,
videos, collaborating editions, etc) in either one's computing device, for
which none of them has privileged (root) access. Trusted software runs on
both devices. Content is generated in say, Alice's device once Bob has
granted his consent for that. Right after content creation, it should be
immediately encrypted and stored that way and replicated on both devices,
controlled by the trusted software. If later on, any of them wants to open
that content, he/she would have to request for the other party's consent
again. And in that situation, through some secret sharing technique,
reproduction would occur for a limited time on the petitioner's device
under the control of the trusted software. While file is open/reproduced,
no on-device recording mechanisms is allowed.

I've thought about a relatively simple (and most probably awful) solution.
Both parties have their pair of Pub & Priv keys created and managed by the
trusted software on each device. Trusted software maintains a database of
file metadata (with both parties pub keys, and a nonce randomly assigned to
every new file's entry) replicated on both devices. Alice and Bob generate
their subkeys for symmetric de/encryption by digitally signing each file's
metadata. Encryption/Decryption keys are merely the concatenation of both
parties subkeys. Consent request includes digitally signing part of file's
metadata, and the action verb (create, open, export, etc). Consent reply
includes digitally signing the file's metadata.
I'm sure this is horrible and that's why I requested for some pointers from
people with more experience than me.
Thanks!

On Fri, Mar 29, 2019 at 5:27 PM Ian Goldberg <iang at cs.uwaterloo.ca> wrote:

> On Thu, Mar 28, 2019 at 08:28:41PM -0700, Max Skibinsky wrote:
> > As Ben mentioned, who encrypts the file is crucial differentiator. Either
> > you can accept one party knows contents of the file beforehand, or you
> need
> > to solve quite different challenge first — how file content is created in
> > the encrypted form without either party ever having full plaintext.
> >
> > If it is acceptable that one party does encryption as the first step,
> then
> > indeed *n/n* Shamir schema is the way to go. We did a lot of thinking how
> > an application for Shamir split/storage/restore of high-value files
> should
> > work, you can take a look at our whitepaper
> > <https://vault12.com/technology/> , section 4 outlines some practical
> > storage scenarios.
>
> Why would you use Shamir for an "n/n" situation?  You can use much
> simpler schemes if you don't need the flexibiliy and robustness of
> Shamir.  In this particular case, you can even just do "encrypt the file
> with Alice's public key, and then that ciphertext (at least the part
> encrypting the underlying symmetric key) with Bob's public key",
> assuming the two parties allowed to decrypt are known at encryption
> time.
>
> Also unstated is whether it's important that, say, Alice be able to
> prove she performed her stage of the decryption successfully.  That can
> also be pretty straighforward with ZKPs if the public-key encryption is
> something ElGamal based or similar.
>
>    - Ian
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20190329/ce50693f/attachment.html>