Skip to content

WarpSend security · verified against implementation

End-to-end encryption for files. WarpSignet authorization for endpoints.

When you send a file, you need to protect its contents and control which devices may access it. WarpSend uses encryption for supported file-transfer paths and WarpSignet signatures to authorize protected endpoint operations. The endpoint checks those signatures before carrying out the request.

Reviewed
Cryptography
AES-256-GCM · X25519 · Ed25519
Reviewer
Charlie, Co-founder

Two independent protection layers

Encryption protects the data. WarpSignet protects the command.

A secure transport does not prove that a cloud-issued command was authorized. WarpSend handles those questions separately, so an endpoint can reject an invalid instruction even when it arrived through an authenticated service.

Protects file content

End-to-end file encryption

WarpDirect uses X25519 and AES-256-GCM for supported endpoint transfers, and WarpSync Shuttle stages encrypted chunks and manifests. File Requests encrypt content before upload when the owner enables end-to-end encryption with WarpSignet. WarpShare encryption also depends on how the link was created: current password-protected browser uploads keep the decryption secret out of the service; endpoint-backed and legacy links use a different key path. The route details below explain those boundaries.

Protects endpoint control

WarpSignet endpoint authorization

An enrolled admin browser signs the exact intended operation with Ed25519. Explicitly issued, scoped, expiring automation tokens can sign delegated work. The endpoint verifies the signature against a public root pinned on that endpoint before it reads, writes, syncs, or sends protected data.

Cloud boundary

What the WarpSend cloud can see—and what it cannot silently authorize

Encryption protects file content on the paths described below. The service still processes operational metadata to authenticate accounts, route transfers, report status, and resume interrupted work. This section identifies what remains visible and what requires signed authorization.

The cloud does not receive or control

  • Plaintext for the end-to-end encrypted paths described on this page
  • Your WarpSignet passphrase or the unwrapped organization signing key
  • The endpoint’s locally pinned trust root, which the cloud cannot silently replace or disable

The service still processes

  • Account, endpoint, route, file-name/path/size, uploader-field, and delivery-status metadata where each workflow requires it
  • Encrypted key slots, signed authorization records, nonces, timestamps, and replay state
  • Staged file content: encrypted chunks and manifests on end-to-end encrypted routes, and service-managed content on routes without that protection

Endpoint authorization

How WarpSignet verifies an operation

WarpSignet is WarpSend’s endpoint authorization model. Its public signing root is pinned locally on each enrolled endpoint, so a cloud session, job record, endpoint token, or MCP credential is not enough by itself to create or broaden protected access.

  1. Unlock the signer locally

    The organization key is unwrapped in an enrolled admin browser. The passphrase is used only in that browser and is never sent to WarpSend; the cloud stores an encrypted key slot, not the passphrase or plaintext private key.

  2. Sign the exact intent

    Immediate requests bind the endpoint, protocol, request, timestamp, and nonce. Durable transfers, sync, and File Request delivery use signed exact task scopes and revisions, including the protected source and destination where applicable.

  3. Verify at the endpoint

    The endpoint verifies the signature, scope, freshness, revision, and replay state against its locally pinned public root. Missing, stale, changed, replayed, or invalid authorization is rejected before protected access.

  4. Keep automation usable and bounded

    Retries, resumable work, offline delivery, and scheduled sync can continue inside the already accepted scope. Explicitly issued automation credentials are scoped and expiring, so unattended work does not require a human prompt for every chunk or run.

Data-flow evidence

Four transfer methods, four explicit routes

The diagrams below are derived from the current WarpSend endpoint, browser, and cloud implementations. “Control plane” means authentication, coordination, policy, and status; “data plane” means the actual file payload.

File Requests

Collect files in a cloud inbox, with optional delivery to a computer or NAS.

Uploader browser → WarpFabric cloud inbox → owner download or optional endpoint delivery
  1. STEP 1 Uploader browser Selects files and follows the request’s access and encryption settings
  2. STEP 2 Upload preparation Encrypts content in the browser when end-to-end encryption is enabled
  3. STEP 3 WarpFabric cloud inbox Stores submissions and their upload and delivery status
  4. STEP 4 Request owner Downloads submissions or delivers them to a selected endpoint; encrypted content is decrypted by the recipient

Payload in the cloud

WarpFabric stores submissions for the owner to retrieve. Content is encrypted before upload when the request has end-to-end encryption enabled.

Encryption boundary

The owner chooses end-to-end encryption when creating the request; this requires WarpSignet. When enabled, the uploader browser uses X25519 and AES-256-GCM to encrypt content for the request owner, with a wrapped key for an authorized delivery endpoint when needed. Without it, files use TLS and service-managed storage and access controls. A request password controls access and does not enable content encryption.

  • The uploader needs no WarpSend account or app.
  • The owner can download submissions or choose an endpoint, Share, and folder for delivery.
  • Upload sessions can resume. Optional automatic delivery waits for the selected endpoint to reconnect when it is offline.
  • File names, paths, sizes, uploader fields, and delivery status are operational metadata visible to the service.
Explore File Requests 

WarpDirect

Move files directly between two WarpSend endpoints.

Source endpoint → direct peer tunnel → destination endpoint
  1. STEP 1 Source endpoint Reads an authorized Share and prepares encrypted transfer frames
  2. STEP 2 WarpSend control plane Authenticates endpoints and coordinates direct connectivity
  3. STEP 3 Direct peer tunnel Carries the file payload without cloud staging
  4. STEP 4 Destination endpoint Verifies and writes the received files

Payload in the cloud

The file payload is not stored in cloud object storage when the direct tunnel succeeds.

Encryption boundary

Current paired endpoints can derive transfer keys with X25519 and seal data frames with AES-256-GCM; the direct transport is also protected in transit.

  • The cloud control plane authenticates endpoints and coordinates connection setup; it is not the successful tunnel’s file-data path.
  • Automatic routing may switch a transfer to the resumable Shuttle path only after a typed direct-connectivity failure.
  • An explicitly requested Tunnel fails instead of silently changing the selected route.
  • Chunk progress and integrity checks support recovery from an interrupted transfer.
  • File and folder size is not capped by the direct workflow; WarpSend has tested a 500 GB single file and more than 50,000 files in one transfer.
  • Files do not need to be manually split, compressed, or prepared before transfer.
Explore WarpDirect 

WarpShare

Stage files once and send a browser download link.

Sender endpoint or browser → WarpFabric Global Delivery Network → recipient browser
  1. STEP 1 Sender Chooses content from an authorized endpoint Share or browser
  2. STEP 2 Upload path Optionally encrypts with the link password, then uploads to WarpFabric
  3. STEP 3 WarpFabric + access service Stores the object and issues controlled download access
  4. STEP 4 Recipient browser Downloads and, for protected links, derives the key and decrypts locally

Payload in the cloud

WarpFabric stores the link payload so the sender can go offline after upload.

Encryption boundary

Current password-protected browser uploads use the v2 key scheme: AES-256-GCM encrypts content before upload, recipients decrypt in their browser, and only a password verifier reaches the service. Endpoint-backed and legacy v1 links can encrypt content but send password or key material through the service, so password protection does not keep that decryption material out of the service. Links without a password use TLS and service-managed storage and access controls.

  • Recipients need no WarpSend account or app.
  • WarpFabric staging keeps the link available while the sender device is offline.
  • Large object uploads and downloads use multipart/range workflows with resume support.
  • Password protection is optional. Its encryption boundary also depends on whether the files came from a browser upload or an endpoint, and on the link’s key scheme.
  • WarpShare is billed by upload volume and can be used independently, with no UDP subscription required.
  • A link stays online for 7 days by default; paid plans can set up to 90 days, and it can be changed after the link is sent.
  • Multiple recipients and repeat downloads add no fees, and downloads have no plan speed cap.
Explore WarpShare 

WarpSync

Keep selected folders synchronized between endpoints.

Source scan → direct Tunnel or encrypted Shuttle staging → destination endpoint
  1. STEP 1 Source scanner Builds a manifest and identifies changed content
  2. STEP 2 Selected route Uses a direct Tunnel or encrypts chunks and a manifest for Shuttle
  3. STEP 3 WarpFabric (Shuttle only) Stores encrypted, content-addressed chunks and the encrypted manifest
  4. STEP 4 Destination endpoint Fetches missing chunks, decrypts, verifies, and applies changes

Payload in the cloud

Tunnel does not stage the payload; Shuttle stores encrypted chunks and an encrypted manifest in WarpFabric.

Encryption boundary

The Shuttle path derives a pair key, encrypts content-addressed chunks and the manifest, and lets the receiving endpoint decrypt and reconstruct the change set.

  • The sync engine scans the selected Share, computes a change set, and transfers only required data.
  • Tunnel is the direct endpoint path; Shuttle is the managed WarpFabric route for networks where staging is preferred or required.
  • Shuttle’s cloud manifest and chunks are encrypted; the receiving endpoint applies them locally.
  • Temporary writes are assembled and renamed into place to reduce partial-file exposure.
  • Sync pairs can automate one-way or two-way folder workflows between supported endpoints.
  • Scheduled and continuous workflows resume after interruptions and record run status in the control plane.
Explore WarpSync 

Security FAQ

Questions teams ask before trusting WarpSend

These answers use the same route-specific boundaries as the implementation review above.

Is WarpSend end-to-end encrypted?

Supported WarpDirect transfers and WarpSync Shuttle content are end-to-end encrypted as described above. File Requests have an end-to-end encryption option that requires WarpSignet. Current password-protected browser uploads to WarpShare use the v2 key scheme, which keeps the decryption secret out of the service. Endpoint-backed and legacy v1 share links send password or key material through the service; links without a password and File Requests without end-to-end encryption use TLS and service-managed storage and access controls.

What is WarpSignet?

WarpSignet is WarpSend’s endpoint authorization model. An enrolled signer or explicitly issued scoped automation credential signs the intended operation, and the endpoint verifies it against a locally pinned organization public root before protected access.

Can WarpSend read my files?

Where the end-to-end encrypted paths described here use cloud staging, the service stores ciphertext without the recipient decryption keys. This does not apply to every file: File Requests without end-to-end encryption and WarpShare links without a password use service-managed content storage. Endpoint-backed and legacy password-protected share links also send password or key material through the service. Operational metadata remains visible where the workflow needs it.

What if the cloud control plane is compromised?

A cloud session, job record, endpoint token, or MCP credential alone cannot produce a valid WarpSignet signature for a new or broader protected operation. This does not protect an already approved scope or a compromised signer or endpoint.

Does WarpSignet block scheduled or unattended transfers?

No. Retries, resume, offline delivery, and scheduled sync can reuse an accepted exact scope. Scoped, expiring automation credentials can authorize delegated work without prompting a person for every chunk or run.

Verified against implementation

This page was checked against the current WarpSend product source rather than only against marketing copy. The review covered:

  • Direct and Shuttle transfer routing
  • Share-link upload and browser receive paths
  • File Request cloud collection, optional end-to-end encryption, and optional endpoint delivery
  • WarpSync Tunnel paths and CAS-based Shuttle paths using WarpFabric managed staging
  • WarpSignet signing, exact task scopes, endpoint-side verification, replay handling, recovery, and pairing challenges

Security without blanket claims

Security depends on the selected route and controls. For WarpShare, check the upload source and link key scheme as well as password protection. For File Requests, check whether end-to-end encryption was enabled when the request was created. WarpSignet separately authorizes protected endpoint operations.

We do not describe WarpSend as unhackable, “military grade,” or universally zero knowledge. End-to-end encryption protects the listed content paths; it does not hide the operational metadata needed to run the service or replace endpoint security and account hygiene.

Explore WarpSend capabilities