Table of contents

  1. Advanced browser features
    1. Web Workers
    2. File API
  2. XHR loading for pages
    1. Persisting the state
    2. Hashtag navigation
    3. Preventing malicious javascript
  3. Gathering entropy
  4. Symmetric Encryption
  5. Hashing algorithm
  6. Authentication
    1. A day in the life of your password
    2. Generating your secret key
    3. Javascript closures to protect against malicious javascript
    4. Generating your authentication key and authenticating with the server
  7. Public Key Cryptograpy
    1. Generating your keys
    2. Storing your keys
    3. Retrieving a recipients public key
    4. What happens if a recipient changes their public key
  8. Managing contacts
    1. Why contacts need to be registered before you can send to them
    2. How we limit what we know about your contacts
  9. The code
    1. All code transfered as one blob
    2. No minified code
    3. Use of closures for code protection
  10. Transport
    1. SSL
    2. Emails

Advanced browser features

Web Workers

Web Workers allow us to push the time consuming processing into the background so that we don't hold up the main processing thread. Also by utilising multiple web workers we can take advantage of multi-core processors.

Web Workers are currently not supported in Internet Explorer so we cannot support it at this time.

File API

The File API allows us to read files from the users local storage into memory. This is vital as we need access to the file before it is uploaded in order to encrypt it.

The File API is currently not supported in Internet Explorer so we cannot support it at this time.

XHR Loading for pages

Persisting the state

Typically the user navigates around a website by clicking on hypertext links which instruct the browser to load a new page. The new page doesn't remember any of the state of the previous page and thus it is up to the server to maintain state by the use of cookies and the session.

For a host-proof application this prevents some issues as the users initial password is usually used as the secret key to the initial encryption and decryption. In order to work in a typical fashion the user would need to re-enter their password after every page load.

To combat this we prevent the user from changing page, and instead we use XML HTTP Requests to grab the next pages content from the server. This way we can keep the secret details in a variable in javascript yet at the same time allow the user to change pages.

Hashtag navigation

One of the issues with AJAXing pages in instead of changing pages is that it does not preserve browsing history. By changing the hashtag on the URL we enable the user to be able to use the back and forward buttons. It also allows us to enter the secure page at a different page instead of just the login page. We use this ability to allow us to drop into the drop box pages.

Preventing malicious javascript

A host-proof application needs to be auditable before entering any secret information (such as the password). Therefore the entire javascript code that will ever be run in the session needs to be sent to the browser before the user logs in. This initially seems incompatible with using web remoting as the server will continuously send javascript down to the client as they change pages.

To tackle this issue we use a javascript library called Caja which provides a HTML Sanitizer. This sanitizer will check the response from the server for any invalid HTML elements or attributes such as the script tag and remove them. Therefore even if the server were to send down malicious JS then it would not be executed.

Gathering entropy

In order to seed the cryptographically secure pseudo random number generator we need a source of entropy. This is a weakness of the browser javascript environment as we don't have a reliable source. Senditonthenet attempts to gather entropy from the users mouse movements and clicks

Symmetric encryption

Symmetric encryption is a type of encryption were data can be encrypted and decrypted using the same key.

We use symmetric encryption in SendItOnTheNet to encrypt the files that are uploaded for sending to recipients, only the actual exchange of a files secret key is encrypted with public/private key encryption. Also the users private key and their contacts are symmetricaly encrypted before being stored on our server.

The symmetric encryption algorithm used by senditonthenet is AES and it is powered by the Stanford Javascript Crypto Library [].

AES is considered to be secure and is considered to be sufficient to protect documents up to the TOP SECRET level by the United States government. Read more about AES encryption at wikipedia.

Hashing algorithms

A hashing algorithm is a alogorithm that can take a block of text and convert it to a shorter fixed length string. A good algorithm will change its output drastically even if just a single character is changed in the input. It should also be difficuilt to find two different inputs that result in the same output. Since it is impossible to reverse a hashing algorithm (go back to the original text having only the output) it is useful for verifying an input without knowing the original.

SendItOnTheNet uses a hashing algorithm to create your secret key from your password, it then creates your authentication token based on hashing the secret key again. This way senditonthenet will never know your original password even though it receives your authentication token.

The hashing algorithm that SendItOnTheNet uses is called SHA2. You can read more about it here


A day in the life of your password

Your password is the key to maintaining the security of your SendItOnTheNet account, therefore it is vital that this information never gets leaked to the server or stolen in any way.

Generating your secret key

Your secret key (the key used to encrypt and decrypt your private key and contacts) is created by concatenating your password and email address together which is then run through the SHA256 algorithm.

The resulting key is never sent to the server, but is held in memory in javascript.

It is for this reason that there is no password recovery feature. Firstly we do not know your password so we can't tell you what it is. Secondly we cannot reset your password since you would be unable to retrieve your private key and contacts.

Javascript closures to protect against malicious javascript

We use javascript closures to hide the state of certain objects. Your secret key is contained in a closure in the code. The result is that it is very difficuilt to extract the secret key by using javascript code to interogate the object, while at the same time it is easy to expose methods that themselves have access to the variable. This gives some protection against malicious injected javascript being able to retrieve your key.

Generating your authentication key and authenticating with the server

The authentication key is generated by putting the secret key through the hashing function again. When this is sent to the server for authentication it is salted and hashed a further time before being compared to the salted and hashed value that is stored in the database. By the time it reaches the databases your password has been hashed 3 times!

Public Key Cryptography

Public key cryptography involves two keys which are mathematically related, yet you can't discover one key, based on the other.

The two keys are generated at the same time, one is called a private key and the other is called a public key, the public key is handed out to everyone whilst the private key is kept secret.

Anything encrypted with the public key can only be decrypted with the private key, this allows anyone to send you an encrypted message that cannot be decrypted by anyone else and without having to pre-arrange a shared secret passphrase.

The algorithm Senditonthenet uses is called RSA.

Generating your keys

Your encryption keys are generated during your first login after activating. This process can take up to a couple of minutes on a slower computer, and it is at this point when we require the advanced features of a modern web browsers. IE users will be asked to install the google chrome frame at this point.

Once the keys are generated your public key is uploaded to the server un-encrypted. Your private key is encrypted using your secret key using AES, and is uploaded to the server for retrieval later.

We use a 768bit key length which is a compromise due to the computing power available in the browser environment, we intend on upping this to 1024 by the end of 2012 and increasing this again in 2013.

Retrieving a recipients public key

A potential weakness in the system is that our server provides the public keys for your contacts. The server could in theory generate a new public/private key pair and supply you with that public key. Then when you attempt to send files to the recipient the server could decrypt the file, steal it, then re-encrypt it with the real recipients key. This way you would never know that the file has been intercepted.

To tackle this we display the recipients public key to you before you confirm them. To keep the system host-proof you would then need to independantly confirm the public key with the recipient. We email you your public key after generation to make it easier to do this.

We have designed the system to make sure you don't have to re-confirm a recipients public key every time you send them a file. To see how jump to this section.

What happens if a recipient changes their public key

If a recipients public key would only change if their account had been reset. A user might do this if they have genuinely forgotten their password (there is no password retrieval system). When you add a contact as a recipient to a new package we verify with the server that the public key you have stored matches the one on the server. If they do not match you will get an error message and have to re-add the contact to continue. At this point you should verify with the recipient that they actually have had their account reset.

Managing Contacts

Why contacts need to be registered before you can send to them

In order to send a file to a recipient (without us being able to see the data) you need to have the recipients public key. Since the recipient wont have a public key until they generate it, they first need an account.

How we limit what we know about your contacts

Your contact list and their associated public keys are stored encrypted on the server (encrypted using your secret key). This doesn't mean we don't know anything about your contacts, in theory we could work out who your contacts are based on email logs and package recipients. In practise we don't.

The power of you maintaining your own encrypted copy of your contact list is that you have protection against the server substituting your contacts public key for a fake one.

The Code

All code transfered as one blob

We merge all of the javascript code into a single file along with all the dependencies such as prototypejs, sjcl, downloadify etc. This is to aid auditing the code as there is only a single file to monitor for changes. It also makes it much easier to detect if another javascript file is being loaded.

No minified code

Minifying the javascript code would make it much harder to read the code, and thus it would be easier for the server to include malicious code. By keeping the code in its original format we help protect you (even though its more to download).

Use of closures for code protection

We have already mentioned our use of javascript closures above



The main section of the website is protected by https ssl encryption, therefore traffic between your browser and the server is completed encrypted.


We use google for our email service, this means google can access the content of emails that are sent by our system. Due to this we do not send any sensitive information by email. You can read about what happens with your data in our privacy policy.