Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Directly return from final sha3/keccak_final if no bytes are requested #9433
Reference implementation in keccak1600.c does not touch output buffer
A regression test for this issue is added to evp_test.c
I need help to verify the fix for architectures i have no access.
Already verified for: s390.
no fix needed, verified:
no fix needed, not verified:
fixed, not verified:
Please hep with the still to be verified platforms, if you have access or an emulation set up.
I dont feel comfortable making changes to the arm and c64 asm. @dot-asm could you help here ?
Here is "philosophical" question. Where would you stop? I mean if you test for buffer length, then why not test for pointers' validity[!] as well? And block size? What I'm trying to say is that there is a reasonable limit for amount of checks, and it is not inappropriate to make it caller's responsibility. Observation is that some assembly subroutines behave differently from reference implementation. So what? One can legitimately claim that despite that reference SHA3_squeeze implementation does nothing if zero length is passed, doing so constitutes undefined behaviour. It won't be a contradiction.
Also, keep in mind that this is private interface, application code won't be making the direct call. So question is where does length argument come from? It's either constant or value set with EVP_MD_CTRL_XOF_LEN. But then wouldn't it be more appropriate to vet the value in shake_ctrl? Because that's where you can communicate to application whether or not it's suitable? As opposite to choosing to opt for something application has no way of figuring out as effectively suggested here?
Just in case, as for vetting value in shake_ctrl. Note that it's
But in either case, let's say that consensus would still be to check for non-zero length in all SHA3_squeeze. Since we don't check for pointers' validity, would it be appropriate to assume that pointer to A is always valid? Why question? Well, it's only appropriate to aim for minimizing amount of branches. This in turn means that if a branch has to be added, it would be appropriate to position it some place where it would be less likely to be evaluated. In this case to squeeze_tail, which is actually an [highly] unlike path. This in turn would mean that for example on PPC A would be always dereferenced... What I'm getting at is that it's possible to avoid additional misprediction penalty for most common scenario, which should be viewed as desirable goal.