feat(dpapi): implement encryption and key derivation functions #350
Conversation
…ept the `kdf` itself;
| rand.workspace = true | ||
| hmac.workspace = true | ||
|
|
||
| rust-kbkdf = { version = "1.1", git = "https://gitlab.com/TheBestTvarynka/rust-kbkdf.git", branch = "fix-key-generation" } |
There was a problem hiding this comment.
Is it awful? Absolutely yes.
Do we have any alternative? Not really. See this: RustCrypto/KDFs#75 (comment)
I think the best solution is to contribute to RustCrypto. Or we can fork the rust-kbkdf crate
There was a problem hiding this comment.
The best approach is typically to contribute to the upstream project, because this gives back to the open source community while removing maintenance burden from our shoulders. We definitely can’t release a crate with a git dependency. As you said, either we contribute back, either we go the fork route with a crate we maintain and push to crates.io. I’ll link this to Marc-André, and we’ll see how we prioritize this work.
There was a problem hiding this comment.
@TheBestTvarynka UPD: We agreed with Marc that the best course of action was to contribute KBKDF to RustCrypto.
- Take over the work in progress PR. Collaborate with the author and RustCrypto maintainers to implement the missing pieces so that PR can be merged. Check with them if you can open a new PR from your fork, or work from theirs.
- Let RustCrypto publish the crate and manage it.
- Remove the git dependency from dpdpi in favor of the proper crates.io dependency.
- Integrate and publish our dpdpi crate.
Your priority should be to move this forward so we’re not stuck with a git dependency when it’s time to integrate dpdpi into sspi.
It’s fine to merge work on dpdpi even with the git dependency, because dpdpi is not depended on by our other crates that we are publishing to crates.io yet.
Feel free to rotate back on the dpdpi work when you wait for their feedback.
RustCrypto maintainers are pretty responsive, so I believe things should move forward quickly 🙂
The `crypto` module contains many _magic_ numbers. I took them from the Python DPAPI implementation: https://github.com/jborean93/dpapi-ng/blob/main/src/dpapi_ng/_crypto.py and https://github.com/jborean93/dpapi-ng/blob/main/src/dpapi_ng/_gkdi.py. Docs & references: * [[MS-GKDI]: Group Key Distribution Protocol](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gkdi/943dd4f6-6b80-4a66-8594-80df6d2aad0a). * [jborean93/dpapi-ng](https://github.com/jborean93/dpapi-ng/tree/main).
The `crypto` module contains many _magic_ numbers. I took them from the Python DPAPI implementation: https://github.com/jborean93/dpapi-ng/blob/main/src/dpapi_ng/_crypto.py and https://github.com/jborean93/dpapi-ng/blob/main/src/dpapi_ng/_gkdi.py. Docs & references: * [[MS-GKDI]: Group Key Distribution Protocol](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gkdi/943dd4f6-6b80-4a66-8594-80df6d2aad0a). * [jborean93/dpapi-ng](https://github.com/jborean93/dpapi-ng/tree/main).
Hi,
I implemented encryption/decryption and key derivation functions in this PR.
The
cryptomodule contains many magic numbers. I took them from the Python DPAPI implementation: https://github.com/jborean93/dpapi-ng/blob/main/src/dpapi_ng/_crypto.py and https://github.com/jborean93/dpapi-ng/blob/main/src/dpapi_ng/_gkdi.py.Docs & references: