Communication Encryption Layer

The Communication Encryption Layer is not only the foundational security module of the DF Protocol but also an openly integrable, securely verifiable, and long-term evolvable communication standard sy

As the first core security foundation of the DF Protocol, it is responsible for establishing encrypted communication channels between nodes, ensuring the confidentiality, integrity, and tamper resistance of computing power reporting, identity binding, and control instructions during transmission.

This layer mainly consists of the following cryptographic technical components:

ECDH: Elliptic Curve Diffie–Hellman

The DF Protocol adopts ECDH (Elliptic Curve Diffie–Hellman) as the key agreement mechanism for communication encryption. Compared with the traditional large-number modular exponentiation Diffie–Hellman, ECDH offers higher encryption strength and smaller key sizes, making it suitable for node operating environments with limited computing power.

  • Each node generates an independent ECDH public/private key pair during initialization;

  • Before establishing a connection, both parties negotiate a shared session key (Shared Secret) by exchanging public keys;

  • This shared secret is never transmitted in plaintext either on-chain or off-chain, featuring resistance to eavesdropping and Forward Secrecy.

AES-256 Symmetric Encryption Transmission（Authenticated Symmetric Encryption）

The Advanced Encryption Standard (AES) is a widely used encryption protocol designed to protect sensitive data by converting readable information into a secure encoded format. AES is a symmetric key encryption method, meaning it uses the same key for both encryption and decryption, ensuring data remains secure during transmission or storage.

The AES encryption algorithm uses the same key for both encryption and decryption, and the algorithm methods for encryption and decryption are also identical—hence it is called a symmetric encryption algorithm. The key length of the AES algorithm can be 128 bits, 192 bits, or 256 bits, with the 256-bit key length providing the highest level of security but requiring greater computational power. Generally, 128 bits (1 byte = 8 bits) equate to 16 bytes.

Example Code (Python + cryptography library)

Below is reference code for the AES-256-GCM encryption and decryption process, simulating the message encryption logic between nodes in the DF communication layer:

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

# Generate 32-byte (256-bit) shared key (from ECDH negotiation)
shared_key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(shared_key)

# Encryption process
nonce = os.urandom(12)  # GCM recommends 96-bit IV
plaintext = b"DF Compute Payload: SHA256(computing power digest + timestamp)"
aad = b"DF-Protocol-Metadata"  # Optional additional data as authenticated data

ciphertext = aesgcm.encrypt(nonce, plaintext, aad)

# Decryption process (successful only if key and nonce match)
decrypted = aesgcm.decrypt(nonce, ciphertext, aad)
assert decrypted == plaintext

In the DF Protocol, data encrypted with AES-256 includes but is not limited to:

  • Computing power digests and timestamps reported by nodes

  • DH-ID identity binding requests

  • Node profit distribution information

  • Contract call signature digests, etc.

Each encryption round uses a unique Initialization Vector (IV), and attaches an Additional Authenticated Data (AAD) field to the encrypted data to prevent content tampering.

Session Key Rotation & Forward Secrecy

In the DF Protocol, key agreement adopts the ECDH (Elliptic Curve Diffie–Hellman) mechanism to generate communication session keys for encrypting data between nodes. To further enhance the protocol’s resistance to attacks during long-term operation, DF introduces a "session-level key update" mechanism and implements Perfect Forward Secrecy (PFS), ensuring that historical communication content remains undecryptable even if keys are compromised in the future.

Core Objectives

  • Prevent attackers from retroactively decrypting past data through a single private key leak after long-term monitoring of node communications;

  • Each session has an independent key—even if some keys become invalid, the confidentiality of other communication segments is not affected;

  • In building a long-running computing power collaboration network, provide nodes with verifiable key rotation logic to improve system resilience and resistance to audit tracing.

Mechanism Design

The communication layer of DF implements key update and forward secrecy through the following processes:

Initial Handshake Phase (Session 0)

  • Node A and Node B negotiate to generate the first shared key K₀ using their respective static ECDH public keys;

  • All Session-0 communications are encrypted with K₀.

Session Cycle Setting

  • A session key refresh is triggered every N rounds of task reporting (or M minutes);

  • This parameter can be set by smart contracts and delivered as control signals.

Dynamic Key Rotation (Session i → i+1)

  • Nodes periodically exchange "short-lifecycle ephemeral ECDH public keys";

  • Negotiate a new shared key Kᵢ₊₁ using the ephemeral key pair and the counterpart’s static/ephemeral key;

  • The old key Kᵢ is no longer used for any transmission or decryption and is immediately destroyed.

Key Forgetting Strategy (Ephemeral Key Wipe)

  • Each old key is immediately erased from memory after use, with no local copies retained;

  • Avoid batch key leakage in case of physical attacks or device control loss.

On-Chain Anchoring Authentication (Optional)

  • Nodes can submit their rotated key fingerprints on-chain (in salted hash form)for session proof and retrospective audit purposes.

Security Notes

  • Even if an attacker obtains the current node’s private key at time T, they cannot decrypt any data packets transmitted via old keys during T₀～T₋₁;

  • All session keys do not appear on-chain and are not forwarded through relay servers;

  • Keys have short usage cycles and high exchange frequencies, and combined with ECDH’s small size characteristics, do not affect communication efficiency.

Scalability & Post-Quantum Compatibility

The DF Protocol will subsequently support PQC (Post-Quantum Cryptography) key rotation mechanisms, using an ECDH + Lattice-based hybrid negotiation algorithm to achieve PFS capabilities under quantum attack models, providing lasting protection for future high-sensitivity computing scenarios.

Zero-Knowledge Preprocessing ＆ MITM-Resilience

Man-in-the-Middle (MITM) attacks are common security threats to key agreement protocols. Attackers impersonate both communicating parties, intercept or tamper with public keys during key agreement, thereby inducing both parties to generate shared key copies with them and further decrypt transmission content.

To prevent such attacks, the DF Protocol’s communication layer combines an on-chain identity declaration mechanism with ZKP Preset Proof to build a verifiable, anti-deception encrypted handshake path.

Technical Objectives

  • Ensure the authenticity of node identities and prevent forged identity keys from participating in handshakes;

  • Complete on-chain trusted anchoring before establishing off-chain communication;

  • Achieve identity verification without exposing private keys or shared keys;

  • Provide a man-in-the-middle attack detection path to reject non-compliant key connections.

Mechanism Design

  1. On-Chain DH Commitments

  • Before joining the DF network, each node must process its static ECDH public key (PubKey_DH) through a hash function (e.g., SHA-256) and submit it to the chain, binding it to its wallet address;

  • This hash value (H(PubKey_DH)) is recorded as an identity declaration in the on-chain contract, which can be verified by any participant;

  • This process is similar to "public key pre-registration," establishing a trusted anchor for subsequent connection establishment.

  1. Handshake Identity Match

  • During ECDH negotiation, Node A sends its current ECDH public key to Node B;

  • Node B hashes this public key and compares it with the pre-declared value stored on the chain;

  • If the match is successful, the other party’s identity is deemed trusted, and key negotiation continues;

  • If inconsistent, communication is immediately terminated to prevent fake public keys from entering the channel.

3）ZKP Preset Commitment

  • Nodes can choose to enable the zero-knowledge pre-verification path, i.e.: Use the Schnorr/ZK-SNARK structure to generate an unforgeable proof of the binding relationship between its public key declaration and identity, proving "I know a private key x such that x·G = PubKey and H(PubKey) = on-chain hash";

  • This proof does not require exposing the public key or private key itself and can be verified through off-chain channels;

  • Enhance the provability of the private key holder for on-chain declarations and improve security levels.

Protocol Interfaces ＆ Extensibility

As the communication security foundation module in the computing power verification protocol, the communication encryption layer of DF Protocol not only emphasizes encryption strength and attack protection capabilities but also values standardized interface design and system-level integration flexibility. This layer adopts a modular architecture, supporting developers, verification nodes, and third-party systems to integrate with the communication protocol through clear API interfaces with low coupling, ensuring adaptability in different computing power environments, node structures, and operating platforms.

Core Module Interface Design

The communication encryption layer exposes the following main interfaces to upper layers:

  1. Public Key Registration API

    • Function: Submit the node’s public key or its hash fingerprint (H(PubKey_DH)) to the on-chain registry;

    • Input: ECDH public key (or hash), node wallet address, declaration timestamp;

    • Output: On-chain confirmation event;

    • Security: The contract verifies the address signature to prevent submission by others.

  2. Encrypted Channel Establishment Protocol (ECEP)

    • Function: Standardized DH handshake protocol to generate session keys for encrypted channels;

    • Input: Counterparty’s ECDH public key, own private key, session context (Session ID);

    • Output: Derived value of the shared key (for internal encryption module use);

    • Description: Provides standard algorithms (ECDH-SHA256-AES256GCM) and custom encryption callback interfaces.

  3. Message Transport Handler

    • Function: Construct standard-format encrypted message packets for transmission of communication content such as computing power reporting and identity requests;

    • Message Structure:

  • {
  "iv": <nonce>,
  "cipher": <AES-GCM ciphertext>,
  "tag": <auth_tag>,
  "aad": <optional metadata>,
  "from": <sender DH-ID>,
  "sig": <ECDSA or BLS signature>
}

  • 特点：报文字段自带完整性校验与加密状态标识，适用于链下通道或 p2p 通信。

  1. Session Key Lifecycle Manager

    • Function: Set key refresh cycles, trigger conditions, and key erasure policies;

    • Supported Interfaces: Key renegotiation (ReKey), ephemeral key rotation (EphemeralKeyRotate), old key revocation (KeyWipe);

    • Security: Mandatory rotation policies support on-chain parameter configuration or node policy customization.

Adaptability ＆ Extensibility

  1. Replaceable Encryption Algorithm Architecture

    • Default Algorithms: ECDH (SECP256R1) + AES-256-GCM

    • Supported Extensions: BLS12-381, Curve25519, Kyber (PQC), ChaCha20-Poly1305

    • Implementation: Encryption modules call a unified interface (CryptoInterface), and algorithm switching does not affect upper-layer logic

  2. Network Protocol Independence (Off-Chain Communication Compatibility)The communication encryption layer is not bound to specific network protocols (TCP / QUIC / libp2p) and can be used for:

    • P2P data broadcasting

    • HTTP-RPC encrypted payloads

    • WebSocket long connections

    • Layer2 state synchronization

  3. Cross-Language SDK Interface Specifications (SDK Interoperability)

    • Currently available: Python / Rust / Golang SDK (for node development and integration)

    • Interface specification documents are open in OpenAPI / gRPC Schema format

    • Supports third-party applications (wallets, node consoles) to call communication encryption processes and link with computing power reporting

PreviousTechnical ArchitectureNextNode Identity Authentication Layer

Last updated