Encryption

After you choose a wallet, Organigram asks it to sign a message. The signed message proves three things:

• you control the address you are connecting with
• you are signing in to the current Organigram domain
• you accept the Terms of service and Privacy Policy linked in the message

During first sign-in, Organigram also prepares an encryption key for your browser when possible. The public part of this key can be included in the sign-in message and registered on your account. The private part is kept in runtime memory while the wallet is unlocked, and can be stored server-side only as an encrypted vault envelope protected by a password chosen by the user or by a passkey.

Registering an encryption key

The generated encryption key is registered automatically for private IPFS storage and encrypted workspace envelopes. It lets other workspace members wrap access keys for your address without learning your private key.

You can manage this key from Account Settings:

• save or refresh the encrypted server vault by entering the vault password or passkey
• export the IPFS private key from Developer settings after unlocking that vault

If the private encryption key is not available in runtime memory, you may still be signed in, but private workspace files encrypted for that key cannot be opened until the encrypted vault is unlocked.

Workspace envelopes

Some workspace content is stored through an encrypted envelope instead of being referenced by a raw IPFS CID.

An envelope is a versioned index for a workspace. It maps stable logical references, such as a proposal file or certified proof attachment, to the current file manifest stored on IPFS. In Organigram these references use the workspace scope, so the application can keep using a durable reference while the underlying file version changes over time.

For encrypted content, the file itself is encrypted in the browser before it is uploaded. IPFS only receives encrypted bytes and a manifest describing how to resolve them. The manifest includes the encrypted payload CID, the encryption algorithm, the initialization vector, the content size, optional file metadata, and a wrapped content key.

The content key is not stored in clear text. It is wrapped by a workspace envelope key, and the envelope key is itself wrapped by the current workspace access group key. This gives Organigram two useful properties:

• each file version can have its own content key
• the workspace can rotate access when membership changes without rewriting every encrypted file

Uploading an encrypted file

When a workspace file is uploaded with encryption enabled, Organigram follows this flow:

1. The workspace envelope and current access group are loaded.
2. A fresh content key encrypts the file with AES-GCM in the browser.
3. The encrypted bytes are uploaded to IPFS.
4. A file version manifest is uploaded to IPFS. It points to the encrypted bytes and stores the wrapped content key.
5. The workspace envelope is updated so the logical reference points to the new manifest CID.
6. The update is signed by the connected wallet and checked against the current workspace membership hash.

This means a workspace reference can remain stable while the content behind it is versioned. Older manifests can still exist on IPFS, but the current envelope defines which version is active for the workspace.

Reading an encrypted file

When a member opens an encrypted workspace reference, Organigram resolves it in the opposite direction:

1. The logical workspace reference is resolved through the current envelope.
2. The file manifest is loaded from IPFS.
3. The member unwraps the workspace group key with their local private key.
4. The workspace envelope key unwraps the file content key.
5. The encrypted payload is downloaded from IPFS and decrypted locally.

If the connected user is not part of the current access group, or does not have the private encryption key available in runtime memory, the encrypted payload cannot be opened from that browser.

How this integrates to your workspace

When workspace encryption is enabled, Organigram automaticaly builds a membership snapshot from the workspace: personal workspace owners, organization workspace admins, and the relevant organization members. The snapshot is hashed and used to create an access group epoch.

For each epoch, a workspace group key is generated and wrapped separately for each recipient public key. A member can decrypt the group key only with their own private encryption key after unlocking it locally. If the workspace membership changes, or a member rotates their encryption key, the access group becomes stale and a new epoch is created, ensuring that only current members can access the latest encrypted content while keeping the audit trail intact for previous versions.