In my understanding, PGP based encrypted email is implemented with (1) symmetric encryption using a shared secret, and with (2) asymmetric encryption of the shared secret under the public key of each party in the email exchange.
What are the semantics of addKeys (see also Draft API specification) after the cryptographic operation was started.
The cryptographic operation, i.e. the encryption of the PGP/MIME document, is triggered by one of multiple situations:
- The user calls
process on a job, this returns a (variation on) ReadableStream.
- The job is optimized for speed, triggering
ReadableStream-based encryption when the size-treshold for the job was exceeded.
Is it possible to add keys at a later stage, after the cryptographic operation has started? This would only be possible if the asymmetrically encrypted shared secret can be appended or prepended to the PGP encrypted message at the end of the cryptographic operation. I need a better understanding of the PGP standard to answer this question. In any case, the underlying implementation of PGP (OpenPGP.js) would have to support it.
Possible workaround
- Tracking the status of a job, (i.e.
staging, locked or processing, and complete) with the addKeys operation becoming unavailable as soon as the job is locked.
- Adding and API to
unlock a job, thereby returning to the staging status and throwing away any work that was done.
- This would also introduce the obvious feature of restarting the cryptographic operation on a job after reaching
complete, simply by calling yield.
- In order to avoid duplicate work under the previous scenario, it might be necessary to track a job
changed flag.
This workaround, especially introducing an unlock API, has the obvious downside that the need for ReadableStream-based encryption becomes non-obvious. I introduced this API for clients to start submitting/streaming the resulting ciphertext before the cryptographic operation has completed. What would the semantics be under this scenario? Is it possible for clients to recall or terminate an ongoing submission?
In my understanding, PGP based encrypted email is implemented with (1) symmetric encryption using a shared secret, and with (2) asymmetric encryption of the shared secret under the public key of each party in the email exchange.
What are the semantics of
addKeys(see also Draft API specification) after the cryptographic operation was started.The cryptographic operation, i.e. the encryption of the PGP/MIME document, is triggered by one of multiple situations:
processon a job, this returns a (variation on)ReadableStream.ReadableStream-based encryption when the size-treshold for the job was exceeded.Is it possible to add keys at a later stage, after the cryptographic operation has started? This would only be possible if the asymmetrically encrypted shared secret can be appended or prepended to the PGP encrypted message at the end of the cryptographic operation. I need a better understanding of the PGP standard to answer this question. In any case, the underlying implementation of PGP (OpenPGP.js) would have to support it.
Possible workaround
staging,lockedorprocessing, andcomplete) with theaddKeysoperation becoming unavailable as soon as the job islocked.unlocka job, thereby returning to thestagingstatus and throwing away any work that was done.complete, simply by callingyield.changedflag.This workaround, especially introducing an
unlockAPI, has the obvious downside that the need forReadableStream-based encryption becomes non-obvious. I introduced this API for clients to start submitting/streaming the resulting ciphertext before the cryptographic operation has completed. What would the semantics be under this scenario? Is it possible for clients to recall or terminate an ongoing submission?