Safe Note - Privacy just got easy. Client-side, javascript, AES encryption.


Q & A


Quickly sending anything I don't want others seeing. Passwords for my friend to login to my account, my dad's credit card info so I could buy his laptop, my ssh private key so I can install it on another computer.


We wanted to send secure messages but didn't want to walk the recipient through installing TrueCrypt or some desktop encryption software? We're security guys and it was pain even for us. So we wrote Safe Note. Then we decided it was too handy to keep to ourselves!


Either through a good hint, or use a passcode you already both know, such as "its our Gmail password." You can also call/SMS them with it. Even though SMS isn't encrypted, you are still much better off since you're using two channels to communicate the sensitive information.


In a word, yes. Even we as the developers can't read your messages. Its safe after it leaves your browser. Encrypted with industry-grade AES client-side encryption, structured to support privacy and combat brute force attacks. But we welcome anyone to review our open source javascript code. We are firm believers in open source security. The server never sees or stores any cleartext, clear password, clear anything. And why should it- we don't trust it either. We're a little paranoid in case you haven't noticed. So check the HTML, javascript and even sniff the traffic on post. Its nothing but noise.


Using https certainly wouldn't hurt. But no, it is not required because everything is encrypted before it leaves your browser. The passcode is never transmitted in the clear. It's just like encrypting a file before emailing it.


Sorry to be the bearer of bad news- but no, email is transmitted in completely clear text.


Those do not use true encryption and can be cracked in seconds.


To keep it free. We tried to make it large enough to be useful for anything sensitive (config files, ssh keys, even log snippets) but small enough so we could host hundred of thousands of encrypted blob messages without charging.


Sorry, no. Due to the nature of javascript (warning: slightly technical answer to follow)- it (thankfully) doesn't have a way to perform file operations. It can't open, read and encrypt the file, so you'd have to send us the file in order to encrypt it. This would obviously violate one of our core 'Trust No One' tenants. We can, however, highly recommend TrueCrypt for all your encryption (file, virtual disk, full drive) needs.


Your data is gone, forever to stay in encrypted land. Like we said, there are no back doors or ways to do passcode recovery.


Techie Q & A


It's a hassle. Trust us, we've done it. Both have to have the software and then swap keys. Not exactly simple. Don't get us wrong - we know, love and use those products - they just all require client installations, which is difficult with nontechnical parents on other continents (hypothetically speaking of course ;-)).


First, its old. SEVEN years old, which makes it difficult to support. Second, it would require an ActiveX control to do the XmlHttpRequest queries we want. ActiveX- something we tell people to DISABLE due to its many many security problems. So we do apologize, but encourage you to upgrade to Internet Explorer 7, or Firefox.


Ask Microsoft- its the way the implement Javascript. We are doing some fairly math intensive functions, but still. We recommend you switch to Firefox. Its a better, more secure browser anyway, and works much faster on these hashes with Safe Note.


So we can verify you have the password before giving you the ciphertext. Could you crack the ciphertext? Probably not. But you also can't crack what you don't have. We're paranoid like that.


So even while we're using the challenge hash to verify your password, it is useless for opening the encrypted blob we store. Trust no one, not even us. If your challenge hash verifies- we sent you the blob to decrypt yourself on the client-side.


Yes, salts aren't sensitive. They are used to prevent precomputation attacks, also called Rainbow tables ("A rainbow table is ineffective against one-way hashes that include salts."). These tables can takes months to build. A simple salt renders all of the existing hashes worthless. You can see this elsewhere. If you encrypt something with openssl (openssl enc -aes-256-ecb -in file.txt -out file.txt.enc) you'll see the salt included on the first line. The salt is then used on the recipient side to easily reconstruct the key. Rehashing with the salt is hardly noticeable to the recipient since it only takes a few seconds.