Skip to content
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

Open
Sajjon opened this issue Jul 3, 2023 · 4 comments
Open

Noncopyable / moveonly PrivateKey API? #188

Sajjon opened this issue Jul 3, 2023 · 4 comments

Comments

@Sajjon
Copy link
Contributor

Sajjon commented Jul 3, 2023

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 how P256 and SecureEnclave.P256 namespaces exists in parallell. It could be Safe.P26.Signing.PrivateKey, the corresponding PublicKey need not be ~Copyable. An alternative would be to put the non copyable variant in P256.Signing.Safe.PrivateKey or let the type itself be prefix with "Safe", i.e. P256.Signing.SafePrivateKey.

Importance:

Does this API unlock entirely new use-case

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!

@Lukasa
Copy link
Collaborator

Lukasa commented Jul 3, 2023

Thanks for this suggestion. Can you clarify why having copyable Private Keys is a safety concern?

@Sajjon
Copy link
Contributor Author

Sajjon commented Jul 4, 2023

@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.

@Sajjon
Copy link
Contributor Author

Sajjon commented Jul 4, 2023

Case study, e.g. Rust Crate "Dalek" has an EphemeralSecret (PrivateKey) which does not have the Copy "trait", i.e. is move-only https://github.com/dalek-cryptography/x25519-dalek/blob/main/src/x25519.rs#L75

@Lukasa
Copy link
Collaborator

Lukasa commented Jul 4, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants