SHA1 Code ermitteln

[Fuerchau]

Das liegt wohl mal wieder an der CCSID!
Da hier auch wieder C-Funktionen eine Rolle spielen, ist die aktuelle Locale entscheidend (das hatten wir hier auch schon mal bei anderen API's).
Wenn man nichts macht, geht das API von der CCSID 037 aus.
Ich denke mal, das wird wieder der Grund sein.

Weiteres hilft dir ggf. hier:
http://newsolutions.de/forum-systemi...ghlight=locale

[HJZeig]

Hallo! Danke für die Antwort. Leider liegt es daran auch nicht. Das habe ich bereits versucht - aber dennoch kommen "wundersame" Ergebnisse. ASCII Konvertierung ist auch gelaufen....

[Fuerchau]

Initialisierst du auch einen Kontext ?
Create Algorithm Context (QC3CRTAX, Qc3CreateAlgorithmContext)

Und wie stellst du fest, dass der Hash "seltsam" ist ?
Das Ergebnis läßt sich ja nicht mit einem Hash auf Windows vergleichen.

Wo kommen deine Daten her?
Wie ist die CCSID deines Job's, der DB usw. ?

[TARASIK]

Hallo,
diesen SHA1 zu bekommen geht laut Scot Clement auch ohne APIs:

SHA1, MD5, and Base64 Without APIs
Article ID: 57612
Posted January 15th, 2009
By:
Scott Klement
I recently discovered that IBM offers a free tool for PASE that provides the capability to encode and decode Base64, as well as calculate MD5 and SHA-1 hashes. This tool works both interactively and from programs and is relatively easy to use.
Which tool, you ask? OpenSSL. OpenSSL is a prerequisite for running PHP as well as the (different, but similarly named) OpenSSH suite of tools. This article describes what's needed to use the OpenSSL tool for MD5, SHA-1, and Base64.
Prerequisites
IBM provides the OpenSSL tool at no charge as part of the IBM Portable Utilities for i5/OS (5733-SC1) licensed program. If you're running Zend Core or OpenSSH on your IBM i system, you already have 5733-SC1 installed. If not, you'll need to order a copy from IBM. It's a no-charge item. Visit IBM's home page for 5733-SC1 if you want more detailed information about the product, what it offers, and how to install it.
You'll also need PASE (57xx-SS1 option 33) installed. PASE is part of the IBM i operating system, and is included on the same CDs that you use to install the operating system, but it isn't installed by default.
I also highly recommend having QShell installed. QShell makes it easier to integrate the PASE utilities with native IBM i software. QShell is another component of IBM i and is included on the operating system CDs. You can read more about it in the Information Center.
Performing a Hash Interactively
To give OpenSSL a try, start an interactive PASE shell by typing the following command:
CALL QP2TERM
Now you should be at a PASE shell. ("Shell" is a term that means "command-line environment.") You can try to create an MD5 hash for a simple string by typing the following command:
echo "Hello World" | openssl md5
It should print the string "e59ff97941044f85df5297e1c302d260" to the screen. That's the MD5 hash for the words "Hello World" in ASCII. That's it. Pretty easy, huh?
To create an SHA-1 hash, simply replace md5 with sha1 in the preceding command line, so that it looks like this:
echo "Hello World" | openssl sha1
If you want to calculate the hash of a stream file in the IFS, you can use the following syntax:
openssl sha1 < /xxx/yyy/mystream.file
In the preceding example, you'd want to replace /xxx/yyy/mystream.file with the actual IFS path. PASE will open the file you specify and feed its contents into the openssl program. The openssl program will calculate an SHA-1 hash from its contents. If you prefer an MD5 hash, you would simply use md5 in place of sha1 in the preceding command.
For example, if I have a file named /java/jdbc/sqljdbc.jar in my IFS, I could calculate an MD5 hash by typing the following:
openssl md5 < /java/jdbc/sqljdbc.jar
Running these hashes interactively is a great way to tell whether two files are identical. For example, if you have two computers that both have an sqljdbc.jar file on them, and you want to know whether the two jar files are identical, you could an SHA-1 hash on both files and check whether the hashes match. If the hashes match, the files are identical. The OpenSSL tool is available for Windows, Mac, and Unix as well as IBM i, so you can use this technique to check whether files are the same, even if they're on different operating systems.
Hashes from a CL Program
Now that you know how to calculate a hash interactively, how do you do it from a CL program? You could, of course, run the exact same command that you ran interactively from within a CL program, but the output would display on the screen instead of going to your program. Oops!
The trick is to write the output to something that CL can read. This is where QShell comes in handy, since QShell has utilities that let you write data to physical files, data queues, or data areas. In this example, I'm going to use a data area.
STRQSH CMD('export PATH=$PATH:/qopensys/usr/bin && +
echo "Hello World" | +
openssl sha1 | +
datarea -wl sha1output')

PATH is the name of an environment variable that QShell and PASE use to find commands. By default, QShell doesn't have /qopensys/usr/bin in its PATH, since /qopensys/usr/bin contains PASE programs. The first line in the preceding code adds /qopensys/usr/bin so that QShell will be able to find the openssl command. The && at the end of the first line means that the remainder of the command line will be run only if the PATH was set without causing an error.
The next line prints the words "Hello World." The output is sent to a pipe, signified by the | character at the end of the second line. That pipe connects the output from the echo command to the input of the openssl command.
Openssl calculates the sha1 hash and then writes the hash to another pipe, which connects it to the datarea command, which is a QShell tool that reads from OpenSSL's output and writes it to a data area that I can easily read back into my CL program.
There's still a flaw in the above command, however! The SHA-1 hash will be calculated on ASCII data, even though my CL program specified "Hello World" in EBCDIC. Why would it do that, you ask? Because PASE is an ASCII environment, so when PASE receives data from QShell, it automatically translates from EBCDIC to ASCII. There are times when that's desirable. For example, if you're checking the SHA-1 (or MD5) hash on a password that will be sent to an ASCII machine, you'll want to translate the data to ASCII before calculating the hash. After all, that's what the ASCII machine will be doing. However, there are other times when you want the hash to be on pure EBCDIC data, or even raw binary data.
Fortunately, IBM provides an easy way to control whether PASE translates EBCDIC to ASCII: the QIBM_PASE_DESCRIPTOR_STDIO environment variable. You can set this variable to T (for text) to enable translation, or B (for binary) if you want to disable translation. But there's still a problem. If you disable translation, the hash itself will come back to your CL program as gibberish, because it'll still be in ASCII! Fortunately, QShell also includes a tool named iconv, which you can use to convert between one CCSID and another, which means we can selectively control when translation is done.
Consider the following CL program:
PGM PARM(&DATA)

DCL VAR(&DATA) TYPE(*CHAR) LEN(32)
DCL VAR(&SHA1) TYPE(*CHAR) LEN(40)

CHKOBJ OBJ(SHA1OUTPUT) OBJTYPE(*DTAARA)
MONMSG CPF9801 EXEC(DO)
CRTDTAARA DTAARA(SHA1OUTPUT) TYPE(*CHAR) LEN(40)
ENDDO

ADDENVVAR ENVVAR(SHA1_INPUT) VALUE(&DATA) REPLACE(*YES)
ADDENVVAR ENVVAR(QIBM_PASE_DESCRIPTOR_STDIO) VALUE(B) +
REPLACE(*YES)

STRQSH CMD('export PATH=$PATH:/qopensys/usr/bin && +
echo "$SHA1_INPUT" | +
openssl sha1 | +
iconv -f 819 -t 0 | +
datarea -wl sha1output')

RTVDTAARA DTAARA(SHA1OUTPUT) RTNVAR(&SHA1)

SNDPGMMSG MSGID(CPF9897) MSGF(QCPFMSG) MSGTYPE(*COMP) +
MSGDTA('SHA1 hash is' *BCAT &SHA1)

ENDPGM

The program starts by creating a data area called SHA1OUTPUT to receive the output from QShell. It then creates an environment variable named SHA1_INPUT and puts the data (received as a parameter) into that variable. The program also sets the QIBM_PASE_DESCRIPTOR_STDIO to tell PASE not to translate ASCII to EBCDIC.
The program runs a QShell command. The QShell command reads whatever is in the SHA1_INPUT environment variable and feeds that into the input of the openssl command. Openssl calculates the SHA-1 hash and writes it in ASCII to a pipe. The iconv QShell command translates that ASCII value to EBCDIC, and finally, the datarea command writes it to a data area.
The CL program then retrieves the contents of the data area and prints it as a completion message. The result looks something like this:
CALL PGM(SHA1CL) PARM('Hello World')
SHA1 hash is 3b549cbb8a2e2d7d7377fc9fdc048f0074b0a90d

That tells me the SHA-1 hash of "Hello World" in EBCDIC. If I wanted to use MD5 instead of SHA-1, I'd simply replace "openssl sha1" in the STRQSH command with "openssl md5".
Base64 Encoding Interactively
It's rarely useful to base64 encode something at an interactive prompt, since base64 is usually used as part of a larger process, such as HTTP authentication or attaching a file to an email message. However, there are occasions, especially when you're debugging something, when you want to try encoding or decoding something.
You can base64 encode some data interactively with the OpenSSL command the same way that you calculated hashes. Just replace md5 or sha1 with base64.
echo "Hello World" | openssl base64
Or to encode an entire file:
openssl base64 < /xxx/yyy/myfile.file
You can decode base64 encoded data by passing the -d switch to openssl. For example, if you're debugging a program and you see that it passes a base64 encoded string and you decide you want to know what's in that string, you could do something like this:
echo "U2NvdHQgS2xlbWVudCBpcyBteSBoZXJvCg==" | openssl base64 -d
These commands (both base64 and hashes) will work on any sort of IFS stream file. That includes .PDF, .JPG, .PNG, .DOC, .XLS, .CSV, and so forth.
The purpose of base64 is to let you transfer data without changing the binary values of the bits that make up the file. For example, if I have a picture that I want to transfer through email, I can base64 encode it. While encoded, it doesn't matter whether the email message gets translated to ASCII or EBCDIC. It doesn't matter whether the character set changes from USA English to Russian or Japanese. No matter what happens to the base64 encoded data, when it's decoded, it returns to an exact byte-for-byte copy of the original data. This behavior is useful when sending a picture through email, since pictures aren't made up of text. Instead, the binary values of the bytes in my file tell the system which pixels to set to which colors when displaying the picture. Because the data isn't text, if I tried to run it through an ASCII to EBCDIC table, I'd change the pixel values and corrupt the image. Base64 ensures that this won't happen.
However, if you do use base64 on text data (as opposed to binary data such as a picture) it's important to make sure that the data is already in the correct character set for the destination computer. Again, base64 will ensure that the raw binary data that makes up the file stays intact. So, for example, if you have a CSV file that's encoded in EBCDIC and you base64 encode it, it will remain EBCDIC. Even if the encoded data gets translated to ASCII, it'll still decode to an EBCDIC file--even on an ASCII machine where that EBCDIC looks like gibberish. The moral of the story? Make sure you convert the file to ASCII (or whatever is required) before you base64 encode it.
Base64 Encoding from a Program
The same concepts that I used to run hashes from a CL program will also work for base64. Give it a try!

[KM]

Also ich konvertiere vorher erst den String von EBCDIC (1141) in ASCII (819). Erst danach führe ich den Qc3CalculateHash aus.

Damit funktioniert's bei mir problemlos.

Gruß,
KM

[Fuerchau]

Anstelle von 819 solltest du besser 1252 wählen.

Wie geht SHA1 denn mit Unicode um ?
Oder muss man dann UTF-8 (1208) verwenden ?

[KM]

Anstelle von 819 solltest du besser 1252 wählen.

Von Windows war hier ja nicht die Rede.

Und wenn man SHA-1 Codes vergleichen will, muß natürlich der Ausgangsstring jeweils identisch vorliegen (also mit derselben Codepage). Wenn Du Probleme mit dem "@" hast, bedeutet das ja nur, dass dahinter offenbar ein anderer Hex-Code liegt als erwartet. Also scheint die Codepage nicht zu stimmen.

Wie kommst Du denn darauf, dass der SHA-1 Code fehlerhaft ist? Womit vergleichst Du den?

Gruß,
KM

[Fuerchau]

1252 hat nichts mit Windows zu tun sondern entspricht dem vollständigen ISO8859-1.
Die 819 hat nicht den vollen Umfang da die Codes 80-9F nur 1 zu 1 übersetzt werden. Mit 819 geht z.B. das €-Zeichen verloren.

Ascii Table - Codepage 819 - Latin 1 - ISO 8859-1
Windows-1252 - Wikipedia, the free encyclopedia

Das Problem hatte ich letztens mit (leider) den CPYxxxPCD-Befehlen, da die nur 819 und nicht 1252 unterstützen.

Nunja, und Binärdaten sollten natürlich nicht gewandelt werden .