Expose EVP_DigestSqueeze from Hasher #2275
Conversation
| /// Squeezes buf out of the hasher. Can be called multiple times, unlike `finish_xof`. | ||
| /// The output will be as long as the buf. | ||
| #[cfg(ossl330)] | ||
| pub fn squeeze_xof(&mut self, buf: &mut [u8]) -> Result<(), ErrorStack> { |
There was a problem hiding this comment.
Does this need to check that state isn't finalized? Is it permissible to update after a squeeze?
There was a problem hiding this comment.
Re finalized: good point, it indeed fails if already finalized: https://github.com/openssl/openssl/blob/master/crypto/sha/sha3.c#L144-L145
There was a problem hiding this comment.
Re update: that is also not allowed: https://github.com/openssl/openssl/blob/master/crypto/sha/sha3.c#L55-L57
There was a problem hiding this comment.
Thanks for the catch, lemme fix the PR.
|
Hmm, so it looks like if you do a |
|
I am having trouble following the state machine transitions here. If I call Existing behavior (prior to this PR) appears to allow calling The particular case Alex mentioned should be fixed, but we should really fix the state machine here in general since it allows nonsense. |
|
Unfortunately we can't change the existing behavior, but I guess there's no reason we can't just make it an error to call other methods after squeeze! |
|
Yes, I tried to preserve prior behavior of silently re-initializing instead of error-ing. Nope, it's not allowable to call finalize after squeeze. We could allow it, but that would further deviate from the underlying openssl. |
|
@initsecret are you still planning to revise this to make it an error to call other methods after squeeze while retaining the rest of the behavior of this API? I think, despite the deviation from the rest of the API, that's what I'd prefer, but @alex may disagree. |
|
I updated the PR to not silently re-init after squeeze, but |
|
Interesting, all OSes seem to allow Updates after Squeeze. The documentation seems to only promise that Finalize will fail if called after Squeeze:
And indeed, the Finalized check is done at the EVP level while the Squeeze check is only done in the above cited implementation code. When I get a chance, I will dig deeper because afaict this---allowing updates after squeezing---is inconsistent with Section 4 of FIPS 202. |
|
@initsecret Are you still planning to look at this? I'm triaging issues for our next pyca/cryptography release and this is in our milestone right now 😄 |
|
@reaperhulk thanks for the ping. Sorry this dropped off my list, I made a note to look deeper tonight and update the PR. |
| if self.state == Squeeze { | ||
| // [`EVP_DigestUpdate`], depending on the implementation, may allow Updates after Squeezes. | ||
| // But, [FIPS 202], as shown in Figure 7, has a distinguished absorbing phase followed by a squeezing phase. | ||
| // Indeed, the [`sha3.c`] implmentation disallows Updates after Squeezes. | ||
| // For consistency, we always return an error when Update is called after Squeeze. | ||
| // | ||
| // [`EVP_DigestUpdate`]: https://github.com/openssl/openssl/blob/b3bb214720f20f3b126ae4b9c330e9a48b835415/crypto/evp/digest.c#L385-L393 | ||
| // [FIPS 202]: https://dx.doi.org/10.6028/NIST.FIPS.202 | ||
| // [`sha3.c`]: https://github.com/openssl/openssl/blob/b3bb214720f20f3b126ae4b9c330e9a48b835415/crypto/sha/sha3.c#L52-L63 | ||
| let errors = ErrorStack::get(); | ||
| return Err(errors); | ||
| } |
There was a problem hiding this comment.
Doing this check in rust-openssl is not ideal, but it is the best I could come up with.
The alternative is to update individual implementations in OpenSSL, because they likely will not accept this change at the EVP_DigestUpdate level, since they may want to use it for cryptographic objects that allow updates after squeezes.
Here, I think we can be more opinionated and say that if we have objects that support updates after squeezes, they should define a new API, rather than further overload this API.
This completes the streaming API.