6f63b8fa | 22-Nov-2023 |
Aaron LI <aly@aaronly.me> |
crypto: Add ChaCha20-Poly1305 and XChaCha20-Poly1305 AEAD
Derived from OpenBSD with significant modifications by me:
- Removed unused code to hook into the cryptosoft framework. - Adjusted the inte
crypto: Add ChaCha20-Poly1305 and XChaCha20-Poly1305 AEAD
Derived from OpenBSD with significant modifications by me:
- Removed unused code to hook into the cryptosoft framework. - Adjusted the interface to align with the IETF RFC document (e.g., make the nonce a byte string other than a uint64_t), so that the code becomes more generic.
References: - RFC 8439: ChaCha20 and Poly1305 for IETF Protocols - RFC draft: XChaCha: eXtended-nonce ChaCha and AEAD_XChaCha20_Poly1305
show more ...
|
6a8dae24 | 19-Dec-2022 |
Sascha Wildner <saw@online.de> |
Bump CSTD to gnu11 for world and kernel.
In practice, I don't think this will change a lot for base code, and I am doing it mainly for contrib/ code which might in certain cases use different paths
Bump CSTD to gnu11 for world and kernel.
In practice, I don't think this will change a lot for base code, and I am doing it mainly for contrib/ code which might in certain cases use different paths (for example zstd will). Also affected might be dports which use base's share/mk infrastructure, of which there are a few.
I have compared the object directories with all temporary files (.s, .i) between a LINT64 kernel compiled with -std=gnu11 vs. one built with c99 and there were no differences whatsoever.
Thanks to tuxillo for testing with a full bulk build.
Note that the kernel was previously using c99 and has now been switched to gnu11, not c11. This is because we were always using GNU extensions in kernel code, so c99 should really have been gnu99 always.
Also note that we could in theory have switched to gnu17 directly since c17 only addressed some defects in c11 and did not add new features, but I chose to use 11 because our secondary compiler does not support 17.
Reminded-by: Peeter Must
show more ...
|