Public threat model
CryptPeer® is designed to reduce technical and operational risks in sensitive environments: critical infrastructures, sovereign organizations, self-hosted environments, and closed or disconnected networks.
The adversaries considered at the public level include in particular:
- Network adversary — interception, observation, traffic alteration, and MITM attempts.
- Server adversary — compromise of the relay server, access to the database, served code, or technical metadata.
- Local adversary — compromise of the client terminal, malware, workstation theft, or post-mortem analysis.
- Visual adversary — direct observation, screenshots, or temporary exposure of displayed content.
- Organizational adversary — misconfiguration, insufficient partitioning, or inadequate governance.
The guiding principle is: the server must not become a plaintext source or a root holder of application secrets.
Key protection and access security
A core differentiator of CryptPeer is its focus on local protection of application keys.
- Segmented key system: CryptPeer relies on a segmented key authentication system to limit direct exposure of the local application root.
- Ephemeral exposure of useful secrets: working keys are derived locally and are only meant to be kept for the strictly necessary duration.
- No centralization of structuring secrets: the relay server is not designed to hold the application decryption root.
- Supplementary authentication: depending on configuration, mechanisms such as TOTP 2FA may be enabled to strengthen account access security.
The detailed derivation mechanisms and key hierarchy are documented in the public cryptographic specification.
Cryptography and security architecture
The public primitives used and the normative security properties are documented in the specifications.
- Authenticated encryption: AES-256-GCM for application content.
- Derivation functions: PBKDF2-HMAC-SHA-256, HKDF-SHA-256, and documented public uses of SHA-256 / SHA-3.
- Usage separation: distinction between conversation, file, display, and session keys.
- On-demand local derivation: reduction of the value of an isolated server compromise.
- Robust symmetric approach: architecture oriented toward long-term robustness of symmetric building blocks.
Cryptographic specifications →
Operational security and resilience
Operational safety does not rely on algorithms alone. It also depends on deployment architecture, infrastructure control, and continuity of operations.
- Self-hosting: control of the relay server, storage, and deployment policies.
- Local-only and closed-network modes: operation possible without structural dependence on a third-party messaging cloud.
- Encrypted backups: resilience and restoration strategy without exposure of plaintext content.
- Persistence reduction modes: depending on configuration, limitation of durable traces, history, or server persistence.
- Reduced external dependencies: coherence with an operational sovereignty approach.
Trace minimization and confidentiality protection
CryptPeer® follows a logic of minimizing exploitable information:
- reduction of exposure of unnecessary metadata;
- no structural dependence on analytics or profiling services for the sovereign product model;
- limitation of local or server persistence depending on operating modes;
- reduction of visual exposure through display-protection modes where the configuration provides them.
This does not mean the absolute absence of any technical trace, but rather the systematic reduction of avoidable traces and non-essential dependencies.
Compliance and cyber framework
CryptPeer fits within a logic of compliance and risk control. The exact level of obligation depends on the deployed product, the licensee, the business sector, and the applicable regulatory perimeter.
- Cyber Resilience Act (CRA)
- EU Declaration of Conformity (CRA)
- GDPR: data minimization, content protection, and reduced dependency on third parties.
- NIS2: infrastructure control and reduction of critical external dependencies.
- DORA: relevance depends on the status of the operating entity and the applicable financial perimeter.
- Dual-use: case-by-case analysis depending on use, jurisdiction, and applicable regulatory regimes.
cryptpeer.com website security
The presentation website follows a security-by-design logic consistent with the general positioning of CryptPeer®.
Security principles applied to the website
- HTTPS for secure content transport.
- Security headers configured to reduce common browser integration and exposure risks.
- Restrictive Content Security Policy (CSP) to limit the execution surface of third-party resources.
- Integrity of external resources where applicable for CDN dependencies.
- Reduced attack surface through a mostly static architecture.
- Reduced tracking and limitation of non-essential components.
- HTTPS enforced — objective of encrypted transport across the whole website.
- Security headers — protection against clickjacking, MIME sniffing, certain referrer leaks, and reduction of execution surface.
- Minimal attack surface — primarily static architecture, without complex server-side application logic for the public presentation layer.
- Reduction of unnecessary components — limitation of scripts, dependencies, and superfluous external services.
- Cookies and consent — local and transparent management of preferences where technical cookies are used.
- Integration best practices — secure links and control of served resources.
The security of the presentation website is not equivalent to that of the communication product itself, but it should remain consistent with the same requirements of seriousness, technical sobriety, and reduced attack surface.
Useful public references
Transparency and evolution
Product transparency is supported through public documentation, published versions, and release notes. Sensitive elements or details that could weaken security through over-disclosure are not exposed publicly.