Re: Unencrypt an FTP'd file -- MIDRANGE-L

Hi Kathie,

> I asked the customer the CCSID they used and this is their reply:
> "All the data is sent in ASCII format not sure what code page that is on
> the 400.

There are many different codepages that can be called "ASCII".  The ASCII
codepage used on Windows systems in the United States and several other
western countries is 1252.  Unix systems usually use 819.  MS-DOS in the
United States uses 437.

But that's the least of your problems right now.  MOST of the characters
in codepages 437, 819, 1252 are the same.  So, if the document is still
unreadable after setting it to one of the ASCII codepages, then the
codepage isn't your problem.

> Also below are the settings that were used to encrypt the
> document.
> Format Type: S/Mime Signed and Encrypted
> Encryption Type: RC2 128
> Signing Algorithm: SHA1 160
> Compression: NO
> Let me know if you can do this type of S/Mime....I have several other
> encryption options and signing options that I can choose between.  The
> ones above though are the most common."

If this is S/MIME then there are a few different things going on here:

You've got the signature that you use to verify that the document was sent
by the people who say they sent it, and that it has not been modified by a
3rd party in transit.

S/MIME was originally developed for e-mail, and so it may have the
document base64 encoded to ensure that it will not be corrupted by the
transport media.  This precaution isn't necessary for FTP, but S/MIME
usually uses it.

Then you've got the actually cryptography, and it would appear that you're
using an 128-bit RC2 cipher for that.  Problem is, I don't think RC2 is
natively supported on the iSeries -- you'd have to write your own
cryptography code to handle it.

So, to handle it, you'd have to:

a) Parse the MIME headers from the message to get all of the relevant
information.

b) Base64-decode the message data.

c) Check the digital signature to ensure that everything's safe.

d) Decrypt the document.

I really doubt that you want to code this yourself.  It would take a lot
of time and a lot of study.  I would recommend that you look for a
software vendor who can sell you an S/MIME package.

Most EDI over Internet software supports S/MIME, since it's used in the
AS1 standard for EDI.  You might try contacting the typical EDI people,
Inovis, TrailBlazer, Extol, etc.


> Perhaps I can ask them for some other encryption? If so, do you have a
> suggestion?

Personally, I'd just encrypt the transportation channel rather than the
document itself.   In other words, send the document over an SSL channel.
Let SSL protect the document in transit, but have the receiving
application receive it in unencrypted form.

Granted, depending on your scenario, this may not be an option.  Hard to
say, since I know very little about your application.