Announcing secrets.xmission.com – A Self Destructing Encrypted Notes Service
Today, XMission launched https://secrets.xmission.com, our new free, publicly available service to fight off Big Brother, snooping individuals, hackers, and adversaries.
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.
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.
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.
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.
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.
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.
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.
When visiting the URL, you are now presented with an input field to provide 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.
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.
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.
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.
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 <firstname.lastname@example.org>”.
- 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.