Motivation
WWDC has arrived! 🎉 As part of the celebration, let's
bring Crypto up to speed with the new CryptoKit API surface.
Modifications
Substantial new docstrings
HPKE support
Result
WWDC 2023 support.
Needed to expose SecureEncalve through SwiftCrypto when building for
Swift-Certificates. CRYPTO_IN_SWIFTPM is set all of the time in
package.swift, while CRYPTO_IN_SWIFTPM_FORCE_BUILD_API is only set in
development. Lets enable the one that's on all of the time, and remove
the one that isn't so that we get our declarations.
* OpenSSLChaCha20CTR Implementation. Wraps CCryptoBoringSSL_CRYPTO_chacha_20.
* Insecure extension implementing the ChaCha20 CTR encrypt method.
* Added ChaCha20CTR Tests based on vectors provided in RFC9001 Appendix A.5
* Corrected year in header
* Changed return type to Data. Removed redundant pointer castings. Removed unnecessary array allocations in favor of withUnsafeBytes.
* Introduced a typed ChaCha20CTR Nonce and Counter struct in order to help enforce parameter constraints and type safety.
* Formatting
* Updated tests to use new Nonce and Counter structs. Added additional test checking for invalid parameters.
* Switch to HexStrings for better readability.
* Removed empty line at top of file
* Fixed UInt32.max counter assertion.
* Moved the bindMemory calls out of the function and copied a note from a similar situation elsewhere in the codebase.
* Formatting
* Implemented an _encryptContiguous function that prevents having to use the withContiguousStorageIfAvailable method. If our DataProtocol is contiguous we encrypt directly, otherwise we consolidate before encrypting. Removed inLen param from chacha20CTR call.
* Replaced the chacha20CTR function with a direct call to CCryptoBoringSSL_CRYPTO_chacha_20.
* Counter is now backed by a UInt32 instead of Data. Removed Sequence conformance.
* Formatting
* Formatting
* Replaced unsafe code (unsafeBytes and load) with a more generic and safer UInt32 construction.
* Replaced counterAsUInt32 definitions with integer literals to avoid symmetric bugs in the load.
* Updated _CryptoExtras/CMakeList.txt
* Add five new ECDSA Wycheproof test vectors with signatures on IEEE P1363 format, remove four unused Wycheproof test vectors.
* Revert unnecessary protocol extension
* Update ASN1 test helpers to not fatalError but rather fail/throw, needed for some new tests in Wycheproof v1
* Update Wycheproof ecdh_secp521r1_test.json to v1
---------
Co-authored-by: Cory Benfield <lukasa@apple.com>
* Update ASN1 test helpers to not fatalError but rather fail/throw, needed for some new tests in Wycheproof v1
* Update Wycheproof ecdh_secp384r1_test.json to v1
---------
Co-authored-by: Cory Benfield <lukasa@apple.com>
* Exclude AES from CMake
SwiftPM doesn't need it and this would allow removal of CCryptoBoringSSL dependency on non-Darwin platforms, thus reducing SwiftPM size.
* Update update_cmakelists.sh to exclude AES source files
Motivation
CryptoExtras RSA public keys support being exported in DER and PEM form.
These exports work great, but it turns out they are inconsistent between
the Darwin and non-Darwin implementations. Darwin platforms would export
the public keys in PKCS1 format, while non-Darwin was exporting them as
SPKI. This isn't great!
Modifications
- Make the two consistent. `.derRepresentation` should export SPKI
formatted public keys, because that's what it does for all the EC
keys.
- Add `.pkcs1DERRepresentation` and `.pkcs1PEMRepresentation` for those
users that require the PKCS1 formatted key.
Result
Key export types are now consistent on all platforms.
In some cases developers have need of AES modes other than what we
support today, or need the ability to implement algorithms that require
access to the core AES permutation function. As a starting point, we can
provide access to the AES block function in CryptoExtras.
The package DLL `Crypto.dll` was building the BoringSSL wrapper
(`CryptoBoringWrapper`) in the style that the user requested (static or
shared). However, there is a single user of the library and is not
directly included by the SPM client. Furthermore, the library was not
setup for installation which makes redistribution of it impossible.
Always build the library in a static mode to allow compaction into the
`Crypto` target.
Motivation
The init(derRepresentation:) and init(pemRepresentation:) constructors
for RSA public keys support both PKCS#8 and PKCS#1 key formats on
Darwin. This support was missing from Linux, with only PKCS#8 support.
This patch brings the two platforms into parity.
Modifications
Add code to try both versions on Linux.
Add tests.
Results
PKCS#1 keys are supported on Linux too!
# Motivation
BoringSSL exposes AES-GCM-SIV algorithms which are in general useful to have and provide a nonce-misuse resistant mode of AES-GCM. Since, `CryptoKit` is not exposing AES-GCM-SIV we need to add this to `_CryptoExtras`
# Modification
Exposes `AES-GCM-SIV` through `_CryptoExtras`.
# Result
We can now use `AES-GCM-SIV` through `_CryptoExtras`.
Motivation:
Old Swift versions are periodically dropped. Now that 5.7 has been
released, 5.4 will be dropped.
Modifications:
- Update tools version
- Remove 5.4 docker-compose
- Update 5.7 docker-compose to use released image and move from focal to
jammy
- Update docs
Result:
Swift 5.5 is the minimum supported Swift version
* Make BoringSSL wrapper match CryptoKit behaviour when working with x963 representation
* Revert Package.swift changes
* Fix Signing tests and add test cases for invalid key lengths
* Bring over API files from macOS Ventura
* Implement the new API surface
This patch implements the new API surface, and removes anything that's
no longer compatible with the expected API surface from CryptoKit
Without the explicit typing, the build fails with recent toolchain
builds expecting the type to conform to an incorrect type. This
repairs the build.
Co-authored-by: Cory Benfield <lukasa@apple.com>
When contentLength is greater than 8 bits, i.e., greater than UInt8.max, the original implementation crashes.
To work around this, use UInt8.init(truncatingIfNeeded:) to truncate only the lower 8 bits.
Motivation:
When using only the CryptoKit API on Apple platforms we have always
thunked through to the CryptoKit interface and implementation. However,
we didn't do a thorough job of preventing the BoringSSL target from
getting compiled and linked.
We can do a better job now, which will save compile times and binary
sizes in many cases.
Modifications:
- Change Package.swift to express a target specific dependency in most
cases.
- Preserve a development mode which overrides that target specific
dependency.
- Add the missing compile guards.
Results:
Smaller binaries and faster compiles on Apple platforms.
As outlined in a [Swift forums post in November ’21](https://forums.swift.org/t/swiftnio-swift-version-support/53232), SwiftNIO will only support the latest non-patch Swift release and the 2 immediately prior non-patch versions.
In this commit we drop support for Swift 5.2 and 5.3. We update CI for Swift 5.4 to run on bionic instead of focal to ensure that we still test bionic.
Cory Benfield