Kibu White Paper: Ensuring Genuine Human-to-Human Communication in the Digital Age

Updated May 2025

Overview

Kibu is at the forefront of addressing the fundamental challenges posed by the convergence of artificial intelligence and human interaction within digital spaces. Recognizing the necessity for verified personal identity and trust online, Kibu introduces a robust protocol underpinned by advanced cryptography. This protocol is designed to assure users of the integrity of their data and to certify the authenticity of their human interactions.

The digital age necessitates a re-evaluation of trust - traditionally established through in-person interactions - in the context of online engagements. Kibu acts as a critical intermediary, translating this traditional trust to the digital sphere. It facilitates the transition of established offline relationships to online environments, thereby creating secure and trusted networks. Kibu addresses the inefficiency of relying on physical verification for trust in the digital domain by offering a suite of human validation, verification, and authorization tools and processes.

The protocol is designed to deliver key functionalities, tailored to enhance trust and secure interaction:

• Proof of Humanity: A combination of biometric validation and additional offline checks ensures users are verifiably human, and eliminates weak credentials such as email addresses and phone numbers as attack vectors.

• Secure Messaging: End-to-end encrypted channels for private and group messaging protect the confidentiality of communication.

• Private Media Sharing: A secure framework for sharing sensitive media in selected groups.

• Consensus-based Authorization: Mechanisms for permitting actions based on a quorum vote, e.g. sharing content outside of an organization, pushing code into production, changing access permissions for an internal resource or system, etc.

• Public Broadcasting: Features for users to share content broadly, with customizable privacy settings and categorization.

• Provenance Auditability: Verifiable tracing of the user that introduced a piece of content into the Kibu ecosystem and any subsequent alterations or modifications to that content.

Central to the platform's innovation is the concept of 'Pods'—digitally encapsulated networks of a priori trusted contacts that emulate the collaborative and democratic ethos of real-world social structures. Within Kibu Pods, members collectively govern; entry, information dissemination, and transactional activities, ensuring that the platform's digital interactions inherit the trust and integrity of offline engagements. Through this, Kibu establishes a digital ecosystem where trust is not just an attribute but the foundational characteristic, mirroring the innate confidence of trusted personal and organizational networks.

Introduction

The foundation of our societies is trust; it underpins every interaction we undertake. In the fabric of human society, credibility is established through the steadfast fulfillment of promises, the exhibition of empathy and transparency, and the fostering of rapport among individuals. In modernity, a significant shift has occurred: societal exchanges increasingly unfold within the digital sphere. Conversations that once took place over coffee are now exchanged via texts; photographs that were physically shared among friends are now disseminated through digital galleries; monetary transactions no longer rely on tangible currency. Even assets have transitioned from the material to the digital, as evidenced by the proliferation of cryptocurrencies and comparable digital properties.

The evolution towards digital interaction is not novel, and a myriad of digital spaces have surfaced to support this new paradigm. Encrypted messaging applications like WhatsApp, Telegram, and Signal have made secure communication commonplace, while social media platforms such as Facebook and TikTok have expanded the landscape for direct messaging, content sharing, and global broadcasting. Platforms like DropBox and Google Drive facilitate not only storage but collaborative engagements. Financial exchanges have also been revolutionized by online services like Stripe and PayPal, alongside mobile applications such as Venmo and CashApp that simplify digital monetary transfers. Cryptocurrencies and blockchain technology have introduced a new era of digital assets, managed and transacted through platforms like Coinbase and Circle, expanding the financial ecosystem beyond traditional fiat currencies.

As we gravitate towards a digital-centric existence, with diverse platforms enabling communication, transactions, and collaboration, the question of trust within these digital spaces becomes paramount. Social media is beleaguered by bots and content of dubious origin. Cloud storage and collaboration tools often overlook the critical aspect of content provenance. Financial applications, though reliable in transferring funds, are fraught with vulnerabilities to fraud. Moreover, crypto platforms tend to favor anonymity over transparent, trust-based transactions, and are susceptible to theft or the loss of digital assets due to insecure storage or the misplacement of keys.

The intensification of online deception amplifies these issues. Misrepresented identities, AI-generated content, and the advent of deepfakes have engendered a crisis of trust in the digital domain. These dynamics pose significant threats to the authenticity and reliability of online content and interactions. Kibu is poised to confront these complexities, with a resolute commitment to reinstating trust and human-centricity in every virtual interaction.

Kibu Identity

In Kibu, the user verification protocol is grounded in establishing both the authenticity of an individual's identity and confirming their humanity. In the digital era, where the nuances of trust are ever-evolving and fragile, this dual-focused verification method is essential to the platform's integrity.

User Onboarding and Authentication

User onboarding and authentication in Kibu integrates identity verification with device authentication.

1. Account Creation and Verification: When Alice joins Kibu, she begins by creating an account and registering with a Kibu Server. During account creation, the Kibu client generates two unique cryptographic key pairs, representing Alice’s User account and her specific endpoint Device.

2. Secure Key Storage: Alice stores the private keys for her User and Device credentials securely on her own Device. These private keys are secured using biometrics (e.g., Apple FaceID) so that future access will be granted to Alice only when she is physically present.

3. Account and Device Registration: To register herself as a new User and her Device, Alice completes a WebAuthn authentication flow with a Kibu server. She provides a chain of signatures to prove ownership of both the User and Device private keys. Once proven, the server registers the corresponding public keys as a newly-verified User and Device.

4. Device Integration and Authentication:

• Alice can connect multiple devices to her Kibu account. Each device she connects has a distinct Device key that is permanently tied to that Device.

• Each new Device key requires a signature from Alice's User private key.

• Suppose Alice wishes to introduce a new Device. In that case, she will engage in a local data exchange between one of her already-registered Devices and her new Device. Her existing Device may securely transfer her User private key onto her new device, where it can be used to cryptographically sign a newly-generated Device key pair. This new Device key pair may then be registered with the server, as described in Step 3.

5. Establishing a Secure Connection: Before interacting with the Kibu server, Alice's client establishes a secure connection. This connection is encrypted using standard TLS, bolstered by a recognized certificate. For authenticating Alice's identity, Kibu employs Web Authentication (WebAuthn), a web standard published by the World Wide Web Consortium [1]. With this mechanism, the server may verify Alice’s identity using her public keys while she retains full personal ownership of her own private keys and their storage.

Adding New Pod Members

1. Alice must be invited by an existing Kibu member, say Bob, to join a Pod. This invitation may be shared in person using a QR code or it may be shared via link using a communication channel such as text message or e-mail. 

2. When Alice receives a Pod invite from Bob, she is required to undergo human verification. This process necessitates that Alice submits attestations of her identity to Bob that he will share with any other Pod members. Examples of these attestations include a facial photograph or video, an answer to a challenge question such as “What was the venue of our last lunch?”, a digital representation of an external identity, such as a connected SSO identity or MDM device certificate, or a hardware security key. Each of Alice’s attestations will include digital signatures which will be used to verify the provenance of the information.

3. Once Alice has submitted her attestations to Bob, Bob is tasked with authenticating Alice's identity using various methods that bridge digital and offline activities. He may perform a visual review of her attached “selfie” photo or utilize identity servers to validate her provided digital credentials. 

4. If Bob is unsatisfied with Alice’s proof of identity, he may reject her response and she will not be granted access to the Pod. If he is satisfied, he will forward Alice’s attestations to the other Pod members. He will include Alice’s digital signatures to prove that he did not tamper with the information. All Pod members will see the information exactly as Alice presented it to Bob. 

5. All Pod members, including Bob, are responsible for verifying the authenticity of Alice’s photograph, checking its congruence with her real-world appearance, and confirming her engagement with other biometric verifications like Face ID through her signatures.

6. Each user records their approval or disapproval of Alice’s proposed membership in the form of a vote. If all users approve, Alice will be invited to join the Pod. If any member disapproves, Alice will not be invited to join.

7. The rules that define “consensus” are intended to be configurable per-Pod. For example, a Pod’s members can amend the above voting mechanism for a Pod to require a simple majority, rather than 100% consensus between Pod members. Amendments to such rules themselves require a vote. 

8. Once Alice has been approved by the members of a Pod, she will be given access to the Pod’s contents on her Device. It is important to note that Pod membership is per-Device. If Alice would like to access a Pod on more than one Device, each individual device must be approved by the Pod members using the above voting mechanism. 

Removing Pod Members

1. If a Pod has only one member, that member may leave the Pod at any time. 

2. If a Pod has two members, they may not remove the other Pod member. Each of the two Pod members may leave the Pod at any time. 

3. Once a Pod has three or more members, they may vote to remove a Pod member at any time. A Pod member cannot vote on their own removal. Only one Pod member may be removed in a single vote.

Leaving a Pod

1. Any Pod member may leave the Pod at any time. 

Lost Device

1. Should a user lose access to their device, their Device private key will be unrecoverable.

2. User private keys may be recoverable for Kibu clients that support User key backup mechanisms. 

• In the case that a User key backup is available, the user may recover their User key onto a new Device. 

• This new Device will generate a new, unique Device key and the User may register the new Device on a Kibu server. 

• The User may use their User key to remotely de-register any previous Device keys from their account. In the case of a lost device, this allows a user to remove the unusable device from any Pods.

• The new Device may be added to any Pods where the User’s previous Device was a member via a vote of the Pod members. The User will appear to the Pod as the same User with a new Device.

3. If no User key backup mechanism is available, the User’s previous Devices may be removed from their Pods by a vote of the Pod members. The User may create a new User and Device, which may be added back into each Pod via a vote. 

4. All Pod members have access to the full Pod history. A re-admitted Pod member will not lose any information when leaving and re-joining a Pod for any reason. 

Adding a New Device for a User

1. A Kibu client may support the ability for a User to have multiple Devices.

2. Each Device that is registered for the User account should be admitted separately into each Pod. 

3. In the case that a User has multiple Devices in the same Pod, they will appear as a single User to the other Pod members.

Kibu’s Pods, Quorum, and Consensus-based Authorization

Kibu Pods provide an advanced system that governs interactions ranging from simple messaging to complex, quorum-based decision-making processes relevant for both individual and corporate entities. This architecture is not limited to group messaging but is instrumental in managing a spectrum of activities including content distribution, executive decision-making, data access permissions, and the execution of financial transactions.

Consensus-based Authorization

The Pod structure is engineered to enhance privacy, establish trust, and validate authenticity through collective agreement—thereby mitigating the risks inherent in unilateral decision-making. Closing this vulnerability is exemplified where traditional role-based access controls are used; instead of a single administrator holding or granting permissions, Kibu supports a consensus-driven, group decision among the Pod members. For instance, if Alice needs access to a shared resource, Kibu can be configured such that a quorum consisting of the Pod members would be required to approve this access, effectively sharing trust and authority.

Where privileges can be altered or spoofed on a single thread of accountability, credential theft, deepfakes, and phishing can replace a single authentic access privilege with an adversarial one. However, such a threat is much more difficult to accomplish if a group of authorized approvers reviews the transaction, and requires consensus before an action is taken.

The Kibu consensus-based authorization framework is designed to harden existing authorization technologies, while remaining compatible with standards such as OAuth and OIDC. Utilizing JSON Web Tokens (JWTs)—a widely accepted method for generating data payloads that can be signed and, optionally, encrypted to assert specific claims—this framework introduces a sophisticated layer of security and verification. In practice, Kibu enriches the JWTs issued by organizations, enterprises, or third-party applications, encapsulating the original claims and re-signing them with its own secure keys. This procedure ensures not only enhanced security but also embeds additional contextual information, such as the consent of Pod members to the actions proposed within the claims.

Kibu Pods: The Foundation of the Kibu Protocol

Pod Definitions and Characteristics

• A 'Pod' is a unique group entity in the Kibu system.

• The uniqueness of each Pod is established through a Pod ID, a 256-bit random value assigned by the Kibu Server.

• Encryption of Pod messages is facilitated via a rotatable, shared symmetric key, the Group Key. Unlike architectures such as Messaging Layer Security (MLS) and Signal, this method provides ease of access to historical messages for new or recovering users via the Group Key. [2]

Key Components of a Pod

• Pod ID: A unique identifier.

• Membership Lists: This encompasses the current list of Pod members and a sequential history of previous lists. Each list modification is supported by a vote of the Pod members, represented by a series of digital signatures using each user’s Device Key Pair.

• Pod Invitations: A mechanism to streamline member addition, consisting of details like Invitation ID, User IDs, and an encrypted response.

• Invitation Response Public Key Ring: This cryptographic tool ensures only Pod members can view the responses from invitees.

• Associated Messages: Every piece of communication within the Pod, each encrypted using the Group Key.

Pod Invitations

• Any member of a Pod can extend an invitation to an account holder. This is facilitated through a link containing a unique Invitation ID or verification session in the form of a QR Code.

• The process respects user autonomy: upon receiving an invitation, the invitee can choose to either join the Pod or decline the invitation. If the user accepts the invitation, the user will be prompted to respond with attestations of their identity, and will then be the subject of an admission vote within the Pod. Once the invitee has been accepted, the vote result is verified by the Kibu server, after which the user is added to the Pod.

Pod Member Identity Re-Verification and Deepfake Protection

• Pod membership may be used to re-verify the identity of other Pod members either in-person or via video call using any video platform. This tool allows the tokenized human-to-human relationship represented by shared Pod membership to be utilized for identity verification outside of Kibu. 

• Any Pod member may initiate an “Identity Scan” session from within the Pod. The initiator of the Identity Scan (the Verifier) will generate a unique key pair on their device. For the duration of the Identity Scan session, the private key will be known only to the Verifier. The Verifier will be prompted to present a QR code to other participating Pod Members that contains the public key for the Identity Scan . 

• Each Pod Member will receive a prompt within the Pod to scan the Verifier’s QR code and receive a unique public key for the session. Each Pod Member will then send attestations of their identity, signed with their identity keys as well as the unique Identity Scan key for that session. Each response must be submitted before the time elapses. 

• The Verifier will receive each response as it is submitted from the other Pod Members. The Verifier device will validate each response using the private key for the Identity Scan session and will review all contained information. A valid response from a participating Pod Member proves that they possessed biometrically-verified access to the Pod within the short time-frame of the Identity Scan session. 

• The Verifier may close the session at any time before it expires. Once the session has ended, the Verifier will share the results, including the private key for the session, with the rest of the Pod. This allows all other Pod Members to validate that the Verifier did not tamper with any Identity Scan results and that all provided signatures are valid. 

• On a video call or in-person meeting, Identity Scan may be used to verify the identity of the meeting participants. Such verification can be used to detect possible impersonation attacks, including those using deepfakes.

Member Removal and Pod Key Rotation

• Any member can propose the removal of another, but this action necessitates cryptographic updates: rekeying of the Group Key and the Invite Response key pair. In the event of a user removal, these keys will be rotated and new keys will be shared with the remaining Pod members.

• Similar to Pod invitations, all member removal proposals are subject to a quorum.

• Users also have the capacity to remove themselves from a Pod, through a direct self removal process.

Pod Consensus Mechanisms

• Central to the Kibu system is the idea of collective decision-making, achieved through quorum. The exact number of members required to reach quorum is set by Pod members at the Pod level. The initial quorum requirement is one, representing the Pod creator. As additional Pod members join, the quorum defaults to full-consensus (100% “yes” votes).

• Members use the Vote message stream to initiate Proposals. Proposals can be initiated for many purposes, such as membership changes, rule changes (e.g. whether or not to allow screenshots within a Pod), or content broadcasts from the Pod’s file vault.

• Each proposal encompasses details like the type of vote, the required quorum, the proposal's unique ID, and the data under consideration.

Message Encryption and Cryptography

Secure in-band message transmission is a cornerstone of how we provide digital security and trust in the context of high-stakes decision making. Kibu's cryptographic model employs a Pod Group Key to encrypt all communication within a Pod, encompassing chat, file sharing, and vote signaling. While the end-to-end encryption approach mirrors that of WhatsApp and Signal, Kibu uniquely utilizes the NaCl Secret Box cryptographic library. This library offers a contrast to the Signal Protocol, deployed in applications like Signal or WhatsApp. It instead draws inspiration from the Web of Trust concept incorporated in the traditional PGP system. [3]

In Kibu, Stream IDs serve to categorize and manage messages, marking a distinct approach compared to the unified message databases seen in other platforms while streamlining the key management process. Unlike the double ratchet mechanism used in Signal, which generates a unique key for every message, Kibu utilizes a shared symmetric key ring. This key remains in use as long as the Pod members with access are considered trustworthy, thus differing from Signal's approach where each message has a unique key, preventing historical recoverability. The end-to-end encryption (E2EE) in Kibu is anchored on two primary elements: 1) The employment of a shared symmetric key ring to encrypt messages within a Pod, and 2) The capability for clients to authenticate the comprehensive chain of signatures that constitute the current and historical membership lists, tracing back to the inception of the Pod.

Kibu employs the ChaCha20-Poly1305 cipher suite for encryption, maintaining confidentiality and integrity while keeping PayloadMetadata visible for authorization purposes. For larger attachments, a shared symmetric key and separate encrypted blob storage is used, diverging from PGP's single encrypted format and aligning more closely with WhatsApp and Signal's media handling, yet with enhanced key-data segregation.

Kibu's Pod Group Key rotation adds a layer of security, differing from the static key approach of PGP and introducing a security measure often absent in mainstream messaging apps. This is a proactive step in maintaining security against prolonged cryptographic attacks.

The ChaCha20-Poly1305 cipher suite was chosen for its performance benefits and authentication features. The suite creates a robust diffusion and confusion process, making it extremely hard for an adversary to obtain or guess keys or other weaknesses. Using a 256-bit key plus a 96-bit nonce, it is resistant to brute-force attacks feasible with current technology. ChaCha20 as a symmetric cipher may make it less vulnerable to advances in Post-Quantum Computing (PQC) than asymmetric ciphers such as RSA; however, Kibu is aware that developments in PQC may present both opportunities and challenges for the future of its cryptographic methods. Specific advances in PQC that may strengthen certain cryptographic methods in the Kibu architecture are continually assessed for integration into Kibu.

ChaCha20-Poly1305 are also resistant to other cryptanalytic methods, such as timing vulnerabilities of block ciphers. When implemented correctly, ChaCha20 does not use lookup tables that could seep information through cache timing. The deployment of ChaCha20 is widely used in protocols including TLS (paired with Poly1305) and the WireGuard protocol.

Alternatives Considered

Message Layer Security (MLS), RFC 9420:

Kibu considered MLS, which introduces forward secrecy through a double ratchet mechanism. However, this complexity does not align with Kibu's full recovery objectives from a client’s Encrypted User Data and Pod Keys. The key deletion schedule fundamental to MLS's forward secrecy would have been counterproductive to Kibu's design, necessitating a resend-to-recover method that would conflict with Kibu’s recovery model.

Signal Private Groups:

Signal's metadata privacy was not a focus for Kibu, as Kibu aims to support diverse user needs, including corporate needs, in which metadata privacy is incompatible with reporting standards. Moreover, Signal's framework is device-centric rather than user-centric, its Private Groups do not align well with Kibu's Pod quorum concept, and Signal does not offer a good option for recovering lost data due to its ratchet scheme.

Threshold Signature Schemes:

Despite the utility of threshold signature schemes for features such as Pod membership voting, as suggested by various academic papers [4], many of these schemes have practical limitations for the current version of our protocol. Some schemes had prolonged setup times, with interactive protocols necessitating waiting for peers to become available—potentially delaying processing. The complexity of these schemes, compared to every-user-signs models, along with uncertainties in protocol resumption, led to their exclusion from Kibu's cryptographic strategy.

Conclusion

In the constantly evolving digital landscape, trust, authenticity, and security stand paramount. Kibu is a testament to this, bridging the chasm between human-centric communication and the challenges posed by the digital age. By employing state-of-the-art cryptographic techniques, introducing the democratic and transparent 'Pod' concept, and emphasizing genuine human-to-human interaction, Kibu sets a gold standard for digital communication platforms. The platform's rigorous human verification and sophisticated Pod system underscore its dedication to ensuring that digital interactions are not only secure but inherently genuine. As artificial intelligence and other advancements continue to shape our online experiences, Kibu stands as a novel platform to engage in digital spaces that emphasizes the importance of genuine human connection, integrity, and collaboration.