This document explains the encryption and data protection design used in EgnaFlex privacy-first products (with ReglFit as the primary implementation). It is written for users, security reviewers, partners, and investors who want a clear and verifiable understanding of how sensitive data is protected.

1. EXECUTIVE SUMMARY

EgnaFlex builds privacy-first products where sensitive user data remains under user control. Our systems are designed around a zero-knowledge principle: EgnaFlex servers cannot decrypt or read user health data, even if the data is stored or synchronized in the cloud.

We implement:

• Client-side encryption: Data is encrypted on the user's device before leaving it.
• End-to-end encryption (E2EE): Only authorized user devices can decrypt.
• Envelope encryption with separated keys:
  • DEK (Data Encryption Key) encrypts data.
  • KEK (Key Encryption Key) encrypts the DEK.
• Offline-first architecture: Core features work without cloud connectivity.
• User-controlled recovery (where enabled): recovery codes and controlled re-keying mechanisms.

This approach is intended to reduce the risk of:

• Data exposure from server breaches
• Insider access by service operators
• Third-party tracking and monetization of health data
• Over-collection of identifiable information

2. Scope

This white paper covers:

• Threat model and security goals
• Key hierarchy (DEK/KEK) and encryption workflow
• Cryptographic primitives and parameters
• Data storage and sync boundaries (client vs server)
• Recovery and multi-device considerations
• Operational security and limitations

This document does not cover:

• Non-cryptographic privacy topics (marketing analytics, cookies, etc.) unless explicitly stated
• User device compromise scenarios beyond reasonable mitigation
• Full source code (we may publish selected modules later)

3. DEFINITIONS

• E2EE (End-to-End Encryption): Data is encrypted on the sender device and decrypted only on authorized recipient devices; the server cannot decrypt.
• Zero-knowledge: Service operator does not have access to plaintext data or the keys needed to decrypt it.
• DEK (Data Encryption Key): Symmetric key used to encrypt data payloads.
• KEK (Key Encryption Key): Key used to encrypt/wrap the DEK (envelope encryption).
• KDF (Key Derivation Function): Produces cryptographic keys from inputs (passwords, secrets) with strong resistance against brute force.
• AAD (Additional Authenticated Data): Metadata authenticated (not encrypted) in AEAD modes like AES-GCM, preventing tampering.

4. THREAT MODEL

4.1. Adversaries Considered

We design against:

1. Cloud/Server compromise
   Attacker gains access to databases, backups, logs, or storage buckets.
2. Insider threat
   A malicious or coerced operator at a cloud provider or within the organization.
3. Network attacker (MitM)
   Intercepts traffic between device and server.
4. Unauthorized account access
   Attempts to access user data by abusing auth flows or stolen tokens.

4.2. Adversaries Not Fully Preventable

No encryption system can fully protect against:

• A fully compromised user device (malware, root/jailbreak with persistence, key exfiltration)
• User sharing secrets (e.g., recovery codes) with third parties
• Physical coercion attacks

We focus on making these attacks harder through device-bound key storage, integrity checks, and recommended security practices.

5. Security Goals

1. Confidentiality: Cloud-stored user data remains unreadable without user-held keys.
2. Integrity: Encrypted data cannot be modified without detection.
3. Key separation: Compromise of one component does not reveal all user data.
4. Least knowledge: Servers do not possess decryption keys.
5. Recoverability (optional): Users can regain access to encrypted data without EgnaFlex holding plaintext keys.
6. Practicality: Security must not break usability; offline-first is maintained.

6. ARCHITECTURE OVERVIEW

6.1. High-Level Flow

1. User generates or obtains a Master Secret (device-bound and/or user-recoverable, depending on configuration).
2. A KEK is derived from the Master Secret using a KDF.
3. A DEK encrypts user data fields or documents using an AEAD scheme.
4. The DEK is wrapped (encrypted) by the KEK.
5. The server stores:
   • Encrypted payload(s)
   • Wrapped DEK(s)
   • Non-sensitive metadata required for syncing (minimized)

At no point does the server receive plaintext health data or unwrapped DEKs.

6.2. Data Model (Conceptual)

• ciphertext: encrypted user data
• iv/nonce: per-encryption random nonce
• tag: authentication tag (AEAD)
• wrapped_dek: DEK encrypted with KEK
• aad: authenticated metadata (e.g., schema version, date bucket), no sensitive content

6.3. Architecture Diagram

The following diagram illustrates the end-to-end encryption flow from user input to cloud storage and back to authorized devices:

7. KEY MANAGEMENT

7.1. Key Hierarchy

• Master Secret → derived into KEK
• KEK → wraps DEK
• DEK → encrypts data

This reduces blast radius:

• If a DEK is rotated, only payloads under that DEK need re-encryption.
• The KEK can remain stable while DEKs change (recommended).

7.2. Key Generation and Storage

Keys are generated using a cryptographically secure random number generator on device.

Device protection (recommended):

• iOS: Keychain with Secure Enclave when available
• Android: Keystore-backed key material when available

We avoid storing raw keys in plaintext on the server.

7.3. Key Rotation

We support/plan:

• DEK rotation on schedule or after security events
• Schema/versioned encryption to support backward compatibility during upgrades

Rotation is designed to be transparent to users where possible.

8. Cryptography

8.1. Encryption Scheme

We use an AEAD construction to ensure confidentiality and integrity.

Recommended default:

• AES-256-GCM for payload encryption

Where platform constraints apply, equivalent secure AEAD modes may be used.

8.2. Key Derivation Function (KDF)

To derive keys from secrets, we use a modern KDF (e.g., HKDF for key expansion).
If user passwords/passphrases are used, we apply a memory-hard KDF (e.g., Argon2id or scrypt) to resist offline attacks.

8.3. Nonces and Randomness

• Nonces/IVs are generated uniquely per encryption operation.
• Nonce reuse is prevented by design (critical for GCM security).

8.4. Authenticated Metadata (AAD)

AAD is used to bind ciphertext to context such as:

• user identifier (non-sensitive internal ID)
• record type
• encryption version

This prevents ciphertext transplant and certain tampering attacks.

9. WHAT THE SERVER CAN AND CANNOT SEE

9.1. Server Cannot See

• Period tracking entries in plaintext
• Symptoms, moods, notes, or daily logs in plaintext
• User-generated sensitive health data in plaintext
• Encryption keys (KEK/DEK) in unwrapped form

9.2. Server May See (Minimized)

• Encrypted blobs (ciphertext)
• Timestamps for syncing (coarsened where possible)
• Record counters and sizes (inherent to storage)
• User account identifiers required for authentication

We aim to minimize metadata to reduce inference risk.

10. OFFLINE-FIRST AND SYNC

10.1. Offline-First Operation

Core features operate locally without requiring cloud access.
When sync is enabled, encrypted payloads are uploaded and merged.

10.2. Conflict Handling (Encrypted Domain)

Because the server cannot inspect plaintext, conflict resolution is designed around:

• deterministic record IDs
• last-write-wins for certain fields (where safe)
• append-only logs for sensitive entries (recommended pattern)

We avoid server-side business logic that would require plaintext.

11. MULTI-DEVICE ACCESS (OPTIONAL)

When multi-device is enabled, a second device must be authorized without exposing plaintext keys to the server.

Common approaches:

• Secure device-to-device transfer (QR / local channel)
• Recovery code-based re-derivation of KEK
• Encrypted key packages stored server-side but decryptable only by authorized devices

EgnaFlex does not require server-held plaintext keys for multi-device access.

12. RECOVERY MODEL (OPTIONAL)

We support/plan a recovery approach that does not rely on EgnaFlex holding decryption keys.

Possible mechanisms include:

• Recovery codes generated once and shown to the user
• User-controlled re-keying to add a new device
• Clear UX around tradeoffs: recovery improves availability but introduces risks if codes are mishandled

Important: If a user loses all devices and recovery codes, EgnaFlex cannot decrypt the data. This is a direct consequence of zero-knowledge design.

13. LOGGING, TELEMETRY, AND PRIVACY

We design telemetry to avoid sensitive content:

• No plaintext health data in logs
• Strict redaction of identifiers where possible
• Crash reports are configured to minimize payloads
• Analytics (if enabled) focuses on non-sensitive operational metrics

14. SECURITY TESTING & ASSURANCE

We use a layered assurance approach:

• Internal security reviews for cryptographic changes
• Static analysis and dependency monitoring
• Secure coding practices and secrets management
• Incident response playbooks

Roadmap (recommended):

• Independent third-party security assessment
• Public disclosure policy for vulnerabilities
• Potential open-sourcing of selected crypto modules

15. LIMITATIONS AND USER RESPONSIBILITIES

E2EE does not protect against:

• Malware on the user's device
• Rooted/jailbroken environments with advanced attackers
• Social engineering attacks (phishing, fake support)
• User sharing recovery codes

We recommend:

• Device passcode/biometrics enabled
• OS kept up to date
• Avoid installing untrusted apps
• Store recovery codes offline in a secure location

16. Frequently Asked Questions

Can EgnaFlex read my data?

No. Our design prevents EgnaFlex from decrypting user health data stored in the cloud.

What happens if your servers are breached?

Attackers may obtain encrypted blobs, but without user-held keys the data remains unreadable.

Can I delete my data?

Yes. Users can delete cloud-stored encrypted data and local data per product settings. Deletion removes ciphertext and associated key-wrapping material from our systems.

If I forget my password / lose my device, can you restore my data?

Only if you have enabled recovery and kept your recovery codes. Otherwise, EgnaFlex cannot decrypt your data.

Why is this different from typical "encrypted at rest" systems?

Encrypted-at-rest usually means the provider holds keys and can decrypt. E2EE means only the user can decrypt.

17. CHANGELOG

• v1.0 (January 15, 2026): Initial public release.

18. CONTACT

General: info@egnaflex.com

If you believe you found a vulnerability, please contact us with a detailed report. Responsible disclosure is encouraged.