Group Encryption

Status and Overview

Status: Writing Specification
This application does not have a finalized specification. This is a working draft.

The goal of group encryption application is to share information with a selected group of individuals, while granting no intermediaries access and requiring the reading users to have access to the content's hyperlink.

As a starting point, we are working with the more advanced sharing concept found in this video.

---

URL Format

For more details on the URL format, see the URL Specification.

Identifiers

These strings assign the privlyInjectableApplication parameter with the name of the referenced injectable application.

• GroupEncryption

Anchor Parameters

These parameters cannot be placed on the parameter string since that would result in their being transmitted to the remote server.

• privlyLinkKey: This key is used to decrypt the ciphertext. It may also be placed in the server parameters, but doing so is discouraged since it provides the parameter to the remote server.

Anchor and Server Parameters

These parameters can be on either the parameter string or the hash text.

• privlyDataURL: The injected web application fetches the ciphertext from this URL. When the application is injected by an extension, the content found at this URL will be messaged to this application from the extension.

Extension Parameters

These parameters are added by the extension.

• privlyOriginalURL: This parameter gives the original URL of the application. Privly-type extensions often have to change the source URL to point to local storage on the extension, but the extension still needs to provide the original parameters to the application. This parameter is only used internally in the extensions.

---

Which Systems Have Access to What

We list which components have access to particular pieces of information below:

• Content Server (Privly or similar party)
• Ciphertext
• Twice-encrypted content keys
• Public keys
• Host Page
• Link Key
• [Injectable Application](Injectable Applications) - Posting
• Cleartext
• Ciphertext
• Link Key
• Encrypted Content Key
• Twice Encrypted Content Key
• Public Keys
• [Injectable Application](Injectable Applications) - Reading, non-permissioned
• Link Key (if they discovered the link on the host page)
• [Injectable Application](Injectable Applications) - Reading, permissioned
• Cleartext
• Link Key (if they discovered the link on the host page)
• Ciphertext
• Twice Encrypted Content Key
• Encrypted Content Key
• Content Key
• Extension
• Everything Accessible by the [Injectable Application](Injectable Applications), and nothing more
• Encryption Library
• Private Key
• Everything Accessible by the [Injectable Application](Injectable Applications)

Note that the private key is never transferred outside the library for these operation, and the symmetric keys are one time use. If the cleartext is in javascript, it does not matter that the symmetric keys are in Javascript.

---

Posting Process (Encryption)

This is the high level process for encrypting content by the user generating content.

1. (User Action) The user types the content into the Posting Application, selects which identities they want to share with, and submits the form.
2. The application requests a new symmetric key, ContentKey, from the library
3. The application requests that the content be encrypted with the ContentKey
4. The application requests a second symmetric key, LinkKey, from the library
5. The application encrypts the ContentKey with the LinkKey
6. The application uses the public keys of each of the users the content is shared with to encrypt the encrypted ContentKey. This will generate N twice-encrypted content keys, where N is the number of public keys the content is shared with.
7. The application receives the encrypted content from the library and posts it to the content server with all the twice-encrypted content keys
8. The content server then returns a URL for the content, which is placed into the host page with the LinkKey

Cryptography API Function Calls

• asymmetricEncryptString:key:cleartext
• symmetricEncryptString:key:cleartext
• generateNewKey

HTTPS Requests

The following network requests will be made by the application:

• Get user sharing lists and CSRF token
• Post Encrypted Content and Twice Encrypted Content Key

---

Viewing Process (Decryption)

This is the high level process for decrypting content by users who have permission to view the content.

1. The application recovers the LinkKey from the URL for the content
2. The application receives the encrypted content and the twice-encrypted content keys from the content server
3. The application decrypts the twice-encrypted ContentKey with the current user's private key which is stored in the library
4. The application decrypts the once-encrypted ContentKey with the LinkKey
5. The application decrypts the content with the ContentKey

Cryptography API Function Calls

• asymmetricDecryptString:key:ciphertext
• symmetricDecryptString:key:ciphertext

HTTPS Requests

The following network requests will be made by the application:

• Get Encrypted Content and Twice Encrypted Content Key

---

Cryptographic Specification

Todo: We need to write this up in the formal style typical of cryptographic specifications and discussions.