Transmission

XMission's Company Journal

Announcing secrets.xmission.com – A Self Destructing Encrypted Notes Service

securityToday, XMission launched https://secrets.xmission.com, our new free, publicly available service to fight off Big Brother, snooping individuals, hackers, and adversaries.

Background
Off and on for a few years, I had been toying with the idea that I wanted the general public to have access to 100% transparent encryption, repudiation, and deniable plausibility. I am a large advocate of PGP and encryption in general, but I wanted to provide some way for users to use a system where they would not need to manage their own encryption keys. I thought this would be a difficult task. Turns out, that’s not the case.

In light of the revelations by Edward Snowden about the NSA, this project kicked into high gear. I had seen that there were actually many services out there that provided exctaly the solution I was trying to develop. However, none of them provided the source code, so I could run my own instance on my own server. As such, how do I know they aren’t being malicious with my data? How do I know that these service providers really aren’t the NSA just parading around as someone else? Especially with services that require an account to be created before I could even use the service.

As a result, I created d-note, a web service that encrypts notes sent to it, and self destructs the note immediately after decryption. If you’re interested in the nitty-gritty details of how the system works, I’ve detailed it on my personal blog, such as internal workings for version 1.0 and some JavaScript security enhancements. Instead, let’s discuss why this service would be important to you.

The Need for Privacy
As a business or an individual, there are times when private information needs to be shared. For new employees, this could mean birthdates, social security numbers, salaries, and banking account information for direct deposit. For individuals, it could mean sharing with your spouse how much is currently in the checking account, or the username and password to an email account. All too often, these details are shared in the clear, via fax, email, pen-and-paper, or telephone conversation. While no system is 100% secure, there are some steps we could take to be more conscious about privacy and security.

In generaly, however, it is probably wise not to put all of your eggs into one basket. Even though this service encrypts your notes and goes to great lengths to ensure your privacy and anonymity, no service is 100% secure. As such, you may want to split up the information, so should an encrypted note be forcibly decrytped, there will not be enough information for the attacker to retrieve everything they are looking for. So, send your usernames via one method, and your passwords via another. Put half of the banking account information in one note, and the other half in a different note. Of course, this is for the ultra paranoid, but it’s good advice, and isn’t too terribly difficult to do in practice.

How It Works
When visiting https://secrets.xmission.com, you will be presented with the ability to post your note, and submit the note to the server for encryption before it is saved to disk.

Screenshot showing secrets.xmission.com with some text.

You then can press the “Submit Secret Note” button, which will force your browser to solve a challenging puzzle. This puzzle solving may take a few seconds before you are redirected to the next page. I opted for this approach rather than using captchas, as a way to deter spammers, and “prove” that you are human. The more powerful the processor on your hardware, the faster the puzzle will be solved. Once solved, the solution to the puzzle (a token) will be submitted to the server with your note.

At the redirected page, you will be given a unique 22-character URL to your note. This URL is random and unpredictable. This is to prevent would-be attackers from discovering the next URL to a submitted note, or trying to find valid URLs to previously submitted notes. In fact, the URL is large enough, that if you were trying one billion URLs every second, it would take you 700 years before you reached the probability of 50% that you’ve found a valid URL that contains a note. Yes, this service is THAT over engineered for safety and security.

Screenshot showing the redirection of a sucessfully submitted note.

This page will give you the full URL, including the domain name, as well as just the ID to the note itself. For plausible deniability, you could agree to use https://secrets.xmission.com beforehand, at which point you could send just the ID to the note, rather than the full URL. Should Big Brother intercept the email, and demand to know what “2BzSqfbm5q2BMIdeF4Y8Rw” is, you can deny any knowledge of what it is, or what it’s used for, while “https://secrets.xmission.com/2BzSqfbm5q2BMIdeF4Y8Rw” is obviously revealing as to what it is.

If the note was submitted in error, a link is provided for you to immediately decrypt the note. All decrypted notes are destroyed immediately on the server. Thus, you could destroy the note, without sending it to your recipient, and try again.

Also, part of the page is a QR code, which is hidden by default (to prevent would-be over-the-shoulder scanning). The existence of the QR code gives you the ability to submit the note on your workstation, then share the URL to a recipient via your mobile device, such as through text messaging. Of course, the QR code is not required to decrypt or share the note. It only exists as a bridge between the desktop and mobile devices, should you wish to use it.

Screenshot showing a QR code to a submitted note.

Once the recipient has clicked the link, and opened the note, the URL is no longer valid, as the note has been destroyed on the server. As such, a standard 404 or “Page not found” error is raised when the URL is attempted to be visited again. While viewing the note, the recipient will have 3 minutes to view its contents, after which the browser will be redirected back to the home page, and attempt to retrieve the note contents will fail. This 3 minute timeout is hard coded, and not configurable. I am looking at changing this behavior in a future release.

Screenshot showing the decryption of a secret note.

It’s important to understand that unless you provide your own passphrase encrypting the note, the URL will always decrypt it. On the server, access and error logs are not saved. This protects the system administrators from Big Brother should they seize the server. However, if you use Google to email the URL, a Google employee could view the link in the email, thus destroying the note. As such, it is strongly advisable that you supply a passphrase to encrypt the note, so should the note fall into the wrong hands. If you are not comfortable providing a passphrase, but wish to have one generated for you, you can press the “Generate random passphrase” button. Whatever text exists in that field, will be used for the encryption and decryption of the note. Further, that key is not stored on the server. If the key is forgotten, or incorrectly typed, there is nothing that can be done to decrypt the note.

Screenshot showing a new note with an optional passphrase.

When the note is sucessfully submitted, you will be redirected to the post page, as previous, with all the information necessary to decrypt the note, including a new key called a “duress key”. A duress key is a key that you would provide to someone if under pressure from an adversary to provide the key that decrypts the note. However, the duress key will not decrypt the note, but destroy the note, and give the adversary arbitrary, randomized text. In this case, the text comes from the Zen of Python, and 5 sentences are chosen at random. A duress key is only available if a passphrase is chosen, as it is assumed that the adversary knows the note is encrypted with a key, but doesn’t know what the key is.

Screenshot showing the passphrase key and the duress key, as well as the note URL and ID.

When visiting the URL, you are now presented with an input field to provide the key necessary to decrypt the note.

Screenshot showing the page asking for the key necessary to decrypt the note.

At which point I can provide the passphrase that will sucessfully decrypt the note, or I can provide the duress key which will return random sentences from the Zen of Python. Additional texts for falsified data will be provided at later releases, making it more difficult for an adversary to determine if they have the actual data or not. As with the passphrase, the duress key is not stored on disk. As such, if the duress key is lost, you lose your one-way ticket out of a troubling situation.

Screenshot showing the duress key returning 5 random sentences from the Zen of Python.

Finally, after 30 days, any notes that have not been read will be destroyed. This is not built into the application (yet) but was deployed by us as a safety measure. Further, the notes are not backed up. If the server crashes, and needs to be rebuilt, any notes that have not yeat been read will no longer be available. By storing backups, this means that encrypted notes hang around after being destroyed, which is less than optimal.

Self Hosted
If you don’t believe that we are doing what we claim, or you are more paranoid than most, you are more than welcome to run your own self-destructing encrypted notes installation. Python and Flask are the only requirements to host the application, aside from a web server. You can grab the source code from https://github.com/atoponce/d-note. You will notice that the upstream source code is not themed. This is intentional. I want to provide a skeleton code base that you can build from.

If you need a hosting provider, we provide hosting for as little as $10 per month where you could run your own encrypted notes instance.

Future Features
Very, very soon, a mobile theme will be baked in for those using phones or tablets to access the site. I am aware of this need, and it’s very high on the priority list to get finished. Also, an API will be baked in, so for our Zimbra Hosting package, a Zimlet could be built, that will allow you to send secure notes to people in your address book, but the note will not be stored on email servers. Additional planned features include account support for having a “drop” to send the note to. Thus, when logging into the web interface, I would have “unread notes” waiting, that I could view. This would eliminate the need to send the URL over an insecure channel that others might have access to, such as email. Other features are planned, and will be baked in as I have the time to implement them.

Security
We have found it very useful to send private and sensitive information back and forth to each other and to customers. I have full confidence in the product, and I have followed industry standards and best practices with regard to cryptography, and believe your notes are fully secure. You’ll notice that you are forced to use SSL to communicate with the server. We are taking no chances. Only our senior system administrators have root access to the server, which is a separate server only hosting the encrypted notes, and nothing else. Access and error logs are not stored on the server, protecting our administrators should the box become compromised. The box is consistently updated, and all of the latest security patches are applied. If you would like to evaluate the latest source code, you can view everything that is running on that server at https://github.com/xmission/d-note, which is a legitimate fork of my upstream project.

If you are interested in the mathematics and cryptography in the service, I would be more than happy to discuss it with you. Email me at “Aaron Toponce <at@xmission.com>”.

Conclusion
To paraphrase:

  • All notes are never stored in plaintext anywhere on the server. The notes are ALWAYS encrypted with military-grade, industry standard encryption.
  • No web serving or application logs of any kind are stored on the server that could reveal who created which note.
  • Never at any time are any keys of any type stored on the server.
  • Notes without custom passphrases will use the URL as the key to decrypt the note.
  • Notes with custom passphrases must be decrypted with that passphrase.
  • Duress keys are provided with custom passphrases to give to law enforcement or adversaries that demand the key to decrypt a known note.
  • A QR code could be scanned if you wish to share the encrypted note using an application on your mobile device.
  • There are no backdoors in the service.
  • The source code is available if you wish to run your own instance. I know of an excellent hosting provider. :)

We hope you find this service as useful as we do. As always, if you have any questions or comments, please let us know.

facebooktwittergoogle_plusredditpinterestlinkedinmail

,

Comments are currently closed.

5 thoughts on “Announcing secrets.xmission.com – A Self Destructing Encrypted Notes Service

  • puddleglum says:

    Interesting idea. Will you be able to attach documents like PDF files or is this only for txt?

    I think it would be more useful to be given then option of choosing your own duress key. I would never be able to remember that random string to give out. You should be able to use the same duress key for all your messages since presumably it should only be needed once.

  • Aaron Toponce says:

    I do plan on implementing file uploads as a feature in the future, with limited scope (2 MB maximum, or something similar). I don’t want the service to be a click-hoster, so the goal would be to discourage that.

    Regarding the duress key, I’m not fully satisfied 100% with how it is implemented. The current reason why the generated duress key is the way it is, is so it matches the structure of the URL ID. As such, if you were to send an email with: “VLROk6rKBuLL_ZNQI_PVn0 N3CCk_BYGtY06Tp3vL9obQ SNXL_DnDJp8kZYc_T0BAYw”, which is the URL ID, which is the passphrase, and which is the duress key? Of course, it’s not wise that you do this, but I need to take some protections in the event that lazy users aren’t really that interested in sending each through a different channel to the recipient.

    Initially, I had a checkbox only that you could select to enable a duress key. Unfortunately, I don’t expect many people to take advantage of it. As such, if you provide a passphrase, you get a duress key by default now. This removes user interaction, but as you’ve discovered, removes the ability to enter custom duress keys. Also, the random string, as you have noticed, is not memorable. It would be nice to have a memorable duress key. Even better, it would be nice to have a duress key that matched in syntax and style, the custom passphrase. I think there is work to be done here, and I’m still working out those details.

    Lastly, I’m not 100% satisfied with the duress text being strictly sourced from the Zen of Python. Suppose Big Brother forces you to reveal the key, and you supply the duress key. It has to be assumed that they will be familiar with the text the duress key returns. This may cause you additional duress, seeing that they are now fully aware that you deliberately gave them the wrong key. As such, it would be nice if I could use an artifical intelligence algorithm, such as a Chomsky “bot”, to deliver legitimate sentences, without being obvious that the text is the result of a duress key. Even better, it would be nice if the user could supply their own duress text. That way, they could style the duress text to be structurally formatted to be similar to the real data, which is the ultimate goal.

    Long story short, I appreciate your feedback, and I’m doing more work here to tighten security where I can, while also giving some flexibility with the user, and without leaking data to the system administrator, or random people. It’s a hard problem to solve, so keep an eye on the site for updates. :)

  • Rich says:

    https://openwireless.org/

    Unrelated but does XMission currently support Open Wireless Movement!?

  • puddleglum says:

    Sounds to me like it’s up to individual users if they want to participate in Open Wireless or not. How is the ISP involved?

    It looks like a good start with the routers, but I really wish they would address the modems themselves. They have routing capabilities built in these days and your average home user will use these unless they have a need for something more. That’s definetly the case with DSL modems and I think Utopia’s fiberoptic modem is the same way.

  • Rich says:

    Below are some ISPs that don’t forbid running an open wireless connection in their Terms of Service. This list is based on an informal survey and may be out of date or incorrect. We encourage you to seek out ISPs that respect your rights by offering customers the flexibility to open their wireless networks, and this list is a great place to start. (Last updated: July 22, 2014)

    The more the merrier. Do you know another ISP that promotes (or doesn’t forbid) running an open wireless network? Let us know! Email openwireless@eff.org and tell us about it. And if you’re an ISP looking to woo new, liberty-loving customers, email openwireless@eff.org so we can discuss it with you and get your company listed.

    Changes? We strive to keep this list as up to date as possible. If there are changes to an ISP’s terms of service or availability of service that affect this list, email us at openwireless@eff.org

    Just didn’t see XMission specifically listed as a participating ISP over at https://openwireless.org/