VaultBook Security Spotlight: Password-Protected Entries with AES-GCM

Security in software is most often presented as a binary property - a product is either secure or it is not, and the proof offered is usually a claim about the encryption standard applied to the data at rest or in transit.

This framing is understandable as a starting point for security communication, because the alternatives require more nuance than most product marketing accommodates. But it obscures a distinction that matters significantly for professionals whose work requires them to manage information at different levels of sensitivity within the same workspace: the distinction between application-level access control and cryptographic protection of individual data items.

Application-level access control is what most security features in productivity software actually provide. A password on the application, a lock screen that prevents unauthorized browsing, a session timeout that requires re-authentication after a period of inactivity - these are controls that determine whether an unauthorized person can interact with the application. They do not determine what an authorized person who has passed the application-level authentication can see. In an application with only application-level access control, everyone who has the application password can see everything in the application. The protection boundary is at the application level; there is no protection boundary at the level of individual pieces of content.

For most users, application-level access control is adequate. Their vault contains content that is all roughly equivalent in sensitivity, and the right question about any piece of content is simply whether the person accessing it is authorized to access the vault at all. But for users whose work generates information at genuinely different levels of sensitivity - a therapist whose vault contains both general professional reference material and detailed session notes for specific patients, a lawyer whose vault contains both general case management notes and highly sensitive strategy documents, a financial professional whose vault contains both administrative records and specific client account data - application-level access control is insufficient. The protection model needs to reflect the actual structure of the information, not just the structure of the application.

VaultBook’s per-entry password protection with AES-256-GCM encryption provides exactly this additional layer. Individual entries can be encrypted with passwords that are separate from the global vault password, with the encryption strong enough to be relied upon for genuinely sensitive professional content and the implementation careful enough that the protection is real rather than nominal. This feature is the security spotlight of this article - not because it is VaultBook’s only security feature, but because it exemplifies the architectural principle that distinguishes VaultBook’s approach to security from the approach taken by every cloud-dependent alternative: the principle that protection should match the structure of the information being protected, not the structure that is most convenient for the application to implement.

The Threat Model That Per-Entry Encryption Addresses

To understand why per-entry encryption is valuable, it helps to be precise about the threat scenarios that application-level access control does not address and that per-entry encryption does.

The first scenario is the shared device or shared access context. A professional who uses their device in an environment where others may occasionally have legitimate access to it - a colleague who borrows the device for a quick task, a household member who uses the same computer, a situation where the device is left unlocked in a shared space - has a need to distinguish between vault content that is acceptable to be seen in these contexts and vault content that should require an additional credential. Application-level access control handles the scenario where the vault should be completely inaccessible to unauthorized users; it does not handle the scenario where the vault is accessible to some users who should still not be able to access specific highly sensitive entries within it.

The second scenario is the device compromise or forensic access context. If a device is lost, stolen, or subjected to forensic examination - a scenario that is not hypothetical for professionals working in regulated industries - the content of the device’s storage is potentially accessible to whoever has the device. System-level encryption like FileVault or BitLocker protects the device’s storage when the device is powered off, but once the device is powered on and the system encryption is unlocked, the file system is accessible. Application-level access control adds another barrier, but an attacker with sufficient time and technical capability may be able to bypass application-level controls without breaking the encryption. Per-entry encryption adds a cryptographic barrier at the level of the individual entry’s content - a barrier that cannot be bypassed without the password, regardless of how the attacker has obtained access to the file system.

The third scenario is the compliance and auditability context. Some regulatory frameworks require that access to specific categories of sensitive information be separately controlled and logged - that accessing highly sensitive records requires additional authentication beyond the general system access that authorized users possess. Per-entry password protection provides a mechanism for implementing this kind of tiered access control within VaultBook, where entries containing the most sensitive content require a separate credential that documents an explicit access decision rather than inheriting access from the general application authentication.

The fourth scenario is the multi-user or delegation context. A professional who shares their vault structure with an assistant or colleague - allowing general vault access for administrative tasks - may need to retain exclusive personal access to specific entries that should not be accessible to the delegated user. Per-entry encryption addresses this by maintaining cryptographic protection for specific entries that the delegated user cannot access without the entry-specific password, regardless of their access to the vault as a whole.

Each of these scenarios represents a real situation that professionals in healthcare, law, finance, and other sensitive information fields actually encounter. Per-entry encryption provides a technically sound response to each of them.

The Cryptography Behind the Protection

VaultBook’s per-entry encryption is implemented using AES-256-GCM - Galois/Counter Mode encryption with a 256-bit key - which is the authenticated encryption standard that represents the current consensus best practice for protecting data in a local encryption context. Understanding why this specific combination was chosen, and what it provides, is valuable for professionals who need to justify their data security choices to regulators, auditors, or supervisors.

AES, the Advanced Encryption Standard, is the symmetric encryption algorithm that has been the global standard for symmetric encryption since its adoption by the National Institute of Standards and Technology in 2001. It has been subject to more cryptanalytic scrutiny than any other symmetric cipher and remains unbroken in all practical senses - the best known attacks against AES require computational resources that are not achievable with any foreseeable technology. The 256-bit key variant provides a key space of 2^256 possible keys, making exhaustive key search computationally infeasible by any margin that matters for any realistic threat scenario.

GCM - Galois/Counter Mode - is an authenticated encryption mode that provides two properties simultaneously: confidentiality, through the encryption of the plaintext content into ciphertext that cannot be read without the key; and integrity authentication, through a cryptographic authentication tag that detects any modification to the ciphertext. This integrity authentication property is important because encryption without authentication is vulnerable to manipulation attacks - an attacker who cannot read the encrypted content might still be able to modify it in ways that produce a different plaintext when decrypted. AES-GCM’s authentication tag prevents this class of attack by making any modification to the ciphertext detectable at decryption time.

The key derivation uses PBKDF2 - Password-Based Key Derivation Function 2 - with 100,000 iterations of SHA-256 as the underlying hash function. PBKDF2 converts a human-chosen password into a cryptographic key through an iterated hashing process. The 100,000 iteration count is chosen to make the key derivation computationally expensive for an attacker attempting to guess the password through brute force: each password guess requires running PBKDF2 with 100,000 SHA-256 iterations, which slows the guessing rate to a level where even a powerful attacker can only test a limited number of password candidates per second. For a user who has chosen a reasonably strong password, this makes exhaustive password guessing impractical.

Each encryption operation generates a fresh random 16-byte salt and a fresh random 12-byte initialization vector. The salt is an input to the PBKDF2 key derivation, ensuring that two entries encrypted with the same password produce different derived keys - which prevents an attacker from recognizing that two entries share a password by comparing their encrypted forms. The initialization vector ensures that two encryptions of the same content with the same key produce different ciphertexts - which prevents information leakage through patterns in repeated encryption of similar content.

The password is never stored. The derived key is never stored. The decrypted plaintext is held only in the browser’s working memory in the entry’s runtime state, identified by the internal _plain field during an active session, and is never written to the local storage files in decrypted form. The files on disk always contain the encrypted ciphertext plus the salt and IV needed for decryption - everything required for decryption except the password itself, which exists only in the user’s memory.

This implementation represents genuine cryptographic protection. It is not encryption theater - a lock icon and a password prompt that obscures content without actually protecting it cryptographically. It is a careful implementation of established cryptographic standards that provides protection that is technically defensible in regulatory, legal, and professional contexts where the strength of the protection may be evaluated.

Session Password Caching and the Usability-Security Balance

A cryptographic system that is secure in theory but impractical in daily use will be worked around by users who find the friction unacceptable. VaultBook’s session password caching addresses the usability dimension of per-entry encryption without compromising the security properties that the encryption provides.

When a user enters the password for an encrypted entry during a session, the password is cached for the duration of that session. Subsequent accesses to the same entry within the same session do not require re-entering the password - the cached credential is used to derive the key and decrypt the content each time the entry is accessed. This means that a user who routinely accesses a specific encrypted entry multiple times during a working session experiences the protection as a single authentication event at the beginning of the session rather than as a repeated interruption.

The session scope of the caching is important for security. When the browser tab or window is closed - ending the session - the cached passwords are discarded along with all other session state. The next session begins with no cached credentials; each encrypted entry must be unlocked explicitly by re-entering its password before the entry’s content is accessible. This session-scoped caching means that the usability benefit of not having to re-enter passwords repeatedly within a session does not extend to cross-session persistence - the protection that requires the password to access the content is fully in effect at the beginning of each session.

The decrypted content’s scope is similarly session-limited. The plaintext of a decrypted entry is held in the entry’s runtime state only for the duration of the active session. It is never written to the local storage files in decrypted form. The vault’s files on disk always contain the encrypted versions of protected entries, regardless of whether those entries have been decrypted and accessed during the current session. An attacker who obtains the vault files - by copying the vault folder from the device, by forensic examination of the device’s storage, or by any other means of accessing the file system - obtains encrypted content for all protected entries, regardless of whether those entries were actively being used when the files were obtained.

This combination - session-scoped caching for usability, decrypted content in memory only for security, encrypted-only content on disk at all times - represents a carefully considered balance between the competing requirements of a security feature that professionals will actually use and a security feature that provides genuine protection. The caching reduces the friction of per-entry encryption to a level that is compatible with regular daily use; the memory-only scope of decrypted content ensures that the friction reduction does not create the file-level exposure that would undermine the protection.

The Lock Screen: Session-Level Protection for the Full Vault

Per-entry encryption operates at the content level - protecting specific entries within the vault with cryptographic barriers that require entry-specific passwords. VaultBook’s lock screen operates at a different level: it is a session-level access control that prevents any interaction with the vault’s content until the vault password is entered.

The lock screen is a full-page mechanism - a blur overlay applied to the entire vault interface, with pointer event blocking and user selection blocking that prevent any interaction with the content beneath. The vault layout, the page hierarchy, the note list, and any content that was visible before the lock was applied all become obscured and uninteractable. The lock screen presents only the password prompt, and the vault interface becomes available only after the correct password is entered.

The lock screen addresses scenarios that per-entry encryption does not - specifically, the scenario where the user needs to step away from the device temporarily and wants to prevent casual viewing of vault content by anyone who approaches the device, without requiring the vault to be completely closed and reopened. Activating the lock screen takes a single action; returning to work requires only entering the vault password without the startup sequence of selecting the vault folder and loading the application state that reopening would require.

The blur overlay is visually complete - the content beneath it is unreadable, not merely obscured by a pattern overlay that might allow text to be distinguished through the blur. The pointer event blocking prevents any accidental or deliberate interaction with the interface elements beneath the overlay. The user selection blocking prevents text selection operations that might reveal content through selection highlighting. Together, these properties ensure that the lock screen is a genuine visual and interactive barrier rather than a cosmetic one.

For professionals who work in shared physical environments - open-plan offices, shared workspaces, clinical settings where others are present, any environment where another person might see the screen during a period of inattention - the lock screen provides a quick and reliable way to protect the vault’s contents during temporary absences without interrupting the working session.

Per-Entry Encryption Across VaultBook’s Full Feature Set

The per-entry encryption capability integrates naturally with VaultBook’s full feature set rather than being an isolated security module that operates separately from the rest of the application’s functionality. Understanding how encrypted entries interact with search, with the AI features, with version history, and with the organizational structure helps clarify the practical scope of the protection.

Encrypted entries participate in the vault’s organizational structure in the same way as unencrypted entries. They appear in the page hierarchy, carry labels, have due dates and expiry dates, and are associated with pages and sections like any other entry. The organizational metadata is visible without decryption; it is the entry’s content - the body, the section content, the attached files - that is protected by the per-entry encryption. This means that a vault’s organizational structure remains navigable even in a session where specific encrypted entries have not yet been unlocked, and that the label system and page hierarchy can be used to locate encrypted entries without first decrypting them.

The search behavior for encrypted entries is consistent with their protection level. An entry whose content is encrypted and whose decryption has not been performed in the current session will not expose its content to search results - the search indexes the decrypted content when it is available in session state, and the encrypted content that is stored on disk is not indexed in a form that would reveal the protected text. This means that per-entry encryption provides genuine content protection even within the search interface - an attacker who gained access to the vault’s search interface without the entry password would not be able to discover the protected entry’s content through search queries.

When an encrypted entry is unlocked during a session - when the user enters the correct password and the content is decrypted into session state - the decrypted content becomes available to the session’s search and AI features for the duration of the session. The AI Suggestions carousel can include decrypted entries in its pattern analysis. The Related Entries feature can surface connections involving decrypted entries. The QA natural language search can include decrypted entry content in its results. The session-duration availability of decrypted content means that unlocking an entry integrates it fully into the session’s intelligent features while maintaining the protection that requires unlocking at the start of each session.

Version History for encrypted entries maintains the encryption across versions. Each snapshot in the version history preserves the entry’s state at the time of the snapshot, including its encrypted status. Restoring an earlier version from the history restores the encrypted state of that version - a user who reviews version history for an encrypted entry is navigating encrypted snapshots, each of which requires the entry password to decrypt and view.

Healthcare, Legal, Finance, and the Professional Privacy Spectrum

The per-entry encryption feature, combined with VaultBook’s fully local architecture and its comprehensive feature set, positions the application as a complete professional knowledge workspace for the categories of work where privacy is not a preference but an obligation. The specific requirements of each professional domain deserve individual consideration.

Healthcare professionals working under HIPAA face specific obligations regarding the protection of protected health information that are not satisfied by application-level access control alone. The Security Rule’s technical safeguard requirements include access controls that limit access to PHI to only those with a need to know, and encryption of PHI as an addressable implementation specification - an implementation standard that covered entities must either implement or document a specific justification for not implementing. Per-entry encryption in VaultBook provides a direct implementation of this addressable specification: PHI in specific entries is encrypted with a password known only to the authorized clinical user, providing access control at the individual record level rather than only at the application level.

The local architecture ensures that PHI never reaches any third-party infrastructure, satisfying the fundamental requirement that PHI not be disclosed to third parties without a valid HIPAA authorization or an applicable exception. The combination of per-entry encryption for individual record-level protection, local architecture for no third-party disclosure, and the 60-day purge policy for compliant disposal of deleted records provides a comprehensive HIPAA-aligned data protection framework within a single application.

Legal professionals face confidentiality obligations that arise from both the attorney-client privilege and the professional conduct rules of their jurisdiction. Per-entry encryption supports the implementation of tiered confidentiality within a legal vault - where routine case management notes are accessible to everyone with vault access, but strategy documents, privileged analysis, and highly sensitive client communications are encrypted at the entry level and accessible only to the specific attorney responsible for those matters. The encryption provides a technical barrier that reinforces the professional confidentiality obligation with a cryptographic control rather than relying on access discipline alone.

Financial professionals managing client account information, proprietary investment analysis, and confidential transaction records face both regulatory requirements and contractual confidentiality obligations that per-entry encryption helps satisfy. The ability to encrypt entries containing specific client financial data with passwords that are separate from general vault access provides a mechanism for implementing client-level access controls within a single vault - where each client’s most sensitive records are protected by credentials that are specific to that client relationship.

Corporate knowledge workers managing internal information whose distribution is restricted - unreleased financial data, personnel records, proprietary strategic analysis, confidential partnership negotiations - benefit from per-entry encryption as a mechanism for implementing the information classification policies that most organizations maintain but struggle to enforce technically. When an entry is classified as highly restricted, encrypting it with a per-entry password makes the restriction technically enforced rather than merely stated.

VaultBook’s analytics features provide visibility into vault usage patterns that is valuable in a security context as well as a productivity context. The analytics panel available in the Plus tier provides entry count, the number of entries with attached files, total file count, and total storage size - the basic structural metrics of the vault. The Pro tier extends this with canvas-rendered charts covering label utilization as a pie chart, the last fourteen days of activity as a line chart, page utilization as a pie chart, and monthly activity as a bar chart.

For security and compliance purposes, the activity charts provide visibility into usage patterns that can support both proactive monitoring and retrospective audit. The last fourteen days activity line chart shows the pattern of note creation and modification over recent weeks - a pattern that can reveal unusual spikes of activity, extended periods of inactivity that might indicate the vault is not being used as intended, or other patterns that warrant attention in a compliance context. The label utilization chart shows how frequently labels that indicate sensitive content - labels like “HIPAA,” “Privileged,” “Confidential,” or “PII” - are being used relative to the vault’s total content, providing a baseline against which anomalies can be detected.

The attachment type breakdown chips in the analytics panel show the composition of the vault’s attached files by type, providing at-a-glance awareness of how many encrypted entries have attached files and what types of files are present in the vault. For a professional conducting a periodic review of their vault’s content to ensure that sensitive attachments are correctly associated with encrypted entries, the type breakdown provides a starting point for that review.

All of this analytics data is computed locally from the vault’s own content, with no data transmitted anywhere. The security-relevant behavioral information that the analytics surface - usage patterns, label distributions, content composition - is visible only to the vault’s owner, computed on their own device, and never accessible to any external service or infrastructure.

Building a Security Architecture That Scales

VaultBook’s per-entry encryption is most valuable when it is part of a deliberate security architecture rather than an ad-hoc measure applied inconsistently. The combination of features that VaultBook provides supports the construction of a layered security architecture that addresses the full range of threats that professional information faces.

The foundation layer is the device-level encryption provided by the operating system - FileVault on macOS, BitLocker on Windows - which protects all data on the device’s storage when the device is powered off. This layer addresses the physical access threat: a device that is stolen or lost and that has full-disk encryption enabled exposes no readable content to whoever obtains it, because decrypting the storage requires the system encryption credentials.

The second layer is VaultBook’s application-level access control - the vault password and the lock screen that prevent unauthorized access to the vault’s content by anyone who has access to a running, unlocked device. This layer addresses the logical access threat: a person who can interact with the device but should not have access to the vault’s content is blocked by the application-level credential.

The third layer is VaultBook’s per-entry AES-256-GCM encryption, which protects specific entries with cryptographic barriers that require entry-specific passwords independent of the application password. This layer addresses the selective access threat: a person who has legitimate access to the vault for general purposes but who should not have access to specific highly sensitive entries cannot access those entries without the entry-specific password, regardless of their vault-level credentials.

The fourth layer is VaultBook’s organizational and lifecycle controls - the label system that flags sensitive content for consistent handling, the expiry date system that ensures time-limited sensitive content is reviewed and purged rather than accumulated indefinitely, and the 60-day purge policy that ensures deleted entries are permanently removed after a defined retention window rather than remaining indefinitely in a recoverable state.

Each of these layers addresses a different threat vector and a different failure mode. Together, they constitute a security architecture that is technically defensible, professionally appropriate, and practically implementable within VaultBook’s local-first, offline-first environment. The architecture requires no external security infrastructure, no third-party services, and no complex configuration beyond the choices the user makes within VaultBook’s interface.

The Smart Features That Work Alongside Security

Security features are most valuable when they coexist comfortably with the productivity features that make the application worth using - when the protection does not come at the cost of the capability that justifies the application’s place in the professional workflow. VaultBook’s integration of per-entry encryption with its full AI and smart feature suite demonstrates that these requirements are compatible rather than in tension.

The AI Suggestions carousel’s pattern learning encompasses the user’s engagement with encrypted entries that have been unlocked in a session, building a model of the user’s reading and working patterns that includes the full vault content rather than only the unencrypted portion. The Suggestions page’s identification of the top three entries for the current day of the week reflects patterns across the entire vault, including encrypted entries that have been accessed in past sessions. This means that the personalized relevance surfacing that makes the AI Suggestions valuable is not degraded by the user’s choice to encrypt some entries.

The Related Entries feature’s contextual similarity analysis in VaultBook Pro similarly operates on the full vault content as it is available in the session state, including decrypted entries that have been unlocked during the current session. The relationships that the feature surfaces are relationships across the full intellectual content of the vault - the connections between an encrypted strategy document and the related case notes that surround it, the similarity between an encrypted patient entry and the clinical reference material it relates to, the conceptual links between encrypted client financial data and the market analysis that informs it. These connections are valuable precisely because they span the full vault, and they are available within VaultBook’s secure session model.

The Smart Label Suggestions feature, which analyzes entry content to suggest relevant labels from the existing label set, operates on the content of the entry being edited - including encrypted entries that the user has unlocked and is currently editing. Labels are organizational metadata rather than protected content, and the smart suggestions serve the organizational function of helping the user maintain consistent labeling practices across the vault without requiring manual recall of every label in the system.

The Typeahead Search and QA natural language search both operate over the vault content available in the current session, including the decrypted content of entries that have been unlocked. A user who has unlocked specific encrypted entries during a session can search across those entries’ content through both the typeahead interface and the full QA query interface, treating the unlocked encrypted entries as fully searchable content for the duration of the session. This session-scoped search availability means that the per-entry encryption protects content between sessions without reducing the search utility of the vault during sessions when the user has authenticated to access the protected content.

Why Per-Entry Encryption Changes the Security Conversation

The significance of VaultBook’s per-entry encryption feature is not just the feature itself but what it represents in the broader conversation about security in productivity software.

Most discussions of security in productivity tools are discussions about the security of the system’s perimeter - the application login, the encryption of data in transit, the vendor’s security certifications and compliance frameworks. These are legitimate and important security dimensions. But they are all discussions about the security of the boundary between authorized and unauthorized users of the system as a whole. They do not address the security of the content within the system relative to the users who have legitimate system access.

Per-entry encryption is a security feature that operates inside the perimeter rather than at it. It acknowledges that the set of people with legitimate access to the vault as a whole is not the same as the set of people who should have access to every entry within the vault - and that the difference between these two sets should be enforced by a technical control rather than relying on policy compliance or user discipline.

This is not a novel security concept. Multi-level security systems, need-to-know access controls, and tiered information classification have been standard practice in sensitive information environments for decades. What is novel is the implementation of these concepts within a local-first, offline, browser-based note-taking application that combines strong per-entry encryption with a comprehensive feature set, an intelligent AI layer, and a usability model that does not make security the enemy of productivity.

VaultBook’s per-entry AES-256-GCM encryption is the implementation of that combination - the security feature that makes VaultBook appropriate for the full range of sensitive professional information, from the content that requires vault-level protection to the content that requires entry-level cryptographic protection that even vault access cannot bypass. For the professionals whose work generates both categories of information - and that is most serious professionals in most regulated fields - this feature is not an optional enhancement to a note-taking application. It is the capability that makes VaultBook the right tool for the job.

Secure by architecture. Encrypted by standard. Private by design. VaultBook is built for the trust that professional work requires and the control that sensitive information deserves.