DWK-Lock: Dual Wallet Keychain Locking Protocol

DWK-Lock is a serverless, peer-to-peer cryptographic protocol responsible for secure room establishment and message encryption. Room keys are dynamically derived through a multi-source process that includes cryptographic proof of wallet ownership from both participants, an internal handshake key, and the hash of a genesis transaction used as historical context.

Room keys are ephemeral and exist only for the duration of an active session. Each message uses chained encryption, where message keys are derived from the cryptographic state of the previous message. This design prevents replay attacks, room cloning, and historical reconstruction, while ensuring that compromise of a single message or device does not expose the entire session.

Key Points

• Serverless (Peer-to-Peer Architecture) PRIV8 operates on a fully peer-to-peer architecture without reliance on centralized servers, third-party key management, or external message logging systems. All communication occurs directly between participants, eliminating centralized infrastructure that could introduce trust assumptions, surveillance vectors, or data custody risks.

• Multi-Source Key Derivation Session room keys are derived through a composite cryptographic process that incorporates wallet signatures from both participants, an internally generated handshake key, and the hash of a genesis transaction. Wallet private keys are never used directly as encryption material, ensuring that identity credentials remain isolated from payload security.

• Ephemeral and Chained Encryption Room keys are strictly ephemeral and valid only for the duration of an active session. Each message is encrypted using a uniquely derived key that is cryptographically chained to the previous message state. This design prevents message replay, session duplication, and unauthorized reconstruction of communication history.

• No Single Point of Failure The security model is intentionally distributed, such that compromising a single wallet, device, or session component is insufficient to decrypt a communication room. Multiple independent cryptographic elements must be simultaneously compromised, significantly increasing the attack complexity and resilience of the system.

• History-Bound Security Each chat room is cryptographically bound to its genesis transaction, anchoring the session to a unique historical context. This binding renders room cloning, replay attacks, or session resurrection invalid, as cryptographic states cannot be reproduced outside the original session lifecycle.