End-to-End Encryption

The Abyrint Connect platform supports end-to-end encryption (E2EE). This feature is similar in concept to encrypted messaging apps such as Signal. Only authorized workspace members can decrypt and read data in cleartext. E2EE can be enabled for select applications or for all applications within a workspace. As a result, all data entries and files—whether images or documents—are encrypted and decrypted on your device. It is not technically possible for Abyrint or any other party to access decrypted data.

Setup

Enabling E2EE is straightforward. Workspace administrators can activate it from the Workspace Settings area within the Connect web application. Once enabled, workspace members will be guided through a one-time key generation process. This document outlines the technical mechanisms that power this feature.

Use Cases

  1. Highly Sensitive Workspaces: Projects for enterprises or governments with restricted data. A deal room or workspace can be locked down entirely.
  2. Sensitive Field Data: For example, health-related field surveys. You can configure enumerators to write new data without the ability to read it. Only approved workspace administrators can decrypt entries.

Gotchas

  • No External Integrations: Automated integrations with third‑party services (e.g., Google Sheets, Power BI) require access to clear text data. This defeats the purpose of E2EE. Avoid connecting sensitive workspaces to such platforms. In this case it just will not work.
  • Key Loss Risk: Abyrint cannot recover encrypted data if all access keys are lost on your end. Our key‑management process is simple and robust, but lost keys mean permanent data inaccessibility. In that case, data can only be deleted.
  • Legal Requests: We respond to lawful data inquiries. However, E2EE data remains encrypted, and we cannot decrypt it for any authority.

Key Management & Recovery

User-Centric Control: It is a true end-to-end encrypted system, you are in complete control of your keys. This means that Abyrint has no “master key” and cannot recover your encrypted data if you lose access. This design is essential to the security promise of E2EE.

Best Practices for Preventing Key Loss:

  • Register Multiple Devices/Keys: We highly recommend registering more than one device or hardware security key to your account. If you lose access to one device, you can still decrypt your data using another. This is especially important for workspace administrators.
  • Workspace Administrator Role: Workspace administrators manage workspace membership. An administrator can remove a user who has lost their keys and re-invite them, allowing them to generate a new key and regain access to new data added to the workspace (but this only applies to workspace shared data, while a users personal space, if any, will be lost).
  • Secure Backup (Manual): For advanced use cases, your workspace administrator may provide a method for you to manually back up your workspace key in a secure location (e.g., a password manager or physical storage). This process is entirely user-managed.

Technical Underpinnings

  • Client-Side Encryption: Data is encrypted in the client (browser or mobile app) before transmission.
  • Encryption Algorithms: We use AES‑GCM with 256‑bit keys for content encryption. This is the “long-lasting” persistent encryption that your data will be safeguarded by. For key negotiation and distribution of the workspace key among team members, we employ the ML KEM (Kyber) post‑quantum Key Encapsulation Mechanism (KEM). This quantum‑safe algorithm shares the workspace encryption key among authorized users only. These cryptographic protocols are approved by the U.S. National Institute of Standards and Technology (NIST) and other authorities for post‑quantum security; compliance is required for U.S. government systems by 2035, with several other governments mandating adoption earlier. To prevent unauthorized additions to the workspace (the “WhatsApp problem”), we use a cryptographically signed key manifest issued by the workspace administrator.
  • Key Storage: User decryption keys are stored by default in device-secure enclaves or protected by device-level encryption. As an alternative, designated hardware security keys (e.g., YubiKeys) supporting the FIDO2 “Prf” extension protocol can be used. This protocol has been implemented in Chromium-based browsers since version 122 (February 2024) and in Apple Safari 17.4 since early 2024, and is available in several securlty keys.
  • Metadata Protection: Only essential metadata (e.g., timestamps, file sizes) is visible to the server. File names and content remain encrypted.

Usage Tips

  • Unlike messaging or password‑manager apps, encryption here is not tied to your password. Decoupling the encryption key from your password strengthens security and enables joining multiple workspaces, each locked with a unique key set.
  • Your secret key is a 256‑bit sequence of random binary digits (0s and 1s) and need not be memorized. It is cryptographically unbreakable. Its stored on your device, built into the core of the “secure enclave”, as it is called, supported by all major hardware producers.
  • Workspace administrators may optionally enable manual passphrase usage for specific, authorized scenarios. In that case, key access depends on the chosen passphrase.
  • Be aware that platforms like Apple iCloud and certain Android or Windows services may synchronize keys across your devices. Practically this means that access depends on access to your device and to your icloud account for example. For extremely sensitive workspaces, restrict key storage to dedicated hardware security keys (e.g., YubiKeys) identified by serial numbers.
  • Forward-Encryption Handling: Compared to Signal, we implement forward-secrecy differently. In a business workspace, this allows newly-enrolled users to decrypt existing data seamlessly—a key requirement for long-lived project spaces where membership may evolve over time.