× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I did not get around to actually trying out Qc3DecryptData.

Yesterday the DLEs in the debug eval of record really told me all I needed
to know. This morning I looked more at the debug eval
of encodedExchangeToken, saw the leading x'0058' and realized you had it
defined as varying length. That value tells me that XML-INTO returned 88
bytes and the -base64 argument to enc told me it was base64 indicating the
actual length received (based64 decoded) was 66 bytes with two trailing pad
characters (the == from record) leaving 64 "real" bytes. The last 16 bytes
(the DLEs) then must have been in the original stream (OK, maybe AES
decryption and base64 decoding uses DLEs for errors or somesuch though I've
never seen that behavior or found it documented). In any case "someone" is
adding 16 bytes to encodedExchangeToken prior to your receiving it with
XML-INTO. As you did not provide the XML file (as requested with 8. Post
the contents of /home/I0RS01HU/INPUT.xml) I'm assuming it's there in the
file and that XML-INTO didn't add it (an add which I've never seen and I
have played with it, XML-INTO, in the past).

As you now have it working with openssl enc I wouldn't bother changing.

Personally I use the i cryptographic APIs (but I'm also somewhat biased
when it comes to system APIs) when doing development.

When the SQL encrypt and decrypt functions first came out I did take a
quick look at them and immediately saw that there were a whole lot of
features (that I sometimes use) that the SQL interfaces do not support. So
I would not use them unless forced to -- meaning that someone was sending
me data encrypted using say ENCRYPT_AES. To date I have never run into
that situation.

I do however wonder why base64 is being used as it appears to be text data
being exchanged (with the exception of the DLEs) and what padding might be
done if say the "real" data was only 45 bytes rather than a multiple of 16
such as 48.

Hope this helps,

On Thu, Nov 21, 2019 at 10:09 AM Rishi Seth <rishiseth99@xxxxxxxxx> wrote:

Hi,

How could we say or conclude so because whenever i interactively call
openssl command the same DLE seems to be coming that time as well in the
result of pase ?

so does this mean xml itself is faulty i mean the value which is supplied
in XML (specially data in that encodedexchangetoken field in that XML file
itself is faulty ?)

secondly were you able to run that 'Qc3DecryptData' API program
successfully could you please share your program example for current case
as i tried to use Qc3DecryptData API for same decryption (Using AES128
Algorithm) but it did not work because i did not know how the data was
encrypted only decryption thing i was focused on, as i did not know how the
data was encoded so may be those sql encrypt and decrypt function also did
not work for this case also when you would have used that Qc3DecryptData
API was your program capable to handle each time different XML files data
like the one which i shared was having XML into kind of builtin functions
so it was capable to handle those different XMLs.
1) If same decrypted value could be achived using Qc3DecryptData' API
Could you please share that program code example ?

2) Can same result be achieved using SQL Decrypt function as well if yes
then could you please share that as well?

3) Which way should be best technically among of all these 3 approaches
in case same decrypted value could be achieved using openssl,
Qc3DecryptData API,SQL Decrypt function ?



Thanks much...



On Thu, Nov 21, 2019 at 1:44 PM Bruce Vining <bruce.vining@xxxxxxxxx>
wrote:

The DLEs are in the original XML stream being received.

On Wed, Nov 20, 2019 at 3:17 PM Bruce Vining <bruce.vining@xxxxxxxxx>
wrote:

Since Rishi has provided the encrypted stream and the key I'll, if I
find
the time (which as I'm currently free of work should be possible),
decrypt
using Qc3DecryptData and at least find out if it's in the stream or
being
added later when running cmd through the UNIXCMD interface...

On Wed, Nov 20, 2019 at 1:12 PM Scott Klement <sk@xxxxxxxxxxxxxxxx>
wrote:

The other possibility is that the PASE shell is inserting them, maybe
thinking it needs to escape something for the sake of a terminal?

On 11/20/2019 9:32 AM, Bruce Vining wrote:
As I cannot imagine Scott inserting those DLEs I have to assume they
are in
the XML document.
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-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



--
Thanks and Regards,
Bruce
931-505-1915



--
Thanks and Regards,
Bruce
931-505-1915
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-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 RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-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




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.