Disclaimer: I am not a security engineer or cryptographer. Use with caution. Feedback on security aspects or potential vulnerabilities is much appreciated.

Find me on Twitter, Mastodon or add a comment.

Prerequisites & Goal

It is important to highlight the asynchronous aspect of the plan. Obviously, you could just send a file directly from A to B using FTPS or similar protocols. In my scenario, a sender (Alice) would upload a file and get a download link in return. She would then send the link to a recipient (Bob) who can download and decrypt the original file. This means the file has to be stored somehow, somewhere along the way.

One of the challenges was to prepare for a potential scenario, where all of the infrastructure, namely API, Database and S3 Storage, would be compromised at the same time. Even in such a case, it shall not be possible to decompile or reverse-engineer the original file, fulfilling the promise of zero-knowledge encryption.

Another challenge is that file encryption requires internal memory (RAM). This becomes a problem when you wanted to encrypt/decrypt a big file at once: You needed twice the file size reserved in memory. For huge files, this amount of memory is simply not available on many devices.

Since I wanted to support massive files (>50GB) another factor to consider is the single file storage limitations many providers have. (Although, AWS supports up to 5TB)

And lastly, I wanted all traces to disappear after the file has been downloaded successfully.

Based on my background as a front-end engineer and because I believe in the open web, I also wanted to create a browser-based solution that is free, transparent and accessible.

Here is how it works

The following schema shows a simplified version of the implementation:

Memory and storage limitations

The solution is to break down the files into chunks and encrypt/decrypt them separately. Each chunk is saved individually to not only circumvent storage limitations but also to increase security. (From a storage perspective each chunk is just a bunch of binary data - it is not obvious which chunks make up a specific file.) Similar to the files stored on S3, the database only contains encrypted data. There is no way to reference database entries directly to files.

End-to-end encryption

Only the client with a valid link is able to connect all the dots and access the original file. It is worth noting that the master key (and alias) never leaves the browser. Both strings will be added to the fragment identifier of the download link. This commonly referred to as the hash (#) or anchor part of the URL is never sent to the server. (You can check yourself in your browser's dev tools: When you access a link, this information will not be part of the request.)

Simplified illustration of the download link (in the final implementation there is also a nonce added to the hash):

Side note: In this proof of concept everyone with the download link can access the file (once). For advanced security, one could easily build a solution that requires an additional password. To increase security with the present implementation, you may manually split the link and send the encryption key separately.

Breakdown: File Upload

Encrypting the file is the easier part: First, a file is split into smaller chunks. Those chunks then get encrypted separately using the master key and stored on S3. A reference to each chunk, together with a signature and a public key is afterwards stored in the database.

Simplified schema of the file upload process:

Breakdown: Download

The download and decryption is the tricky part. Not only do we need to make sure the client is allowed to request a certain file (solved with a cryptographic signature, see blue box), but also, it is not possible to build back the file at once to save it into the download folder. (To be exact, for smaller files, one could download the file, decrypt it in memory and save it right away. But since we want to support large files, we need some magic from the Streams API and the Service Worker API.)

Simplified schema of the file download process:

A service worker is something like a proxy within your browser. It has access to the network and can e.g. intercept requests or change responses. We can interact with it by sending messages back and forth, but it doesn't have direct access to the DOM.

Within our app the service worker is designed to intercept the initial file request (described above), then fetch and decrypt the chunks and finally stream the data back within the response (basically directly into your download folder).

We have to use the "request interception" approach, b/c of a limitation in most browsers: A user has to initiate a file download with a click on <a href="/path/to/file.txt" download>. (This will change with the File System Access API - which is unfortunately not widely available yet).

The role of the service worker:

If you want to learn more about how this works in detail, I recommend this video.

Cryptography

For encryption/decryption only built-in browser APIs are used, namely the Web Crypto API. As a side effect, this app won't run in legacy browsers or with older node versions. The following algorithms are being used:

• AES-GCM (Advanced Encryption Standard - Galois/Counter Mode) for symmetric encryption: This is used for the master key that encrypts/decrypts all file chunks and the data stored in the database.

• ECDSA (Elliptic Curve Digital Signature Algorithm) for asymmetric encryption: This is used to sign the file chunk keys in order to make sure the later download request is allowed to access a specific chunk file.

The Web Crypto API offers a set of low-level cryptographic primitives. On top of those, I created some helper functions that might be useful to others.

Resources

This project is heavily inspired by a great online community and amazing open-source projects:

• hat.sh - A client-side file encryption project

• Proton Drive security model explained (Blog)

• Firefox Send (Archived Repo)

• Thomas Konrad on end-to-end encryption (Video)

• MDN Docs about Web Crypto API

• Sharrr is open source on GitHub

We have a very simple and convenient solution for this problem: With the Scrt.link Slack App you can create one-time secrets right from within your conversations. Only a reference link stays in your chat history. After the secret link has been clicked once, it self destructs and is not accessible anymore. The secret is destroyed for good and a 🔥 emoji is added automatically to indicate that.

How to use

👉 Install the Slack App

After you have installed the app, there is not much more to do.

Slash Commands

You can now create secrets via Slash Commands. Where ever you are, just type:

    /scrt //opens a dialog to create a secret.
    /scrt [secret goes here…] //creates a secret link instantly (of type Text).
    /scrt [text|link|neogram] //opens a dialog to create a specific type of secret.
    /scrt help //opens a help dialog.

Shortcuts

Just click the ⚡️ icon and choose Scrt.link. If you are inside a conversation you can also use the context menu (3 dots) and select Reply with a secret. After that, just use the form.

Important information about security limitations of the Slack App

Due to the nature of how Slack apps are designed, full end-to-end encryption is not possible. We take a number of steps to make sure your secrets are safe, including encrypted connections, sandboxed application server, limited access to infrastructure, etc. In 99% of use cases this is fine and a risk worth taking - still, Slack is proprietary software where we don't have control over. In other words, if you need advanced protection, create secrets on the website instead.

Spread some Love

• Learn more about the Slack App
• Upvote on ProductHunt
• Follow on Twitter

Screenshot from 2011 via Archive.org

Now, for many years the site has been my go-to tool whenever I had to send a password to a coworker. But then, one day, I decided to create my own version of such a tool. (For context, there is a blog post that describes in detail why I created scrt.link.)

A Great Source of Inspiration

When you visit https://onetimesecret.com for the first time, it becomes obvious that the creators don't intend to follow web design trends. And I mean this in a positive way: The website is, above all, practical - it offers a simple interface to help you do one specific thing: Create one time secrets. It's a unpretentious, fast and responsive website without overhead, distraction or ads. It's clearly a project run by idealists not incentivized by selling out its users. To me, it is also a reminder that the web is (still) a great place.

The One Big Caveat

Now, after digging the topic of secure disposable messaging and analyzing the website from a security perspective, I came to notice one big flaw: Messages are not end-to-end encrypted.

As you can see in the screenshot. A secret is sent in plain text to the server. That doesn't mean everybody in the network can just eavesdrop on your message. The connection is still secured with HTTPS. But this fact opens the door for potential vulnerabilities.

What it means is that the backend (server) receives your secret in plain text - in other words, as a user you have to 100% trust the service. And even if you do, a successful attack on the server may still compromise your confidential data. (It is noteworthy that One-Time Secret doesn't hide that fact).

Time for Change

I believe that no one, including the service provider, should be trusted when it comes to handling personal secrets. That's why we created our service not only 100% open source, but also in way that minimizes potential risk. We use end-to-end encryption, where a secret gets encrypted and decrypted in the browser (where you have full access to the code that runs the website).

You will notice in the screenshot that the secret is already encrypted before it gets posted to the server. (You can check for yourself. Just open the network tab in the DevTools and checkout the POST request to the API)

Give it a try!

Other Alternatives

To be transparent, scrt.link is only one among many tools that can be used as alternatives to One-Time Secret. Some of them have similar security features. Try for yourself.

• https://privatebin.info/
• https://yopass.se/
• https://1ty.me/
• https://www.saltify.io/en/
• https://password.link/
• https://privnote.com/
• https://pwpush.com/

For context, sharing information in a truly secure way is harder than you'd think. You can only guarantee confidentiality with end-to-end encryption. In other words, the information you want to transmit has to be encrypted and decrypted on the client. This means you can't just create a secure server infrastructure and offer a public API - you also need code executed on the client. The good news is, you can now just do that.

scrt-link-core has just been published. Use it in your project. It's free.

Installation

In any node based environment you can just install the package like this:

yarn add scrt-link-core
# or: npm i scrt-link-core

Basic usage

The heart of the package is the createSecret function that handles the encryption of the secret, as well as the communication with the API. It returns an object containing secretLink. (This package assumes that you use scrt.link as your backend, but it's not mandatory - feel free to create your own backend. See scrt-link for reference code.)

import { createSecret } from "scrt-link-core";

const { secretLink } = await createSecret("Some confidential information…");
// https://scrt.link/l#hLN8e0jd6xtLuxJqDxp1D/Q4rqaOWQtzFTZIB-7TXEYD2NgI9E1KQdeMXdfsvPykI

Via (hosted) ES Modules

Now wait - before you think it's too much trouble - you don't even need to install any package. With e.g. Skypack it's possible to literally create a secret link with just two lines of code - wherever you need it. Just drop the following snipped into your HTML:

<script type="module">
  import { createSecret } from "https://cdn.skypack.dev/scrt-link-core";

  createSecret("Some confidential information…").then(({ secretLink }) => {console.log(secretLink)});
// https://scrt.link/l#hLN8e0jd6xtLuxJqDxp1D/Q4rqaOWQtzFTZIB-7TXEYD2NgI9E1KQdeMXdfsvPykI
</script>

For more information and examples read the full documentation.

All code is open source and on Gitlab.

Feedback is very welcome :)

The idea grew into a project that could be summarized as "Sharing secrets as a service". Like all side projects, the beginning is easy. In fact, the prototype was online after one weekend: A domain, a fully functional website, database, even the logo was there.

That's when you enter phase two. You start thinking about your project all the time: This feature would be fun, that part should be refactored - oh what about monetization - I want to cover the costs for the infrastructure. Wait a second, I need user accounts for that. Hm, now shouldn't I add terms and a proper privacy policy? Did I choose the right framework to start with? These thoughts are the reason, side projects hardly ever make it beyond the prototype :) I guess, thanks to the pandemic, I stayed focused: Three months later I felt comfortable to post the project on producthunt. Not that I expected much - I just wanted to get some early reactions. That's basically where we are today.

Status quo

The current status of the project:

Scrt.link is a tool to share sensitive information online: End-to-end-encrypted messages that are shared with a one-time link. There are 3 secret types you can share (secret files are in consideration):

Text: This is the standard mode. It's the preferred way to share passwords and similar kind of secrets. The recipient has the option to copy the secret.
Link: Think about it as a URL-shortener where the generated link only works once.
Neogram™: Digital letter-style message that automatically burns after reading. Use it for confidential notes, confessions or secret love letters.

There are browser extensions available for all major browsers and (free & paid) user accounts for power users and/or supporters. There is a Twitter account.

At the point of writing 778 secrets have been created. 42 upvotes on producthunt. 1 paying customer.

What's next?

Since I created this project out of curiosity and with the only intention to learn something, it has been a great success. I've became knowledgeable in previously unfamiliar areas (backend, database, privacy, marketing). I'm still very much in love with this project and I believe it has value, maybe even potential to grow. However, looking only at the numbers, one would consider it a failure, leading to the conclusion that my time is better spent elsewhere.

I'd be happy for ideas, thoughts, wisdom, …

Best Chris