Comments (5)
What it sounds like you're looking for is a Key Encapsulation Mechanism (KEM) and probably hybrid encryption. We do have the available primitives for this, specifically a KEM instantiation of X25519-HKDF-SHA256.
A way to accomplish this, is how age encrypts files. What you would do here is have a recipient's public key (the key of the user that should be able to decrypt the data later on), which you would use to derive a symmetric key, used then to encrypt the actual data (some details omitted here). This is sometimes referred to as an ECIES scheme, or a more formalized and proven construction: HPKE - RFC9180. A user would however still need to securely manage a X25519 keypair (instead of say, an encryption passphrase).
That said, I'm open to add an implementation of the HPKE variant using DHKEM(X25519, HKDF-SHA256) + ChaCha20Poly1305 from the RFC, if this is something you're interested in using?
from orion.
What's the size of the data that needs to be encrypted? Are these files or something that can fit into memory?
from orion.
The size of the data that needs to be encrypted ranges from a small textual value of 20-30 bytes to some image/video files that may take a few MBs.
Also, the usage context here is a case where the public key party doesn't have any way to communicate with the secret key party once the public key's been provided (e.g. through a physical medium).
I'm not yet able to understand hybrid encryption, but yesterday while trying to use libsodium I recall seeing it and concluding it wasn't fit for this; I may be wrong or misunderstanding though.
So, short question: if I were to derive a key (made for symmetrical encryption of the data) from the public key, would that same key be derivable from the private key without any additional factor?
And if as required additional factor one would need a shared salt for example, would it be considered sensitive (ie not able to be provided over by cleartext) ?
(For ref, the test implementations I tried are using libsodium's sealed boxes since both the sender and recipient are the same entity)
from orion.
I'm not yet able to understand hybrid encryption, but yesterday while trying to use libsodium I recall seeing it and concluding it wasn't fit for this; I may be wrong or misunderstanding though.
I'm not sure in what way libsodium's sealed box would be unfit. Do you have a specific concern?
So, a user holds a private key, encrypts the data using this and stores it. Then, later the user should be able to decrypt it again. Is the user itself encrypting or a server (how is there two parties involved)? If there is an encryption service, then the user could simply provide their data and their public key at once, no? Then there'd be no extra communication needed, because the service encrypts it to the just-received public key.
So, short question: if I were to derive a key (made for symmetrical encryption of the data) from the public key, would that same key be derivable from the private key without any additional factor? [..]
For ECIES and HPKE you use the public key and ephemeral key pairs to compute the symmetric key. You also need some contextualization information for this part, that's where HKDF comes in. So some additional factors are used. Whether a salt should be secret or not really depends on what it is used for.
Perhaps take a look at AuthEncap()
and AuthDecap()
here, to get a feeling of how the shared symmetric key is derived: https://www.rfc-editor.org/rfc/rfc9180.html#section-4.1-4
If we were to provide an implementation for your use-case, it would most likely essentially be a variant of sealed box.
from orion.
Okay so the use case's flows are as follows.
- the "server" owns, in database, a collection of all encrypted payloads, all of which were encrypted using the same key (current assumption for this point on encryption)
- when a user directly interacts with the server to send data, they trust the server to encrypt the data using the public key (still assuming)
- a user may/will request access to their data on a later point, trusting the server to decrypt and send the requested stored data
A user may/will need an offline tool providing the same implementation for the encryption part, in which case the user would need to import the server-owned public key so the offline tool can encrypt data for later sending the pre-encrypted data to the server without need for any link during encryption.
The reference to "ephemeral session keys" makes me feel it's something made for active-link encrypted transfer between two parties, and that's what I may misunderstand.
If I were to want a sealed box kind of flow, I would then suppose that my offline client would have its own keypair acting as its sender identity; its public key being provided to the server, but then I'm lost on "what more is supposed" and "how to go from here" (ie how should such a mechanism be implemented properly, what are its limitations, and such).
If a sealed-box-like would still fill all the "offline/no-session/etc" requirements and the encryption-related issue would lie in my lack of knowledge, I'm planning to see my crypto professor/researcher at my uni for more explanations from him anyways, so I'll get more info on it too.
edit: (on the "me learning" part, soatok's newest article comes in handy now)
edit: overall, i'm gonna spend a few days digging into the topic around and such, so as this is probably out of scope for orion we may close the issue or mark it as non-bug or something to avoid cluttering. And yeah, now I see how HPKE can be used to fill this need, and if it's something welcome, then I think it would be useful to have DHKEM in the library.
Thanks a lot for your time and patience on this, I've got lots to read now and should be able to progress in the meantime!
from orion.
Related Issues (20)
- Missing `Debug` trait for BLAKE2b `Hasher` enum HOT 3
- MSRV `1.52.0` fails because of bad version of `plotters`
- Consider adding `Eq` where possible HOT 5
- Investigate whether actions-rs should be replaced HOT 1
- Remove ignores of `criterion`-based RUSTSEC advisories once fixed HOT 2
- Misuse issue in (X)ChaCha20 and (X)ChaCha20-Poly1305 APIs HOT 2
- Remove `cargo audit` workflow HOT 1
- Making zeroization optional
- Adding key-committing AEAD implementations (CTX or UtC/RtC/HtE) HOT 7
- Consider using `cargo-semver-checks`
- Provide link to OWASP in Argon2i documentation
- Update Wycheproof test vectors
- Add chunked input processing of KATs
- Unify hashing APIs of BLAKE2b, SHA2 and SHA3
- Add support for HPKE (ChaCha20-Poly1305 + DHKEM(X25519, HKDF-SHA256))
- `Digest` to `&[u8]` HOT 2
- Does orion support iOS and Android platforms? HOT 1
- Consider using checked_mul(8) instead of checked_shl(3) in SHA2 HOT 1
- Add Blake3 support HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from orion.