acmeattic-devel team mailing list archive

[Karthik Swaminathan Nagaraj <nkarthiks@xxxxxxxxx>]

Well, now I am convinced that we could operate on the notion that the server
cannot view my files.

On Sun, Jul 4, 2010 at 1:31 AM, Aditya Manthramurthy
<aditya.mmy@xxxxxxxxx>wrote:

>  On Sunday 04 July 2010 09:29 AM, Karthik Swaminathan Nagaraj wrote:
>
> The server software is responsible for maintaining the revisions.
>
>    - A request for a certain revision is processed at the server and the
>    final file is sent to the client.
>    - Similarly, the server periodically needs to perform maintenance on
>    the stored revisions, so that it can support operations to discard unwanted
>    intermediate revisions. (Like what we discussed already. A file that is more
>    than a week old need not have daily revisions stored - these can be merged
>    into a single revision for the week).
>
> For the server to process these locally, it should be able to decrypt the
> content safely. (These operations can definitely be achieved by transferring
> enough data to the client but that is too costly for the network).
> If the server is trusted, it can decrypt these files at runtime and store
> them in-memory. After finishing with the file, the memory is just freed (or
> even erased for the paranoid people).
>
>  I think revisioning can be implemented on top of the encrypted text. Since
> most diff libs are line based, we can preserve newlines in the files (i.e.
> do not encrypt them), and use diffs on top of the encrypted content. It
> should still give fairly compact diffs. We could mitigate the performance
> loss from encryption in this way. There are also binary diff libraries,
> though I need to look at them more to understand them. These will work even
> better than the traditional diffs, and let us handle even large binary files
> (that get updated by a user), more or less gracefully.
>
This may not be a biggie, but if a line may need to be padded to a multiple
of 16 bytes in order to encrypt it. Line based encryption may lead to
increase in the filesize which is O(num-lines * 16).
Another thought: The file now reveals information about the number of lines
in an unencrypted form - this is a security leak of some sort. (trivial)
Since encryption is performed in blocks, I agree that binary diff may be
possible.

The next step would be to identify if people do this already?

>
>
> Also, from the Mercurial documentation, I noticed that it performs
> different mechanisms on diff and compression for storing and network
> transmission - runtime decisions are made based on what is found (or
> predicted) to be optimal.
> Re-encryption can also be performed at the server without client/network
> involvement.
>
> I have some interesting thoughts and questions myself:
>
>    - Is it possible to verify or sign the authenticity of the server code?
>    (So that the client can trust the server)
>
>  Though we can try a few things, I don't think it is possible. A patched
> server s/w can always pretend to be the unpatched s/w because all the info
> required to do so is already available to the server admins. For example,
> doing something like a hash of the server source code, and sending the
> digest to the client, is not only impractical, but the server can just
> pretend to send the right hash code as this can be known in advance.
>
>
>
>    - I imagine generating a user's AES key as a hash (SHA256) of his
>    password. This could be securely sent to the server per-transaction, and the
>    server could handle all its operations and 'forget' the user's AES key.
>
>  I am not to follow this properly. Each user has an AES key? Or is it the
> file's AES key? The problem of patching the server code still presents
> itself.
>
I am referring to the user's AES key. And yes, each user has an AES key
which is used to encrypt this 'master file'. This is one way of easily
arriving at this key. SpiderOak does the same thing, I noticed.

>
>
>    - Even during the maintenance operations, it could be client initiated.
>    I still do not want the administrator to be able to view *any* file by just
>    logging in to the server.
>
> Does this sell the point that trusting the server to some extent is not so
> bad?
>
>  This clearly needs more discussion. So let's think more.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> Post to     : acmeattic-devel@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Karthik