How it Works

1. Goal of the Service

The overarching goal of 0kx is to create a simple, secure, and free service to exchange files (and text messages) over the Internet. In order to achieve this, data needs to be encrypted in transit, at rest, and encryption keys need to be managed. 0kx does all this while keeping complexity to a minimum. From a design perspective, security and usability have been balanced to make it as secure as possible while keeping minimizing complexity.

2. The Design

Here are the design goals of 0kx:

  1. No install required for the sender and the recipient(s): 0kx is a pure web-based application, can be used in any JavaScript-enabled browser.
  2. End-to-end encryption: Encryption must happen on the device, namely, in the browser.
  3. Cryptographic keys used to secure the exchange should be unknown to 0kx: Cryptographic keys are generated and used strictly on the device (in the browser), never sent to 0kx servers, and exchanged from the sender to the recipients by some other means outside 0kx.

0kx uses symmetric encryption (not PKI), specifically AES-GCM 256 encryption. See NIST SP 800-38D and JavaScript reference documentation JavaScript AES-GCM to secure the data stored in an ephemeral secure vault. The process goes as follows:

3. Upload phase

  1. From a browser, the Sender accesses 0kx.io and indicates the files that need to be exchanged.
  2. In the browser, using built-in JavaScript cryptographic libraries:
    1. Generate a random IV (initialization vector)
    2. Generate a random AES 256-bit encryption key
  3. Initiate the creation of a secure vault with a random unique ID on 0kx.io by providing the following information:
    1. Initialization vector (IV)
    2. A SHA-1 hash of the decryption key
    3. Vault retention rules (i.e. how long to keep the files)
  4. For each file:
    1. Request a handler to 0kx.io upload the file directly to the mass storage service (AWS S3), providing the following information:
      1. Vault ID
      2. File name
      3. File size
      4. Content Type
    2. Encrypt the file locally in the browser’s built-in JavaScript cryptographic AES-GCM cipher
    3. Upload the encrypted file directly to the mass storage service
  5. Once all files are uploaded, complete the secure vault creation on 0kx.io
  6. Display the secure vault URL (based on its ID and intended to be a secret) and the decryption key to the Sender
  7. The Sender sends the URL and key to the intended recipients using some means independent of 0kx.io. To provide the best security, the URL and the key can be sent by two independent communication channels

4. Download Phase

  1. The Recipient(s) receive the message(s) from the Sender containing the URL to the secure vault and the decryption key.
  2. The recipient opens the link and accesses the page on 0kx.io to download the files.
  3. The recipient(s) provides the decryption key, then the key is validated in the browser against the key hash associated with the vault.
  4. For each file to be downloaded:
    1. Request a download link to a mass storage service (AWS S3) to 0kx.io.
    2. Download the file directly from the mass storage service.
    3. Using the built-in browser JavaScript cryptographic AES-GCM cipher to decrypt the file using the decryption key.
    4. Complete the download of the file.

5. Notes

  1. The decryption key is randomly generated in the browser, used in the browser to encrypt files, shown to the Sender and NEVER communicated to 0kx or stored locally. The encryption/decryption key is a secret that is shared only between the Sender and the Recipients. By design, 0kx has no knowledge of the encryption/decryption key. (0kx only knows the SHA-1 hash of the key, for integrity checks)
  2. The secure vault ID is a UUID4 and is intended to be a secret; and only someone with the URL (based on the ID) can access the secure vault. The vault URL/ID is a secret shared between the Sender, the recipients, but is also known by 0kx.
  3. Since the URL to the vault and the decryption key is shared to recipients by means independent of 0kx (via existing unsecure channel(s) between the Sender and the Recipient(s), by design, 0kx has no knowledge of who the recipients are.
  4. The secure vault will be deleted in accordance with the retention rules (Ex: 24h) and is intended to be ephemeral.
  5. File names exchanged are known by 0kx and are displayed to anyone with the URL of the secure vault.
  6. A text message (with or without files) can also be securely sent via a vault. In practical terms, messages are treated like files with a special content type that indicates they’re meant to be displayed in a browser. This approach enables the exchange of sensitive information, such as credit cards and passwords, without the need to store it in plain text in a local file. The same principle applies at the receiving end; the message isn’t persisted on the recipient’s disk during the exchange, but it’s simply displayed in the browser.