Analysis of Drime Cloud's E2EE and Zero-Knowledge Claims

Original Report: October 2025 | Updated: November 2025

Drime lies about contacting me

Drime's founder has publicly stated on Reddit that they "reached out to me multiple times" and sent a "detailed response document" but that I "never replied".

This is a fabrication.

• The Timeline: My email address (sylphie@tuta.io) was only added to this report in the "Part 2" update (November 2025). Prior to this update, this report was anonymous and listed no contact information whatsoever(verifiable by Github history).
• The Impossibility: It is physically impossible for Drime to have emailed me "multiple times" before November because the contact method did not exist. Unless Drime has found a way to send emails to the future, their claim is a lie designed to discredit this research.
• The "Document": If Drime actually possesses a "detailed response document" that refutes these technical findings, they are free to publish it publicly. Hiding it behind a claim of "unanswered emails" suggests the document does not exist.

Message to Drime

You said: "Only metadata is not E2EE for technical reasons."

Translation: "The $29 script we bought (BeDrive) wasn't built to encrypt filenames, and we don't know how to rewrite the core database logic to fix it."

---

The claim that 'File contents are fully E2EE and cannot be read server-side' contradicts the API evidence:

• The IV: The API returns an exposed iv (Initialization Vector) field in the database row. In true Client-Side E2EE, the IV is bundled into the encrypted blob and managed by the client. An exposed database IV is the hallmark of Server-Side Encryption (standard Laravel/PHP encryption).
• Keys: If the server is generating/storing the IV and validating the password hash (check field), the server is an active participant in the cryptography. This means the server holds the keys.
• Meaning?: While you can theoretically have E2EE with plaintext metadata, you are conflating 'End-to-End Encryption' with 'Encryption at Rest.' If the server holds the keys (which the BeDrive architecture does), it is Encryption at Rest, not E2EE.

If the server stores the salt, the password check, and the per-file IVs and can validate whether the vault password is correct, then the server can derive the encryption key and decrypt the files. That means the system is not end-to-end encrypted, even if the metadata or file contents are encrypted.

Drime founder doesn't seem to know the difference between E2EE and Encryption at Rest.

Please explain why the database stores a separate IV if the encryption is truly happening entirely on the client device.

If you would like to discuss these findings, please email me or open a GitHub issue in the repository.

Summary

This document examines the encryption claims made by Drime Cloud regarding their "Vault" feature. Through API analysis, I found significant discrepancies between their marketing statements and the actual implementation.

Drime Cloud advertises their Vault as having "zero-knowledge" and "end-to-end encryption," stating that "Only you can see your files. Not us, not anyone else." However, API responses show that all file and folder metadata is transmitted in plaintext to their servers.

Background

Drime Cloud is a file storage service based in the European Union. Their Vault feature is marketed as a secure, encrypted storage solution for sensitive files. The service claims to implement zero-knowledge encryption, which typically means that the service provider cannot access any user data, including metadata.

Marketing Claims

The following statements appear on Drime's official website at drime.cloud/vault:

"Drime end-to-end encrypted (E2EE) Vault provide the most secure way to store your most sensitive files in the cloud."

"Zero-knowledge: Only you can see your files. Not us, not anyone else. We don't store passwords, and we can't access your data."

"Your files are encrypted on your device and never leave it unprotected. Only you can access them, not even Drime."

Figure 1: Drime's "Zero-knowledge" marketing claim (Source: drime.cloud/vault)

Technical Analysis

When accessing the Vault feature, the client makes an API request to:

https://app.drime.cloud/api/v1/vault/file-entries

The response contains the following data structure:

{
    "id": 26833,
    "name": "My Confidential Tax Documents",
    "description": null,
    "file_name": "2024_tax_return.pdf",
    "mime": "application/pdf",
    "file_size": 2547891,
    "type": "folder",
    "extension": "pdf",
    "created_at": "2025-10-03T19:45:30.000000Z",
    "updated_at": "2025-10-05T16:38:35.000000Z",
    "path": "26833",
    "vault_id": 440,
    "is_encrypted": 1
}

Exposed Metadata

The API response reveals the following information in plaintext:

• Complete file and folder names
• File descriptions
• MIME types and file extensions
• Exact file sizes in bytes
• Complete directory structure
• Creation and modification timestamps
• Access patterns

The response includes an "is_encrypted" flag set to 1, which appears to indicate that file contents are encrypted, but not the metadata.

Figure 2: API response showing unencrypted metadata in browser DevTools

Comparison with Industry Standards

True zero-knowledge encryption implementations encrypt metadata on the client side before transmission. For comparison, pCloud's Crypto Folder service returns encrypted filenames:

{
    "name": "CM4LSAOHWDTXNPEJF2XZA67KOPDJ5XOJWACR3JVTT4KK3DRQBAE5RHIY4Z4IUKSDO4AM4ZODDSH7S",
    "encrypted": true,
    "contenttype": "application/octet-stream"
}

Other services implementing true zero-knowledge encryption include:

• Proton Drive - Uses PGP-based encryption for all metadata
• Tresorit - Client-side encryption of filenames and folder structure

Figure 3: pCloud Crypto folder showing encrypted filename vs Drime's plaintext

Privacy Implications

The exposure of metadata has significant privacy implications:

This metadata can be:

• Accessed by Drime employees
• Subpoenaed by law enforcement
• Exposed in the event of a data breach
• Used for internal analytics or profiling

Additional Security Concern

The vault_id field uses sequential integers (440, 441, 442, etc.). This implementation allows any user to determine the total number of vaults created system-wide by creating and deleting vaults and observing the increment. This is a minor information disclosure that violates common security practices. Standard implementations use UUIDs or random identifiers to prevent enumeration.

Figure 4: Sequential vault_id allowing enumeration of total vaults

Reproduction Steps

The findings can be verified using the following process:

1. Create a Drime account and enable the Vault feature
2. Create folders with descriptive names (e.g., "Personal Medical Records")
3. Upload files with recognizable filenames
4. Open browser developer tools (F12) and navigate to the Network tab
5. Access the Vault by entering the vault password
6. Locate the API request to /api/v1/vault/file-entries
7. Examine the JSON response body

All metadata will be visible in plaintext in the response.

Company Response

When these findings were initially reported, Drime's team responded with the following statement:

"Drime Vault is a new feature, and we've already addressed these concerns. The file content is fully end-to-end encrypted, it's encrypted on your device before being uploaded. Some providers use the term 'zero knowledge,' which usually means that even metadata is encrypted. We plan to bring this level as well once Vault is fully stable."

In a subsequent response, they stated:

"We do not claim 'zero knowledge', and we've already clarified this in past discussions when asked."

This statement contradicts their marketing page, which explicitly includes a section titled "Zero-knowledge" with claims about data access.

Figure 5: Drime's response claiming they "do not claim 'zero knowledge'"

Legal and Regulatory Considerations

Drime Cloud operates in the European Union and markets services to EU citizens. The discrepancy between marketing claims and actual implementation may raise concerns under several regulatory frameworks:

• GDPR Article 5 requires accuracy and transparency in data processing claims
• The Unfair Commercial Practices Directive prohibits misleading advertising
• Consumer protection laws require truthful product representations

The use of terms like "zero-knowledge" and statements such as "Not us, not anyone else" while maintaining server-side visibility of metadata could be considered misleading to consumers making security decisions.

Recommendations

For Drime Cloud:

• Update marketing materials to accurately reflect what data is and is not encrypted
• Remove or clarify the "zero-knowledge" claims until metadata encryption is implemented
• Provide clear documentation about what information is visible to the service
• Implement UUID-based identifiers instead of sequential integers
• Provide a specific timeline for implementing metadata encryption

For users considering Drime Vault:

• Understand that file and folder names are visible to Drime's servers
• Assume metadata can be accessed by the company and legal authorities
• Consider whether the current level of encryption meets your threat model
• Evaluate alternative services if metadata privacy is critical

Conclusion (Part 1)

Drime Vault appears to implement encryption-at-rest for file contents, which provides some level of protection. However, the implementation does not meet the industry standard definition of "zero-knowledge" encryption, which requires that metadata also be encrypted client-side before transmission.

"hash": "MzQ0NDZ8cGFkZA"

34446|padd

public function getHashAttribute(): string {
    return trim(base64_encode(str_pad($this->getRawOriginal('id').'|', 10, 'padding')), '=');
}

{
    "is_encrypted": 1,
    "iv": "TM49hT8aKz73V8iP"
}

"check": "VqpUxQg3x4kJB2aKekAR6KQi15X476qvp1dtMQ=="

This analysis was conducted in October and updated November 2025. All evidence has been archived and is available for verification.

Contact: sylphie@tuta.io