The following embedded SQL example works for me, i.e. data is correctly encrypted and after decrypted again.
ctl-opt datfmt(*iso) timfmt(*iso);
//------------------------------------------------------------------------
dcl-s Text varchar(20) inz('My encryption data');
dcl-s Encrypted varchar(256) ccsid(65535);
dcl-s PassWord varchar(15) inz('MyPassword');
dcl-s Decrypted varchar(256);
dcl-s Error char(50);
//------------------------------------------------------------------------
Exec SQL set :Encrypted = Encrypt_AES(:Text, :Password);
Dsply SQLCODE;
Text = Encrypted;
Dsply Text;
Exec SQL Set :Decrypted = Decrypt_Char(Trim(:Encrypted), :Password);
If SQLCODE < 0;
Dsply SQLCODE;
Exec SQL Get Diagnostics Condition 1 :Error = Message_Text;
Dsply Error;
EndIf;
Text = Decrypted;
Dsply Text;
*INLR = *On;
There were 2 problems in the previous example codes:
1. The output field for the encrypted data was too short. Encrypted data need (much) more space than the original data.
2. The ouput field must be generated FOR BIT DATA which means CCSID 65535. The CCSID can be explicitly set in RPG since Release 7.2.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them and keeping them!"
„Train people well enough so they can leave, treat them well enough so they don't want to.“ (Richard Branson)
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Peter Dow
Sent: Mittwoch, 2. Oktober 2019 21:11
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Regarding Decryption of AES128 encrypted data in RPGLE and query regarding CRC 32 [PRIVATE REPLY]
You might be able to encrypt UTF-8 (i.e. ccsid 1208) data if you do it with IBM's encrypt_AES SQL function. But data encrypted by some other interface likely will not work.
My impression is that IBM's encryption algorithm throws some other stuff into the encrypted field, such as the password hint, possibly the method of encryption (AES, TDES). That allows the decrypt functions to figure out the encryption method without you having to specify it. But that means the encrypted value is not going to match the encrypted value from some other encryption method.
However, I wouldn't make any blanket statements about what cannot be done on the IBM i. Just because it can't be done in SQL doesn't mean it's not possible. For example, this link
https://www-356.ibm.com/partnerworld/wps/servlet/download/DownloadServlet?id=4E$V_2UMH5yiPCA$cnt&attachmentName=protecting_ibm_i_data_with_encryption.pdf&token=MTU3MDAzOTY5OTA0MQ==&locale=en_ALL_ZZ
has a good discussion of encryption/decryption on the IBM i, which includes the following excerpt:
"Java-based interfaces
The IBM Java-based cryptography interfaces, IBM JCE and IBM JCEFIPS, are supported by IBM i platforms along with the other IBM systems. AES, DES and TDES are some of the encryption methods supported by the IBM Java Cryptography Extension Provider. The IBM JCE also includes support for hashing algorithms and a random-number generator. The IBM JCE is a standard extension to the Java 2 Software Development Kit (J2SDK), Standard Edition. The JCE implementation on IBM i is compatible with the Sun Microsystems implementation. The IBM i Information Center contains documentation regarding the unique aspects of the IBM i implementation.
The IBMJCE and IBMJCEFIPS do not use any of the IBM i cryptography interfaces. All of the cryptography support is completely implemented in Java. "
--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx> pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx> /
On 10/2/2019 2:17 AM, Rishi Seth wrote:
Hi Peter,
As per this it seems like we can never decrypt the data which is
encrypted using some other format like UTF8 or through some other
interface using AES algorithm in AS400 correct ?
Thanks
On Mon, Sep 30, 2019 at 7:13 PM Peter Dow <petercdow@xxxxxxxxx> wrote:
Hi Rishi,
I went to the website you mentioned,
https://www.devglan.com/online-tools/aes-encryption-decryption, and
tried decrypting
u3VtNgfyWU9faZc3Iaa8ZWbE5UZCfmC17yA4MyW0ghflt9dNQNDpCcgMZiG/kXPE4vv2C
HL93B4iKiODHxxdVA==
with password (secret key)
6-9d15-ec98bcc81ec4275OIM1TS7LI
and I noticed a couple of things.
1. Since the encryption is AES128, the password length must be 16
bytes. The pswd in your program is 31 bytes.
2. The "encrypted" data is actually base64 encoded. In order to
decrypt it in RPG, you would first have to decode it from base64, then decrypt it.
On top of that, when I used the aforementioned website to encrypt
'whatever text', in AES with 128-bit key, mode ECB, and password
'mypasswordis16xy', the encrypted value is
x'831720A57F742CBB3A86AB24A3AA23AE'.
If I use the SQL encrypt_AES function, with the same password, the
encrypted value is
x'4CB947FF0025D5A6B96180506FFE4F23B96180506FFE4F23'.
The reason for this difference probably has something to do with the
following notes from IBM's SQL manual on the encrypt_AES function:
"The length attribute of the result depends on the arguments that are
specified:
* when /password-string/ is specified but a /hint-string/ is not
specified, the length
attribute of /data-string/ plus 24 plus the number of bytes to
a 16-byte boundary.
* Otherwise, the length attribute of /data-string/ plus 64 plus
the number of bytes to
a 16-byte boundary."
Apparently IBM's encrypt_AES function includes more than just the
encrypted value in its result.
In short, it looks like you cannot use IBM's decrypt_AES function to
decrypt a value encrypted by anything other than IBM's encrypt_AES
function.
--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx> pdow@xxxxxxxxxxxxxx
<mailto:pdow@xxxxxxxxxxxxxx>
/
On 9/30/2019 4:50 AM, Rishi Seth wrote:
I Know below is the IBM API for same but need a real working example
which
could decrypt data which is encoded using UTF8 or ACII. with 128 bit
key and Mode is ECB?
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our
affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
