# CryptoSwift: Pure Swift Cryptography, and Where Its Edges Are

> CryptoSwift implements ciphers, hashes, MACs and key derivation in pure Swift for Apple platforms, Linux and Android. It is a practical choice for cross-platform Swift code, but the README itself marks several algorithms as legacy interoperability paths.

**krzyzanowskim/CryptoSwift** — CryptoSwift is a growing collection of standard and secure cryptographic algorithms implemented in Swift

- Repository: https://github.com/krzyzanowskim/CryptoSwift
- Website: http://cryptoswift.io
- Stars: 10,577 · Forks: 1,808
- Language: Swift
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/krzyzanowskim-cryptoswift

## What CryptoSwift Solves for Swift Developers

Swift projects that need a hash, an HMAC or a block cipher face a fork in the road. On Apple platforms, CommonCrypto and CryptoKit exist, but they are Apple-only. If the same source file has to compile for a Linux server or an Android build, those APIs are not available, and the usual workaround is a C library wrapped in a module map. CryptoSwift takes the other path: the algorithms are written in Swift itself, so the package builds wherever the Swift toolchain builds. The README describes it as "Pure Swift cryptographic primitives and utilities for Swift" and lists Apple platforms, Linux and Android as supported, with Linux and Android exercised in CI. The audience is therefore Swift developers shipping code across more than one platform, plus anyone who wants a single dependency rather than per-platform shims. The feature list is broad: MD5 through SHA-3, CRC16/32/32C, AES-128/192/256, ChaCha20, XChaCha20, Rabbit and Blowfish, RSA encryption and signatures, Poly1305, HMAC, CMAC and CBC-MAC, the ECB, CBC, PCBC, CFB, OFB, CTR, GCM, CCM and OCB modes, PBKDF1, PBKDF2, HKDF and Scrypt, and a long list of padding schemes. Extensions for String, Data and Array<UInt8> keep the call sites short. That breadth is the point: one import covers hashing, symmetric encryption, authentication and key derivation.

## How the Package Is Built and What Pure Swift Costs

The repository is a Swift Package with sources under Sources/ and tests under Tests/, plus an Xcode project and a podspec for the older distribution channels. Package.swift is the manifest; the Makefile is thin, exposing a frameworks target that shells out to scripts/build-framework.sh and reports that the framework is built into CryptoSwift.xcframework. That target is how you produce a binary framework rather than depending on source. The pure Swift choice has a real consequence: AES and the other primitives are implemented in Swift rather than dispatched to a platform's C implementation, so performance depends on the compiler and the target, and the README makes no performance claim either way. The README does not document a hardware-acceleration path. The API surface is organised by primitive rather than by protocol, with incremental update and streaming APIs noted in the feature list, which matters for large inputs where you do not want the whole buffer in memory. The README also carries a Recommended Defaults section that reads like a maintainer's opinion: prefer AEAD constructions such as AES-GCM, AES-CCM, ChaCha20-Poly1305 or XChaCha20-Poly1305 for new protocols; prefer SHA-256, SHA-512 or SHA-3 over MD5 and SHA-1; use a fresh IV or nonce for every encryption operation; use RSA keys of at least 2048 bits; and treat MD5, SHA-1, ECB, CBC-MAC and PKCS#1 v1.5 compatibility paths as legacy interoperability features. That section is the most useful part of the documentation, because it tells you which of the many available options the project itself would not pick today.

## Installing CryptoSwift with Swift Package Manager

The README states that CryptoSwift is primarily distributed as source through Swift Package Manager, and that the current release line builds with Swift 5.6 and newer toolchains. Add the package to your manifest with the repository URL, then import it in the file that needs it. The version string below is the 1.10.0 release; substitute whatever tag you have verified against your toolchain.

## A First Real Use: AES-GCM in a Few Lines

The README's Recommended Defaults point at AEAD constructions for new protocols, so a first exercise should be AES-GCM rather than CBC. The example below follows the shape the README gives for AES: build a key, build an AES instance with a mode, then encrypt. GCM authenticates as well as encrypts, so the caller must supply a nonce and can supply additional authenticated data. The README's rule is a fresh IV or nonce for every encryption operation; reusing one with the same key breaks the guarantee the mode is supposed to provide. What you should see is a SealedBox whose ciphertext and tag you store together, and a successful open only when the tag verifies. Treat a failed open as a signal that the data or the tag was altered, not as a case to retry with a different key.

## Where CryptoSwift Is the Wrong Tool

Two boundaries are worth stating plainly. First, this is a primitives library, not a key-management system. The README does not claim integration with the platform keystore, and nothing in the feature list covers key storage, attestation or secure enclave access. If your requirement is "the private key never leaves the secure hardware", CryptoSwift is not the component that gives you that; you still need the platform's own key APIs, and on Apple platforms that means CryptoKit or the Security framework alongside it. Second, the breadth of the feature list is a liability if you treat every entry as a recommendation. The README explicitly places MD5, SHA-1, ECB, CBC-MAC and PKCS#1 v1.5 in a legacy interoperability bucket. ECB in particular leaks structure in the plaintext, and using it because the API makes it a one-line option is the classic mistake this library makes easy. Third, the maintenance picture: the last push to the repository was on 2026-08-19, and release 1.10.0 is dated 2026-04-22. The README states that older branches matching older compilers are not actively maintained, so a team pinned to a Swift toolchain older than 5.6 is on a branch the project itself describes as unsupported. Finally, the README does not document a security-audit history or a formal verification process, so the trust decision rests on reading the source and the tests rather than on a published audit statement.

## CryptoSwift Versus Apple's CryptoKit

The obvious alternative on Apple platforms is CryptoKit, and the difference is architectural rather than cosmetic. CryptoKit is a system framework: it ships with the OS, it is not part of your binary, and it is only available where Apple ships it. CryptoSwift is a package you compile and link, which is why it can target Linux and Android at all. CryptoKit's API is built around typed keys and sealed boxes with the nonce handling folded into the call, while CryptoSwift exposes the underlying parameters, which is more flexible and easier to misuse. If your project is Apple-only and your deployment targets allow it, CryptoKit removes a dependency and puts the implementation in the platform's hands. If your project shares Swift code with a Linux service or an Android build, CryptoKit is simply unavailable and the comparison ends there. A second alternative for teams that want vetted C implementations is to wrap a C library such as OpenSSL through a module map; that trades the pure Swift build for a C dependency and its own build and linking story. CryptoSwift's selling point is that it needs neither.

## Licence, Upgrade Cost and Release Cadence

The repository's licence is reported as NOASSERTION, meaning the automated classifier could not map the LICENSE file to a known SPDX identifier. The LICENSE file is present at the top level, so the terms exist; read it directly before you depend on it, and treat the NOASSERTION label as a reason to check rather than as a statement about the terms. This is not legal advice. On upgrades, the release history shows 1.10.0 in April 2026, 1.9.0 in July 2025 and 1.8.5 in June 2025, so the cadence is measured in months rather than weeks. The README's note about older compiler branches not being actively maintained is the main upgrade cost driver: staying on the current line means staying on Swift 5.6 or newer. Distribution also carries a cost. The README lists Swift Package Manager and Carthage as compatible, and the CocoaPods badge is labelled Deprecated, so a project still pulling CryptoSwift through CocoaPods is on a channel the project has marked as such. The Makefile's frameworks target exists for consumers who need a prebuilt CryptoSwift.xcframework rather than source.

## Answers to Common Questions About CryptoSwift

The questions people search for around this project cluster on installation and on what it actually contains. Swift Package Manager is the primary channel; CocoaPods is marked deprecated in the README's badge; Carthage is listed as compatible. The RSA support covers encryption and signature, with the README recommending keys of at least 2048 bits for new systems. On platforms, the README names Apple platforms, Linux and Android, with the deployment floors at iOS 11, macOS 10.13, Mac Catalyst 13, tvOS 11, watchOS 4 and visionOS 1. The one thing the README does not answer is performance, and that is the question to settle with your own measurement on your own target rather than from documentation.

## Conclusion

Adopt CryptoSwift when you need cryptographic primitives in Swift code that must also build on Linux or Android, and when you can pin a release and verify the exact construction you use (for example AES.GCM with a fresh nonce) against a known test vector before shipping. Do not adopt it as a drop-in replacement for platform key storage, and do not reach for MD5, SHA-1, ECB or CBC-MAC in new protocols; the README classifies those as legacy interoperability features. Verify first that your toolchain is Swift 5.6 or newer and that your deployment targets are at least iOS 11, macOS 10.13, tvOS 11, watchOS 4 or visionOS 1, since older compilers require the legacy branches the README says are not actively maintained.

## FAQ

### What is CryptoSwift?

CryptoSwift is a collection of cryptographic algorithms implemented in pure Swift. The README lists hashes, ciphers, RSA, message authenticators, cipher modes, key derivation functions and padding schemes, with support for Apple platforms, Linux and Android.

### How do I install CryptoSwift?

The README states that CryptoSwift is primarily distributed as source through Swift Package Manager, and the current release line builds with Swift 5.6 and newer toolchains. Carthage is listed as compatible, and the CocoaPods badge in the README is labelled Deprecated.

### Does CryptoSwift support RSA?

Yes. The feature list includes RSA for encryption and signature, and the README's Recommended Defaults say to use RSA keys of at least 2048 bits for new systems.

### Which Apple deployment targets does CryptoSwift require?

The README lists iOS 11, macOS 10.13, Mac Catalyst 13, tvOS 11, watchOS 4 and visionOS 1, and states that Linux and Android are exercised in CI.

### Should I use CryptoSwift's CBC or ECB modes in new code?

The README's Recommended Defaults say to prefer AEAD constructions such as AES-GCM, AES-CCM, ChaCha20-Poly1305 or XChaCha20-Poly1305 for new protocols, and to treat MD5, SHA-1, ECB, CBC-MAC and PKCS#1 v1.5 compatibility paths as legacy interoperability features.

### What licence is CryptoSwift released under?

The licence is reported as NOASSERTION, which means the classifier could not map the LICENSE file to a known SPDX identifier. The LICENSE file is present at the top level of the repository, so read it directly for the actual terms.

## Sources

- [Issues](https://github.com/krzyzanowskim/CryptoSwift/issues)
- [krzyzanowskim/CryptoSwift on GitHub](https://github.com/krzyzanowskim/CryptoSwift)
- [Project website](http://cryptoswift.io)
- [README](https://github.com/krzyzanowskim/CryptoSwift/blob/main/README.md)
- [Releases](https://github.com/krzyzanowskim/CryptoSwift/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/krzyzanowskim-cryptoswift