I could not get it to work so it made me rethink the code and I got something much simpler than I had using _cipher api. Instead of all the api coding I am just using....


If Function = 'ENCRYPT';
EXEC SQL SET :ResultVarying = ENCRYPT_TDES(:InputVarying, :pw);

If Function = 'DECRYPT';
cast(:InputVarying as char(5000) for bit data), :pw);


There is some additional code that I am using to control access to this utility but the encrypting/decrypting is all done with the above code. Function is a parameter passed in along with an Input strip up to 5,000 bytes and a result string.

Not sure why exactly the cast needs to be done as it is on the decrypt but it's the only code that works. I plan on using this from any application that needs to encrypt or decrypt data so the password is only needed to be know by this application.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of SJL
Sent: Thursday, March 27, 2008 9:42 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: _cipher vs SQL Encrypt

Short answer: Yes.

- sjl

"Mike Cunningham" <mcunning@xxxxxxx> wrote in message
If a field in a database was encrypted using TDES and that row was inserted
using SQL and encrypted using SQL should the _ciper API be able to decrypt
that same field using TDES and the same password? No hint was included in
the SQL insert

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].