Tags: apple/swift-crypto
Tags
Add missing availability guards required when development mode enabled ( #337) ### Motivation When developing code that uses the BoringSSL backend on macOS, developers set a `development` boolean flag in the Package.swift. We recently switched from declaring minimum platform versions to annotating symbols with availability annotations. However, when `development = true`, it flushes out some annotations that were missing in the first pass. The result is that `main` currently doesn't build on macOS with this flag set. ### Modifications - Add missing availability guards required when development mode enabled. ### Result: Code builds macOS with `development = true` in Package.swift.
Use more efficient serialization and deserialization for ARC types (#336 ) ### Motivation The use of `Data.subdata(in:)` results in needless copies when decoding fields from bytes. Additionally, the use of a long chain of `Data.append(_:)` without a call to `Data.init(capacity:)` or `Data.reserveCapacity(_:)` can result in needless reallocations. ### Modifications - Remove unused `EncodeInt` and `DecodeInt` functions. They were unused before this PR but are there from when ARC credential serialization included the presentation limit. `DecodeInt` also happened to be incorrect and would crash when called with a slice. - Add some useful utility methods for popping bytes from a view without copying. - Add some generic functions for encoding and decoding `FixedWidthInteger` types along with tests for concrete types over `Data` and slices. - In ARC decoding, replace the use of `Data.subdata(in:)` with code that uses the `Data.Subsequence` slice (which happens to be `Data` since the type is self-slicing). - In ARC encoding, reserve enough capacity in the resulting `Data` when the sizes are known to reduce allocations. ## Results More performant serialization and deserialization for ARC types.
Fix CMakeLists.txt for Windows (#326) This change prepares swift-crypto for use on Windows with CMake and also the Package.swift for use in the Swift toolchain CI system. ### Checklist - [X] I've run tests to see all new and existing tests pass - [X] I've followed the code style of the rest of the project - [X] I've read the [Contribution Guidelines](CONTRIBUTING.md) - [X] I've updated the documentation if necessary #### If you've made changes to `gyb` files - [X] I've run `.script/generate_boilerplate_files_with_gyb` and included updated generated files in a commit of this pull request ### Motivation: Upgrading swift-crypto from an older version requires that Windows works properly with CMake, and also SwiftPM. ### Modifications: Modify the CMakeLists.txt files and the generator script so that it conditionally adds assembly files for non-Windows platforms. Prepare the Package.swift file for use in Swift CI pipelines, by consulting an environment to either use the absolute URL, or a prepared version of the swift-asn1 dependency. ### Result: After this change it should be possible to build with the newest swift-crypto in the Swift CI system.
Add missing assembly files to CMake and generator script (#322) Update both the CMakeLists.txt for CCryptoBoringSSL and the CMakeLists.txt generator so that it can add platform-independent assembly files. ### Checklist - [X] I've run tests to see all new and existing tests pass - [X] I've followed the code style of the rest of the project - [X] I've read the [Contribution Guidelines](CONTRIBUTING.md) - [X] I've updated the documentation if necessary #### If you've made changes to `gyb` files - [X] I've run `./scripts/generate_boilerplate_files_with_gyb` and included updated generated files in a commit of this pull request ### Motivation: There are downstream linker failures due to missing symbols from certain platform neutral assembly files. ### Modifications: The `scripts/update-cmake-lists.sh` has an updated find expression to discover platform-independent assembly files and includes them in the `CMakeLists.txt` files. ### Result: There will be more symbols included from third-parties such as BoringSSL.
extras: Add EC toolbox abstractions and OPRF(P-384, SHA-384) VOPRF API ( #292) ## Motivation We would like to provide support for the P384-SHA384 Verifiable Oblivious Pseudorandom Function (VOPRF) as defined in [RFC 9497: VOPRF Protocol](https://www.rfc-editor.org/rfc/rfc9497.html#name-voprf-protocol). ## Modifications - Add protocols for some "ECToolbox" abstractions: `Group`, `GroupElement`, `GroupScalar`, `HashToGroup`. - Add implementations backed by BoringSSL. - Duplicate some utilities from Crypto into _CryptoExtras: hexadecimal bytes and I2OSP. - Add VOPRF API, rooted at `enum P384._VOPRF`. ## Results - New internal abstractions that make it easier to bring up new implementations. - New API for `OPRF(P-384, SHA-384)` in VOPRF mode. ## Tests - Test vectors for internal `HashToField` implementation. - Test vectors for internal VOPRF implementation. - Tests of the VOPRF public API.
PreviousNext