You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To safe us in parsing fabric proposal in enclave/c, we currently pass also the request-message to the enclave and take arguments from there, not proposal. However, we do only include proposal into signature which we later verify in enclave without nothing verifying the consistency of the two. So we either - should include also request message into (to be signed) response message and have __endorse verify the proposal and request message in signature are consistent, i.e., the latter is contained in the former, or
we extract inside enclave the request from proposal (making also passing of proposal unnecessary)
Elaborating on the two solutions (extracting request from proposal; include request in response, sign and verify later) above, there are tradeoffs.
The former results in fewer bytes passed between Go and enclave space, and it requires some nanopb/cpp coding inside the enclave to handle the signed proposal. Essentially this is what Fabric does in the shim to set it up.
The latter incurs in additional bytes passed to the enclave (twice the request, since this is passed directly and it is also included in the signed proposal). However, it does not require any extraction from the signed proposal, thereby saving nanopb/cpp code for handling Fabric-internal details. Finally, the hash of the request must additionally be included in the response, and checked later.
To safe us in parsing fabric proposal in enclave/c, we currently pass also the request-message to the enclave and take arguments from there, not proposal. However, we do only include proposal into signature which we later verify in enclave without nothing verifying the consistency of the two. So we either - should include also request message into (to be signed) response message and have __endorse verify the proposal and request message in signature are consistent, i.e., the latter is contained in the former, or
(Related to #460)
The text was updated successfully, but these errors were encountered: