Yes, you can glue some kind of solution together to dodge this or that
kind's KNOWN exposure to the "sensitive information". But "database with
encryption" seems to be THE solution that wrap them together elegantly and
simply works for a lot of situations (definitely not promising the world
though :)

Yes, it would cost some Firebird developer's time, but in the mean time it
would save so much pain for programmers of applications built on top of
Firebird. Remember, not so many developers has expertise on the subject of
encryption and key managment. But I bet there are quite some application
developers out there in the world who want to keep some information secure
(I mean serously secure, not by obscuration).

BTW, talking about justifying the developing effort in Firebird developer
group, the reason I brought up the "old" issue is because I found that some
encryption-related code have already been in the Firebird code base since
2003 (based on the comment I read in the source files). I assume that the
architecture had been adjusted at that time to enable this effort as well.
If nothing existed in current code base, I would not say a word on this
giving all other priorities in core Firebird development :)

Thanks

On Thu, Nov 4, 2010 at 10:26 AM, Geoff Worboys <
geoff@...> wrote:

> Sijun Kang wrote:
> > [...], database with encryption actually solve problems that
> > might be incurred by "good programs" :)
> >
> > Let me elaborate a bit more - when EFS is mounted as a drive/
> > directory, all sorts of programs might "try to help you find
> > information" (such as google desktop search, microsoft search
> > companion, etc, etc). Although you consider them "good
> > programs", but they definite serve as a information leaking
> > hole (for one thing - who knows where they store their index
> > data or even transfer your data?).
>
> An interesting and relevant example - although I must say that
> my experience with these search engines is that they tend to
> find only documents they recognise (they don't try to index
> executables etc).
>
> Curiously this particular "problem" (if it is indeed a real
> problem, I've never read of complaints to this effect) could
> indeed be solved with simple obscuration (no key management
> or other such issues need apply). And since that can be done
> much much faster than real encryption it is something that you
> could propose - but I suggest explicit examples of problems
> (where the issue you describe actually does occur) would be
> the best way to convince developers to spent time on it.
>
>
> > Also worth mentioning is the operating system, although we
> > defintely consider it our friend (when free of virus/malware),
> > but it caches information to speed up IO access and thus also
> > contributes as another leaking channel of any sensitive
> > information stored in EFS. Anyway, this list can go on and on ...
>
> And yet you said earlier that you were "not promising the
> world!" ;-)
>
> To consider availability of information sitting in RAM really
> is getting into the realm of detailed security and not
> the sort of thing you can expect to achieve with simple page-
> level encryption/obscuration of the database.
>
>
> > Another thing - key management with EFS might be a pain,
> > whereas database with encryption might greatly reduce it
> > (with such mechanism as proposed by Jim Starkey - see his
> > post on this topic yesterday) and even pain-free.
>
> One of the reasons why I put forward Truecrypt as an example
> is that (secure) key management issues are already dealt with
> (keyfiles and tokens and smart-cards etc). I can just imagine
> Firebird starting to implement encryption and then getting
> lumbered with all these feature requests that would
> inevitably(?) follow.
>
>
> > BTW, Truecrypt's license is more or less copylefted. I don't
> > think you can deploy it along with your application without
> > making your application open-source.
>
> I think this effects you only if you are going to try and
> modify their product. If all you are going to do is have
> your user install Truecrypt (as available from the truecrypt
> website) the I don't think you have problems. There are other
> possibilities out there that could be investigated depending
> on your specific needs.
>
>
> > To summary (but not to conclude) -
> > A. encryption (either at database or file system level)
> > does solve problem within some defined boundary.
>
> I see what you mean but can't help feeling that you are
> stretching things a bit in trying to make this a real issue.
>
> > B. EFS serves well in situation where information needs
> > to be accessed by more programs.
>
> Well I'm not a fan of EFS, but volume encryption is very useful
> and centralises and broadens your security to cover many
> applications - indeed it can cover the entire operating system.
> The thing to remember with volume encryption is that it can
> be used to encrypt application data that applications have no
> control over (paging and hibernation). If you're worried about
> minor leakage (such as your words picked up for indexing etc)
> then system volume encryption is the appropriate solution.
>
> > C. database with encryption has less exposure surface
> > for sensitive information and might be able to make key
> > management easier.
>
> Here I have to disagree. If Firebird does eventually make
> encryption available (I can see them doing it just to stop the
> same arguments appearing every few months), I suspect that very
> few implementations using the encryption will actually be
> secure. People will use it and think that because they've
> enabled encryption they are "safe" ... well, if it makes them
> feel better who am I to complain?
>
>
> --
> Geoff Worboys
> Telesis Computing
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]