Image of the glider from the Game of Life by John Conway
Skip to content

Announcing d-note: A Self Destructing Notes Application

I'm pleased to announce something I've been working on, on and off, for over a year. Introducing d-note, a self hosted web application with self destructing notes. d-note is written in Python using the Flask web framework.

d-note comes from the idea that sending private information across the Internet can be very insecure. Ask yourself- how often you've sent usernames and passwords in chat or email, either across the global Internet, or even inside of your work's Intranet? Maybe you've sent PINs, SSNs, credit cards, or other sensitive information too. Or maybe you haven't, but someone you know has.

d-note aims to solve this problem. With d-note, notes are compressed and encrypted with Blowfish on disk, using either a shared key stored on the server, or a private key which is not stored. When a note is created, the sender is given a random URL which will link to the note. That URL can only be viewed once, and when viewed, it is immediately destroyed on the server. If you try to visit the note again, because it doesn't exist, a standard 404 error will be raised.

Here are the current features in this release:

  • Data is compressed with zlib, then encrypted with Blowfish. Never at any point is the note in plaintext on the filesystem.
  • Form submission is protected by the browser minting a Hashcash token. This will prevent form spam, and POST denial of service attacks. As such, JavaScript must be enabled.
  • The note can be encrypted with a separate private key. This private key must be securely communicated to the recipient, so they may decrypt the note. The private key is not stored on the server.
  • The note can also be protected with a duress key, in case someone is trying to coerce the decryption key out of you. The duress key will immediately and silently destroy the note, without decrypting it, and redirect the browser to a standard 404 error.
  • Notes are destroyed immediately upon viewing. They are destroyed by securely overwriting the note with random data before removing it from the underlying filesystem.
  • Notes can be shared with mobile devices, by scanning a QR code. This allows you to share the note via SMS, email, instant message, or some other application installed on your mobile device.
  • Unread notes are automatically and securely destroyed after 30 days.
  • d-note tries its best at preventing the browser from caching the session. With that said, the back button is still functional.

Because the application uses Hashcash to protect the submission form, JavaScript must be enabled to post a note. Don't worry, there is no identifying or tracking software in the default source code. Further, it may take your browser a few seconds to mint a valid token, before the form is submitted (it may even take longer if using a mobile device to create the note).

Due to the nature of this application, some best practices and precautions should be made:

  • The web application MUST be served over HTTPS.
  • The server administrator hosting the d-note application could have modified the source code to store private keys, or even the notes in plaintext. As such, don't put all of your eggs in one basket. Give the usernames over one channel, and use d-note for the passwords, or vice versa. Even better, host this on your own web server, where you have full control.
  • Storing the encrypted notes in a ramdisk would be the most secure. However, if the web server stops, unread notes will be lost.

There are still some things that need to be done, such as improving the overall look and feel with much needed CSS, and making the site a bit more dynamic with JavaScript. I'm also debating on creating account support, so you can view which notes you've created, and which ones have not been read. In the long term, I'd like to create an API, so you can create notes from other sources, such as the command line, or mobile device apps.

However, for the time being, it works, it's feature complete (for a 0.1 release), and it's mostly bug free. If you would like to try a demo of d-note, you can visit It's currently using a self-signed certificate. As such, to verify you have the right server, the certificate fingerprints are:

MD5 Fingerprint=5A:E1:4E:B6:31:B8:3D:69:B1:D6:C0:A7:6B:46:FE:67
SHA1 Fingerprint=55:89:CD:C0:D4:85:CC:A5:DE:30:11:5D:9C:C9:12:1C:5C:9D:10:C5
SHA256 Fingerprint=12:91:BB:4C:E8:2F:1C:0C:D9:96:AF:4E:1D:8C:F7:B0:A8:07:70:C5:9C:89:B8:94:EE:E2:2A:D6:19:43:17:A4

{ 2 } Comments

  1. aland | February 22, 2014 at 1:40 pm | Permalink

    Would you think about replacing the ECB encryption with CBC or CTR mode. whilst compressing the plaintext before encrypting does prevent some of the obvious attacks on ECB, it's not cryptographic security.

    My guess there is a lot of similarity in strings that are anagrams or extensions of each other


    >>> import zlib
    >>> zlib.compress("television ads")
    >>> zlib.compress("enslave idiots")
    >>> zlib.compress("the trouble with")
    >>> zlib.compress("the trouble with cryptography")
  2. Aaron Toponce | February 27, 2014 at 1:15 pm | Permalink

    Hmm. You make a good point. I've gone back and forth with it. The big drawback to CBC/CTR mode is maintaining an IV/counter. By not having an IV/counter, the code is simplified, although it's not greatly complex maintaining it either.

    I looked at what your sample text would look like using d-note, converting the bytes to base64. I get the following:

    "MjVIQlBXQzZGcGFDVU16VGRnSG82QlM1RkRqckkxaVoK" == "television ads"
    "UzdBVENIajh0YW56SEVXa2R6U2V3TmJ6N0s1VmZOYmEK" == "enslave idiots"
    "Y2UzeVhsUldEdnZ3UTlDaHY2MVJPWkgrcWlZc0xvZWJ5UG1KYTFoTnY2WT0K" == "the trouble with"
    "Y2UzeVhsUldEdnZ3UTlDaHY2MVJPUzUvVDV5c094N2NRTmdhSlh5QkwrY21VanNhZFpQclZRPT0K" == "the trouble with cryptography"

    Upon visial inspection, I don't see any immediate patterns or correlations between "television ads" or "enslave idiots" and the other examples you gave. However, there is a pattern exposed with "the trouble with" and "the trouble with cryptography", indeed. "Y2UzeVhsUldEdnZ3UTlDaHY2MVJP" is a repeated pattern between both texts. About 47% of the shared text is exposed in the crypto. An attack vector most certainly exists here, although I don't know how much of the original text could be recovered.

    I'll go back to using CBC mode with an IV. Thanks for the feedback!

Post a Comment

Your email is never published nor shared.