Every value entered during signing
- Signatures and initials
- Names, dates, and text entered into fields
- Banking, tax, or identification information
- Any other value entered during signing
Security
Zero-knowledge e-signatures, without giving up the agreement workflow.
Every value entered during signing is encrypted in the browser before it reaches Inklok. We can operate the agreement workflow, but we do not hold the private key needed to independently decrypt what participants enter.
Client-side encryption
Signing data is encrypted before upload.
The encryption boundary begins in the participant's browser. Values are encrypted before they are transmitted to Inklok.
What reaches Inklok
Inklok receives encrypted signing values rather than readable plaintext.
Those encrypted values can be stored and moved through the agreement workflow without giving Inklok an independent key that can decrypt them.
The security boundary
What Inklok can see.
Zero-knowledge encryption does not prevent Inklok from operating the agreement itself. We still need normal workflow information to run the service.
Inklok can access
- The original agreement PDF
- Templates and workflow configuration
- Participant names and email addresses
- Signing order and agreement status
- Permissions
- Audit and workflow events
We use that information to
- Route agreements between participants
- Manage signing order and permissions
- Send notifications
- Track agreement status
- Maintain audit and workflow history
This is what lets Inklok behave like a normal e-signature platform while keeping the values participants enter behind a separate cryptographic boundary.
Zero-knowledge
What we don't have is a spare key.
Values entered during signing are stored in encrypted form. Inklok does not hold an independent private key that lets us decrypt them.
Decryption requires authorization
Reading a completed signing value requires cryptographic identity material belonging to a participant who is authorized to access it.
Inklok cannot substitute itself
The application server cannot simply retrieve a master key and decrypt signing values on its own.
The people involved in the agreement keep cryptographic control of what they enter.
Why it matters
Encryption at rest is not the same thing.
Traditional server-side encryption can protect stored data while still leaving the application in control of the keys needed to decrypt it.
Server-side encryption
Encryption at rest is useful protection for stored data. But when the application also controls the decryption key, the application may still be capable of reading that data during normal operation.
Inklok's approach
Signing values are encrypted before they reach the server, and Inklok does not receive an independent private key that can decrypt them.
A database-only compromise can expose encrypted signing values, but not the participant-held cryptographic identity required to read them.
Account access
Use Inklok across your devices.
Zero-knowledge encryption should not turn ordinary account access into a special workflow.
New device
Sign in normally to access your agreements from another device.
Recovery Key
Keep your Recovery Key somewhere safe. You may need it to restore encryption access during certain account recovery flows, such as if you forget your password.
Security FAQ
Security questions worth asking.
Can Inklok read what I enter during signing?
No. Every value entered during signing is encrypted in the browser before it is sent to Inklok. We store those completed values in encrypted form and do not hold the private key needed to independently decrypt them.
Can Inklok see the original agreement PDF?
Yes. Inklok can access the original agreement PDF so we can operate the agreement workflow. Signing values are handled separately and encrypted in the browser before transmission.
Is Inklok zero-knowledge?
Yes. Signing data uses a zero-knowledge encryption model. Inklok can run the agreement workflow, but we do not hold the private key needed to independently decrypt the values participants enter during signing.
What happens if Inklok's database is compromised?
Completed signing values stored in the database remain encrypted. Reading them requires the cryptographic identity of an authorized participant.
Other information needed to operate the service, such as the original agreement PDF and workflow metadata, remains within Inklok's normal server-side security boundary.
Who can decrypt signing data?
Decryption requires cryptographic identity material belonging to someone authorized to access that value. Depending on the agreement and its permissions, that could include the sender, a signer, an assigned reviewer, or someone the sender has authorized to view it. Inklok does not keep an independent private key that can be used instead.
What happens if I use a new device?
Just sign in. You can access your agreements from your other devices without changing how you use Inklok. We recommend keeping your Recovery Key somewhere safe. You may need it to restore encryption access during certain account recovery flows, such as if you forget your password.
What is my Recovery Key for?
Your Recovery Key helps restore access to your encryption identity during certain account recovery situations. Keep it somewhere safe because it protects access to signing data encrypted for your account.
Sign agreements without handing us the keys.
Zero-knowledge protection is part of every Inklok plan.