-
Notifications
You must be signed in to change notification settings - Fork 167
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
Noncopyable / moveonly PrivateKey
API?
#188
Comments
Thanks for this suggestion. Can you clarify why having copyable Private Keys is a safety concern? |
@Lukasa not so much that having copyable being a safety concern as to being able to use non-copyable private keys and thus know that I have not accidentally made a copy somewhere, being kept in memory, that I did not think about. Just like using Implicitly Unwrapped Optionals is not a concern if one always uses them correctly, but the nice thing about Swift (non-Implicitly unwrapped) Optionals is that I get help from the compiler. |
Case study, e.g. Rust Crate "Dalek" has an |
You can still arrange to do this by defining wrapper types in your own code that are non-copyable. I'd be fairly nervous about inflicting this constraint on the entire userbase of Crypto, especially as defining these wrappers is a straightforward affair. |
New API Proposal: Noncopyable PrivateKey
Motivation:
For the past six years I've been working with cryptography and Swift and I've been missing some kind of compiler help regarding my usage of private keys. Rust's powerful ownership model is most likely a strong reason why many crypto project chose Rust as a go to language. With Swift 5.9 we have noncopyable types, along
consume
/borrow
which seem like a nice fit for swift-crypto!What is Apple's thoughts on including a new API layer to each curve that ships with swift-crypto where the private keys are
~Copyable
? I imagine it would be a new namespace, similar to howP256
andSecureEnclave.P256
namespaces exists in parallell. It could beSafe.P26.Signing.PrivateKey
, the corresponding PublicKey need not be~Copyable
. An alternative would be to put the non copyable variant inP256.Signing.Safe.PrivateKey
or let the type itself be prefix with "Safe", i.e.P256.Signing.SafePrivateKey
.Importance:
YES, it unlocks an entire new use-case for the developer writing the code! Just how
async
/await
offers an entire new way and safer way to write concurrency code in Swift,~Copyable
offers the users of swift-crypto - and CryptoKit - an entire new and safer way of using private keys!The text was updated successfully, but these errors were encountered: