Cryptographic Specifications of CryptPeer
Segmented Key Messaging and Authentication System

1. About This Document

This document specifies the cryptographic and security aspects of CryptPeer, a collaborative platform for private end-to-end encrypted communications, based on a segmented key authentication system.

Objectives:

• to describe normatively:
  • the cryptographic primitives used;
  • the key hierarchy and KDFs;
  • the application protocols (messaging, files, backups, Hidden / Defense modes);
• to formalize the role of the segmented key authentication engine as the root of all application secrets;
• to provide a basis for:
  • reference implementation;
  • independent cryptographic audits;
  • potential regulatory evaluations (CSPN type or equivalent).

The target audience is technical: developers, security architects, cryptographers, auditors. This document is normative for CryptPeer reference components. Any divergence must be explicitly documented.

2. Functional and Cryptographic Scope

2.1 Covered Functions

The following are covered:

• 1:1 and group encrypted messaging within a CryptPeer instance;
• file transfers and attachments (including audio/video);
• audio/video recordings captured locally then sent encrypted;
• audio/video calls and video conferencing, including screen sharing, in a self-hosted environment;
• encrypted 3-2-1 backup on multiple media (USB, SSD, NAS, cloud, etc.);
• autonomous file encryption / decryption;
• export / import of discussion threads (raw JSON, discussion mode, restoration);
• operating modes:
  • CryptPeer (standard),
  • CryptPeer Hidden,
  • CryptPeer Defense;
• segmented key authentication engine and its API (K_pair, K_seg);
• key hierarchy:
  • K_seg, K_base, K_conv_v2, K_file_v2, K_msg, K_view, K_tunnel_def;
• local PFS mechanisms (unique key per message or per epoch);
• server-side database/metadata encryption (abstractly);
• topologies:
  • autonomous self-hosted relay server,
  • local-only mode,
  • remote access via NAT / reverse proxy,
  • client-side favorite server list.

2.2 Out of Scope

The following are not covered, unless explicitly mentioned:

• purely ergonomic aspects (UI, UX flows);
• detailed OS hardening (disk encryption, MDM, system policies);
• organizational procedures (HR, physical access control, etc.);
• complete compliance analyses (GDPR DPIA, detailed NIS2 policy);
• the internal cryptographic mechanisms of license management (EviEngine), described only at the architectural level, without detailing their cryptographic implementation.

3. Notations, Types and Conventions

3.1 Types

• A byte: value in {0,…,255}.
• Byte string: b ∈ {0,1}^*; we denote |b| the length in bytes.
• Character string: encoded in UTF-8 before any cryptographic processing.
• Unsigned integer: encoded in big-endian on a fixed size (generally 64 bits) when included in KDF inputs.

3.2 Operations

• Concatenation: X || Y.
• Hash: H(x) (function specified in Part III).
• PBKDF2: PBKDF2_HMAC_SHA256(P, salt, iter, L) → output of length L bytes.
• HKDF: HKDF_SHA256(salt, IKM, info, L) / HKDF_SHA3_256(...).
• 64-bit integer encoding: encodeUint64(n).

3.3 Key Notation

• K_pair: segmented pairing key, managed by the segmented key engine, not handled in plaintext by CryptPeer.
• K_seg: local root key exposed to CryptPeer by the engine.
• K_base: base key of a conversation (v1).
• K_conv_v2: conversation key v2.
• K_file_base, K_file_v2: keys associated with file / export encryption.
• K_msg: ephemeral key associated with a message or epoch.
• K_view: key used for temporary decryption on display (Hidden mode).
• K_tunnel_def: tunnel keys in Defense mode.

Unless explicitly mentioned, all symmetric keys used for encryption are 256 bits in length.

4. References and Design Principles

CryptPeer relies on:

• standard symmetric primitives (AES-256-GCM, SHA-256 / SHA-3);
• standardized KDFs (PBKDF2, HKDF);
• the patented segmented key authentication system (WO2018154258A1), modeled as a component providing:
  • a restricted API,
  • non-export and volatility guarantees.

The design respects the principles:

• 256-bit symmetric robustness;
• clear separation of roles:
  • segmented engine,
  • client,
  • blind relay server;
• minimization of metadata and traces.

5. Global Architecture of CryptPeer

5.1 Components

A CryptPeer instance comprises:

• a relay server S:
  • self-hosted (local, on-premise, NAS, controlled VPS);
  • storing only already encrypted content/metadata;
• a web client bundle:
  • JS/TS/WASM code served by S;
  • executed in the terminal's browser;
• a local segmented key engine:
  • software and/or hardware;
  • exposing K_seg to the client;
• a local directory structuring users into categories.

A CryptPeer instance does not participate in any federation. Messages never transit through other CryptPeer servers.

5.2 Roles

• Client:
  • derives all application keys from K_seg and public data;
  • performs all encryption/decryption;
  • manages display (normal mode, Hidden, Defense).
• Segmented Key Engine:
  • manages K_pair and its segments;
  • temporarily restores K_seg according to a policy.
• Relay Server S:
  • serves the web client;
  • authenticates connections (never handling plaintext);
  • stores and relays encrypted blocks.
• Backup Media:
  • receive encrypted backups (no secrets in plaintext).

5.3 Hardware License Management (EviEngine)

CryptPeer integrates EviEngine technology from Freemindtronic for license management without a server or database. This component is not part of the encryption path for messages or files, but it is structural for the platform's sovereignty, anonymity, and autonomy model.

Main properties of the license model:

• Hardware-bound license:
  • the license is associated with hardware characteristics of the machine (e.g., motherboard serial number);
  • it is not linked to the user's civil identity.
• No license server or database:
  • no external license server is queried to validate CryptPeer usage;
  • no centralized license database is required;
  • license verification is performed locally, on the instance, via EviEngine.
• Offline operation:
  • license validation works in local-only mode, without Internet connection;
  • service continuity does not depend on a remote license third party.
• Preserved anonymity:
  • since the license is linked to hardware and not to a nominal identity, no centralized user account is required;
  • no license telemetry to a third-party cloud is necessary.

From a cryptographic perspective, license management via EviEngine is orthogonal to content security (messages, files, backups). The primitives, key hierarchy, and protocols described in Parts III to VII remain unchanged, whether the license is present or not. However, from the perspective of the "Zero Trust. Zero Cloud. Zero Trace." doctrine, this license model:

• eliminates risks related to license servers (exfiltration, unavailability, usage tracking);
• avoids creating a centralized database of client identifiers;
• allows a CryptPeer instance to operate in a sovereign manner, including on completely closed networks.

The internal cryptographic details of EviEngine (license formats, exact algorithms for hardware binding, etc.) are not covered by this document. They may be the subject of a separate specification and a specific audit focused on the license chain.

6. Deployment Modes

6.1 Local-only Mode

In local-only mode:

• S is only accessible on a local network (LAN, private Wi-Fi, dedicated AP);
• no direct visibility from the Internet;
• all communications remain within the local network bubble.

This mode is preferred for environments:

• regal, military, diplomatic;
• sensitive sites;
• air-gap networks with physical synchronization.

6.2 Mode with Remote Access

In remote mode:

• S is behind a router/firewall;
• a reverse proxy/NAT exposes a domain name or subdomain;
• TLS is used to secure HTTP(S) transport.

Application content is end-to-end encrypted: TLS protects the transport layer, AES-256-GCM (with keys derived from K_seg) protects application data.

6.3 Self-Portability

The S instance can be deployed on:

• Raspberry Pi 5;
• fanless mini-PC;
• servers, NAS, Linux VPS.

The instance is self-contained: the server code + encrypted database can be physically moved, provided deployment secrets are protected (admin credentials, possible database or OS encryption keys).

7. Universal Web Client

7.1 Principle

CryptPeer provides a single client:

• implemented in JS/TS/WASM;
• executed in a modern browser (desktop, mobile, TV, media);
• no specific native application is provided.

7.2 Consequences

• a single client codebase to audit and harden;
• centralized updates via S:
  • as soon as a new bundle is served, all clients use it on the next load;
• no obsolete versions installed on terminals.

Browser-specific risks (extensions, 0-day) are taken into account in the threat model (section 12).

8. Operating Modes

8.1 CryptPeer Mode (standard)

Features:

• 1:1 and group messaging;
• file transfers, attachments;
• encrypted audio/video recordings;
• audio/video calls / conferences;
• encrypted backups.

Cryptographic properties:

• E2E based on K_seg;
• local PFS via K_msg;
• no content keys on the server.

8.2 CryptPeer Hidden Mode

Objective: reduce visual exposure.

Characteristics:

• encrypted display by default;
• explicit decryption of a conversation;
• automatic re-encryption of the view:
  • after a delay;
  • or on event (tab change, focus loss, etc.);
• memory erasure of plaintext buffers after re-encryption.

Uses a view key K_view derived from K_seg.

8.3 CryptPeer Defense Mode

Objective: regal / highly sensitive uses. Learn more →

Characteristics:

• dedicated server and engine instance;
• encrypted tunnel with segmented and ephemeral keys (K_tunnel_def);
• RAM-only policy:
  • no persistent logs;
  • no exploitable durable metadata;
  • aggressive memory auto-purge;
• reduced or absent history depending on configuration.
• No storage: tunneled encryption with direct transfer of encrypted messages and files without storage on the relay server.

Defense mode prioritizes absence of traces over historization capability.

9. Multi-Server Favorites and Absence of Federation

9.1 Favorites List

The client maintains locally:

Favorites = { (label_i, url_i) }_i

The user chooses at any time a single server S to connect to.

9.2 No Mesh

There is:

• no inter-server routing;
• no federation;
• no global directory.

Consequences:

• each S instance is a totally independent bubble;
• global communication mapping is difficult to establish for an external adversary.

10. Directory, Categories and Logical Partitioning

10.1 Local Directory

Each S instance maintains a directory:

• set of users U;
• identifiers, contact information (pseudonyms, possibly attributes);
• information necessary for authentication, stored encrypted.

10.2 Contact Categories

The administrator associates each user u with one or more categories:

C = { C_1, C_2, … }  with  C_i ⊆ U

Rules:

• category membership is decided by the admin;
• a user cannot self-assign.

10.3 Groups and Partitioning

A discussion group G is defined as:

G = (groupId, C_i, Members)

with Members ⊆ C_i

By default:

• groups do not directly mix multiple categories;
• a user can only invite members of their authorized categories.

This partitioning limits the lateral propagation of account compromise and inter-perimeter espionage risks within the same instance.

11. Doctrine « Zero Trust. Zero Cloud. Zero Trace. »

11.1 Zero Trust

• the server S is untrusted by design;
• S holds no decryption keys;
• S never derives keys from identifiers:
  • all derivations are client-side with K_seg.

11.2 Zero Cloud

• no structuring secrets (K_pair, segments, K_seg, content keys) are entrusted to a third-party cloud service;
• remote media (NAS, cloud) only receive pre-encrypted data.

11.3 Zero Trace

• on-demand derivation, rapid key erasure;
• no persistent plaintext on the client side;
• minimal server-side logs:
  • and non-existent in Defense mode.

Hidden and Defense modes reinforce this doctrine on the visual dimension and on memory traces.

12. Threat Model and Assumptions

12.1 Considered Adversaries

• Server adversary:
  • full control of S (root, DB, served code);
• Network adversary:
  • interception, MITM, massive observation;
• Local adversary:
  • malware, terminal theft, post-mortem forensics;
• Visual adversary:
  • screen capture, direct observation, spy camera;
• Organizational adversary:
  • unauthorized account creation, misconfiguration of categories.

12.2 Trust Assumptions

• segmented engine compliant with Part IV;
• browsers and OS reasonably up to date;
• adversary does not simultaneously and durably possess all segments of K_pair.

12.3 Out of Scope

• sophisticated hardware attacks (TEMPEST, deep side-channels);
• simultaneous and durable compromise of all segments on all media;
• uncorrected critical 0-day allowing instant exfiltration of all sensitive memory.

13. Random Number Generator

13.1 Entropy Source

The client MUST use:

• the system / browser CSPRNG API (e.g., window.crypto.getRandomValues);
• or an equivalent of comparable robustness.

The server, when generating random values (non-critical for content secrets), MUST use an appropriate CSPRNG source.

13.2 Usage

The RNG is used for:

• AES-GCM IV/nonce;
• random salts (v2 files, certain backups);
• random identifiers (groupId, etc.) when they are not derived.

14. Hash Functions

CryptPeer uses by default:

• SHA-256 for:
  • identifier hashing,
  • deterministic salt derivation v1;
• optionally SHA3-256 for certain strengthened derivations.

Notation:

• H256(x) = SHA-256(x);
• H3_256(x) = SHA3-256(x).

15. Key Derivation Functions (KDF)

15.1 PBKDF2-HMAC-SHA-256

Default parameters:

• iter = 100000;
• L = 32 bytes (256 bits).

Usage:

• derivation of K_base from keyMaterial_ids;
• derivation of K_file_base from userId.

15.2 HKDF

Two variants:

• HKDF_SHA256 (default);
• HKDF_SHA3_256 (hardening option).

Call:

HKDF(salt, IKM, info, L) -> OKM

Usage:

• derivation of K_conv_v2, K_file_v2, K_msg, K_view, K_tunnel_def from K_base, K_file_base and K_seg.

16. Authenticated Encryption

16.1 AES-256-GCM

Parameters:

• key: 256 bits;
• nonce/IV: 96 bits;
• authentication tag: 128 bits.

The IV MUST be:

• either randomly generated for each encryption;
• or derived from a unique counter per key, to ensure uniqueness.

In CryptPeer:

• for messages: random 96-bit IV;
• for files: random 96-bit IV;
• the storage formalism is described in Annex D.

17. Role and Positioning of the Segmented Engine

The segmented key engine:

• manages K_pair, segmented pairing key;
• never exposes it in plaintext;
• restores root keys K_seg to CryptPeer via a local API;
• applies segmentation policies (segment order, factors, attempt limits, context).

CryptPeer considers it as a black box presenting the properties of section 20. Internal implementation details fall under the international patent WO2018154258A1 of Freemindtronic (segmented key authentication system) and non-public internal technical documents.

Reference: For more information on the reference patent implemented in CryptPeer, see the Segmented Key Patent page.

18. Abstract Data Model

18.1 Entities

• K_pair: logical pairing key;
• Segment: unit stored on a medium / factor:
  • segment matériel (NFC, HSM, etc.) ;
  • segment logiciel (secret local chiffré) ;
  • segment cognitif (PIN, phrase) ;
  • segment contextuel (présence d'un device, d'un réseau) ;
• Policy :
  • policyId ;
  • liste ordonnée de segments requis ;
  • paramètres (limites de tentatives, expire, contexte).

18.2 Context

The engine takes into account an abstract context:

RootContext = {
  mode: "standard" | "masque" | "defense",
  serverId: string,      // cryptographic identifier of instance S
  localId: string,       // logical identifier of instance (URL, label)
  categoryId?: string,   // optional: contact category
  deviceId?: string,     // terminal identifier
  appVersion?: string    // CryptPeer client version
}

This context is incorporated into the derivation of K_seg.

19. Functional Interface

Minimal interface exposed to the CryptPeer client:

type RootContext = {
  mode: "standard" | "masque" | "defense";
  serverId: string;
  localId: string;
  categoryId?: string;
  deviceId?: string;
  appVersion?: string;
};

interface SegmentedKeyEngine {
  getRootKey(policyId: string, context: RootContext): Promise<ArrayBuffer>; // K_seg
  clear(): Promise<void>;
}

19.1 getRootKey

• input:
  • policyId: identifier of the segmentation policy to use;
  • context: logical context (instance, mode, device).
• output:
  • K_seg: byte string of length at least 32 bytes.

Conditions:

• the recomposition of K_pair (if necessary) is performed in volatile memory;
• K_seg is only maintained in memory, for a minimal duration.

19.2 clear

Erases:

• any copy of K_seg;
• any temporary sensitive material related to recomposition in the engine's memory.

20. Required Security Properties

The engine MUST guarantee at minimum:

1. Non-export of K_pair and segments
   • no API call allows retrieving K_pair or a raw segment.
2. Ephemeral recomposition
   • K_pair (if recomposed) and K_seg only reside in volatile memory;
   • active erasure after use.
3. Segmentation policy
   • respect of policyId:
     • number and type of required segments;
     • order;
     • attempt limits;
     • authorized contexts.
4. Context binding
   • K_seg is a function of:
     • K_pair;
     • policyId;
     • context;
     • label (usage, e.g., "CryptPeer-root").
5. Resistance to reasonable local attacks
   • direct extraction of segments or K_pair made difficult;
   • protection against simple inspection of software storage.

21. Integration with Hardware Media

The engine can integrate:

• NFC HSM;
• PGP HSM (PC);
• other sovereign media.

CryptPeer does not require a particular type of media, but requires that:

• segments stored on these media be non-exportable in plaintext;
• the use of the media be integrated into the segmentation policy.

22. Overview

K_pair (segmentée, moteur)
   ↓  KDF_segmented(policyId, context, "CryptPeer-root")
K_seg
   ↓ PBKDF2/HKDF + IDs publics
K_base, K_file_base
   ↓ HKDF + K_seg
K_conv_v2, K_file_v2
   ↓ HKDF + index/epoch
K_msg

Plus:

• K_view derived from K_seg for Hidden mode;
• K_tunnel_def derived from K_seg for Defense mode.

23. Local Root Key K_seg

Formally:

K_seg = KDF_segmented(
  K_pair,
  label   = "CryptPeer-root",
  policyId,
  context // encodé de manière déterministe
)

Minimum size: 256 bits.

24. Conversation Base Keys K_base

24.1 1:1 Conversations

Let userId_A, userId_B, conversationId.

We define:

ids_sorted      = sortLex(userId_A, userId_B)
keyMaterial_ids = ids_sorted[0] || ":" || ids_sorted[1] || ":" || conversationId

salt_v1 = H256("CryptPeer/salt/v1" || keyMaterial_ids)

K_base = PBKDF2_HMAC_SHA256(
  P    = keyMaterial_ids,
  salt = salt_v1,
  iter = 100000,
  L    = 32
)

24.2 Groups

For a group groupId:

keyMaterial_ids = "group:" || groupId

salt_v1 = H256("CryptPeer/salt/v1" || keyMaterial_ids)

K_base = PBKDF2_HMAC_SHA256(
  P    = keyMaterial_ids,
  salt = salt_v1,
  iter = 100000,
  L    = 32
)

K_base reste dérivable par le serveur en v1 ; en v2, le contenu est protégé par l'ancrage sur K_seg.

25. Conversation Keys v2: K_conv_v2

For each conversation (1:1 or group):

K_conv_v2 = HKDF_SHA256(
  salt = K_seg,
  IKM  = K_base,
  info = "CryptPeer/msg/v2",
  L    = 32
)

Properties:

• depends simultaneously on:
  • the identifier structure (K_base);
  • the local root K_seg;
• not derivable by the server.

26. File Keys v2: K_file_v2

26.1 Base File Key per User

salt_file_v1 = H256("CryptPeer/file/salt/v1" || userId)

K_file_base = PBKDF2_HMAC_SHA256(
  P    = userId,
  salt = salt_file_v1,
  iter = 100000,
  L    = 32
)

26.2 File Keys v2

K_file_v2 = HKDF_SHA256(
  salt = K_seg,
  IKM  = K_file_base,
  info = "CryptPeer/file/v2",
  L    = 32
)

For each file, a random salt and a random IV are used at the AES-GCM level. One can optionally derive a key per file by including a file identifier in info.

27. Ephemeral Message Keys: K_msg

27.1 Conversation Seed Key

K_conv_v2_seed = HKDF_SHA256(
  salt = K_seg,
  IKM  = K_base,
  info = "CryptPeer/msg/v2-seed",
  L    = 32
)

27.2 Key per Message or Epoch

Let epochId, typically a 64-bit integer (message index, or time window).

K_msg = HKDF_SHA256(
  salt = encodeUint64(epochId),
  IKM  = K_conv_v2_seed,
  info = "CryptPeer/msg/epoch",
  L    = 32
)

Each message is encrypted with a distinct K_msg; erasure of previous keys provides local PFS.

28. View Keys K_view (Hidden Mode)

For a given display session, identified by viewSessionId (random):

K_view = HKDF_SHA256(
  salt = viewSessionId,
  IKM  = K_seg,
  info = "CryptPeer/view/v1",
  L    = 32
)

Usage: temporarily encrypt/decrypt conversation display buffers. K_view is invalidated as soon as the view is re-encrypted.

29. Tunnel Keys K_tunnel_def (Defense Mode)

In Defense mode, a tunnel channel is established between client and S:

• K_tunnel_seed derived from K_seg:

K_tunnel_seed = HKDF_SHA256(
  salt = H256("CryptPeer/defense/serverId:" || serverId),
  IKM  = K_seg,
  info = "CryptPeer/defense/seed/v1",
  L    = 32
)

• for each network epoch netEpoch:

K_tunnel_def = HKDF_SHA256(
  salt = encodeUint64(netEpoch),
  IKM  = K_tunnel_seed,
  info = "CryptPeer/defense/tunnel/v1",
  L    = 32
)

These keys are never persisted; the Defense server does not maintain durable state.

30. Migration v1 → v2

v1 messages or files can be:

• recognized by a version field;
• decrypted with v1 keys derived without K_seg;
• optionally re-encrypted to v2.

v1/v2 coexistence must be strictly time-bounded. Eventually, derivation without K_seg is disabled.

31. 1:1 Message Encryption

For a 1:1 conversation between userId_A and userId_B:

1. Derivation of K_conv_v2: according to section 25, from K_base and K_seg.
2. Derivation of K_msg: according to section 27, for each message or epoch.
3. Encryption:
   • 96-bit random IV generated via CSPRNG;
   • AES-256-GCM encryption with K_msg;
   • format: IV || ciphertext || tag.
4. Sending: the encrypted message is sent to relay server S with minimal metadata (conversationId, timestamp, version).

Server S stores only the encrypted blob, without decryption capability.

32. Group Conversations

For a group groupId:

1. Group key: K_base is derived according to section 24.2, then K_conv_v2 according to section 25.
2. Participant management:
   • adding/removing participants: the creator or group administrator can modify the list;
   • voluntary departure: any participant can leave the group;
   • creator/admin departure: a new administrator must be designated among remaining participants.
3. Encryption: identical to section 31, with K_conv_v2 and K_msg derived from groupId.
4. Distribution: server S relays the encrypted message to all active group members.

Group keys are never shared in plaintext: each participant derives K_conv_v2 locally from K_seg and groupId.

33. File Transfers and Attachments

For a file associated with user userId:

1. Derivation of K_file_v2: according to section 26, from K_file_base and K_seg.
2. Encryption:
   • 256-bit random salt generated via CSPRNG;
   • 96-bit random IV per file;
   • AES-256-GCM encryption with K_file_v2;
   • format: salt || IV || ciphertext || tag.
3. Metadata: filename, size, MIME type can be encrypted separately or included in the blob.
4. Storage: the encrypted file is stored on S or on a backup medium (section 34).

For attachments in messages, the file is encrypted with K_file_v2 and a reference is included in the encrypted message.

34. Encrypted Backups 3-2-1

The 3-2-1 backup strategy consists of:

• 3 copies of data;
• 2 different media;
• 1 off-site copy.

CryptPeer implementation:

1. Encryption: backups use K_file_v2 according to section 26, with a unique salt per backup.
2. Media:
   • USB, external SSD (local);
   • NAS (local network);
   • cloud (optional, data pre-encrypted).
3. Format: encrypted archive containing:
   • structure metadata (encrypted);
   • messages, files, directory (all encrypted);
   • verification manifest.
4. Restoration: requires K_seg to derive all decryption keys.

No plaintext secrets are stored in backups: only possession of K_seg (via the segmented engine) allows restoration.

35. JSON Exports / Imports of Discussions

Export allows saving a conversation in a portable JSON format:

1. Export format:
   • conversation metadata (conversationId, participants, dates);
   • encrypted messages (IV, ciphertext, tag);
   • attached files (encrypted references);
   • format version, cryptographic parameters used.
2. Export encryption: the complete JSON archive can be encrypted with K_file_v2 for additional protection.
3. Import:
   • verification of integrity and authenticity;
   • decryption with K_conv_v2 and K_msg derived locally;
   • restoration in a new instance or conversation.

Import requires that the destination instance shares the same K_seg (same segmented engine) or that keys are migrated according to section 30.

36. Audio/Video Calls and Screen Sharing

For real-time communications:

1. Session establishment:
   • negotiation via encrypted messages (WebRTC or proprietary protocol);
   • session keys derived from K_conv_v2 with a unique nonce per session.
2. Media stream encryption:
   • SRTP or equivalent encryption with keys derived from the session;
   • unique IV/nonce per packet;
   • authentication of each packet.
3. Screen sharing:
   • screen capture encrypted frame by frame;
   • optional compression before encryption;
   • transmission via the same encrypted channel.
4. Recording: if enabled, streams are recorded locally with K_file_v2 according to section 33.

Server S only relays encrypted packets, without decryption or inspection of media content.

37. Practical Implementation of Local PFS

Local Perfect Forward Secrecy is ensured by:

1. K_msg derivation per message: according to section 27, each message uses a unique K_msg derived from K_conv_v2_seed and an epochId.
2. Key erasure:
   • after decrypting a message, K_msg is erased from memory;
   • keys from previous epochs are not retained.
3. Epoch management:
   • epoch = message index or time window;
   • epoch change: derivation of a new K_msg;
   • old K_msg cannot be recalculated without K_conv_v2_seed.
4. Memory protection:
   • secure erasure of buffers containing keys;
   • no swap/paging of sensitive memory areas (if possible);
   • automatic purge after inactivity.

In case of local compromise, only messages from the current epoch are exposed. Previous messages remain protected because their K_msg have been erased.

38. Security Objectives

CryptPeer aims to guarantee:

1. End-to-end confidentiality:
   • messages and files are never in plaintext on the server;
   • only legitimate participants can decrypt content;
   • the relay server cannot access decryption keys.
2. Integrity:
   • detection of any modification of messages or files;
   • authentication of message origin;
   • protection against man-in-the-middle attacks.
3. Authentication:
   • verification of participant identity;
   • protection against identity spoofing;
   • integrity of directory and categories.
4. Availability:
   • operation in local-only mode (without Internet dependency);
   • resilience to server failures (backups, redundancy);
   • self-hosting for total infrastructure control.
5. Non-repudiation (optional depending on context):
   • cryptographic proofs of message origin;
   • traceability for sovereign uses (if configured).

39. Confidentiality and Integrity Properties

39.1 Confidentiality

Confidentiality is ensured by:

• E2E encryption: all application data is encrypted with AES-256-GCM before transmission.
• Anchoring on K_seg: encryption keys depend on K_seg, not accessible to the server.
• Local PFS: each message uses a distinct ephemeral K_msg key (section 37).
• Absence of exploitable metadata: the server cannot derive keys from public identifiers.

39.2 Integrity

Integrity is guaranteed by:

• GCM authentication tag: each message/file includes a 128-bit tag verifying integrity and authenticity.
• Protection against modification: any alteration of ciphertext or tag is detected during decryption.
• Protection against replay: uniqueness of IV/nonce prevents reuse of encrypted messages.
• Origin verification: only participants possessing K_seg can generate valid messages.

40. Zero Trust / Zero Cloud / Zero Trace Properties

40.1 Zero Trust

Server S is considered untrusted:

• no decryption keys are stored on S;
• S cannot derive keys from identifiers;
• all key derivations are performed client-side with K_seg;
• total compromise of S does not expose encrypted content.

40.2 Zero Cloud

No structuring secrets are entrusted to third-party cloud services:

• K_pair and its segments remain local;
• K_seg is never transmitted or stored on external cloud;
• cloud backups (if used) contain only pre-encrypted data;
• operation possible in local-only mode without Internet connection.

40.3 Zero Trace

Minimization of exploitable traces and metadata:

• on-demand key derivation, rapid erasure after use;
• no persistent plaintext client-side (except standard mode with history);
• minimal server-side logs (non-existent in Defense mode);
• encrypted or minimized metadata;
• Masked mode: encrypted display by default, automatic re-encryption.

41. Resilience to Server Compromise

In case of total server S compromise:

1. Encrypted data: the server only holds encrypted blobs, not decryptable without K_seg.
2. Absence of keys: S cannot derive K_seg, K_conv_v2, or K_msg from public identifiers.
3. Limited metadata: even if metadata (conversationId, timestamps) are exposed, they do not enable decryption.
4. No retroactive compromise: thanks to local PFS, previous messages remain protected even if S is compromised.
5. Recovery: restoration from encrypted backups (section 34) on a new server, without secret exposure.

Compromise of S may allow:

• interception of new messages (but not their decryption);
• traffic analysis (volumes, frequencies, patterns);
• availability attacks (DoS).

These risks are limited by self-hosting and infrastructure control.

42. Resilience to Local Compromise

In case of client terminal compromise:

1. Segmentation protection:
   • K_pair is segmented and not stored in plaintext;
   • access to K_seg requires segment recomposition according to policy;
   • hardware segments (NFC, HSM) are not accessible via software malware.
2. Memory erasure:
   • K_seg is only maintained in memory temporarily;
   • active erasure after use or inactivity;
   • protection against memory dump (if possible via OS).
3. Local PFS:
   • K_msg keys from previous messages are erased;
   • only messages from the current epoch are exposed in case of compromise.
4. Masked mode:
   • encrypted display by default;
   • automatic re-encryption after temporary decryption;
   • protection against screenshots and visual espionage.

Limitations: malware with durable root access and physical access to segments can compromise K_seg. Segmentation and hardware segments reduce this attack surface.

43. Resilience to Ransomware and Infostealers

Protection against malware exfiltrating or encrypting data:

1. Already encrypted data:
   • messages and files are stored encrypted on the terminal;
   • ransomware cannot re-encrypt already encrypted data in an exploitable manner;
   • exfiltration of encrypted blobs is useless without K_seg.
2. K_seg protection:
   • K_seg is not stored in plaintext on disk;
   • access via segmented engine with segmentation policy;
   • hardware segments not accessible to software malware.
3. Encrypted backups:
   • 3-2-1 backups on external media (section 34);
   • restoration possible without depending on compromised terminal;
   • backups are encrypted independently of the file system.
4. Defense mode:
   • RAM-only storage, no disk persistence;
   • aggressive automatic memory purge;
   • reduced attack surface for infostealers.

An infostealer can exfiltrate encrypted blobs, but cannot decrypt them without access to segments and K_seg.

44. Resilience to Visual Espionage

Protection against direct screen observation:

1. Masked mode:
   • encrypted display by default (content not readable);
   • explicit decryption on user request;
   • automatic re-encryption after delay or event (tab change, focus loss).
2. View keys K_view:
   • K_view derivation according to section 28;
   • temporary encryption of display buffers;
   • K_view invalidation after re-encryption.
3. Capture protection:
   • detection and blocking of screenshots (if supported by OS/browser);
   • optional watermarking for traceability;
   • automatic masking during screen sharing (if detected).
4. Physical protection:
   • screen privacy filters (organizational measure);
   • visual exclusion zones for sensitive uses.

Masked mode significantly reduces the visual exposure window, but cannot protect against continuous observation during temporary decryption.

45. Symmetric Post-Quantum Considerations

45.1. Modèle d'attaquant quantique

On considère un attaquant disposant :

• d'un calculateur quantique capable d'exécuter :
  • Shor sur RSA/ECC (non utilisés dans CryptPeer),
  • Grover sur les primitives symétriques,
• d'une capacité illimitée de stockage ("store now, decrypt later") :
  • il peut archiver tout le trafic chiffré,
  • les bases de données serveur,
  • et tenter de les déchiffrer des années plus tard.

But de la méthode :

Même dans ce modèle, aucune clé utile pour déchiffrer les messages/fichiers ne doit être dérivable sans :

• casser AES-256 / SHA-3-512 sous Grover, et
• reconstruire la clé segmentée K_seg à partir de ses segments, ce qui suppose de casser la mécanique brevetée locale.

45.2. Choix de primitives et longueurs "quantum-informed"

Pour résumer :

• Chiffrement : AES-256-GCM
  • Sous Grover, la sécurité effective ≈ 128 bits, ce qui reste largement suffisant pour des usages réalistes de très long terme.
• Hachage / KDF :
  • SHA-256 pour compat (PBKDF2),
  • SHA-3-512 pour les dérivations critiques (HKDF) et dans le moteur segmenté.
• Longueurs de clés :
  • K_seg : au moins 256 bits, idéalement 256 ou 512 bits de sortie HKDF_SHA3_512,
  • K_conv_v2, K_file_v2, K_msg : 256 bits (clés AES-256).

Avec Grover, une clé de 256 bits se comporte approximativement comme une clé de 128 bits contre un adversaire quantique ; une marge encore très confortable.

45.3. Impact du quantique sur chaque étage de la méthode

Rappel de la chaîne :

Segments S1..Sn  ──>  Z  ──>  H = SHA3-512(Z || policyId || deviceContext)
                          │
                          └─>  K_pair = HKDF_SHA3_512(H, policySalt, "EviLink/SegmentedPairKey", 64)
                                    │
                                    └─>  K_seg = HKDF_SHA3_512(K_pair, appSalt, "CryptPeer/RootKey", 32..64)
                                              │
                                              ├─> K_conv_v2    = HKDF_SHA3_512(K_base_conv, K_seg, contextConv, 32)
                                              └─> K_file_v2    = HKDF_SHA3_512(K_file_base, K_seg, contextFile, 32)
                                                        │
                                                        └─> AES-256-GCM (messages, fichiers)

Effets quantiques :

Sur les segments et K_pair

Les segments ne sont pas le résultat d'un échange cryptographique à clé publique (pas d'ECDH à casser via Shor). Ils sont locaux, souvent matériels ou cognitifs.

Pour reproduire K_pair, un attaquant doit :

• soit obtenir tous les segments (compromission physique / sociale),
• soit casser directement SHA3-512 / HKDF_SHA3_512 (préimage) via Grover sur un espace de 512 bits → sécurité effective toujours très élevée.

Sur K_seg

K_seg est dérivé via HKDF_SHA3_512 à partir de K_pair et d'un sel d'application. Même en présence d'un ordinateur quantique, la recherche préimage sur un espace de 512 bits avec Grover reste impraticable, et K_seg n'est jamais en transit ni stocké côté serveur.

Sur les étapes PBKDF2-SHA-256 (K_base_conv, K_file_base)

Ces KDF restent basés sur SHA-256 : Grover réduit la sécurité asymptotiquement, mais on reste en pratique à un niveau proche de 128 bits. Surtout, K_base_conv et K_file_base ne suffisent plus : il faut aussi K_seg pour obtenir les clés finales.

Sur HKDF_SHA3_512 (K_conv_v2, K_file_v2, K_msg)

L'attaquant, même quantique, doit :

• soit casser HKDF_SHA3_512 (préimage) sur une sortie de 256 bits sous Grover,
• soit s'attaquer à AES-256-GCM directement,
• soit remonter à K_seg → ce qui ramène au problème précédent.

En pratique, à chaque étage, on impose un coût d'attaque exponentiel, divisé au mieux par √N avec Grover, mais toujours hors de portée.

45.4. Neutralisation du scénario "store now, decrypt later"

Scénario typique :

• L'attaquant enregistre aujourd'hui :
  • tout le trafic TLS (même si TLS est classiquement sécurisé),
  • toutes les BD serveur (messages chiffrés, fichiers chiffrés, IDs, etc.).
• Dans 20 ans, il dispose d'un calculateur quantique puissant.

Dans la méthode actuelle :

Il n'existe :

• aucune clé publique / privée à casser par Shor,
• aucun secret d'établissement de session sur le réseau,
• aucune copie de K_seg côté serveur.

Pour déchiffrer des données :

Il doit casser AES-256-GCM ou HKDF_SHA3_512 pour remonter à une clé utile, et même en remontant à K_base_conv / K_file_base, il lui manque toujours K_seg, qui n'est pas dans les données archivées.

Le modèle "je stocke maintenant et je casserai l'ECDH plus tard" n'a tout simplement pas de prise, parce que :

• il n'y a pas d'ECDH,
• la racine de sécurité est locale et segmentée, hors canal.

45.5. PFS locale et horizon d'exposition

La méthode peut être renforcée par une Forward Secrecy locale, en dérivant des clés éphémères :

K_epoch  = HKDF_SHA3_512(K_conv_v2, 0x00..00, "CryptPeer/msg/epoch", 32)
K_msg    = HKDF_SHA3_512(K_epoch, encodeUint64(msgIndex), "CryptPeer/msg", 32)

Conséquences (même face à un attaquant quantique) :

La compromission d'une clé K_msg ou même d'un petit ensemble de messages ne permet pas :

• de remonter à K_conv_v2,
• ni à K_seg,
• ni aux messages hors de l'"époque" considérée.

Tu peux inscrire dans ta doctrine : un horizon temporel explicite (par exemple : "au-delà de N années, l'accès à l'historique nécessite une re-validation segmentée stricte"), ce qui limite encore plus la valeur d'un dump de données anciennes, même pour un attaquant quantique.

45.6. Résumé "quantique" de la méthode de chiffrement à clé segmentée

La clé d'appairage segmentée est :

• locale,
• reconstruite à partir de segments multiples,
• hachée / dérivée avec SHA-3-512 + HKDF,
• jamais transmise ni stockée côté serveur.

La clé racine d'application K_seg :

• est obtenue à partir de K_pair,
• sert de sel fort dans des dérivations HKDF_SHA3_512 vers K_conv_v2, K_file_v2, K_msg.

Les clés opérationnelles chiffrent avec AES-256-GCM :

• Shor n'est pas applicable (pas de crypto asymétrique),
• Grover réduit la sécurité, mais on part de tailles de clés largement dimensionnées (256 bits).

Même avec un calculateur quantique :

• la recomposition de K_seg ne peut pas être attaquée via un "bruteforce réseau" (tout est local et segmenté),
• l'attaquant doit combiner une attaque contre AES-256/HKDF_SHA3_512 et contre la segmentation brevetée elle-même.

On peut donc présenter la méthode comme une architecture symétrique segmentée "quantum-informed" :

• elle ne dépend pas encore des schémas post-quantiques à clé publique (KEM/PKE),
• mais elle est conçue pour rester robuste même face à un adversaire quantique fort, grâce à :
  • l'absence de crypto asymétrique exposée,
  • le dimensionnement des primitives symétriques,
  • et la segmentation brevetée comme racine de confiance non exportable.

46. Data Protection (GDPR, LCPDP)

CryptPeer is designed to respect personal data protection principles, notably the General Data Protection Regulation (GDPR) of the European Union and the Framework Law on Personal Data Protection (LCPDP) of Andorra.

Key data minimization principles are integrated into the architecture: end-to-end encryption, absence of centralized collection of personal identifiers for communications, and user control over encryption keys.

46.1 Role of EviEngine in Data Protection

The EviEngine hardware license model directly contributes to the data minimization principle (GDPR, LCPDP) by avoiding any centralized collection of personal identifiers for license management. The license is linked to hardware characteristics of the machine, not to users' civil identity.

In practice, this means that the CryptPeer operator does not need to:

• maintain a nominal database specific to licenses;
• report license information of deployed instances to a third party;
• process "real identity ↔ license" pairs in a cloud service.

EviEngine is not intended to replace a GDPR or LCPDP impact analysis, but it reduces the surface of personal data potentially processed solely for license management, in line with a "privacy by design" approach:

• fewer technically necessary personal data;
• fewer intermediaries with access to this data;
• fewer data flows to external services.

47. NIS2 and Infrastructure Control

The NIS2 Directive (Network and Information Systems Directive) of the European Union requires operators of essential services and important entities to control their critical infrastructure and reduce dependencies on third parties.

CryptPeer meets these requirements through its self-hosting model: the operator fully controls the communication infrastructure, without dependency on external cloud services for message relay or data storage.

47.1 EviEngine and External Dependencies Management

In the NIS2 context, control of critical dependencies (providers of essential services for availability or security) is central. Using EviEngine for license management avoids creating an additional dependency on an external cloud-based license service.

Concretely, for an operator:

• CryptPeer availability does not depend on the availability of a third-party license server;
• no third party has real-time visibility into the inventory of deployed instances;
• license validation remains under the organization's control, within its network perimeter.

EviEngine thus reinforces the coherence of the "100% self-hosted" model: the CryptPeer instance operator controls both the communication infrastructure and the license mechanism, without a hidden cloud back-end. This reduction of external dependencies aligns with an NIS2 compliance approach focused on resilience, operational sovereignty, and limiting imposed trusted third parties.

48. Cryptography Export (Llei 10/2025 and EU Context)

Andorra's Llei 10/2025 and European regulations govern the export of cryptographic technologies. CryptPeer, developed in Andorra, complies with these regulatory frameworks.

The cryptographic primitives used (AES-256-GCM, SHA-256, SHA3-512, PBKDF2, HKDF) are international standards widely deployed and are not subject to specific export restrictions in the European context.

Part IX – Implementation, Hardening and Logging

Annexes

Annex A – Cryptographic Parameters

Annex B – Key Derivation Pseudo-code

B.1 Derivation of K_seg

function derive_K_seg(K_pair, policyId, context):
    // Deterministic context encoding
    contextBytes = encodeContext(context)
    
    // Derivation via HKDF_SHA3_512
    K_seg = HKDF_SHA3_512(
        salt = K_pair,
        IKM = H3_512(policyId || contextBytes),
        info = "CryptPeer/RootKey",
        L = 32  // 256 bits
    )
    
    return K_seg
end function

B.2 Derivation of K_base (1:1 conversation)

function derive_K_base(userId_A, userId_B, conversationId):
    // Lexicographic sort of IDs
    ids_sorted = sort([userId_A, userId_B])
    keyMaterial = ids_sorted[0] || ":" || ids_sorted[1] || ":" || conversationId
    
    // Deterministic salt
    salt = SHA256("CryptPeer/salt/v1" || keyMaterial)
    
    // PBKDF2
    K_base = PBKDF2_HMAC_SHA256(
        P = keyMaterial,
        salt = salt,
        iter = 100000,
        L = 32
    )
    
    return K_base
end function

B.3 Derivation of K_conv_v2

function derive_K_conv_v2(K_base, K_seg):
    K_conv_v2 = HKDF_SHA256(
        salt = K_seg,
        IKM = K_base,
        info = "CryptPeer/msg/v2",
        L = 32
    )
    
    return K_conv_v2
end function

B.4 Derivation of K_msg

function derive_K_msg(K_conv_v2_seed, epochId):
    // Epoch encoding (64 bits big-endian)
    epochBytes = encodeUint64(epochId)
    
    K_msg = HKDF_SHA256(
        salt = epochBytes,
        IKM = K_conv_v2_seed,
        info = "CryptPeer/msg/epoch",
        L = 32
    )
    
    return K_msg
end function

Annex C – Segmentation Policy Profiles

Segmentation policies define the segments required to obtain K_seg:

C.1 Standard Policy

• Required segments: minimum 2
• Types:
  • 1 hardware segment (NFC, HSM) or encrypted software segment
  • 1 cognitive segment (PIN, passphrase)
• Order: hardware/software then cognitive
• Attempt limit: 3 failures → temporary lockout

C.2 Enhanced Policy

• Required segments: minimum 3
• Types:
  • 1 hardware segment (HSM)
  • 1 encrypted software segment
  • 1 cognitive segment (strong PIN)
• Order: hardware → software → cognitive
• Attempt limit: 2 failures → lockout
• Context: instance and mode validation

C.3 Defense Policy

• Required segments: 3+ with context
• Types:
  • 1 dedicated hardware segment (Defense HSM)
  • 1 encrypted software segment
  • 1 cognitive segment
  • 1 contextual segment (network presence, device)
• Order: strict, with context validation at each step
• Attempt limit: 1 failure → immediate lockout
• Expiration: K_seg expires after limited duration

Annex D – Message and File Formats

D.1 Encrypted Message Format

EncryptedMessage = {
    version: uint8,           // Format version (1 or 2)
    conversationId: bytes,     // Conversation identifier
    epochId: uint64,          // Epoch identifier (for K_msg)
    timestamp: uint64,        // Unix timestamp
    iv: bytes[12],            // 96-bit IV for AES-GCM
    ciphertext: bytes,        // Encrypted message
    tag: bytes[16]            // 128-bit GCM authentication tag
}

D.2 Encrypted File Format

EncryptedFile = {
    version: uint8,           // Format version (1 or 2)
    userId: bytes,            // User identifier
    fileId: bytes,            // Unique file identifier
    salt: bytes[32],          // 256-bit salt for K_file_v2
    iv: bytes[12],            // 96-bit IV for AES-GCM
    metadata: bytes,          // Encrypted metadata (name, type, size)
    ciphertext: bytes,        // Encrypted file
    tag: bytes[16]            // 128-bit GCM authentication tag
}

D.3 JSON Export Format

ExportJSON = {
    formatVersion: string,    // "1.0"
    exportDate: string,       // ISO 8601
    conversationId: bytes,
    participants: [bytes],   // List of userId
    messages: [
        {
            epochId: uint64,
            timestamp: uint64,
            iv: base64,
            ciphertext: base64,
            tag: base64
        }
    ],
    files: [
        {
            fileId: bytes,
            salt: base64,
            iv: base64,
            metadata: base64,
            ciphertext: base64,
            tag: base64
        }
    ],
    cryptographicParams: {
        algorithm: "AES-256-GCM",
        kdf: "HKDF-SHA256",
        keyDerivation: "v2"
    }
}

D.4 Encoding

• Bytes: base64 encoded for JSON, binary for binary storage
• Integers: big-endian, uint8 (1 byte), uint64 (8 bytes)
• Strings: UTF-8 for text fields

Annex E – Glossary

K_pair

Segmented pairing key managed by the engine.

K_seg

Local root key derived from K_pair.

Local PFS

Perfect Forward Secrecy limited to the scope of messages and history on a given terminal.

Local-only mode

Deployment mode without Internet dependency.

Hidden mode

Default encrypted display mode.

Defense mode

RAM-only, no-logs mode for regal uses.

Annex F – Hardware License Model (EviEngine)

This annex summarizes the role of EviEngine in CryptPeer. EviEngine is used to associate a software license with a given hardware platform, without a license server and without a centralized database. This mechanism allows:

• to control CryptPeer usage to an authorized machine park;
• to respect an economic model without exposing personal identity information;
• to maintain the ability to operate on a closed network (local-only, air-gap).

EviEngine does not intervene in the generation or derivation of cryptographic keys used for encrypting messages, files, backups, or tunnels. It is therefore analytically separate from the E2E security described in this document, while contributing to the operational sovereignty of the solution.