How Encryption Works

DulyNote uses industry-standard encryption to protect your data when exporting or sharing collections. Encryption is optional but strongly recommended for sensitive content.

File-Level Encryption

When you enable encryption on a .dnote export, DulyNote applies AES-256-GCM encryption to every item in the package:

• Each file and metadata record is encrypted individually.
• The encryption key is derived from your Recovery Key using PBKDF2 with a random salt.
• The salt and initialization vector (IV) are stored in the package header — the key itself is never stored.

Key Derivation

Your Recovery Key is a 32-character alphanumeric string generated at export time. The actual AES encryption key is derived from it using:

• Algorithm: PBKDF2-HMAC-SHA256
• Iterations: 100,000+
• Salt: 16 bytes, randomly generated per export

This means even if two exports use the same Recovery Key, the derived encryption keys will differ.

Transparent Archive, Encrypted Content

The .dnote package structure is readable (you can see collection names and item counts), but all content — titles, descriptions, URLs, file data — is encrypted. Only someone with the Recovery Key can decrypt and read the actual data.

• Minimal Metadata Exposure: Only non-sensitive information (such as application version and encryption status) is accessible. All user data remains encrypted during storage and transfer.

There Is No Server To Know Anything

Other apps describe this as “zero-knowledge”, meaning their servers hold your data but cannot read it. DulyNote goes one step further: there are no DulyNote servers at all.

• No account, no upload: Your library never leaves the device. There is nothing to transmit encryption keys or content to.
• Local key storage: Your Recovery Key is stored only in secure device storage (iOS Keychain or Android Keystore), pinned so it never syncs to iCloud.
• You are the only holder: Only you can decrypt an encrypted export. DulyNote cannot, because DulyNote never receives it.