Secure Sharing
Share certified digital assets with anyone — without compromising your encryption. Grant read-only access to specific versions of your files while keeping full control.
Beta: Secure Sharing is currently in beta. The core encryption and access control are fully functional, but some features (multi-recipient sharing, bulk sharing, blockchain-anchored audit trails) are still in development.
When to use Secure Sharing
Share certified content with third parties without handing over your account or losing control of your files.
Legal proceedings
Share a certified revision with opposing counsel or a court. Attach terms and conditions they must accept before viewing.
Due diligence
Let an auditor, investor, or partner review certified documents with a full audit trail of who accessed what and when.
Client delivery
Send final deliverables to a client with proof of the certification timestamp.
Insurance claims
Disclose certified evidence to an insurance provider with controlled, time-limited access.
Collaboration review
Give a colleague or external reviewer read-only access to a specific version, without sharing your vault credentials.
Choose your sharing mode
Both modes use the same end-to-end encryption. The only difference is how the decryption key reaches the recipient.
Keycard (Zero-Knowledge)
The most secure option. Bernstein generates a PDF keycard containing a unique access key. You deliver it to the recipient yourself — through any channel you trust. The decryption key never touches Bernstein's servers.
How it works for the recipient:
- 1You send them the keycard (outside of Bernstein) along with the share URL.
- 2They open the share URL in their browser.
- 3They request a verification code sent to their email.
- 4They enter the 6-digit code to prove their identity.
- 5They enter the access key from the keycard.
- 6If terms are attached, they review and accept them.
- 7The content decrypts in their browser — files are viewable and downloadable.
Direct Share
The convenient option. Bernstein sends the recipient an email with a secure link. The decryption key is embedded in the URL fragment, which by design is never stored on the server — it stays entirely in the browser.
How it works for the recipient:
- 1They receive an email with a link.
- 2They click the link and request a verification code.
- 3They enter the 6-digit code to prove their identity.
- 4If terms are attached, they review and accept them.
- 5The content decrypts in their browser — files are viewable and downloadable.
Choosing between the two
Both modes are end-to-end encrypted. Choose based on your security requirements and convenience needs.
| Keycard (Zero-Knowledge) | Direct Share | |
|---|---|---|
| Key delivery | You deliver it yourself (PDF keycard) | Embedded in email link |
| Convenience | Requires a separate handoff step | One-click from email |
| Server exposure | Key never touches any server | Key passes through email but is never stored by Bernstein |
| Best for | High-sensitivity content, regulated industries, maximum control | Day-to-day sharing, non-technical recipients, speed |
Rule of thumb: Use Keycard when the content is highly sensitive and you want to control every step of the key handoff. Use Direct Share when convenience matters and email delivery is acceptable.
How the encryption works
Bernstein uses a two-layer key model for sharing, built on AES-256-GCM encryption via the Web Crypto API.
DEK (Data Encryption Key)
The symmetric key (AES-256-GCM) that encrypts your revision's content. This is the same key used when you originally certified your files. It lives in your browser's encrypted vault and is never sent to the server in plaintext.
KEK (Key Encryption Key)
A fresh symmetric key (AES-256-GCM) generated in your browser when you create a share. The KEK encrypts (wraps) the DEK, producing a wrapped DEK that can only be unwrapped by someone who holds the KEK.
When you create a share
Generate keys
Your browser generates a random Key Encryption Key (KEK) and loads your revision's Data Encryption Key (DEK) from your encrypted vault.
Wrap DEK
The DEK is encrypted with the KEK, producing a wrapped DEK that is stored on the server.
Deliver KEK
In Direct Share mode, the KEK is embedded in the email link fragment. In Keycard mode, it is embedded in a PDF generated in your browser — never sent to the server.
When the recipient opens a share
Retrieve wrapped DEK
The recipient's browser fetches the encrypted wrapped DEK from the server.
Unwrap DEK
Using the KEK (from the URL fragment or keycard), the browser unwraps the DEK.
Decrypt content
The DEK decrypts the revision metadata and file contents. All decryption happens client-side — the server never has access to the plaintext.
Identity verification
Before any content is delivered, the recipient must prove they control the email address specified in the share.
Access controls
Configure exactly how and when your shared content can be accessed.
Expiration date
The share becomes inaccessible after this date. Leave empty for no expiration.
Terms & conditions
Add legal terms the recipient must explicitly accept before viewing the content.
Instant revocation
Revoke any active share at any time. The recipient immediately loses access — even if their session is still valid.
Max opens
Limit how many times the content can be viewed.
Max downloads
Limit how many file downloads are allowed.
Watermark previews
Display a watermark on previewed files for added protection.
Complete audit trail
Every share generates a full event log. For shares with verifiable audit enabled, events are chained using SHA-256 hashes, creating a tamper-evident log.
Each event records the recipient's IP address and user agent. You can export the complete audit log as JSON.
Frequently asked questions
The share is locked to the recipient's email address. Even if someone else obtains the link, they cannot pass the OTP verification step because the code is sent to the original recipient's email. In Keycard mode, they would also need the keycard.
No. The server stores only the encrypted wrapped DEK and the encrypted file blobs. Without the KEK (which the server never retains), the content cannot be decrypted. In Keycard mode, the KEK never even reaches the server.
Their current session is immediately invalidated. Any subsequent content or download requests will be denied. Content already decrypted in their browser remains accessible until they close the tab, but no new data can be fetched.
Currently, each share targets one recipient. To share with multiple people, create a separate share for each. Multi-recipient sharing is on the roadmap.
You'll need to create a new share and generate a new keycard. Each keycard contains a unique key tied to a specific share — there is no way to recover or regenerate a lost keycard.
Once the recipient verifies their OTP, their session is valid for 24 hours. After that, they need to re-verify with a new OTP to continue accessing the content.
AES-256-GCM for key generation and DEK wrapping (via Web Crypto API), AES-256-GCM with per-part initialization vectors for file encryption, cryptographically secure random 6-digit OTP codes, and SHA-256 hash linking for verifiable audit chains.
No. Sharing is tied to a specific revision — a certified snapshot of your project. You must have at least one certified revision to create a share.