> This means you must use client-side crypto or encrypted file system.
> If you send plain-text + key to the "sql server" and call external crypto
routine from within the DBMS, then it will not be "oblivious" to the crypto
stuff :-).
Unfortunately, you need both.
client crypto: secure transfer to client (could be done with SSL/SSH
tunneling), but also offering the option of leaving sensitive bits encrypted
on the screen when others are peeking over your shoulder. Imagine: you
request progress notes of patient X, where you have commented on his/her
drug seeking behaviour. This patient is interested in some information which
is stored in the same progress notes, and you want to show him on screen
what you had documented ("See, I told you ....") but you don't want hoim to
see your "private" comments. In gnumed, the whole information comes from the
server, but the sensitive bit is encrypted with a different method and
appears on the screen only as a highlighted symbol. Double clicking it you
can enter the pass phrase and decrypt it, otherwise you can only read the
less sensitive material.
server crypto / crypto FS:
There are many items that are impractical to encrypt at a level "higher"
than the FS: especially anything that has to be indexed or searched in a
specific order, as well as items that are that small tat they would assist
"known plaintext attacks". To keep that information secure, you need a
secure file system.
> How do they/you propose to deal with the key management problem? I am not
talking about complying with any regulation at all here. As you know, any
crypto system is only as secure as the security of its keys :-(.
We have a hierarchical structure of public/private key pairs, where the
"master" private keys are not supposed to be kept on the system. Wait until
I release the functional beta (soon), it is easier to see it working than to
explain it.
Horst
