How are notes stored on the server?

All notes are first compressed using zlib. Data compressed with zlib provides good compression ratios with minimal system resources. After the note is compressed, it is then encrypted with the AES-256 cipher using CTR mode. Part of the encryption includes using HMAC-SHA512 to maintain data integrity and authentication of the encrypted message. The keys used are not stored in disk, and instead are part of the URL. After the note has been encrypted, it is then stored on disk. All of this is done in RAM on the server.

Why not use client-side encryption with Javascript?

First, JavaScript does not support very large integers when it comes to encryption. The maximum integer size in JavaScript is 53-bits. To do encryption properly, you need at least 128-bits, and many times 256-bits of entropy. This means using the BigInt.js library. This is certainly doable, but it also means that the client must download an additional 50 KB.

Second, JavaScript does not have any built-in cryptographic libraries. As such, we would then need to support a 3rd party JavaScript library. There are a few out there, with CryptoJS probably the most feature complete, and most mature. But, this also means more to download. For AES, PBKDF2, and HMAC-SHA512, that's an additional 25 KB to download at a minumum.

Lastly, the big argument against server-side encryption, is not trusting the service administrator. This is why the project is Free and Open Source Software, so you can host it on your own server. But, even with client-side encryption, people generally aren't going to verify that the server is sending them the correct JavaScript code that will actually do the encryption. So, you must trust the service provider that the note is stored encrypted on the server, without tampering or snooping by the administrator. Service providers require trust, server-side encryption or client-side.

How secure is AES-256 encryption?

AES is based on the Rijndael cipher, and supercedes DES. Currently, there has not been a practical attack on the AES cipher. AES-256 was chosen due to it's fast performance in software and its ability to withstand cryptanalysis over time. It's an industry standard, open block cipher.

How can I send my note?

After a note has been created, you will be given a random and unique link that you can send to your intended recipient. You could then send this link via email or instant message. Further, a QR code is generated that you can scan with a mobile device. This allows you to also send the link via text message easily, or any other communication tool that may be installed on the mobile device..

How do I undo sending a note?

If you suspect that you have sent the note to the wrong person, have sent the note prematurely, or just sent the wrong data, you can destroy the note by just visiting the link. Once the note has been viewed, the note is destroyed, and will no longer be available.

Can I send a note to multiple recipients?

No, you cannot. This web application is designed for single viewing only. If you want to send a note to multiple recipients, then you must create multiple notes, one for each person.

How secure is the private passphrase?

Because the note encryption is symmetric cryptography, anyone with the encryption key can decrypt the note, and view its contents. As such, it is critical that the private passphrase be private, only between the sender and the recipient.

What is a duress key?

A duress key is a key that is provided when the user who has knowledge of decrypting the note is under coersion by a third party, such as law enforcement. A duress key is separate from a private key, in that a duress key will not decrypt the note. Instead, the duress key will immediately and silently destroy the note, and return 5 random sentences from The Zen of Python. Thus, no knowledge about the note is gained, and because the note has been destroyed, there are no options to take in recovering its contents.

Why am I forced to use JavaScript?

This site could run fine without JavaScript. However, when creating a note, a Hashcash token is minted and submitted to the server for verificaiton. Hashcash tokens are minted to prevent form spam and to prevent brute forcing POST denial of service attacks. JavaScript is also used to create a QR code when the note has been submitted, allowing you to share the note using your mobile device. There is no JavaScript tracking software in the default install of d-note.

What is a hashcash token?

A hashcash token is a proof-of-work puzzle that your browser must solve before it can submit the form data. It is built for the sole purpose of fighting spam. Typically, hashcash tokens are used when composing emails. The token is minted by the sender's email client, then put into the headers of the email. The token is computationally expensive for the sender to create. However, when the email is sent, the recipient can verify the token is valid quickly. This implementation of hashcash uses browser fingerprints as the resource string to uniquely identify your browser, rather than an email address. This fingerprint is an anonymous 32-bit MurmurHash digest.

What are browser fingerprints?

Browser fingerprints are a subset of device fingerprints, where the browser can be uniquely identified with greater than 90% accuracy. Typically, browser fingerprints are used to identify and track users while on websites. A browser fingerprint is calculated by determining the IP address of the user, its screen resolution, installed extensions, plugins, and fonts, and many other factors. All of these factors are pooled together, and hashed using the MurmurHash function. This function returns a 32-bit decimal number, such as "2199570". That number is used as the resource string for the Hashcash token, which is stored on the server to prevent double spending.

How secure is my note really?

Nothing is 100% secure. There are always tradeoffs. Even though I've gone to great lengths to protect your data by default, the system administrator running this application on his server might be careless, or even malicious. As such, if possible, you should host this application on your own web server. Further, you probably should not put all of your eggs in one basket. It is best practice to send usernames to the recipient via one method, and passwords via another. That way, it could be difficult for a single person to collect all of the necessary data. Lastly, if this application is not served over SSL, then packets could be sniffed off the wire, and the contents of the note revealed in plaintext.

Are there any backdoors?

No. There are no backdoors in the default source code. Because this application is Free and Open Source Software, you are free to download and examine the source code yourself, and determine if any backdoors exist.

Are you sharing my data with the NSA, MI6, KGB, etc.?

You will need to ask the administrator of the server running this site. There are no backdoors in the default source code, as already mentioned, and nothing is calling home. All network interaction, by default, is communicated strictly between your browser and this server.