How Bit-Sign verification works
Bit-Sign creates a verifiable identity token by combining a HandCash cryptographic handshake with multi-factor evidence — passport photos, video statements, and hand-drawn signatures.
This identity token is portable and uniquely yours. It serves as an on-chain root for secure commit signing, IP registration, and document verification.
Hashing, key derivation and document locking all happen in your browser — keys never leave it. When a document is encrypted, Bit-Sign only ever receives ciphertext and cannot read it.
Encryption is something you switch on: set up document encryption from your dashboard first. Documents shared before then are stored unencrypted, which means we can read them. Chat messages are not encrypted.
We use the HandCash SDK to trigger signing requests. Your signature locks and unlocks your secure assets on the Bitcoin SV blockchain.
When you authorize Bit-Sign via HandCash, we request the following permissions:
Bit-Sign encrypts shared documents in your browser before upload, so they can only be read by the recipients you choose — not by other users, and not from a stolen database.
What this does not yet protect against
This is not end-to-end encryption against Bit-Sign itself. Your private key is protected by a signature that our server currently produces on your behalf, so the operator retains the technical ability to decrypt your documents. Chat messages and room contents are not encrypted at all and are stored in readable form.
We are changing this — moving key custody into your own wallet, encrypting room contents, and publishing recoverable instruments on-chain. Until that ships, treat Bit-Sign as a platform you trust rather than one that cannot read your data, and do not put anything here you would not put in a hosted inbox.
Each user generates an ECDH P-256 keypair in their browser. The public key is stored on the server for sharing. The private key is encrypted (AES-256-GCM) before backup, so it is never stored in the clear.
The key that protects it is derived from a HandCash signature that our server produces, which means the operator can currently reproduce it. Moving this into your own wallet is the next change.
Each document is encrypted with a random AES-256-GCM envelope key. The envelope key is then wrapped for each authorized recipient using ECDH key agreement (with HKDF derivation and AES-KW wrapping). One encrypted document, multiple key wrappings.
To share a document: enter the recipient's HandCash handle → their public key is fetched → ECDH key agreement produces a shared secret → the envelope key is wrapped with that secret → the recipient unwraps and decrypts. The server transports ciphertext and does not handle the plaintext in this flow.
The server stores encrypted document blobs, encrypted private-key backups, public keys and wrapped key grants. An outside attacker who stole the database would not be able to read encrypted documents from it.
The operator is a different question. Because the server can produce the signature that protects your private key, it can decrypt what that key opens. Room messages, uploaded files and contract text are separate from this system and are stored readable.
Your private key is backed up on the server, encrypted with a key derived from a HandCash signature over a fixed challenge. This means:
Important
We never store your signatures or private keys in plaintext. Bit-Sign is an interface. Your data lives on the blockchain; your keys stay in your wallet. If you lose access to your HandCash account, you lose access to your encrypted documents and your E2E private key. There is no password reset.