On 11/08/10 18:43, Jim Starkey wrote:

> On 11/8/2010 10:32 AM, Alex Peshkoff wrote:
>> On 11/08/10 18:15, Jim Starkey wrote:
>>> On 11/8/2010 6:38 AM, Daniel Rail wrote:
>>>> I suggest here not to go into details of crypt implementation (what
>>>>> algorithm, what library, etc.). Instead interfaces needed to support
>>>>> line& file encryption should be defined.
>>>> It's all that I'm asking for, is interfaces to be able to define our
>>>> own line and file encryption.
>>>>
>>> I'm afraid that just adding interfaces isn't nearly enough. To do even
>>> plausible line encryption (out of SSL), you need the following:
>>>
>> Certainly, we need to have all of this. Only interface is definitely not
>> enough. But as far as I've understood Daniel, interface is enough from
>> user's POV to be able to write crypt plugin with crypt algorithm
>> particular user needs.
> There is no point in having an encryption interface without a mechanism
> to manage keys.

Certainly. But if we use encryption plugin, we must provide to it
ability to deal with keys. How can we ourself decide which key is
appropriate for black-box plugin? What about exchanging keys with client
on handshake - that's definitely out job, plugin writers should not care
about protocol.

>>> 1. Creation or maintenance of a public key pair on the server for key
>>> transmittal.
>> Suppose this is one more hook on server startup. How does plugin
>> generate keys (or loads from disk - for line encryption that is probably
>> acceptable) is not our problem.
> That's something to be decided. For NimbusDB, I generate an RSA key
> pair at server start up time so I don't have to store the private key on
> disk. But are alternatives, depending on how much you trust the
> security on the disk. If you're considering page level encryption, by
> definition you don't trust the disk.

If we call plugin to obtain keys on server startup (BTW, looks like we
do not need to care about private key at all - only plugin should know
it), we can't say for sure where from did keys arrive (and how will be
used later). One can always return 0x55AA as a key and use it to XOR
data in the packet :-) Another question that we can and must recommend
not to store keys on disk if users wish to use not only line, but also
pages encryption.