-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AES-CBC Support #140
Comments
Thanks for filing this! I'll take this to my colleagues and report back. |
I think this issue has been addressed in #200 and may be closed. |
Can confirm - I'm using it in a project against keys and data generated via other means and it works fine |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
New API Proposal: AES-CBC
Motivation:
AES-GCM may be recommended for new applications, but AES-CBC is likely the most common (and vulnerability-free to-date) symmetric encryption in use. HLS streaming and many third-party file formats and proprietary protocols build on AES-CBC, so not having it in Crypto (and CryptoKit) hinders interoperability with many services.
BoringSSL does AES-CBC. And since we already have a GCM wrapper, adding CBC should be as easy as changing a few parameters. We won't be able to reuse AEAD contexts and protocols to share this implementation with GCM/ChaCha because CBC is not AEAD, but calls to BoringSSL EVP should only require minimal changes.
Importance:
Currently there is no official Swift APIs for AES-CBC. On Apple platforms, one has access to CommonCrypto which does full-feature AES, and Security framework which has limited AES support only on macOS. Third-party Swift cryptography libraries with AES support do exist, but their APIs do not play well if most parts of my application already uses Crypto(Kit).
The text was updated successfully, but these errors were encountered: