Cryptographic Specifications of CryptPeer
Public reference cryptographic specification based on a segmented key authentication system

1. About This Document

This document specifies the public cryptographic aspects of CryptPeer, a secure communication system based on a segmented key authentication system and on an end-to-end encryption architecture.

Objectives:

• to describe normatively the public cryptographic primitives used;
• to formalize the role of the segmented key engine within the application architecture;
• to describe the logical hierarchy of application keys and their usage separations;
• to provide a public reading basis for developers, security architects and auditors.

This document does not disclose the engine’s non-public internal mechanisms, sensitive implementation parameters, proprietary complementary constructions, or mechanisms not necessary to understand the public model.

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;
• audio/video recordings captured locally and then protected;
• audio/video calls and screen sharing;
• multi-media encrypted backups;
• standalone file encryption and decryption;
• protected data exports and imports;
• standard, hidden and defense modes;
• a segmented key authentication engine and its public logical API;
• an application key hierarchy based on K_seg.

2.2 Out of Scope

The following are not covered, unless explicitly stated otherwise:

• non-public internal mechanisms of the segmented key engine;
• proprietary internal formats, sensitive parameters, and detailed implementation policies;
• proprietary complementary licensing, attestation, audit, or local protection mechanisms;
• organizational procedures and physical measures;
• detailed regulatory analyses by jurisdiction.

3. Notation, Types and Conventions

3.1 Types

• A byte: value in {0,…,255}.
• Byte string: b ∈ {0,1}^*; |b| denotes the length in bytes.
• Character string: encoded in UTF-8 before any cryptographic processing.
• Unsigned integer: encoded deterministically when included in a KDF input.

3.2 Operations

• Concatenation: X || Y.
• Hash: H(x).
• PBKDF2: PBKDF2_HMAC_SHA256(P, salt, iter, L).
• HKDF: HKDF_SHA256(salt, IKM, info, L).
• Integer encoding: encodeUint64(n) when required by the context.

3.3 Key Notation

• K_pair: logical pairing or authorization key managed by the segmented engine;
• K_seg: local application root key exposed to CryptPeer by the engine;
• K_conv: conversation key;
• K_file: key associated with file, export, or backup encryption;
• K_msg: ephemeral key associated with a message, a session, or a usage window;
• K_view: key used for temporarily decrypted display.

Unless explicitly stated otherwise, symmetric keys used for application encryption are 256 bits long.

3.4 Normative Conventions

In this document:

• MUST expresses a normative requirement;
• MUST NOT expresses a normative prohibition;
• SHOULD expresses a strong recommendation;
• MAY expresses a possibility or implementation option.

4. References and Design Principles

CryptPeer publicly relies on:

• AES-256-GCM for authenticated encryption of application contents;
• SHA-256 and, depending on the documented public usage, SHA3-256;
• PBKDF2-HMAC-SHA-256 and HKDF-SHA-256 for the public derivations described;
• the patented segmented key authentication system (WO2018154258A1), modeled as a component providing:
  • a restricted API;
  • direct non-export guarantees;
  • ephemeral exposure of useful application secrets.

The design follows these principles:

• 256-bit symmetric robustness;
• clear separation of roles:
  • segmented engine,
  • client,
  • relay server;
• cryptographic separation of usages through labels and contexts;
• on-demand local derivation;
• maximum volatility of application secrets;
• minimization of metadata and traces;
• no public disclosure of internal mechanisms not necessary to understand the model.

5. Overall Architecture of CryptPeer

5.1 Components

A CryptPeer instance comprises:

• a relay server S:
  • self-hosted or operated under control;
  • storing only already protected contents and metadata;
• a web client bundle:
  • JS/TS/WASM code served by S;
  • executed in the terminal browser;
• a local segmented key engine:
  • software and/or hardware;
  • exposing K_seg to the client through a restricted local interface;
• a local directory structuring users into categories.

A CryptPeer instance does not rely on a mandatory global federation.

5.2 Roles

• Client:
  • derives all application keys from K_seg and public data;
  • performs all encryption and decryption;
  • manages display and associated local protections.
• Segmented Key Engine:
  • manages K_pair and its segments;
  • ephemerally restores K_seg according to a local policy.
• Relay Server S:
  • serves the web client;
  • authenticates and relays connections;
  • stores and relays encrypted blocks.
• Backup Media:
  • receive already encrypted backups.

5.3 Hardware License Management (EviEngine)

CryptPeer may integrate EviEngine technology from Freemindtronic for license management without an external server or centralized database. This component is not part of the encryption path of application contents, but contributes to the model of sovereignty, operational autonomy, and offline operation.

Main properties of the license model:

• Hardware-bound license:
  • the license MAY be associated with hardware characteristics of the machine;
  • it is not designed as a centralized nominal identity.
• No license server or database:
  • no external license server is required to validate local usage;
  • no centralized database is required;
  • license verification is performed locally.
• Offline operation:
  • license validation MAY work without Internet connectivity;
  • service continuity does not depend on a remote third party.
• Data minimization:
  • no centralized user account is structurally required for licensing;
  • no license telemetry to a third-party cloud is necessary in the sovereign model.

From a cryptographic standpoint, license management through EviEngine is orthogonal to content security. The primitives, key hierarchy, and protocols described in the following parts remain analytically separate from this function.

Internal cryptographic details of EviEngine are outside the scope of this public document.

6. Deployment Modes

6.1 Local-only Mode

In local-only mode:

• S is accessible only on a local or closed network;
• no direct Internet visibility is required;
• all communications remain inside the local network perimeter.

6.2 Mode with Remote Access

In remote mode:

• S is behind a router, firewall, or reverse proxy;
• a domain or subdomain MAY be exposed;
• TLS MUST be used to secure HTTP(S) transport.

Application content is protected client-side before transport and storage.

6.3 Self-portability

The S instance MAY be deployed on:

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

Server code and protected data MAY be moved provided administrative secrets are protected and the required hardening level is maintained.

7. Universal Web Client

7.1 Principle

CryptPeer provides a single client:

• implemented in JS/TS/WASM;
• executed in a modern browser;
• deployed uniformly across compatible terminals.

7.2 Consequences

• a single client codebase to audit and harden;
• centralized updates through S;
• consistent behavior across compatible terminals.

browser-specific risks remain covered by the threat model.

8. Operating Modes

8.1 CryptPeer Mode (standard)

Features:

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

Cryptographic properties:

• end-to-end encryption based on K_seg;
• local derivations separated by usage;
• no content keys on the server.

8.2 CryptPeer Hidden Mode

Objective: reduce visual exposure.

• protected display by default depending on configuration;
• explicit decryption of a conversation;
• automatic re-protection of the view:
  • after a delay;
  • or on event (tab change, focus loss, etc.);
• erasure of plaintext buffers after use when possible.

This mode MAY use a K_view view key derived from K_seg.

8.3 CryptPeer Defense Mode

Objective: sovereign or highly sensitive usages. Learn more →

• dedicated instance and parameters;
• maximum reduction of persistence;
• RAM-only or no-logs policy depending on configuration;
• reduced or absent history depending on requirements.

9. Favorite Multi-Servers and Absence of Federation

9.1 Favorites List

The client maintains locally:

Favorites = { (label_i, url_i) }_i

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

9.2 No mandatory mesh

In the reference architecture, there is no:

• mandatory global federation;
• mandatory universal directory;
• systemic dependency on inter-instance routing.

Consequences:

• each S instance MAY remain an independent bubble;
• global communication mapping is reduced.

10. Directory, Categories and Logical Partitioning

10.1 Local Directory

Each S instance MAY maintain a directory:

• a set of users;
• identifiers and information required for authentication;
• data protected according to its sensitivity.

10.2 Contact Categories

The administrator MAY associate each user with one or more categories:

C = { C_1, C_2, … }

These categories are used to structure authorizations and logical partitioning.

10.3 Groups and Partitioning

This partitioning limits lateral propagation of account compromise and exposure risks across security perimeters within the same instance.

11. “Zero Trust. Zero Cloud. Zero Trace.” Doctrine

11.1 Zero Trust

• the server S is non-holder of content secrets;
• S holds no application decryption key;
• critical application derivations MUST be performed client-side with K_seg.

11.2 Zero Cloud

• no structuring secret (K_pair, segments, K_seg, content keys) is entrusted to a third-party cloud service;
• remote media receive only previously encrypted data.

11.3 Zero Trace

• on-demand derivation and rapid key erasure;
• no persistent plaintext client-side beyond what is strictly required for operation;
• minimal server-side logging;
• maximum reduction of persistent traces according to the selected mode.

12. Threat Model and Assumptions

12.1 Considered Adversaries

• Server adversary:
  • control of S (root, database, served code);
• Network adversary:
  • interception, MITM, observation;
• Local adversary:
  • malware, terminal theft, post-mortem analysis;
• Visual adversary:
  • screen capture, direct observation, cameras;

12.2 Trust Assumptions

• segmented engine compliant with the public model of the reference patent;
• browsers and operating systems reasonably up to date;
• the adversary does not simultaneously and durably possess all required segments.

12.3 Out of Scope

• sophisticated laboratory-grade hardware attacks;
• simultaneous and durable compromise of all segments across all supports;
• critical 0-days allowing immediate 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 source of comparable robustness.

The server, when generating random values that are not critical for application secrets, MUST use an appropriate CSPRNG source.

13.2 Usage

The RNG is used for:

• AES-GCM IVs/nonces;
• random salts;
• random technical identifiers when they are not derived.

14. Hash Functions

CryptPeer publicly uses:

• SHA-256 for:
  • hashing technical identifiers;
  • building certain public deterministic salts;
• SHA3-256 as a public hardening option for certain documented usages.

Notation:

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

15. Key Derivation Functions (KDF)

15.1 General Principles

• every derivation MUST be deterministic for the same set of inputs;
• distinct usages MUST be separated by the info field or an equivalent label;
• the same key MUST NOT be directly reused for multiple different application purposes;
• the documented public derivations do not disclose the internal segmented KDF of the engine.

15.2 PBKDF2-HMAC-SHA-256

Public default parameters:

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

Usage:

• public deterministic base derivations from identifiers or non-secret contexts;
• construction of base keys later used as input to derivations anchored on K_seg.

15.3 HKDF-SHA-256

Call:

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

Usage:

• derivation of K_conv, K_file, K_msg, and K_view from K_seg and application contexts;
• cryptographic separation of usages through the info field.

16. Authenticated Encryption

16.1 AES-256-GCM

Public parameters:

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

The IV MUST be:

• either randomly generated for each encryption;
• or derived so as to guarantee uniqueness per key.

In CryptPeer:

• messages use a unique IV per encryption;
• files use a unique IV per encryption;
• public logical formats are described in Annex D.

16.2 Associated Authenticated Data

When AAD is used, it SHOULD include non-secret context elements, for example:

• format version;
• logical conversation or file identifier;
• message or block type;
• applicable operating mode.

16.3 Decryption Failure

In case of a GCM authentication failure:

• the content MUST be rejected;
• no partial plaintext MUST be exposed;
• the attempt MUST be treated as an integrity or context error.

17. Role and Positioning of the Segmented Engine

The segmented key engine:

• manages K_pair, a segmented logical pairing or authorization key;
• does not directly expose K_pair in plaintext to the client;
• restores a local root key K_seg to CryptPeer via a restricted local API;
• applies segmentation policies (order, factors, attempt limits, context).

CryptPeer treats it as a black box providing the properties described in section 20. Internal implementation details fall under the international patent WO2018154258A1 of Freemindtronic and non-public internal technical documents.

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

18. Public Functional Model

18.1 Entities

• K_pair: logical pairing or authorization key;
• Segment: a unit stored on a support, a factor, or a context;
• Policy: a local policy defining the conditions under which K_seg may be obtained;
• K_seg: the local application root key provided to the client.

18.2 Public Properties

The engine publicly presents the following properties:

• the original logical key is split into several segments;
• segments MAY be carried by multiple supports or factors;
• useful recomposition is only temporary and performed in volatile memory;
• the application does not directly handle the full original secret;
• a local application root key may be provided to an authorized component.

19. Public 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 be applied;
  • context: logical context (instance, mode, device).
• output:
  • K_seg: a byte string of at least 32 bytes.

Conditions:

• recomposition of K_pair, when necessary, is performed in volatile memory;
• K_seg is held in memory only for a minimal duration.

19.2 clear

Erases:

• any temporary copy of K_seg;
• any temporary sensitive material related to use of the engine.

20. Required Security Properties

At minimum, the engine MUST guarantee:

1. Non-export of K_pair and segments
   • no API call allows retrieval of K_pair or a raw usable segment.
2. Ephemeral recomposition
   • K_pair, if recomposed, and K_seg reside only in volatile memory;
   • active erasure after use.
3. Segmentation policy
   • compliance with policyId:
     • number and type of required segments;
     • order;
     • attempt limits;
     • authorized contexts.
4. Binding to usage context
   • K_seg MUST depend on:
     • K_pair;
     • policyId;
     • context;
     • an application usage label.
5. Resistance to reasonable local attacks
   • direct extraction of segments or K_pair is made difficult;
   • the engine is protected against simple inspection of software storage.
6. Logical fail-closed behavior
   • if the policy is not satisfied, K_seg MUST NOT be returned;
   • no partially usable secret MUST be exposed to the application.

21. Integration with Hardware Supports

The engine MAY integrate:

• NFC HSMs;
• PGP HSMs (PC);
• other sovereign supports.

CryptPeer does not impose a particular type of support, but requires that:

• segments stored on such supports be non-exportable in plaintext;
• support usage be integrated into the segmentation policy.

22. Overview

K_pair (segmented, engine)
   ↓  KDF_segmented(policyId, context, "CryptPeer-root")
K_seg
   ↓ PBKDF2/HKDF + public contexts
K_conv, K_file, K_view
   ↓ HKDF + index/epoch/session
K_msg

Principles:

• cryptographic separation of usages;
• local client-side derivation;
• no server exposure of structuring secrets;
• isolation of conversation, file, display, and session contexts.

23. Local Application Root Key K_seg

Formally:

K_seg = KDF_segmented(
  K_pair,
  label   = "CryptPeer-root",
  policyId,
  context // deterministically encoded
)

Minimum size: 256 bits.

K_seg is neither held by the relay server nor exposed in network protocols.

24. Conversation Keys

Conversations use keys derived locally from K_seg and deterministic application contexts specific to each exchange.

Logical example:

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

This separation ensures that one conversation context does not directly use the same working key as another context.

25. File and Export Keys

Files, attachments, exports, and backups use distinct derivations, logically separated from conversation keys.

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

26. Ephemeral Message or Session Keys

Ephemeral keys may be derived locally in order to reduce the exposure scope of a message, a session, or a temporarily decrypted display.

K_msg = HKDF_SHA256(
  salt = epochOrSessionContext,
  IKM  = K_conv_seed,
  info = "CryptPeer/msg/epoch",
  L    = 32
)

This approach helps reduce the useful compromise window in case of transient local access.

27. Message Encryption

Messages MUST be encrypted client-side before transmission:

1. local derivation of the conversation key;
2. optional derivation of an ephemeral key K_msg;
3. generation of a unique IV;
4. AES-256-GCM encryption of the content;
5. transmission of the protected message to the relay server.

The server S stores only the encrypted blob, without any decryption capability.

28. Group Conversations

For a group:

1. a group conversation key is derived locally;
2. participant management remains driven by application authorizations;
3. content encryption follows the same principles as 1:1 messaging;
4. the server relays the encrypted message to all authorized members.

Group keys are never shared in plaintext: each participant derives the working key locally.

29. File Transfers and Attachments

For a file:

1. local derivation of a K_file key;
2. generation of a suitable salt and IV;
3. AES-256-GCM encryption of the file and, depending on the configuration, its associated metadata;
4. storage of the protected blob on S or on a backup support.

Attachments follow the same principle of derivation-context separation.

30. Encrypted Backups

The encrypted backup strategy consists in:

• multiplying copies;
• diversifying supports;
• preserving an off-site copy when needed.

CryptPeer implementation:

1. backups use a locally derived key anchored on K_seg;
2. supports receive only archives that are already encrypted;
3. restoration requires legitimate access to K_seg through the segmented engine.

No plaintext secret is stored inside backups.

31. Audio/Video Calls and Screen Sharing

For real-time communications:

1. session establishment relies on protected application exchanges;
2. session keys are derived client-side;
3. media streams are encrypted before transport;
4. the server acts as a relay or coordination point without access to content secrets.

32. Security Objectives

CryptPeer aims to guarantee:

1. End-to-end confidentiality:
   • messages and files are never present in plaintext on the server;
   • only legitimate participants may decrypt the content.
2. Integrity:
   • detection of any modification of messages or files;
   • cryptographic authentication built into the schemes used.
3. Strong local authentication:
   • use of a local root derived from a segmented key system;
   • reduction of direct exposure of structuring secrets.
4. Sovereign availability:
   • operation possible in local-only mode;
   • local control of infrastructure and backups.

33. Confidentiality and Integrity

33.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, which is not accessible to the server.
• Usage separation: conversation, file, display, and session use distinct derivation contexts.
• Reduction of exploitable metadata depending on the chosen configuration.

33.2 Integrity

Integrity is guaranteed by:

• GCM authentication tag: each message or file includes a tag verifying integrity and authenticity of the ciphertext.
• Modification detection: any alteration of the ciphertext or tag is detected during decryption.
• Uniqueness of encryption contexts: uniqueness of IVs/nonces and separation of derivations prevent trivial reuse of cryptographic contexts.

34. Resilience to Server Compromise

In the event of total compromise of server S:

1. the server only holds encrypted blobs, not decryptable without K_seg;
2. it does not hold the local application root;
3. technical metadata may be exposed, but content secrets are not;
4. restoration on a new infrastructure remains possible from protected backups.

Compromise of S may nevertheless allow:

• traffic analysis;
• interception of new protected messages;
• availability attacks.

35. Resilience to Local Compromise

In case of compromise of the client terminal:

1. Protection through segmentation:
   • K_pair remains segmented and is not directly exposed;
   • access to K_seg requires satisfaction of the applicable policy;
   • hardware segments are not equivalent to a single plaintext software secret.
2. Memory erasure:
   • K_seg is held in memory only temporarily;
   • active erasure occurs after use or inactivity.
3. Ephemeral keys:
   • message or session keys MAY be renewed;
   • the temporal exposure scope is therefore reduced.
4. Hidden mode:
   • reduces local visual exposure;
   • rapidly re-protects displayed contents.

36. Symmetric Quantum-Resilience Considerations

The public CryptPeer architecture primarily relies on 256-bit symmetric building blocks and on a local root that is not exposed on the network.

In this perspective:

• the absence of remote exposure of structuring secrets reduces the value of network-only archival;
• the selected symmetric primitives provide a high security margin over the long term;
• the separation between the server and K_seg remains a central element of the model.

This section does not claim complete post-quantum security; it only describes the expected robustness of the public symmetric building blocks used in this model.

37. Data Protection

CryptPeer is designed according to a data minimization logic: end-to-end encryption, local control of secrets, and reduced dependence on third-party services.

This approach supports personal data protection principles in applicable jurisdictions, subject to the chosen operational policies and deployment context.

38. NIS2 and Infrastructure Control

Self-hosting, local control of secrets, and reduced external dependencies reinforce operational sovereignty and infrastructure resilience.

39. Cryptography Export

The primitives referenced in this public version are widely known international standards. Any detailed regulatory analysis depends on the exact distribution scope and the jurisdictions involved.

40. Web Client Implementation

The web client is implemented in JavaScript/TypeScript with WebAssembly for critical cryptographic operations:

1. Architecture:
   • JS/TS code served by server S;
   • execution in the browser;
   • WASM for AES-256-GCM, HKDF, and PBKDF2 when relevant.
2. Key Management:
   • interface with the segmented engine through a local API;
   • derivation of all application keys from K_seg;
   • volatile memory storage only, with active erasure.
3. Browser Security:
   • strict Content Security Policy;
   • reduction of script-related attack surface;
   • control of served resources.
4. Updates:
   • centralized deployment through S;
   • version uniformity across clients at each load.

41. Relay Server Implementation

The server S acts as a blind relay:

1. Functions:
   • serve the web client bundle;
   • authenticate connections;
   • store and relay encrypted blobs;
   • manage the directory and categories according to configuration.
2. Storage:
   • database for protected messages, files, and metadata;
   • regular backups of the protected database.
3. Security:
   • OS hardening;
   • TLS for HTTP(S) transport;
   • client connection authentication.

The server must never hold an application decryption key.

42. Software and Hardware Hardening

42.1 Software Hardening

• OS:
  • disk encryption when relevant;
  • regular security updates;
  • minimal configuration.
• Browser:
  • recent and up-to-date version;
  • limited extensions;
  • process isolation when available.
• Network:
  • properly configured firewall;
  • restricted access;
  • VPN or network segmentation depending on the context.

42.2 Hardware Hardening

• Hardware Segments:
  • NFC HSMs, PGP HSMs, or equivalents;
  • physical protection against extraction.
• Terminal:
  • physical access control;
  • endpoint hardening;
  • anti-tampering measures according to sensitivity level.

43. Minimal Logging

Principle: minimize exploitable traces while retaining the logs required for operation:

1. Server Logs:
   • technical logs without decrypted data or secrets;
   • minimal metadata;
   • no plaintext content logs.
2. Client Logs:
   • no logs of keys or decrypted content;
   • technical error logs only;
   • rotation or rapid erasure depending on configuration.
3. Retention:
   • limited retention duration;
   • automatic erasure after expiry where applicable.