I think there is market for in-database encryption (probably small), basically the case when people want to protect the data from a casual look (embedded use of Firebird, dictionaries, etc.). Here EFS is not an option.

On the other hand I believe that at the moment project does not need to worry about the strong (i.e. reasonably unbreakable) in-database encryption. But when considering implementing the "weak" one, we should design it so, that people that need such things get a posibility to do this themselves.

We already know that most physical I/O goes through a relatively simple interface, however the temporary storage - does not. When we define similar interface for the temp files management, I think we are done - people have the ability to embed Firebird in their binaries and provide their own implementation of the secure remote protocol (e.g. SSL-based), secure storage (e.g. get TrueCrypt people to provide an API that can be used to store data on a TrueCrypt partition) and protect the binary from the intrusion as well.

So, I think this level is achievable, how much time would it require and what prio does it have - that is the task for the TTG.

Roman




"Olivier Mascia" <om@...> schrieb:

>Le 6 nov. 2010 à 13:58, Geoff Worboys <geoff@...> a
>écrit :
>
>> I have not mentioned network security because I don't know
>> enough about it. I use a VPN and am happy with it, I've never
>> felt the need to building my own encryption over top of it.
>
>Good point. VPN for the network, EFS for the data and possibly temp
>files.
>Now, what was this discussion all about? :)
>
>--
>Olivier Mascia
>
>
>------------------------------------
>
>Yahoo! Groups Links
>
>
>

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.