On 03/27/2014 06:03 AM, Michael Rogers wrote: >> In an online-encrypted document sharing model, for the 98%, this >> would look like a document being OpenPGP-encrypted in javascript >> with a symmetric key you choose, and stored online by the service. >> The recipient visits the fileshare, using javascript >> OpenPGP-decrypts the document using the password they received >> out-of-band, and downloads it. For the 2%, they PGP-encrypt the >> document using gpg, and upload it, communicate the secret out of >> band, and the recipient decrypts it using javascript. Or, they >> receive a document encrypted with javascript and download it and >> PGP-decrypt it using gpg. If you build the service correctly, the >> service won't know ahead of time if the document is going to be >> decrypted in javascript or gpg, and thus can't reliably attack the >> user without a chance of detection. > > If I understand correctly, this would require signatures as OpenPGP > doesn't provide MACs, and the public signature key would have to be > shared out-of-band along with the password.
For the read-only document-sharing use case, you could stuff the public
signing key inside the encrypted body, in addition to the signed
cleartext. There's no need for it to be out-of-band except for
bandwidth conservation, but a minimal OpenPGP certificate
(mainkey+uid+selfsig, or mainkey+uid+selfsig+signingsubkey+selfsig at
worst) isn't going to be too terribly large compared to most files.
for the read/write document-sharing case, you'd have two divergent
scenarios: one where each participant signs their new version of the
document with their signing key; and another where you've also
pre-shared a the secret part of a document-specific signing key with all
parties.
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
