RE: _cipher API vs Qc3Encrypt/Qc3DecryptData vs SQL

Mark,

I am not aware of any, but recall that I left IBM 6 months ago so I'm not in a position to know what the current thinking in the database area is.

Bruce
http://www.brucevining.com/
Providing integrated solutions for the System i user community

"M. Lazarus" <mlazarus@xxxxxxxx> wrote:
Bruce,

Are there any plans that you know of to allow changing a read
trigger buffer? This limitation is a *major* barrier to retrofitting
encryption onto existing databases.

-mark


At 3/25/08 02:58 PM, you wrote:

I'm not sure you want to use a trigger for this type of
application. You could certainly encrypt the field using a trigger
on update/write, but the read trigger doesn't allow you to alter the
buffer delivered to the application (at least the last I looked) and
so you would still need application awareness to decrypt the data.

The APIs and the cipher instruction, where they overlap, are
accessing common function found in the Licensed Internal Code. If
it was me, I would tend to go the Qc3 API route only because the
APIs provide quite a bit more in the way of documentation. I
generally use MI only when there is no suitable alternative. And
while IBM supports the use of both MI and System APIs, the support
tends to be more readily at hand with APIs as MI just isn't used all that much.

SQL could certainly be used for this. But if you are not
currently using SQL I'm not sure that I would change over to it for
a one time application enhancement.

Bruce
http://www.brucevining.com/
Providing integrated solutions for the System i user community


Mike Cunningham wrote:
True, and that is where I might put it since I do want it to be
always encrypted but I still need to figure out if I do the trigger
with _cipher or Qc3 APIs. I don't think the SQL method would work in a trigger