New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BLAKE2 refactoring of common code bringing variable length support to BLAKE2s #22444
Conversation
@mattcaswell I actually think this should go in 3.2.0 The refactoring is fairly straightforward and the xoflen support in 2b only is quite surprising. The documentation is clearly needed as the xoflen handling in Blake is very much different from SHAKE. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@slontis, does this impact your proposal for the digest squeeze function? |
OTC: should we classify these as XOF and use xoflen for the digest's output size? The alternative is that they are not XOF and use size. They have no capability for the squeeze functionality. |
24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually. |
This PR conflicts with 6a0ae39 |
rebased |
…size support like 786b9a8 Test data obtained with libb2 with the following programs: ==> b2.c <== #include <blake2.h> #include <unistd.h> int main() { char buf[16] = {}; blake2s(buf, 0, 0, 16, 0, 0); write(1, buf, 16); } ==> b3.c <== #include <blake2.h> #include <unistd.h> int main() { char buf[10] = {}; blake2s(buf, "\x61", 0, 10, 1, 0); write(1, buf, 10); }
@paulidale AFAIK the OTC hold question is not relevant anymore. Can you please remove the label if you agree? |
@nabijaczleweli I think you'll also need to modify EVP_MD-Blake2 manpage and I'd kindly ask you to add a CHANGES.md entry about adding the variable size support to Blake2s. |
Well, if we're going that far, I should probably document that BLAKE2b also has it? 786b9a8 doesn't have any docs in it, and so it's not mentioned in CHANGES.md. |
Hold removed, we should have removed it after the discussion. For the record, the OTC decided that this wasn't an XOF digest and that the digest size parameter should be used to specify the length. This change to be made to the pre-existing digest before 3.2 beta series releases (because the variable length change hadn't been in a release, it could be updated so long as it was before the API freeze at the first 3.2 beta release). |
EVP_MD-BLAKE2(7) was already modified with text much like was in this PR in 6a0ae39#diff-a94d99d3c13153981b6da8a09b5d5fefcb3f8d6016c8cf0752f44fb30addc919. CHANGES.md entry added. |
CHANGES.md
Outdated
* The BLAKE2b and BLAKE2s hash algorithms support a configurable output length | ||
by setting the "size" parameter. | ||
|
||
*Čestmír Kalina, Tomáš Mráz, and Ahelenia Ziemiańska* | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately this needs two entries. One in ### Changes between 3.1 and 3.2
for BLAKE2b and another in changes between 3.2 and 3.3 for BLAKE2s. Also the first one needs to be in a separate PR so it gets merged to the 3.2 branch as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does it? I only see 786b9a8 in openssl-3.2.0-{alpha{1,2},beta1}
tags, and it doesn't look backported into openssl-3.1.4
under another SHA either?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I am talking about changes that go into 3.2 (Blake2b is variable output length there) and 3.3 (Blake2s gets this support as well by your PR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, misread and misunderstood. fixed
ERR_raise(ERR_LIB_PROV, PROV_R_FAILED_TO_GET_PARAMETER); \ | ||
return 0; \ | ||
} \ | ||
if (size < 1 || size > UINT8_MAX) { \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this upper constraint correct.. RFC 7693 seems to have 1 <= outlen <=64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Input = 61 | ||
OutputSize = 10 | ||
Output = b60d322755eebca92b5e | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is an upper bound on the output length there should be failure checks here..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly, this just mimicks the blake2b tests at the end of the file (but obviously with blake2s outputs). If the limit in the formerly-blake2b code is appropriate, then maybe. No limit is documented afaict
This pull request is ready to merge |
I am merging this as @slontis concerns should IMO be resolved in a separate PR as they are already relevant for Blake2b. |
Merged to the master branch with partially squashing the commits. Thank you for your contribution. |
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #22444)
This avoids code duplication and provides variable-size support for BLAKE2s like 786b9a8 Test data obtained with libb2 with the following programs: ==> b2.c <== #include <blake2.h> #include <unistd.h> int main() { char buf[16] = {}; blake2s(buf, 0, 0, 16, 0, 0); write(1, buf, 16); } ==> b3.c <== #include <blake2.h> #include <unistd.h> int main() { char buf[10] = {}; blake2s(buf, "\x61", 0, 10, 1, 0); write(1, buf, 10); } Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #22444)
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #22444)
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #22444)
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl/openssl#22444) Signed-off-by: fly2x <fly2x@hitls.org>
This avoids code duplication and provides variable-size support for BLAKE2s like 786b9a8 Test data obtained with libb2 with the following programs: ==> b2.c <== #include <blake2.h> #include <unistd.h> int main() { char buf[16] = {}; blake2s(buf, 0, 0, 16, 0, 0); write(1, buf, 16); } ==> b3.c <== #include <blake2.h> #include <unistd.h> int main() { char buf[10] = {}; blake2s(buf, "\x61", 0, 10, 1, 0); write(1, buf, 10); } Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl/openssl#22444) Signed-off-by: fly2x <fly2x@hitls.org>
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl/openssl#22444) Signed-off-by: fly2x <fly2x@hitls.org>
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl/openssl#22444) Signed-off-by: fly2x <fly2x@hitls.org>
The first three patches are functional no-ops, and just move the BLAKE2B stuff from being declared directly into a macro.
The fourth patch replaces the manual implementation of BLAKE2s with a call to the macro, thus matching them both in funxionality. This effectively completes 786b9a8.
The fifth patch explicitly documents what I discovered the hard way over three hours yesterday:
EVP_DigestFinalXOF()
which is a shorthand for setting "xoflen" to the argument and then runningEVP_DigestFinal()
EVP_DigestInit_ex2()
EVP_DigestFinalXOF()
has no bearing on it at all, but you can still pass it there. or you can just useEVP_DigestFinal()
EVP_DigestInit_ex2()
but did pass it toEVP_DigestFinalXOF()
, you just get wrong data (full-width hash, but truncated)EVP_DigestInit_ex2()
doesn't error if it gets a parameter the hash function doesn't understandEVP_DigestFinal()
produces a truncated hash, and on upstream openssl HEAD the same code produces the correct short hashEVP_DigestFinalXOF()
which you shouldn't be using since it does nothing but implies it doesThis all could've been avoided with a startlingly small patch that documents it (+20-4, and most of that +20 is in EVP_MD-BLAKE2.pod which is mostly copied from -SHAKE). The first four patches are really in service of not having to differentiate between b2s and b2b in the manual.
This also means that
EVP_DigestInit_ex2()
blindly accepting whatever it doesn't understand is an oddly dangerous design?