Had missed that part about you column providing ample space for the encrypted string, sorry.
I guess your encrypted data is 'readble', i.e. not causing that -202, and rather the decryption result would be causing the -202?
Can you unload or display the encrypted data?
The only way out I could think about is EILSEQ_COMPAT_MODE onconfig param set to 1, for ignoring *certain* instances of -202 - not sure this is one of them.
You could enable this in a play Informix instance where you can copy the encrypted data to, then run the decrypt function on it. Maybe this would suppress the -202 and allow you access to the decrypted data. You could even play with DB_LOCALE, i.e. database codeset, there, so try this in different codesets since what would be an illegal character in one codeset might be legal and making sense in another.
------------------------------
Andreas Legner
------------------------------
Original Message:
Sent: Wed September 15, 2021 09:14 AM
From: TOM GIRSCH
Subject: ENCRYPT_AES/DECRYPT_CHAR
As soon as you truncate even one character off the end of the string, the error [correctly and expectedly] pivots to -26012, "The internal base64 decoding function failed."
Original Message:
Sent: 9/14/2021 6:34:00 PM
From: David Williams
Subject: RE: ENCRYPT_AES/DECRYPT_CHAR
I believe the idea is to keep remove characters from the end until you remove the bad characters and it decrypts ok.
------------------------------
David Williams
Original Message:
Sent: Tue September 14, 2021 11:51 AM
From: TOM GIRSCH
Subject: ENCRYPT_AES/DECRYPT_CHAR
I'm not sure how that would help. The data in the "bad" column is 43 bytes wide and the column allows a length of up to 250.
Original Message:
Sent: 9/14/2021 11:27:00 AM
From: Andreas Legner
Subject: RE: ENCRYPT_AES/DECRYPT_CHAR
I'd try copying the (encrypted) data into a dummy table with a char column just one byte smaller that what it currently is, then try the decrypt on that, maybe that would allow recovering of partial data at least. If not, try further narrowing the field, one byte at a time.
------------------------------
Andreas Legner
Original Message:
Sent: Mon September 13, 2021 05:43 PM
From: TOM GIRSCH
Subject: ENCRYPT_AES/DECRYPT_CHAR
A small C program is what I was hoping for, but so far they haven't offered that. My guess – and it's only that – is that the encrypted data contains an odd character (perhaps an emoji or something) that's throwing off the algorithm.
Original Message:
Sent: 9/11/2021 11:01:00 AM
From: David Williams
Subject: RE: ENCRYPT_AES/DECRYPT_CHAR
Hi,
Sounds like one for Tech Support.
If you can dump the page to get the row contents and have the key perhaps Tech Support can provide a small C program to decrypt it.
David.
------------------------------
David Williams
Original Message:
Sent: Fri September 03, 2021 06:26 PM
From: TOM GIRSCH
Subject: ENCRYPT_AES/DECRYPT_CHAR
Here's an esoteric one for you. If I have a column that's been encrypted with ENCRYPT_AES, and I know the encryption key, is it possible to decrypt that value external to the database, i.e., without using DECRYPT_CHAR? We're hitting an apparent bug where a particular column won't decrypt, but rather than giving a decryption error, it's mystifyingly giving error -202 (an illegal character was found in the statement). It's a single column in a single record in a table of 300,000. I'm able to isolate that value and insert it into a temp table and recreate the problem. I've replicated it in 12.10.FC14 and 14.10.FC6. I'm trying to figure out what's actually in the column (decrypted) to see if maybe there's an oddball character or something similar that's causing DECRYPT_CHAR to barf. If I can figure that out, I'd like to try to replicate the issue with a dummy encryption key; for obvious reasons, I don't want to send our actual encryption key in with the repro case.
TIA,
- TJG
------------------------------
TOM GIRSCH
------------------------------
#Informix