Security

Syfr Overview

This document provides a detailed overview of Syfr security practices which keep your information safe. Our commitment to security is intrinsically tied to our sacrosanct commitment to freedom of speech, expression, and conscience.

1. Introduction

1.1 End-To-End Encryption (E2EE)

Syfr is designed to protect all user content with end-to-end encryption (E2EE). This means that form submissions text and files are encrypted on the user’s machine (local encryption) before transmission to Syfr. Syfr never possesses user keys and operates on a HSTS domain which ensures all communications are additionally encrypted with HTTPS. This design ensures no one can access your content without your key, not even us. Content is protected by a series of keys (described below) to give users the option to share encrypted data with others, without divulging their own key.

1.2 Confidentiality and Privacy

Syfr provides cryptographic proof of confidentiality for client content through E2EE. This is the strongest level of confidentiality known. Users are encouraged to inspect their network traffic to verify data is encrypted by their own machines prior to transmission. For purposes of operations and billing, Syfr must collect certain non-content information (such as email address and credit card for billing) and apply our Privacy Policy.

1.3 Cryptographic Algorithms

As a reference point, NIST SP 800-57 Rev. 5 requires cryptography with a “security strength” of at least 112 bits until the end of year 2030 to meet Federal Information Processing Standards (FIPS). Security strength represents the resistance to brute force attacks and is not necessarily equal to key length. Security strength can be determined using calculations in FIPS 140-2 IG § 7.5. For example, SHA typically have a security strength equal to half their length. As shown below, Syfr always utilizes encryption that meets or exceeds the NIST recommendation. We only utilize the following cryptographic algorithms and minimum key lengths (shown with respective security strength): 256-bit A256KW / A256GCM ~256 bit strength for symmetric encryption 4096-bit RSA-OAEP-512 ~152 bit strength for asymmetric encryption 512/256-bit PBKDF2 ~256 bit strength for password derivations 512-bit SHA ~256 bit strength for hashing Web Cryptography API for all cryptographic algorithms.

See IANA JOSE registry and Web Crypto API for algorithm implementations, abbreviations, and definitions. Further detail in §2.

2. Client Security

2.1 Key Derivation

Whenever a user provides a password, Syfr will derive a localKey and authKey. The localKey is used for decryption and never leaves the user’s computer. The authKey is only used for authentication with Syfr and is unable to decrypt content. The process is as follows:

  1. The user inputs an email and a password
  2. The password is hashed 100,100 times using PBKDF2 with SHA-512 to produce a 512-bit hash. The user’s email is incorporated as an arbitrary salt to avoid collisions. This iteration count was chosen in consideration of NIST SP 800-63B which recommends at least 10,000 iterations and to not unreasonably impede performance. Increased iterations improves security, but impedes performance for the user. To avoid vulnerability, users are advised to use unique and strong passwords.
  3. The hash is split in half. The first half is the 256-bit localKey which is used as A256KW key material and is never transmitted. The second half is the 256-bit authKey which is used as zero-knowledge proof that the requester is in possession of the localKey.

2.2 User Registration

A new account registration undergoes the following process:

  1. The user inputs an email and a password
  2. The input is used to derive the localKey and a authKey using the key derivation process (§2.1).
  3. The user generates a 4096-bit RSA-OAEP-512 key pair (through their browsers’s Web Crypto API) which contains a public key and a private key. The public key is intended to be disclosed freely, however the private key decrypts content encrypted by the public key. Therefore, the private key is encrypted / wrapped with the user’s localKey to create a encryptedPrivateKey. This is safe to share as no one can decrypt it without the user’s localKey (which never leaves the user’s computer).
  4. The authKey is transmitted to Syfr along with the user’s email, public key, and encryptedPrivateKey (transmissions are always over HTTPS).
  5. If it is a new account, Syfr stores a derivation of the authKey and sends a verification email to the provided address so the user may complete their registration. If the account already exists, that user may be notified of the attempted duplicate registration.
  6. Syfr always replies to the request with a void response. In this way, a user’s account with Syfr is not revealed to an adversary through the registration process.

2.3 User Login

A user’s attempted login undergoes the following process:

  1. The user inputs an email and a password
  2. The input is used to derive the localKey and a authKey using the key derivation process (§2.1).
  3. The authKey is transmitted to Syfr along with the user’s email (transmissions are always over HTTPS).
  4. If the credentials are valid, Syfr will respond with a valid token. If the credentials are not valid, Syfr will respond with an error that the username and password combination is not valid. In particular, Syfr will not confirm if we found a matching email address. In this way, a user’s account with Syfr is not revealed to an adversary through the login process.

2.4 Script Integrity

Syfr provides javascript tools with public source code to facilitate client encryption of web forms. This provides a process to encrypt the content (including any file uploads) before transmission to Syfr (described in section 3.1). The encryption algorithms are implemented entirely through the submitting user’s native browser Web Cryptography API (described below). Users are encouraged to test this behavior, such as by reviewing their network traffic in their web browser and auditing the script source code. A subresource integrity hash is required to ensure the script remains unchanged. This makes it infeasible for anyone (including Syfr) to modify the script in any way without breaking the hash; causing the browser to reject it. As a non-working visual example, the HTML for the script element may appear as follows:

<script
  integrity="sha256-EpgoQL5aocICfvAkZ9Pb2b+EvUrAwWgTInlEH7v6wW4=
sha384-mHmFBm2gwZv9OfNkHedRdgq4fjqzs8rQMPdzh8m27XxsE8E9X9oT2uHg3ohJNrXt
sha512-5YZn2xKppz9M+18/0kjU6x/ek9VGk1IQIGP36DVhhXeoP9775+yuyfd4ieat0TIoNzQn7rdEo0ieiphfFWKCEw=="
  defer
  src="https://js.syfr.app/1.0.3/formCipher.min.js"
></script>

Our packages adhere to semantic versioning and subresource integrity ensures all upgrades must obtain explicit user approval. When Syfr releases an update, users may review and test it before electing to update their websites with the new version and corresponding new subresource integrity hash. This explicit approval process ensures users cannot be blindsighted by an automatic update.

2.5 Web Cryptography API

Syfr ensures perfect cryptography by requiring all such processes to utilize the (Web Cryptography API)web-crypto-api . By utilizing the web browser’s native cryptography, Syfr provides several benefits:

  1. Syfr cannot introduce cryptographic implementation errors.
  2. The user need not trust our cryptographic implementation. The user only needs to trust their browser. If the user does not trust their browser, then it is impossible to secure.
  3. Web Crypto API provides the fastest processing (near native speed).
  4. Near universal browser support. See (caniuse.com/cryptography)caniuse/crypto .
  5. Possible NIST / FIPS compliance.

2.6 HSTS

The Syfr website always operates with

(HTTP Strict Transport Security (HSTS))rfc6797 . This ensures that all communications are encrypted with the additional protection of HTTPS (in addition to the content encryption described below).

3. Content Security

3.1 Content Encryption

New content (such as a web form submission) is encrypted prior to transmission as follows:

  1. The user inputs their content (text, selections, files, etc)
  2. Each of the files (if any) are A256GCM encrypted with a single-use key which is generated from Web Crypto API CSPRNG
  3. The submission’s files are replaced with the newly encrypted versions.
  4. The non-file content is A256GCM encrypted with a single-use key which is generated from Web Crypto API CSPRNG.
  5. Each of the A256GCM keys are encrypted using the form's public key.
  6. The encrypted content is submitted to Syfr for secure storage.

3.2 Content Storage

When Syfr receives encrypted content for storage, it is further encrypted as follows:

  1. The encrypted data is further encrypted with a key and algorithm known only to Syfr.
  2. The double-encrypted data is stored highly redundant and secure cloud storage provider. You should treat your key as the sole means of protection for your information. We provide this second layer of encryption as a courtesy only and without any warranty of performance.

3.3 Content Decryption

A user may access encrypted content from Syfr as follows:

  1. Syfr screens the user’s request to ensure the user is a known keyholder for the content.
  2. Upon succeeding the screening, Syfr transmits the encrypted data and any applicable encryptedPrivateKey to the user.
  3. The user’s machine decrypts the encryptedPrivateKey using its localKey (according to the key management system described in §3.4) to obtain the form's private key.
  4. The user’s machine decrypts the content’s A256GCM with the form's private key.
  5. The user’s machine decrypts the form content with the A256GCM and displays it locally.

3.4 Key Management

Syfr facilitates content sharing using a chain of key-wrapping encryption as follows:

  1. Each form is secured by a cryptographic key pair RSA-4096.
  2. Each form entry is encrypted by a A256GCM key.
  3. Each form entry A256GCM key is encrypted by the form's public key.
  4. The form's private key is encrypted by a group's public key
  5. The groups's private key is encrypted by each user's public key
  6. The user's private key is encrypted by the user's localKey

3.5 Content Sharing

Syfr facilitates content sharing using the key management system described in §3.4. Sharing with a new user is facilitated with the following process:

  1. A user is proposed for addition to a group
  2. A group member in possession of the groups's private key can approve the new member by encrypting the groups's private key with the proposed user's public key.
  3. The new member now has their own user's group key and can access any of the forms available to the group.

Sharing a form with a group undergoes the following process:

  1. A group member must be in possession of the form's private key and have permission to add forms to the group.
  2. The group member encrypts the form's private key with the group's public key to create the form's encrypted private key.
  3. The form’s content is now available to the group.

This process, together with the key management system described in §3.4, facilitates sharing between groups of users without requiring any modification to the forms. Removal of a user only requires the deletion of the user's group key. Therefore organization administrators may boot users even without having access to the group content themselves. Similarly, removing a form from a group simply requires deletion of the form's encrypted private key for the group.

Removing a user disallows them from obtaining further content, but cannot guarantee removal of content or keys previously transmitted to the user. In cases where a user is a member of multiple groups which can access the same form, the user must be removed from each of those groups to terminate access to the form. The group may cycle their keys to invalidate past keys.

3.6 Lost Passwords

Syfr’s end to end encryption means that we are unable to recover data if the user loses their keys. Syfr is only able to reset the account with new keys. A strategy to avoid data loss is for users to share data with others trustworthy individuals. When a user must reset their account, the others who retained their keys may re-encrypt the data with the resetted user’s new key.

4. Responsiveness

4.1 Bounty

We are committed to providing the most secure platform possible. Any vulnerabilities or tips which facilitate a significant security improvement may be eligible for reward. Please contact us for instructions.

4.2 Malicious Activity

In accordance with our Terms of Service, Syfr monitors our systems for bad actors. Upon discovery, Syfr may (at our own discretion): ban the user(s) without refund, take legal action, report such activity to law enforcement, and prosecute to the fullest extent of the law. We require a valid payment method for all organizations to facilitate the identification of bad actors and to expose those individuals to financial risks.

4.3 FIPS Compliance

We are committed to meeting and exceeding Federal Information Processing Standards (FIPS). In certain instances, federal agencies using FIPS-compliant computers and operating in FIPS 140-2 approved mode / FIPS validated software may meet FIPS requirements while using Syfr.