Friday, May 30, 2014

Week 3

I added the detection function to the chrome extension this week.

The extension can now detect whether a gnocchi-encrypted file or a gnocchi-signed file is received from the server, as long as the server follows the Multipurpose Internet Mail Extensions (MIME) protocol and the Security Multiparts for MIME, multipart/signed and multipart/encrypted (see RFC-1847 for more information).

To be more specific, the extension checks the headers received from a server and determines whether a gnocchi file is received according to the header named "content-type". I selected header checking rather than data checking for the following reasons:

  1. Although data checking is more reliable since the information in the headers may not correctly record the content type of a file, we can still ensure security in this case. On one hand, suppose a non-gnochhi file is sent with the header declaring it as a gnocchi file. That file will not be decrypted correctly and it is unlikely for a mis-decrypted file to get passed in the verification process. On the other hand, if a gnocchi file is sent with the header declaring it as a non-gnocchi one, the extension just ignores it, and the user can obtain and decrypt that file from other servers.
  2. It is more efficient to do header checking. Because we do not rely on something like the "gnocchi servers", every sever can serve as the source of a gnocchi file. Thus, the extension checks the headers received upon every url request to detect a gnocchi file. Generally, the size of the headers is quite minimal, while the size of the file data may vary from extremely limited size to extremely large size. Also, headers are received before the data. Having the extension checking the data every time a url request is made may greatly slow down the browser.
  3. Lastly, most of the servers follow the protocols mentioned above, and the extension works for those servers.

For normal surfing, nothing happens:

A gnocchi is detectd:

For next week, I am going to do some research on File IO in javascript. File IO is critical for replacing the encrypted file with the decrypted one. It seems that Google places a lot of restrictions on File IO for extensions, for some security reasons. Admittedly, File IO can be done with html, but I would like to avoid opening a new webpage prompting the user to input the private key. Also, File IO with html cannot completely solve the problem since I need to find a way to turn a local javascript variable recording the decrypted data into a real file.

Friday, May 23, 2014

Week 2

Week 2

I started implementing the chrome extension for the client side this week, with Nic working on the server. Since we do not have anything cryptographic on the server yet (a cryptographic database generator to be implemented in the near future), the client now is mainly serving as something like a test program, rather than a fully developed chrome extension for practical use. However, we did set up the a way for data transmission between the users and the server with the chrome extension. We decided to choose JSON (JavaScript Object Notation) to transmit data between the server and the client for the following reasons:

  1. Compared to XML (Extensible Markup Language), JSON uses opening and closing brackets such as {, [, ], and }, instead of opening and closing tags like <title> and </title>, which takes less space and is more efficient in communication.
  2. JSON is pretty compatible with JavaScript. A well-formatted JSON string obtained from the server can be easily parsed as a JavaScript object by calling JSON.parse(). Because JavaScript is the most popular scripting language for web development at present, compatibility with JavaScript is a great advantage.

To make the extension less dependent on a specific browser (yes, I am talking about less dependence on chrome), I implemented the extension as a webpage-based one. For now, when the user clicks on the icon to start the extension, a local html file is opened in the browser as a simple user interface.

The user can hit "Enter" directly to view a list of the available files on the server,

or enter a valid file name to view it or download it (depending on whether the publisher specifies the file as downloadable or not when the file is uploaded to the server).

Next week, I will make the extension detect the web requests so that it can be automatically invoked when the users try to access an "encrypted" file on the server. In this way, the users do not need to start the extension and enter the file name every time they want to access a file on the server. Also, I will have the extension be able to read the local files selected by users to gain their private keys for decryption.

Friday, May 16, 2014

Week 1

We started our Gnocchi/NoSSL project this week!

For the first week, it was mainly about research and plan for future implementations. The Gnocchi/NoSSL system we are going to implement is for online file distribution with the purpose of keeping private keys offline as much as possible. By avoiding to store the private keys online, Gnocchi/NoSSL protects the material better even when the server is untrusted or compromised.

Our Gnocchi/NoSSL system consists of three parts: the client, the server, and the database generator.

Since the private keys are kept offline, most of the cryptographic work is on the client side. The client first requests for the needed data from the server, trusted or untrusted, and then interprets the data into a proper file system. Because the server may be untrusted, the client is responsible for verifying the integrity and the authenticity of the files received. As for the specific implementation, we are going to implement it as a plugin of the browsers. As the first attempt, it will be a Chrome extension.

The server is basically a common one without much modification. Since we do not rely on the server for integrity and authenticity, the server simply serves as a place for file storage and responds with the correct data upon the client's request.

The database generator is used to produce a signed and authenticated database with the private key by the publisher. To transform an existing file system into a valid database in Gnocchi/NoSSL, the file data blocks and the inodes are associated with their cryptographic hashes, and the resulting database will have a structure similar to the Merkel hash tree, which aims at protecting the integrity of the files.

I also did some research on how to create an extension for Chrome this week.

Building a Chrome extension is pretty straightforward. A Chrome extension usually consists of the following:

1. A manifest file named manifest.json, recording the metadata of the extension

2. Html files for the contents to display by the extension.

3. JS files for the codes to be executed.