boringssl

414 Commits

61 Branches

23 Tags

511 MiB

Tag: Branch: Tree: 747229ec7e

Commit Graph

Author	SHA1	Message	Date
David Benjamin	a24ab549e6	Use an unsized helper for truncated SHA-512 variants. Although it is strictly fine to call SHA512_Final in SHA384_Final (array sizes in C parameters are purely decorational, according to the language), GCC 11 reportedly checks now and gets upset about the size mismatch. Use an unsized helper function so all our code matches the specified bounds. Unfortunately, the bounds in all the functions are a bit misleading because SHA512_Final really outputs based on sha->md_len (which Init function you called) rather than which Final function. I've fixed this places within a library where we mismatched and added asserts to the smaller functions. SHA512_Final is assert-less because I've seen lots of code use SHA384_Init / SHA512_Update / SHA512_Final. This doesn't fix the SHA256 variant since that is generated by a pile of macros in a multiply-included file. This is probably a good opportunity to make that code less macro-heavy. Update-Note: There is a small chance the asserts will trip something, but hopefully not since I've left SHA512_Final alone. Bug: 402 Change-Id: I4c9d579a63ee0a0dea103c19ef219c13bb9aa62c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46405 Reviewed-by: Adam Langley <agl@google.com>	4 years ago
Adam Langley	fb0c05cac2	acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>	5 years ago

Author

SHA1

Message

Date

David Benjamin

a24ab549e6

Use an unsized helper for truncated SHA-512 variants.

Although it is strictly fine to call SHA512_Final in SHA384_Final
(array sizes in C parameters are purely decorational, according to the
language), GCC 11 reportedly checks now and gets upset about the size
mismatch. Use an unsized helper function so all our code matches the
specified bounds.

Unfortunately, the bounds in all the functions are a bit misleading
because SHA512_Final really outputs based on sha->md_len (which Init
function you called) rather than which Final function. I've fixed this
places within a library where we mismatched and added asserts to the
smaller functions. SHA512_Final is assert-less because I've seen lots of
code use SHA384_Init / SHA512_Update / SHA512_Final.

This doesn't fix the SHA256 variant since that is generated by a pile of
macros in a multiply-included file. This is probably a good opportunity
to make that code less macro-heavy.

Update-Note: There is a small chance the asserts will trip something,
but hopefully not since I've left SHA512_Final alone.

Bug: 402
Change-Id: I4c9d579a63ee0a0dea103c19ef219c13bb9aa62c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46405
Reviewed-by: Adam Langley <agl@google.com>

4 years ago

Adam Langley

fb0c05cac2

acvp: add CMAC-AES support.

Change by Dan Janni.

Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>

5 years ago

2 Commits (747229ec7e0871a253dbbe79f78da9c2cf6c777a)