Security & Privacy

ByteSync is designed as a secure, zero-knowledge synchronization system.

This page provides a clear, technical overview of how the application protects data, identities, and communication between clients.
It summarizes the core principles of ByteSync’s security model and explains why the server cannot access any meaningful information about your files, folders or session activity.

For an in-depth technical specification, see the
Client Security Architecture document on GitHub:
https://github.com/POW-Software/ByteSync/blob/master/docs/client-security-architecture.md

1. Security Model Overview

ByteSync uses modern, well-established cryptographic standards to ensure that only authorized clients can participate in a synchronization session and access its content.

Key principles include:

  • End-to-end encryption for all metadata, session information and file contents
  • Zero-knowledge server: the cloud relay cannot decrypt or interpret any data
  • Trusted Clients system to verify identities and prevent impersonation
  • Per-session encryption keys, never shared with the server
  • Cryptographic isolation between clients across all sessions

ByteSync is built so that security does not depend on the cloud infrastructure.
Even if the server is compromised, encrypted data remains unreadable.

2. Encryption Overview

ByteSync combines asymmetric and symmetric cryptography:

2.a. Asymmetric cryptography (RSA-2048)

Used for:

  • Client identity
  • Public key exchange
  • Digital signatures
  • Secure delivery of session secrets

Every client generates an RSA-2048 key pair on first launch.
The server only knows two things about a client:

  1. Its IP address
  2. Its RSA public key

Nothing else about the client is stored or inferred.

2.b. Symmetric cryptography (AES-256)

Used for:

  • Session encryption
  • Metadata encryption
  • File transfer encryption
  • Local storage protection

Each synchronization session receives a unique AES-256 key, shared securely between participants.
The server never receives this key.

2.c. Hashing

ByteSync uses:

  • SHA-256 for client identifiers, metadata integrity and session-level hashing
  • SHA-512 for cryptographic binding inside signatures
  • MD5 only for human-readable out-of-band verification (not for security)

3. Trusted Clients

ByteSync uses a decentralized trust model called Trusted Clients.

Instead of a central certificate authority, each user confirms the identity of other clients through an out-of-band verification step.

How it works

  1. Two clients exchange their RSA public keys (via the server).
  2. Both compute a shared Safety Key, derived from:
    – Their RSA public keys (SHA-256)
    – A random session salt
  3. Users compare the Safety Key out-of-band (phone call, chat, etc).
  4. If the values match, the public key is stored locally as trusted.

Once trusted, a client can join future sessions without repeating the verification step.

Benefits

  • Prevents man-in-the-middle attacks
  • Prevents the server from injecting rogue keys
  • Ensures long-term client identity stability
  • Keeps trust fully under the user’s control

4. Zero-Knowledge Server

ByteSync’s cloud backend acts only as a relay and orchestrator.
It cannot read, interpret, or reconstruct any data exchanged between clients.

The server does NOT know:

  • File names
  • Directory structures
  • File contents
  • Machine names
  • Data sources or paths
  • Session metadata
  • Actions performed by members

It only sees:

  • Encrypted session blobs
  • Encrypted file slices
  • SHA-256 hashes when required to route encrypted content
  • IP addresses
  • RSA public keys

All meaningful information is encrypted client-side before transmission.

Why the server cannot decrypt anything:

  • It never receives AES session keys
  • It cannot derive session passwords
  • It cannot impersonate a client (thanks to Trusted Clients)
  • It stores encrypted blobs with no ability to interpret them

This architecture ensures confidentiality even in the event of a server compromise.

5. Encrypted File Transfers

All file transfers are end-to-end encrypted using AES-256-CBC.

Characteristics:

  • Files are encrypted on-the-fly before upload
  • Decryption occurs only on the recipient’s machine
  • Each file has a unique initialization vector (IV)
  • Transfers use encrypted slices, never exposing plaintext
  • Server handles only opaque encrypted data

Since names, paths and metadata are also encrypted, the server does not even know which file is being transferred, or how many.

Summary

ByteSync provides a secure, zero-knowledge synchronization environment based on:

  • RSA-2048 identities
  • AES-256 encrypted sessions and file transfers
  • Trusted Clients to prevent impersonation
  • Out-of-band verification for first-time trust
  • Strong hashing (SHA-256 / SHA-512)
  • Encrypted metadata and file names
  • A relay server with no ability to decrypt or interpret data

For a deeper cryptographic breakdown, key lifecycle details, and protocol diagrams, see the official technical document:
https://github.com/POW-Software/ByteSync/blob/master/docs/client-security-architecture.md

Next Article

Application settings