Agreed RE: "SHA-1 not secure". The security concerns with the use of SHA-1 relate to long-term hashes of security credentials like X.509 certificates. If you just want a decent checksum and aren't worried about the *very* unlikely possibility of the same hash for two different documents, then there's no issue. There's always that risk with any hash, but SHA-1 has some crypto weaknesses in being able to *engineer* such a collision.
Here's an amusing article from last year. The headline is utterly misleading, and doesn't mention that it "It took nine quintillion SHA-1 computations" :-) https://www.computerworld.com/article/3173616/security/the-sha1-hash-function-is-now-completely-unsafe.html What's really sad is how many "security experts" are now running around saying that SHA-1 is unsafe for things like checksums on encrypted ssh packets. They don't know / care anything about the context, or the difference between hmac-sha1 and basic sha-1. ICSF OWH is one way to do it, but for performance critical code you can do it cheaper if you drop down and just use the CPACF instructions for SHA1, SHA2, etc. With z14s, CPACF really screams and it turns out that SHA-2 is only a little slower than SHA-1. (ICSF uses CPACF for these too, but can add overhead that is significant to some applications). ICSF OWH can also require SAF/RACF permissions, which is silly and annoying. Kirk Wolf Dovetailed Technologies http://dovetail.com PS> you can use the z/OSMF Files and Datasets REST API to retrieve a file or dataset and also get a hash. On the response is an "ETag" header which has a hash. It is opaque as far as specification, but if you look at it you can probably guess what it is. It wouldn't be good to assume that it is anything other than an opaque "checksum" string. The purpose of this in the API is pretty cool: you can request the same file again and pass it the previous ETag and you will get a response that indicates that the file has not been changed, without having to transmit it to you again. Note: This may be of little use if your purpose is to have some other software calculate and match to it, since you really don't know it is calculated. On Tue, Nov 20, 2018 at 9:06 PM Phil Smith III <li...@akphs.com> wrote: > CM Poncelet wrote: > > >FWIW SHA1 hashing is *not* secure: you should use SHA2. No idea whether > > >there is a z/OS utility to do that: I use PGP. HTH. > > > > FSVO "not secure". If you're just creating a fingerprint to detect > accidental damage, it's surely good enough. If you're protecting > your bank account, maybe not so much. Given that the original request was > "to compare these hashes at source (z/OS) and destination > (linux) after transferring some sizable datasets", I suspect it'll be fine. > > > > In any case, ICSF can do it: > > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.csfb400/owh.htm > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
