Skip to main content

libpep/
lib.rs

1//! # `libpep`: Library for polymorphic pseudonymization and encryption
2//!
3//! This library implements PEP cryptography based on [`ElGamal`](core::elgamal) encrypted messages.
4//! It can be used to encrypt data and re-encrypt it for different keys without decrypting the data,
5//! while pseudonymizing encrypted identifiers in the data.
6//!
7//! In the `ElGamal` scheme, a message `M` can be encrypted for a receiver which has public key `Y`
8//! associated with it, belonging to secret key `y`.
9//! Using the PEP cryptography, these encrypted messages can blindly be *transcrypted* from one key
10//! to another, by a central semi-trusted party, without the need to decrypt the message inbetween.
11//! Meanwhile, if the message contains an identifier of a data subject, this identifier can be
12//! pseudonymized.
13//! This enables end-to-end encrypted data sharing with built-in pseudonymization.
14//! Since at the time of initial encryption, the future recipient does not need to be specified,
15//! data sharing can be done *asynchronously*. This means that encrypted data can be
16//! stored long-term before it is shared at any point in the future.
17//!
18//! This library provides both a [core] API for `ElGamal` encryption and the PEP
19//! [primitives](core::primitives), and a [core] API for
20//! [pseudonymization](core::functions::pseudonymize) and [rekeying](core::functions::rekey)
21//! (i.e. [transcryption](core::functions::transcrypt)) of [`Pseudonym`](core::data::simple::Pseudonym)s
22//! and [`Attribute`](core::data::simple::Attribute)s using this cryptographic concept.
23//!
24//! The PEP framework was initially described in the article by Eric Verheul and Bart Jacobs,
25//! *Polymorphic Encryption and Pseudonymisation in Identity Management and Medical Research*.
26//! In **Nieuw Archief voor Wiskunde (NAW)**, 5/18, nr. 3, 2017, p. 168-172.
27//! [PDF](https://repository.ubn.ru.nl/bitstream/handle/2066/178461/178461.pdf?sequence=1)
28//!
29//! This library implements an extension of the PEP framework, called *n-PEP*, described in the
30//! article by [Job Doesburg](https://jobdoesburg.nl), [Bernard van Gastel](https://sustainablesoftware.info)
31//! and [Erik Poll](http://www.cs.ru.nl/~erikpoll/) (to be published).
32//!
33//! ## Feature flags
34//!
35//! **Note:** The `python` and `wasm` features are mutually exclusive. If both are enabled,
36//! neither binding module will be compiled. This is because PyO3 builds a cdylib that links
37//! to the Python interpreter, while wasm-bindgen builds a cdylib targeting WebAssembly -
38//! they have incompatible linking requirements.
39
40pub mod arithmetic;
41pub mod client;
42pub mod core;
43pub mod data;
44pub mod factors;
45pub mod keys;
46pub mod prelude;
47pub mod transcryptor;
48
49#[cfg(all(feature = "python", not(feature = "wasm")))]
50pub mod py;
51
52#[cfg(all(feature = "wasm", not(feature = "python")))]
53pub mod wasm;
54
55#[cfg(all(feature = "python", not(feature = "wasm")))]
56use pyo3::prelude::*;
57
58/// Python module for libpep
59#[cfg(all(feature = "python", not(feature = "wasm")))]
60#[pymodule]
61fn libpep(m: &Bound<'_, PyModule>) -> PyResult<()> {
62    py::register_module(m)
63}