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.

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.