Understand the security boundary.
What Poulpy protects, what the application must provide, and where to check implementation assumptions.
For application developers · Source guide · 2394fa5
What the library guarantees
The project’s security policy describes Module-LWE-based encryption under the IND-CPA model with appropriate parameters: the evaluator can operate on encrypted inputs without holding the secret key. Parameter selection is part of that assumption.
The policy does not claim ciphertext authenticity, chosen-ciphertext security, or circuit privacy. An encryption of the expected shape is not proof that a server performed the requested computation. Use the policy as the source for vulnerability reporting and security-model updates.
Responsibilities by boundary
| Boundary | Application responsibility |
|---|---|
| Key owner | Protect secret keys, seed material, backups, and access to decryption |
| Randomness | Use cryptographically secure entropy and distinct randomness streams; fixed tutorial seeds are only for reproducibility |
| Evaluator | Supply only the parameters and evaluation keys needed by the computation |
| Transport and storage | Authenticate participants and messages; define ciphertext and key format/version handling |
| Input parsing | Bound sizes and validate the expected parameters before accepting serialized objects |
| Returned results | Decide how correctness is checked; prevent the decryptor from becoming an unrestricted decryption oracle |
| Outputs | Decide who may learn the result and what repeated outputs reveal |
The client/evaluator example demonstrates object separation using local files. It does not establish a secure network protocol.
Parameters and backend assumptions
Use Parameters and precision to document the modulus, ring degree, secret distribution, evaluation-key moduli, and correctness requirements. The security policy points to the Lattice Estimator; estimates must match the actual distributions and exposed key material.
Backend contracts also matter. For example, the ARM backend threat model documents trusted, well-formed inputs and no constant-time guarantee for its operations. Assess which operations handle secrets in your deployment; this backend statement is not a substitute for a whole-application side-channel analysis.
PaCo and SHIP use additional structured-secret assumptions. Sparse-secret encapsulation does not remove those assumptions from their evaluation keys.
Verification and maturity
Poulpy’s reference and parity tests check implementation behavior. They are different from a security audit or a proof for every supported input. The Architecture page states the current verification design and remaining work.
The sources reviewed for this website do not establish a project-wide independent security audit or a production certification. This is a statement about the evidence published here, not an assertion that no other assessment exists. Evaluate the pinned version against your threat model and consult the maintainers about evidence relevant to your deployment.
Report a vulnerability
Use the private contact in the security policy. For ordinary usage questions and reproducible non-sensitive bugs, use GitHub issues.