This library implements PEP cryptography based on ElGamal encrypted messages.
In the ElGamal scheme, a message M can be encrypted for a receiver which has public key Y associated with it, belonging to secret key y.
This encryption is random (polymorphic): every time a different random b is used, results in different ciphertexts (encrypted messages).
We represent this encryption function as Enc(b, M, Y).
The library supports three homomorphic operations on ciphertext in (= Enc(b, M, Y), encrypting message M for public key Y with random b):
out = rekey(in, k): ifincan be decrypted by secret keyy, thenoutcan be decrypted by secret keyk*y. Decryption will both result in messageM. Specifically,in = Enc(r, M, Y)is transformed toout = Enc(r, M, k*Y).out = reshuffle(in, s): modifies a ciphertextin(an encrypted form ofM), so that after decryption ofoutthe decrypted message will be equal tos*M. Specifically,in = Enc(r, M, Y)is transformed toout = Enc(r, n*M, Y).o = rerandomize(in, r): scrambles a ciphertext. Bothinandoutcan be decrypted by the same secret keyy, both resulting in the same decrypted messageM. However, the binary form ofinandoutdiffers. Spec:in = Enc(b, M, Y)is transformed toout = Enc(r+b, M, Y);
With these three operations, encrypted data can be re-encrypted for different keys without decrypting the data, while pseudonymizing encrypted identifiers by reshuffling them with a user-specific factor. The core idea behind is that the pseudonymization and rekeying operations are applied on encrypted data. This means that during initial encryption, the ultimate receiver(s) do(es) not yet need to be known. Data can initially be encrypted for one key, and later rekeyed and potentially reshuffled (in case of identifiers) for another key, leading to non-interactive asynchronous end-to-end encryption with built-in pseudonymisation.
For pseudonymization, the core operation is reshuffle with s.
It modifies a main pseudonym with a factor s that is specific to a user (or user group) receiving the pseudonym.
After applying a user specific factor s, a pseudonym is called a local pseudonym.
The factor s is typically tied to the access group or domain of a user, which we call the pseudonymization domain.
Using only a reshuffle is insufficient, as the pseudonym is still encrypted for a key the user does not possess.
To allow a user to decrypt the encrypted pseudonym, a rekey with k is needed, in combination with a protocol to hand the user the secret key k*y.
The factor k is typically tied to the current session of a user, which we call the encryption context.
When the same encrypted pseudonym is used multiple times, rerandomize is applied every time. This way a binary compare of the encrypted pseudonym will not leak any information.
The reshuffle(in, n) and rekey(in, k) can be combined in a slightly more efficient rsk(in, k, n).
Additionally, reshuffle2(in, n_from, n_to) and rekey2(in, k_from, k_to), as well as rsk2(...), can be used for bidirectional transformations between two keys, effectively applying k = k_from^-1 * k_to and n = n_from^-1 * n_to.
Install from crates.io using cargo:
cargo install libpep
or add as a dependency in your Cargo.toml:
[dependencies]
libpep = <latest-version>Run the peppy CLI using cargo:
cargo run --bin peppy
Apart from a Rust crate, this library provides bindings for multiple platforms:
Install from PyPI:
pip install libpep-pyInstall from npm:
npm install @nolai/libpep-wasmThe library is organized into the following main modules, each providing a different level of abstraction and functionality for working with PEP (not so coincidentally organized alphabetically):
| Module | Description |
|---|---|
arithmetic |
Basic arithmetic operations on scalars and group elements |
base |
ElGamal encryption/decryption and core PEP primitives (rekey, reshuffle, rerandomize) |
core |
User-friendly API with Pseudonym and Attribute types, keys, and transcryption operations |
distributed |
Distributed n-PEP operations with PEPSystem and PEPClient for multi-server setups |
For detailed API documentation, see docs.rs/libpep
Both Python and WASM bindings mirror the Rust API structure with the same modules.
The following features are available:
Default features (included unless you use --no-default-features):
long: enables support for long pseudonyms and attributes over 15 bytes using PKCS#7 padding.offline: enables offline encryption towards global keys (instead of only session keys).batch: enables batch transcryption operations with reordering to prevent linkability.serde: enables serialization/deserialization support via Serde.json: enables PEP json structured data types.build-binary: builds thepeppycommand-line tool.
Optional features:
python: enables Python bindings via PyO3 (mutually exclusive withwasm).wasm: enables WebAssembly bindings via wasm-bindgen (mutually exclusive withpython).elgamal3: enables ElGamal triple encryption, including the recipient's public key in message encoding. This provides additional security verification but is less efficient.legacy: enables compatibility with the legacy PEP repository implementation, which uses a different function to derive scalars from domains, contexts, and secrets.insecure: enables methods that expose global secret keys, to be used with care for testing or special use cases.global-pseudonyms: enables global pseudonyms (which are insecure).
Note: The python and wasm features are mutually exclusive because PyO3 (Python bindings) builds a cdylib that links to the Python interpreter, while wasm-bindgen builds a cdylib targeting WebAssembly.
These have incompatible linking requirements and cannot coexist in the same build.
This library uses Ristretto encoding on Curve25519, implemented in the curve25519-dalek crate.
- All cryptographic operations use constant-time algorithms to prevent timing attacks
- Random number generation uses cryptographically secure sources
- The library has been designed for production use but hasn't yet undergone formal security auditing
- Users should properly secure private keys and avoid exposing sensitive cryptographic material
There are a number of arithmetic rules for scalars and group elements: group elements can be added and subtracted from each other.
Scalars support addition, subtraction, and multiplication.
Division can be done by multiplying with the inverse (using s.invert() for non-zero scalar s).
A scalar can be converted to a group element (by multiplying with the special generator G), but not the other way around.
Group elements can also be multiplied by a scalar.
Group elements have an almost 32 byte range (top bit is always zero, and some other values are invalid).
Group elements can be generated by GroupElement::random(..) or GroupElement::from_hash(..).
Scalars are also 32 bytes, and can be generated with Scalar::random(..) or Scalar::from_hash(..).
There are specific classes for ScalarNonZero and ScalarCanBeZero, since for almost all PEP operations, the scalar should be non-zero.
- Rust 1.70+ (MSRV)
- Node.js 18+ (for WASM bindings)
- Python 3.8+ (for Python bindings)
Build and test the core Rust library:
cargo build
cargo test
cargo clippy
cargo doc --no-depsRun tests with different feature combinations:
cargo test --features elgamal3
cargo test --features legacyTo build and test Python bindings:
python -m venv .venv
source .venv/bin/activate
pip install maturin pytest
maturin develop --features python
python -m unittest discover tests/python/ -vTo build a wheel for distribution:
maturin build --release --features pythonTo build and test WASM bindings:
npm install
npm run build # Builds both Node.js and web targets
npm testTo build for a specific target:
wasm-pack build --target nodejs --features wasm # For Node.js
wasm-pack build --target web --features wasm # For browsers- Authors: Bernard van Gastel and Job Doesburg
- License: Apache License 2.0
Based on the article by Eric Verheul and Bart Jacobs, Polymorphic Encryption and Pseudonymisation in Identity Management and Medical Research. In Nieuw Archief voor Wiskunde (NAW), 5/18, nr. 3, 2017, p. 168-172.