Data Encryption

Technical documentation of our security measures

AES-256 Encryption

1. Overview

Protecting your data is our highest priority. We employ state-of-the-art encryption technologies to ensure that your sensitive information - particularly OAuth tokens for Google services - is protected at all times.

Core Principles of Our Encryption

  • End-to-End Security: Tokens are encrypted before storage
  • Individual Keys: Each user has a unique encryption key
  • No Plaintext: Sensitive data is never stored unencrypted
  • Key Derivation: Encryption keys are dynamically generated, not stored

2. Encryption Algorithm

2.1 Fernet (AES-128-CBC + HMAC-SHA256)

We use Fernet, a highly secure symmetric encryption from the Python Cryptography library. Fernet combines two proven cryptographic methods:

Component Algorithm Purpose
Encryption AES-128-CBC Data confidentiality
Authentication HMAC-SHA256 Integrity and authenticity
Key Length 256 Bit (32 Bytes) High security margin

Why Fernet?

Fernet is an "authenticated encryption" standard that provides both encryption and tamper protection. It is impossible to modify encrypted data without detection.

3. Key Derivation

The encryption key is never stored directly. Instead, it is derived on-demand from three components:

1

User Secret Key

A 64-character SHA256 hash uniquely generated for each user at registration.

2

Application Secret Token

A server-level secret key known only to the system.

3

User ID

The unique database ID of the user as an additional entropy factor.

3.1 Technical Implementation

# Key derivation (simplified)

combined = "{user_secret}:{app_secret}:{user_id}"
key_hash = SHA256(combined) # 32 bytes
encryption_key = Base64(key_hash) # Fernet-compatible

Security Advantage

Even in the event of unauthorized database access, tokens remain protected because the application secret token is not stored in the database. Without all three components, decryption is mathematically impossible.

4. What is Encrypted?

Google Access Tokens

Short-lived access tokens for API requests

Google Refresh Tokens

Long-lived tokens for access renewal

OAuth Credentials

Authentication data for Google services

5. Security Guarantees

Property Status Description
Encryption at Rest Yes All tokens in the database are encrypted
Encryption in Transit Yes TLS 1.3 for all connections
Individual Keys per User Yes Key compromise affects only one user
Keys Not Stored Yes Keys are derived on-demand
Integrity Verification Yes HMAC prevents undetected tampering

6. Compliance and Standards

Our encryption implementation complies with the following standards and best practices:

  • GDPR Art. 32: Technical and organizational measures for data protection
  • OWASP: Recommendations for secure cryptography
  • NIST: Guidelines for cryptographic key lengths
  • ISO 27001: Information security management standards

7. How Secure is 128-Bit Encryption Really?

Short Answer: Very secure.

And more than secure enough for real business data.

128-bit AES encryption has been an international standard for years. Not theoretically, but proven in practice. Banks, cloud providers, and government agencies rely on exactly this.

7.1 Why This Matters

A brute force attack on AES-128 would take longer than the age of the universe, even with today's computing power. There is no known realistic attack that can break AES-128.

7.2 What Many Underestimate

Security doesn't depend on bit count alone. What matters is the implementation.

In our case, this means:

  • User-specific keys instead of a one-size-fits-all solution
  • Combination of User Secret, App Secret, and User ID
  • Encrypted storage of sensitive data
  • Tamper protection through integrity verification
  • No plaintext data in the system

128-Bit vs 256-Bit

The difference to 256-bit is mostly academic in practice. 128-bit AES is not a compromise, but a deliberate, proven security standard.

7.3 Our Philosophy

Data protection is not a marketing buzzword for us, but a technical responsibility.

Security comes not from buzzwords, but from clean architecture. That's exactly what we're building with visibly AI.

8. Contact

For questions about our security measures, please contact our Data Protection Officer:

Email: info@antonioblago.com

Last updated: 2026-03-15

Cookie-Settings