Interruptible APIs for key agreement use cases #199
Conversation
athoelke
added
enhancement
athoelke
requested review from
gilles-peskine-arm,
MarcusJGStreets and
paul-elliott-arm
Provide interruptible operations for message and hash signature calculation and verification. Reworked information in this section of the API relating to the behavior of different types of signature algorithm, consolidating this to the section introduction.
* Align permitted errors with the single-part functions * Introduce the max_ops APIs
* Operation objects are now psa_xxx_iop_t, initialization PSA_XXX_IOP_INIT etc. * Operation and support functions use 'iop' as an infix instead of 'interruptible'
Require that one of psa_xxx_iop_hash() or psa_xxx_iop_update() MUST be called in an interruptible signature operation.
Added three new interruptible operation APIs: * psa_generate_key_iop_*() for key generation * psa_export_public_key_iop_*() for public key export * psa_key_agreement_iop_*() for key agreement
…rruptible operations
Permit an implementation to defer reserving the persistent key id when performing an interruptible key creation operation.
athoelke
force-pushed
the
crypto-interruptible
branch
from
dd94518
to
b714c2e
Compare
|
Rebased on main |
| Number of *ops* that the operation has taken so far. | ||
|
|
||
| After the interruptible operation has completed, the returned value is the number of *ops* required for the entire operation. | ||
| The value is reset to zero by a call to either `psa_key_agreement_iop_setup()` or `psa_key_agreement_iop_abort()`. |
There was a problem hiding this comment.
When we were discussing the specification, we implicitly assumed that setup takes negligible time. But this is not a safe assumption. For example, for key agreement, the public key needs to be validated. In Mbed TLS, we do this during setup (and it's the natural way to do it). Mbed TLS estimates the public key validation to take 3 ops. (The key agreement as a whole takes thousands of ops.)
So I think we should specify that setup resets the op count to 0 at the beginning of its operation, but then adds the number of ops that it takes. And recommend to implementations that this number should be lower than the value set with psa_iop_set_max_ops.
There was a problem hiding this comment.
This applies to all the functions, although key agreement might be the only one for which it's really natural to have setup take a few ops.
There was a problem hiding this comment.
That does complicate the way we can describe the reset of the ops value, but is a valid point. Is it sufficient to expect that validation will occur during setup, or should the recommendation be that if validation can be very complex (substantially more ops than a reasonable application-configured maximum) it should be deferred to the completion function?
Similar to the case for deferring key id allocation (PSA_ERROR_ALREADY_EXISTS returned by psa_key_agreement_iop_complete()), should we also permit psa_key_agreement_iop_complete() to return status codes related to the validation of the peer key? - which enables deferred validation.
There was a problem hiding this comment.
I think we should recommend that setup should only perform a small number of ops, preferably less than whatever was set by psa_iop_set_max_ops().
And I hadn't thought of that, but indeed we should allow complete() to return status codes related to validations that may be considered slow.
Add interruptible operations for
psa_generate_key(),psa_export_public_key()andpsa_key_agreement().This provides the new API elements, and updates the Functionality chapter to cover this simpler interruptible pattern, as well as the complex interruptible multi-part operations used for signature and verification from #107.
This is based on top of #107. The first unique commit is 57ae95c.
A preview of the PDF rendering of this PR: IHI0086-PSA_Certified_Crypto_API-1.3.0-interruptible-operations-draft3.pdf
Fixes #198