6.2 Data Encryption Standards

The OmniPact protocol processes data in two categories: transient communication data (such as payment details in P2P chat) and persistent evidence data (such as contract files stored on IPFS). We have designed encryption standards for each of these two types of data.。

6.2.1 ECIES for P2P Data

For bank card numbers, Swift codes, or communication details in OTC transactions, the data must be end-to-end encrypted (E2EE) between the buyer and seller, and must be invisible to any third party (including OmniPact protocol nodes).

We directly utilize the existing Ethereum accountsecp256k1The key pair uses the ECIES (Elliptic Curve Integrated Encryption Scheme) standard.

• Key Derivation Workflow

Suppose Alice (the buyer) wants to send an encrypted message $M$ to Bob (the seller):

1. Temporary Key Generation: Alice generates a temporary, one-time private key and the corresponding public key 。

2. Shared Secret Computation (ECDH): Alice uses Bob's public key $K_{Bob}$ to compute the shared point $S$: S = r \times K_{Bob}

   (Note: After receiving the data, Bob can use his private key $k_{Bob}$ to calculate $S = k_{Bob} \times R$. According to the properties of elliptic curves, the $S$ calculated by both methods will be the same.)

3. Key Extension (KDF): This involves adding points Input key derivation function（如 ANSI-X9.63-KDF）,Generate a symmetric encryption key and message verification key .

4. Encryption and Encapsulation:

$$C = \text{AES-GCM-256}(M, k_{enc})Tag = \text{HMAC-SHA256}(C, k_{mac})$$

1. Send: Alice will send the data packet Sent to Bob via relay network.

6. Security advantages

• Forward Secrecy: Due to the use of a temporary key ,Even if Alice's long-term private key is leaked in the future, past session records will be difficult to decrypt in bulk (if combined with the Ratchet algorithm).

• Seamless experience: Users do not need to remember additional passwords; they can decrypt the device simply by signing it with a Web3 wallet (MetaMask).

---

6.2.2 Dual-Key Architecture for Arbitration Evidence

Evidence presents a unique challenge: it must remain confidential to the public under normal circumstances, but in the event of a dispute, it must be decryptable and readable by a randomly selected arbitrator.

To resolve the conflict between "privacy" and "judicial transparency," we designed a Dual-Key architecture.

1. The Hybrid Structure: All large files (such as PDFs and design drawings) are encrypted using the AES-256-CBC symmetric algorithm, generating ciphertext $Enc_{Data}$.

The real core issue lies in: how should the AES key $K_{sym}$ be stored?

2. State 1: Normal Trading Period (The Private State)

At the initial stage of transaction creation, the AES key $K_{sym}$ is encrypted and stored in the metadata:

• Key A (For Buyer):

• Key B (For Seller):

At this point, the file is stored on IPFS, but only the buyer and seller can decrypt it This allows the file to be read. To the outside world, it appears as a jumble of gibberish.

3. State Two: The Juror Access State

When the buyer raises a dispute, the protocol mandates that the buyer submit a new key envelope:

• Key C (For Jury):

Here It is not a single private key (otherwise there would be a single point of failure), but a set of threshold keys or temporary session public keys.

• Once an arbitrator is selected by the VRF, the arbitrator client securely obtains it from the party initiating the dispute (or the secret pool of the smart contract) via a Diffie-Hellman key exchange.

• This mechanism implements "(Access on Demand)": you only have the right to view evidence when a dispute arises and you are selected as the judge.

4. Integrity Verification

To prevent one party from tampering with evidence after a dispute arises (e.g., secretly replacing encrypted files), the OES contract records the hash fingerprint of the file during the $S_{lock}$ phase:

$$\text{OnChainHash} = \text{Keccak256}(Enc_{Data})$$

Before decrypting, the arbitrator will verify whether the hash of the IPFS file matches the on-chain record. This ensures the originality of the evidence presented in court.

---

By introducing ECIES and a dual-key architecture, OmniPact demonstrates how it builds a robust yet flexible cryptographic defense between decentralized storage (public) and trade secrets (private).