<div dir="ltr"><div>Thank you Ian and others. And apologies for the understatement of the problem. Let me try one more time.</div><div> The whole idea is to allow consensual creation and reproduction of confidential content.</div><div>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.</div><div><br></div><div>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.</div><div>I'm sure this is horrible and that's why I requested for some pointers from people with more experience than me.</div><div>Thanks!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 29, 2019 at 5:27 PM Ian Goldberg <<a href="mailto:iang@cs.uwaterloo.ca">iang@cs.uwaterloo.ca</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">On Thu, Mar 28, 2019 at 08:28:41PM -0700, Max Skibinsky wrote:<br>
> As Ben mentioned, who encrypts the file is crucial differentiator. Either<br>
> you can accept one party knows contents of the file beforehand, or you need<br>
> to solve quite different challenge first — how file content is created in<br>
> the encrypted form without either party ever having full plaintext.<br>
> <br>
> If it is acceptable that one party does encryption as the first step, then<br>
> indeed *n/n* Shamir schema is the way to go. We did a lot of thinking how<br>
> an application for Shamir split/storage/restore of high-value files should<br>
> work, you can take a look at our whitepaper<br>
> <<a href="https://vault12.com/technology/" rel="noreferrer" target="_blank">https://vault12.com/technology/</a>> , section 4 outlines some practical<br>
> storage scenarios.<br>
<br>
Why would you use Shamir for an "n/n" situation?  You can use much<br>
simpler schemes if you don't need the flexibiliy and robustness of<br>
Shamir.  In this particular case, you can even just do "encrypt the file<br>
with Alice's public key, and then that ciphertext (at least the part<br>
encrypting the underlying symmetric key) with Bob's public key",<br>
assuming the two parties allowed to decrypt are known at encryption<br>
time.<br>
<br>
Also unstated is whether it's important that, say, Alice be able to<br>
prove she performed her stage of the decryption successfully.  That can<br>
also be pretty straighforward with ZKPs if the public-key encryption is<br>
something ElGamal based or similar.<br>
<br>
   - Ian<br>
_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
</blockquote></div>