b0616ea5bc
All checks were successful
Release to Production / build_and_release (push) Successful in 27s
39 lines
1.7 KiB
Markdown
39 lines
1.7 KiB
Markdown
# Offline Flow
|
|
|
|
SIGit is fully functional without a network connection! The creator just needs the following:
|
|
|
|
* Browser
|
|
* Nostr Extension or nS for signing
|
|
* A local copy of the SIGit application
|
|
* The public key (nPub) of each counterparty
|
|
* The documents to be signed
|
|
|
|
The creator flow is as follows:
|
|
|
|
1. Create the SIGit as usual
|
|
2. Export the SIGit
|
|
3. Pass the SIGit to the next counterparty via USB or other offline mechanism
|
|
|
|
The signer flow is as follows:
|
|
|
|
1. Upload the SIGit
|
|
2. Review and sign
|
|
3. Pass on the SIGit (to every counterparty if last signer)
|
|
|
|
To illustrate with a diagram:
|
|
|
|
|
|
|
|
## Offline SIGit Structure
|
|
|
|
The exported SIGit is a zip file that contains everything that the next signer (or verifier) needs to proceed, namely:
|
|
|
|
* app folder - containing a launchable instance of the app
|
|
* encrypted sigit file - containing the files to be signed and associated metadata
|
|
* `keys.json` file
|
|
|
|
The `keys.json` file contains the decryption key(s) for the encrypted sigit file. To decrypt a key, it is necessary to know the receivers private key, and the senders public key. To avoid metadata leakage, the sender is always a throwaway key pair, and that public key (npub) is in the `keys.json` file. Only the receiver can decrypt the decryption key.
|
|
|
|
For the last signer, it is necessary to encrypt the decryption key to multiple npubs. We also do not wish to leak the identity of those npubs, nor the number of counterparties. For this reason we create an **array** of decryption keys, rounded up to the nearest 10 (padded with fake keys), and the recipient must cycle through and try to decrypt each one. This is why you will see multiple decryption requests when verifying an offline (encrypted) SIGit.
|
|
|