| e951219f | 08-Dec-2021 |
John Baldwin <[email protected]> |
libmd: Only define SHA256_Transform_c when using the ARM64 ifunc.
GCC 9 doesn't define a SHA256_Transform symbol when the stub just wraps SHA256_Transform_c resulting in an undefined symbol for _lib
libmd: Only define SHA256_Transform_c when using the ARM64 ifunc.
GCC 9 doesn't define a SHA256_Transform symbol when the stub just wraps SHA256_Transform_c resulting in an undefined symbol for _libmd_SHA256_Transform in libmd.so.
Discussed with: andrew, jrtc27 Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D31945
(cherry picked from commit a6765c4b449d79c6ee24dd7c37deb2239f6281a4)
show more ...
|
| aacfe3bb | 06-Oct-2021 |
John Baldwin <[email protected]> |
aesni: Permit AES-CCM requests with neither payload nor AAD.
Reviewed by: sef Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32114
(cherry picked from comm
aesni: Permit AES-CCM requests with neither payload nor AAD.
Reviewed by: sef Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32114
(cherry picked from commit c09c379c7aa7337680ff3cb73691ce12d627128b)
show more ...
|
| a5d38908 | 06-Oct-2021 |
John Baldwin <[email protected]> |
aesni: Handle requests with an empty payload.
Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32113
(cherry picked from commit d718c2d3c805001db0b0ae0cc0c8a
aesni: Handle requests with an empty payload.
Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32113
(cherry picked from commit d718c2d3c805001db0b0ae0cc0c8a811b8a90a95)
show more ...
|
| 83b3e8e0 | 06-Oct-2021 |
John Baldwin <[email protected]> |
ccp, ccr: Simplify drivers to assume an AES-GCM IV length of 12.
While here, use crypto_read_iv() in a few more places in ccr(4) that I missed previously.
Sponsored by: Chelsio Communications Diffe
ccp, ccr: Simplify drivers to assume an AES-GCM IV length of 12.
While here, use crypto_read_iv() in a few more places in ccr(4) that I missed previously.
Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D32104
(cherry picked from commit cb128893b92994456107d6ca722fdf6e5028eacc)
show more ...
|
| e3d927fa | 01-Apr-2021 |
John Baldwin <[email protected]> |
ossl: Don't encryt/decrypt too much data for chacha20.
The loops for Chacha20 and Chacha20+Poly1305 which encrypted/decrypted full blocks of data used the minimum of the input and output segment len
ossl: Don't encryt/decrypt too much data for chacha20.
The loops for Chacha20 and Chacha20+Poly1305 which encrypted/decrypted full blocks of data used the minimum of the input and output segment lengths to determine the size of the next chunk ('todo') to pass to Chacha20_ctr32(). However, the input and output segments could extend past the end of the ciphertext region into the tag (e.g. if a "plain" single mbuf contained an entire TLS record). If the length of the tag plus the length of the last partial block together were at least as large as a full Chacha20 block (64 bytes), then an extra block was encrypted/decrypted overlapping with the tag. Fix this by also capping the amount of data to encrypt/decrypt by the amount of remaining data in the ciphertext region ('resid').
Reported by: gallatin Reviewed by: cem, gallatin, markj Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D29517
(cherry picked from commit d2e076c37b0963a8be89684a656c4e1640dc7a3e)
show more ...
|