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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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 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.
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.
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.
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.
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.
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 main section of the website is protected by https ssl encryption, therefore traffic between your browser and the server is completed encrypted.