Add error support when RustCrypto doesn't

[ia0]

After #174 the hash API doesn't support returning errors because the RustCrypto API for digest (e.g. Update, FixedOutput) don't return a Result. We should somehow add the possibility to report errors in those operations, for example using a side channel that may be checked. This could be a LastError trait that would be used after each operation to check for error.

trait LastError {
    type Error: Copy;
    fn last_error(&self) -> Option<Error>;
}

[zhouwfang]

Hi, Could you assign this issue to me? Thanks.

[zhouwfang]

Could you give an example on when a hash API should return an error? Thanks.

For example, when should this call of Update return an error?
https://github.com/zhouwfang/wasefire/blob/9888e8fd20018d0e5f55275a9b559bfdfa8d3db6/crates/scheduler/src/call/crypto/hash.rs#L86

[ia0]

Actually, all those functions should return an error for both hash and hmac: initialization, update, finalization.

One solution I see is to make the board::crypto::Hmac trait FixedOutputReset like it is for board::crypto::Hash (not sure if it will break something), and add for both traits the new LastError trait I described above. Then in the scheduler as you pointed out, we will need to call context.last_error() to access the error after each operation that uses the RustCrypto API (which doesn't return errors). So in your case, each branch needs to call context.last_error() after calling context.update(data).

Actually if LastError returns Result<(), Error> this is easier, because that's going to be directly the result for update and finalize. For initialize, it's going to be Result::map first to get the handler.

use wasefire_error::Error;
trait LastError {
    fn last_error(&self) -> Result<(), Error>;
}

[zhouwfang]

Thanks for the explanation! Still wanted to get more contexts:

1. The original question was more about: under what condition, a operation that uses the RustCrypto API would produce an error. In Abstract Hkdf and HkdfExtract over hmac::Mac RustCrypto/KDFs#80, you mentioned the errors could result from hardware failure. How could we detect and get access to hardware failure? Basically, where does the error returned from last_error come from specifically?

2. I could understand we should use LastError for update, and finalize (since it happens after update). Why do we need to use it for initialize? Initializing a HashContext does not seem to use RustCrypto API.

[ia0]

Basically, where does the error returned from last_error come from specifically?

This will come from the board implementation (so it won't be implemented as part of this issue). Platforms where crypto may fail at any time would have to handle an error state on their side. When an error happens during some call (e.g. initialize, update, finalize), they would need to return a dummy result (for unit-returning function it's easy) and store the error somewhere. There is a guarantee that after each function, last_error is called, which is when the error is read.

Actually, this guarantee does not exactly hold when using a software HMAC on top of a hardware hash, because multiple operations may be called before last_error is called at the HMAC level (the software HMAC implementation calls last_error on the hash to implement its own last_error). So the guarantee is more that last_error is eventually called and so before the result is used by the end user.

Why do we need to use it for initialize? Initializing a HashContext does not seem to use RustCrypto API.

The Default trait is an assumption of RustCrypto for the default implementation of Digest. So it's true we could have our own initialization function that may fail, but then we would still need to implement Default which cannot fail to be able to compose the hash API with the HMAC API.

The reason we don't create our own API instead of using RustCrypto, is precisely to be able to have a software implementation of HMAC done by RustCrypto. The only crypto implementation at the moment is HKDF because we can't use RustCrypto, see RustCrypto/KDFs#80.