Re: [Freesafe-devel] jFreeSafe backup and restore updates

[Marai L. <at...@at...>]

  Hi,

>    attached is a patch (against trunk) to allow backup and restore
> functionality. You already had the functionality stubbed out, but with
> no implementation. This implementation is slightly different than what

First of all, thanks for your work!

> you had initially started: in this implementation, the user gets to
> specify a password when he is requesting a backup and restore, and the
> server side simply stores and returns the password protected record

I only had the time to look through your patch. It's a great help as it
has most of the things I was reluctant to write :). However, I don't like
the fact that you use PBE (password based encryption) for sending the
data over the wires. At first I thought I would just do that but it's not
strong enough and can be bruteforced. I just made a simple calculation
and it seems that an 8 char long, completely random alphanumeric password
could be bruteforced with 100% probability in less than a year. I just
ran into an estimation on the website of a similar application for PalmOS
that a 1.2GHz PC can do about 1.5M tries/sec. That application uses MD5
and 3DES but I don't think that there is too much difference between that
and our Twofish/SHA1 scheme. I assumed that today a PC can do 6M
tries/sec (given that they can have 2-4 cores and twice the clock rate
it's a modest assumption).

A few thousand years worth of protection is a realistic requirement, I
think. Note that one has to take in account that the computing power
that one can buy for $1 doubles every 1.5 years and that means a hundred
times in ten years. So what's a thousend year today, will be 10 years from
ten years now, and that means that it's less than 20 years instead of a
thousand. And since FreeSafe can store credit card numbers, thanks to
your patch, that may be valid for _at least_ a decade, we have to go for
strong encryption in this case. Also we have to prevent man-in-the-middle
attacks.

I figured out a protocol that would probably work. I'm not sure if I put
the docs in the CVS or not. It's basically the same as HTTPS: the server
generates an RSA key-pair, and then sends its public key to the mobile.
The mobile generates a symmetric key for twofish, and sends it back to the
server encrypted with the public key and then it sends the data encrypted
with the symmetric key using twofish. To prevent man-in-the-middle
attacks the server and the mobile have to have a shared secret. What I
thought of is generating a random string on the mobile and then typing it
in on the server. Then when the server sends the public key to the mobile
it will also include an HMAC (a hash) of the public key and the random
string.

Now if we don't want this whole authentication thing at first then it's
enough to just use any (non-password based!) symmetric key. But then it
has to be entered by the user manually in case of a restore on another
device. That would mean 32 characters for a 128 bit key or 48 for a 192
bit (that's used to encrypt the password store itself). 32 characters
_might_ be tolerable. I don't know what's the estimated time to
bruteforce 128 bit Twofish.

> store. This approach would probably not work too well in attempting to
> transfer the backups from one handset model to another (e.g. if they
> have different implementations of RecordStore); however, it works well
> with the same or related models (e.g. I just finished a backup from a
> Nokia E61, and restored it into a Nokia E61i).

It's not a problem. The API you hooked in is totally independent of
RecordStore. The data that the applications read out and write into the
store is device independent (of course). The actual record store file
format (if there is a file at all) is what's device dependent but you
only encounter it if you access it e.g. through the filesystem of the
phone.

All in all, what I'm going to do is that I'll apply your patch locally
and then look at what it's like exactly and then I'll figure out how to
fix the crypto part the fastest way. (That would be probably using a
strong key and typing it in before a restrore.) Then I'll do the more
complicated solution. That shouldn't take too much time as you did
write basically all of the application logic part. At least as far as I
can see from looking through the patch.

  Laszlo