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

[Alex K. <ako...@gm...>]

Laszlo,
   my comments are below:

> Well, with strong crypto that wouldn't be a problem. As there is the
> network between the phone and the server, you can assume that the backup
> data will be bruteforced. Period. The easiest would be to use https but
> MIDP does not support messing around with the certificates and that would
> be needed to prevent man-in-te-middle attacks.

   Yeah, I did think that https would be better than creating a custom
encryption scheme, but I am aware of the limited https support in
handsets. One alternative that I was thinking about was to include the
public key in the jar that goes on the handheld. This way, the server
doesn't have to return the public key every time a backup is
requested, but rather the client can use the public key that comes
with the distribution. There is always the alternative of adding a
'request public key' functionality to support a public/private key
combo different from the default.


> Well, that would be almost as long as a sensible strong key. Another
> thing that I thought of for sharing a secret between the mobile and the
> server is using an alpanumeric encoding instead of a simple hexadecimal.
> It could be just lowercase letters and numbers, then it's 36 symbols.
> That's about 5 bits/symbol, which means 26 characters for a 128 bit
> random key. That's quite acceptable for occasional bacups I think.

   The good thing with using the PBE is that the password/password
phrase could be something meaningful to the user, instead of having a
random string that the user has no chance of remembering (and will
definitely have to write down somewhere - you know how when you try to
enforce security too stringently, users end up subverting it by doing
unwise things the the security methods at hand - e.g. like putting the
password in the name of the backup, on a sticky note with the floppy,
or other such things).



> Yes, I had that idea in my mind when I started this backup thingy (if I
> can say that I started it at all). I wanted to have a PC application and
> I still want to have it very much as the one I use is a piece of crap.
> There is a java version of PasswordSafe but unfortunately that is also
> very lame UI wise. It's a shame, because I liked the original windows
> version a lot. But the PC UI is not a problem, I'll be happy to do it
> once I released the initial backup functionality.

   I was thinking more of a web-app type of app, not so much a rich
client / desktop app. The user has to run the backup server anyway in
order to do the backup; thus, it would be nice if the backup server
provides a UI for manipulating the content of the backup as well
(instead of having yet a third app for editing the backups).

> There would be an even better solution that I did a prototype of for my
> previous employer. I'm quite sorry that I didn't come up with the idea or
> that we didn't publish it. I might ask my ex-boss how acceptable it would
> be for me to do that.

    Hey, anything that would give us a kickstart would be nice.

> Yepp. I always wanted to create a generic Entry type with autogenerated
> Forms. Using that would eliminate this problem as well. However it's not
> completely trivial in the MIDP environment as we don't have reflection
> and using Hashtables in each entry would probably waste a lot of memory.
> But this could be profiled.

   I was thinking more in terms of including the flexibility on the
server side, and leave the phone app to be as limited as it needs to
be. So, my thought went something like this : the client asks for
"Entry Layout v. 1.1" for a backup that is stored as version 1.0 (e.g.
the client upgraded from 1.0 to 1.1 but the backup was done in 1.0).
The server reads the stored records using the 1.0 entry spec, and then
writes out the results the the client using spec 1.1 (that is assuming
that the server will have the necessary crypto pieces - e.g. the
password - to decrypt the backup and read the records).

>
> I'm also on NetBeans. The Mobility Pack is quite cool but it wasn't there
> in 2002 when I started the project and I always wanted the project
> to remain IDE agnostic exactly because I thought of other developers who
> might use a different environment. I know it wasn't worth it since it's a
> very small project.

   I was thinking of maybe having a separate folder with a couple of
NetBeans projects pointing to the source code. Thus, we can keep the
regular Ant script  (e.g. so that you can build and release it without
NetBeans) and still have the Mobility Pack advanced functionality. I
understand the concern with the project being accessible to
non-NetBeans users; however, I don't find it as a good enough reason
to not move forward with something better.


> The debugging should work, as there is a linux shell script that starts
> the application in the emulator with debugging enabled. You just have to
> attach the debugger. I know it's one step more than from the IDE but it
> works for the Eclipse guys too. However, I'll review what I could do
> about it.

   Sure, if debugging works, it would probably be a good idea to put
up a note on the site on how to do so.

>
> I started to use the Mercurial VCS lately and I like it a lot and I'm
> planning to move the whole project under it. I think I'll keep the
> sourceforge repository as well and push the changes there from time to
> time but I'll use Mercurial locally and to work with the contributors
> (well, that's you :) ). BTW it has a very nice NetBeans support. It
> allows you to do the commits locally and then other developers can pull
> the changes from you to their repository. Would you mind start using
> that? I can publish a URL where you could pull the latest revision from
> after integrating your patch and from then on you could use it.

     That'll be fine with me, I was looking for a good excuse to start
using Mercurial anyway. The other day I pulled down the NetBeans
mercurial repo, but I haven't done anything with it. One thing that is
slightly concerning with that approach is that I see a lot of
complications with the Hg usage on the NetBeans mailing lists, and
since it's a distributed VCS some things are just conceptually
different and could cause unnecessary trouble.


Cheers,

Alex K