Cryptography detailed description

Introduction

The corporate password manager Passwork is based on the zero-knowledge principle (Zero Trust), which guarantees complete confidentiality of user data. The system is designed for secure storage and sharing of passwords within an organization, while the passwords themselves are inaccessible to both the server and third parties.

The solution architecture is divided into client and server parts, with all critically important cryptographic operations performed exclusively on the client side. This means that secret data is encrypted before being transmitted to the server and stored in the database only in encrypted form.

To ensure reliability, a two-level protection model is applied:

• Client-side encryption (End-to-End Encryption) eliminates the possibility of the server obtaining passwords in plaintext.
• Server-side encryption adds an additional layer of security: even data already encrypted on the client side undergoes re-encryption before being saved in the database.

This approach guarantees maximum protection: even if the server or database is compromised, passwords remain inaccessible because decryption without client keys is impossible.

Zero-knowledge cryptographic model

Zero-knowledge principle

The zero-knowledge principle means that the server does not have enough information to decrypt user data. The model is based on a master password known only to the user. During registration or login, it is never transmitted to the server or stored in plaintext. Instead, the master password is used on the client side to generate a cryptographic master key.

The master key is generated using the PBKDF2 (Password-Based Key Derivation Function) algorithm, which uses a combination of the master password, a random salt, and a large number of iterations. A large number of iterations slows down each brute-force attempt and significantly complicates such attacks, thereby increasing the strength of the master key. The resulting master key becomes the root of trust for all subsequent cryptographic operations.

Generation and use of RSA keys

After creating the master key, a unique pair of asymmetric RSA keys is generated for each user:

• The private key is encrypted on the client side using the master key and stored on the server only in encrypted form. Access to it is possible exclusively by the user after entering the master password;
• The public key contains no secret information and is stored in plaintext. It is used for exchanging key information between users when granting shared access.

Vaults (Virtual storages)

Passwords are grouped into special vaults — virtual storages with their own symmetric keys.

• The vault key is created on the client at the moment of its creation.
• All passwords inside the vault are encrypted with this key.
• When granting access to other users, the vault key is encrypted separately for each of them using their public RSA key.

Thus, each authorized user receives their own copy of the vault key, which can only be decrypted with their personal private key.

Multi-level password protection

For additional security, each password entry is encrypted with a separate AES key (AES-256).

• A unique symmetric key is generated for each password or secret.
• It is used to encrypt the content (login, password, notes, etc.) on the client side.
• Then this AES password key is encrypted with the vault key.

As a result, a multi-level hierarchy is formed:

1. password data is encrypted with its AES key;
2. the AES password key is encrypted with the vault key;
3. the vault key is encrypted with the public RSA keys of users who have access.

This scheme provides maximum protection: the server and external attackers cannot access secrets without knowing the master password and corresponding keys.

Key generation and management

Sources of entropy

The quality of random numbers plays a key role in system security. All cryptographic keys are generated using attack-resistant pseudorandom number generators.

• On the client side, standard tools are used: the built-in Web Crypto API generator in browsers, native application functions, or cryptographic libraries.
• On the server side, if necessary, OpenSSL or similar solutions are used to ensure cryptographic strength.

Random values are used for salt in PBKDF2, symmetric AES keys, and RSA key pairs. Thanks to the use of reliable entropy sources, predictability of results is excluded.

---

Key specifications

The system uses modern and proven algorithms:

• AES-256 for symmetric encryption,
• RSA-2048 for asymmetric operations.

These parameters meet high security standards and are considered sufficient for protecting confidential information today.

• RSA keys (2048 bits) are generated on the client side during user registration. The private key is immediately encrypted with the master key (or password) and only transmitted to the server in this form. The public key is stored in plaintext and used to organize encrypted data exchange. Key generation is a resource-intensive operation, so it is performed once and the result is reused.
• AES keys (256 bits) are created anew for each action requiring a new key: when creating a vault or a new password entry. These keys are completely random and are not derived from the user's password, ensuring independence and high entropy. They are never stored on the server in plaintext: either encrypted by another key or existing only in the client's memory during the session.

---

Storage and distribution of keys

• Private RSA keys are stored on the server only in encrypted form (AES encryption with a key derived from the master password).
• Public RSA keys are saved in the user's profile and used by other participants to encrypt shared secrets.
• Vault keys (AES-256) are stored together with metadata, but for each user in the system, a separate encrypted copy is created, encrypted with their public RSA key.
• Keys of individual password entries (AES-256) never leave the client application in plaintext: they are either encrypted with the vault key or embedded in the overall encrypted data block.

Thus, the system builds a multi-level key hierarchy, ensuring isolation, secure storage, and strict access control through cryptography.

Main cryptographic processes

User authentication

When logging into the system, the user enters the master password. On the client side, a master key is derived from it using PBKDF2 (with individual salt and a specified number of iterations). This master key is used to decrypt the private RSA key: the encrypted key is loaded from the server and decoded locally.

If the password is correct, decryption completes successfully, and the user gains access to their private key. Essentially, the ability to decrypt one's own private key confirms authenticity. The server indirectly verifies correctness (for example, by comparing the hash of the master key with the stored value), but never learns the password itself. Thus, the login process does not reveal secrets to the server, and the user gains access to their keys for further work.

Access to the vault

To open a vault (virtual password storage), the user must obtain its key. In the database, the vault key is stored as several encrypted copies — one for each participant. The application selects the copy encrypted with the public key of the specific user and decrypts it locally using their private RSA key.

As a result, the original symmetric vault key (AES-256) is obtained, which encrypts the content. Importantly, the server never sees either the safe vault in plaintext or the user's private key. After decrypting the vault key, the client can access all passwords inside it or individual entries if an additional encryption layer is used.

Multi-level password encryption

When creating or modifying a password on the client side, several protection layers are applied:

1. Encryption of the entry content — a new random AES key (entry key) is generated, which encrypts the password data (password, all custom fields, file attachments, revisions) using AES-256-CBC mode with a unique IV.
2. Encryption of the entry key — the AES entry key itself is encrypted:
   • either with the vault key (if the entry is inside a vault),
   • or with the public key of a specific user (if sharing just this password without granting access to the vault).

Thus, a hierarchy is formed:

• password data is protected by the AES entry key,
• the entry key is protected by the vault key or the user's RSA key.

When reading the entry, the process unfolds in reverse order: first, the client decrypts the entry key (via the vault key or their private RSA key), then uses this key to decrypt the password itself. Thanks to this scheme, each user receives individual access, and multi-level AES encryption ensures that compromising one level does not reveal the others.

Password sharing between users

Password transfer between users is carried out according to the zero-knowledge principle. When sharing an entry, the owner's client encrypts the AES entry key (or the vault key if sharing the entire storage) with the recipient's public RSA key.

Scenario: user A shares a password with user B.

• Client A takes the entry key and encrypts it with B's public key.
• The resulting encrypted copy is saved on the server and linked to user B.
• Upon synchronization, client B receives this key, decrypts it with their private RSA key, and gains access to the data.

The server acts only as an intermediary: it stores and transmits encrypted keys but cannot decrypt them. Thus, multiple users can safely work with the same passwords, but each receives keys strictly in an individual and protected form.

Algorithm technical specifications

PBKDF2 (Password-Based Key Derivation Function 2)

To derive a key from the master password, the PBKDF2 algorithm with HMAC-SHA256 is used. During registration, each user is assigned a unique cryptographic salt (usually 128 bits or more). The salt is stored in the user's profile on the server and is not secret but prevents dictionary attacks and the use of precomputed hash tables.

When entering the password, PBKDF2 is executed on the client side: the combination master password + salt is repeatedly processed through HMAC-SHA256 (the system uses 300,000 and 600,000 iterations; the parameter can be changed). The higher the number of iterations, the slower each brute-force attempt, significantly increasing resistance to brute-force attacks.

The result of PBKDF2 is a master key of 256 bits or more (for example, 32 or 64 bytes depending on system settings). This master key becomes the root of trust: it is used to encrypt the private RSA key and other cryptographic operations.

It is important that PBKDF2 parameters (salt, iteration count, and even key length) are not fixed: they can change along with security policies. When changing the master password or updating parameters, the key is recalculated and related data updated.

RSA-2048

Asymmetric RSA keys of 2048 bits are used to protect symmetric keys and distribute secrets among users. This key size balances security and performance and is considered sufficient for corporate systems.

• RSA public keys are stored openly and used by other users to encrypt shared data.
• RSA private keys are never stored in plaintext: after generation, they are encrypted with AES-256 using a key derived from the master password. Only the encrypted PEM block (PKCS#8 or similar) is sent to the server. Even an administrator with database access sees only "garbage."

Decryption is performed locally on the client after successful password entry. Cryptographic operations use RSAES-PKCS#1 v1_5 (PKCS#1 v1.5 padding) or another standard mode depending on the library used. RSA is used only for small data (keys), not for direct encryption of large data arrays.

AES-256 (CBC mode)

For symmetric encryption, the system uses AES with a 256-bit key in CBC (Cipher Block Chaining) mode.

• For each encryption, a random 128-bit IV (initialization vector) is generated, preventing repetition of identical encrypted blocks.
• Data is padded to the block size (128 bits) using PKCS#7 padding.
• The IV is stored together with the ciphertext (in plaintext), allowing correct decryption.

AES-256 is applied on the client side to protect user passwords and private RSA keys, and on the server side for an additional data protection layer before storage. CBC mode is chosen for its predictability and proven reliability, provided the IV is handled correctly.

Base64/Base32 encoding

Since keys and ciphertexts are binary data, text encoding is used for storage and transmission.

• Base64 is used to convert binary data into ASCII strings (e.g., when storing encrypted data in the database or transmitting via JSON API).
• In some cases, additional re-encoding to Base32 is used, which facilitates transmission in environments sensitive to case or characters (+/= from Base64).

Base32 uses a limited alphabet (A–Z and 2–7), excluding potentially problematic characters. Encoding does not add cryptographic strength but ensures integrity and convenience during transmission.

Hash function migration

The system architecture provides the ability to replace hash functions and change their parameters (number of iterations, key length, use of new salt types).

The migration mechanism works gradually and transparently for users:

• upon login with the current master password, the system recalculates the master key using new parameters;
• old hashes and keys are updated automatically;
• user operation is uninterrupted.

Thus, the system can adapt to cryptographic developments and maintain an up-to-date security level without requiring changes in user habits.

Server-side encryption

In addition to client-side encryption, the system implements an additional protection layer — server-side encryption of data before saving to the DBMS. This means that data encrypted on the client side, arriving at the server, undergoes re-encryption using a server key before being written to the database.

The mechanism is implemented based on AES-256 (CBC mode with a new IV) via the OpenSSL library. The server has its own symmetric key (or a set of keys) used to encrypt database fields. As a result, the DBMS stores data protected by two layers: first client-side, then server-side.

Configuration flexibility

Administrators can configure server-side encryption through the application configuration file. It is possible to select a specific algorithm from those supported by OpenSSL (e.g., AES-256, GOST, and others). This allows organizations to choose the optimal option depending on corporate security standards and performance requirements.

Purpose and role

The main goal of server-side encryption is to create an additional barrier in case an attacker gains direct access to the database or its backups. Even in the unlikely event that data ends up on the server without client-side encryption (e.g., due to an error), server-side encryption ensures that plaintext is never stored in the database.

At the same time, the zero-knowledge principle is not violated: the server still has no access to the original passwords, as it only encrypts data already encrypted by the client. In case of database compromise, the attacker faces double protection: first server AES encryption, then client encryption, whose keys are also inaccessible.

Infrastructure security

In addition to cryptographic data protection, the system pays special attention to network communication and environment security. All interactions between client and server are carried out exclusively over secure channels using the HTTPS protocol (TLS version 1.2 or 1.3). This guarantees protection against interception or data tampering during transmission and reliably prevents Man-in-the-Middle attacks.

Additional TLS protection is applied to internal integrations as well: server connections to external systems (e.g., LDAP or database) also occur over encrypted channels. This approach ensures confidentiality and data integrity even within the corporate network.

The solution is delivered as a locally installable application (on-premise). The organization deploys the Passwork server within its own infrastructure and gains full control over security parameters. This allows using the system in environments with heightened requirements, including fully closed network contours without internet access.