Security & Cryptography

01 / PROTECTION MODEL

Several controls, each with a clear job.

LockBytes combines file encryption with a registered USB security layer. Optional Google Drive recovery is a separate path. Each control addresses a different part of the workflow.

Encrypted files

LockBytes uses AES-256-GCM for file encryption. Authenticated encryption is designed to detect changes to encrypted data.

Registered USB layer

A registered USB device adds a physical possession check to normal vault operations. It complements encryption and does not replace a strong unlock secret.

Optional recovery

Google Drive recovery is optional and depends on the account and configuration you choose. Review the recovery flow and privacy information before enabling it.

02 / CRYPTOGRAPHIC IMPLEMENTATION

See the cryptography behind LockBytes.

LockBytes uses established cryptographic primitives rather than proprietary encryption algorithms. The simplified example below demonstrates AES-256-GCM authenticated encryption and Argon2id-based key derivation.

PUBLIC EXAMPLE · PYTHON

How the encryption pipeline works

Illustrative processing flow

FILEOriginal fileInput data

CHUNK4 MB chunksBounded processing

AES-256-GCMAuthenticated encryptionConfidentiality + integrity

VERIFYAuthentication tagModification detection

.BURIEncrypted outputProtected file

Chunking, visually

A static example; no files are read, uploaded, or processed.

▧ example.jpg

Chunk 01Chunk 02Chunk 03Chunk 044 MB processing chunks

AES-256-GCM

Encrypted Chunk 01Encrypted Chunk 02Encrypted Chunk 03Encrypted Chunk 04

▧ example_XXXXXXXX.buri

Cryptographic implementation

PUBLIC EXAMPLE · SIMPLIFIED

Python

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from argon2.low_level import hash_secret_raw, Type
import os

AES_KEY_SIZE = 32
GCM_NONCE_SIZE = 12

def generate_encryption_key():
    """
    Generate a cryptographically secure 256-bit AES key.
    """
    return os.urandom(AES_KEY_SIZE)

def generate_nonce():
    """
    Generate a fresh 96-bit nonce for AES-GCM.
    """
    return os.urandom(GCM_NONCE_SIZE)

def encrypt_data(data: bytes, key: bytes) -> bytes:
    """
    Encrypt and authenticate data using AES-256-GCM.
    """
    aesgcm = AESGCM(key)
    nonce = generate_nonce()

    ciphertext = aesgcm.encrypt(
        nonce,
        data,
        None
    )

    # The nonce is not secret and can be
    # stored alongside the ciphertext.
    return nonce + ciphertext

def decrypt_data(
    encrypted_data: bytes,
    key: bytes
) -> bytes:
    nonce = encrypted_data[:GCM_NONCE_SIZE]
    ciphertext = encrypted_data[GCM_NONCE_SIZE:]

    aesgcm = AESGCM(key)

    return aesgcm.decrypt(
        nonce,
        ciphertext,
        None
    )

def derive_key_from_password(
    password: str,
    salt: bytes,
    time_cost: int = 3,
    memory_cost: int = 65536,
    parallelism: int = 4,
) -> bytes:
    return hash_secret_raw(
        secret=password.encode("utf-8"),
        salt=salt,
        time_cost=time_cost,
        memory_cost=memory_cost,
        parallelism=parallelism,
        hash_len=AES_KEY_SIZE,
        type=Type.ID,
    )

Public Example — Simplified

This example demonstrates the cryptographic primitives used by LockBytes. It is intentionally simplified for transparency and education. The production application contains additional file-format handling, validation, key management, recovery logic, and platform-specific security controls.

Cryptographic security depends not only on the algorithm, but also on correct key management, nonce management, implementation, operating-system security, and the user's overall security environment.

This displayed code is a simplified public example, not the complete production source code.

AES-256-GCM

AES-256-GCM provides authenticated encryption using a 256-bit key. In addition to protecting confidentiality, GCM provides authentication that allows modified ciphertext to be detected.

Fresh nonces

AES-GCM requires nonce uniqueness when used with the same key. LockBytes uses nonce construction appropriate to its chunked encryption workflow.

Argon2id

Passwords are not used directly as AES keys. Argon2id derives 256-bit key material using a salt and configurable computational and memory parameters.

Password-based key derivation

Illustrative Argon2id flow

User password

Random salt

Argon2id

256-bit key material

AES-256-GCM

Protected key material

TIME COST3

MEMORY COST64 MiB

PARALLELISM4

DERIVED KEY256-bit

These are the parameters demonstrated in this public example. Cryptographic parameters should be selected according to the application's threat model, platform capabilities, and security requirements.

KEY PROTECTION

Keys are protected separately from file contents.

This architectural illustration shows two conceptual protection paths. It contains no real key material or production secrets.

Master Key illustrative only

Password-based protection↓Argon2id↓AES-256-GCM

Recovery protection↓Recovery key material↓AES-256-GCM

03 / KEY HANDLING

Keys are the critical material.

Encryption protects data only while the relevant key material remains unavailable to an attacker. Protect your account, device, unlock credentials, and any recovery method.

Keep credentials private

Do not share passwords, recovery information, or authentication codes. Avoid storing them beside the files they protect.

Protect the running device

Malware or an attacker with access to an unlocked computer may capture plaintext or credentials while you work.

Make a recovery plan

Understand what you need to regain access before relying on an encrypted vault. Test recovery with noncritical data first.

04 / USB SECURITY LAYER

Physical possession adds a check.

LockBytes includes a registered USB security layer for normal vault operations. Keep the registered device under your control and maintain a safe plan if it is lost or damaged.

REGISTEREnroll device

Register the intended USB device through LockBytes.

CONNECTPresent device

Connect the registered device when the workflow requires it.

CHECKValidate access

The security layer checks for the registered device.

OPERATEUse the vault

Continue only through the application's permitted workflow.

CAREKeep it safe

Protect the USB device and use the documented recovery options.

A USB check is not a substitute for encryption, endpoint security, or a backup. Anyone who can use an already unlocked device may still access available plaintext.

05 / RECOVERY

Recovery changes the access story.

Optional Google Drive recovery can help restore access under the configured recovery process. It introduces an online account and service into the recovery path.

Opt in deliberately

Choose whether to configure recovery and understand what data is involved by reading the current privacy policy and in-app explanations.

Secure your Google account

Use a unique password and multifactor authentication where available. Account compromise can affect services tied to that account.

Check that recovery works

Keep recovery details current and confirm you can complete the process before depending on it for important files.

Cloud recovery is not the same as a local-first workflow. Availability and behavior can depend on Google services, connectivity, account access, and LockBytes configuration.

06 / DATA FLOW

Know where data may travel.

Normal vault operations are described as local-first. Optional online features have their own data flows and service dependencies.

Simplified operating pathsConceptual diagram

Local file → LockBytes on Windows → encrypted output
                         │
                         ├─ registered USB check for vault operations
                         │
                         └─ optional recovery setup → Google Drive / account services

This diagram is a high-level guide, not a network trace. For exact collection and processing details, consult the privacy policy and the application's current documentation.

07 / THREAT MODEL

What the layers help address.

Security depends on the attacker's access and the state of your device. These examples are deliberately bounded.

Lost storage device

Encrypted files can help protect contents when a storage device is lost, provided the keys and credentials remain protected.

Unauthorized vault operation

The registered USB layer adds a possession check to the supported workflow. It does not defeat a compromised or unlocked computer.

Compromised endpoint

Malware, keyloggers, or privileged access can expose files while they are open. Encryption at rest cannot fully protect an infected active device.

08 / BOUNDARIES

Good security includes honest limits.

LockBytes focuses on protecting files through encryption and its supported access workflow. It is not a complete endpoint defense or a replacement for backups.

Situation	What to understand
File is open	Plaintext may be available to the operating system, applications, or an attacker controlling the device.
Weak or exposed credentials	Anyone who obtains valid access information may undermine protections that depend on it.
Lost USB device	Follow the documented recovery process; possession checks do not replace a recovery plan.
Device failure or deletion	Encryption does not preserve data. Maintain separate backups and verify they can be restored.
Cloud account compromise	Optional recovery can depend on account security and third-party service availability.

09 / PRACTICAL SECURITY

Small habits make the design work better.

Protect the whole workflow: the files, computer, credentials, USB device, and recovery path.

Get releases from the official page

Use the LockBytes download page and review release details. Verify checksums when they are provided.

Keep Windows protected

Install security updates, use reputable endpoint protection, and lock the screen when you step away.

Back up separately

Keep protected backups in a separate location and periodically test restoring them.

Use unique credentials

Use a password manager and do not reuse passwords across your Windows, Google, and other accounts.

Handle plaintext carefully

Close files when finished and consider temporary files, exports, and copies created by other applications.

Review recovery settings

Understand what is enabled and keep account recovery methods current and protected.

10 / SUMMARY

A layered tool with explicit boundaries.

LockBytes combines AES-256-GCM file encryption and a registered USB security layer for Windows workflows, with optional Google Drive recovery. The security outcome still depends on sound key handling, a protected device, and a recovery plan.

Read the privacy policy

Understand the data flows and optional services before enabling connected features.

Privacy Policy →

Review the software terms

See the license and use terms that apply to LockBytes.

Terms of Use →

Get the official release

Download LockBytes for Windows from the project download page.

Download LockBytes →

Security & Cryptography

Several controls, each with a clear job.

Encrypted files

Registered USB layer

Optional recovery

See the cryptography behind LockBytes.

How the encryption pipeline works

Chunking, visually

Cryptographic implementation

AES-256-GCM

Fresh nonces

Argon2id

Password-based key derivation

Keys are protected separately from file contents.

Keys are the critical material.

Keep credentials private

Protect the running device

Make a recovery plan

Physical possession adds a check.

Recovery changes the access story.

Opt in deliberately

Secure your Google account

Check that recovery works

Know where data may travel.

What the layers help address.

Lost storage device

Unauthorized vault operation

Compromised endpoint

Good security includes honest limits.

Small habits make the design work better.

Get releases from the official page

Keep Windows protected

Back up separately

Use unique credentials

Handle plaintext carefully

Review recovery settings

A layered tool with explicit boundaries.

Read the privacy policy

Review the software terms

Get the official release

Protect files with a clearer model.