Сталкивался ли кто-нибудь с необходимостью получению хеша по какому-нибудь файлу? По аналогии с md5sum в linux.
Есть задача убраться на минидисках, посмотреть сколько там файлов-дубликатов. Файлов всего 150к. Обычно, на других ОС, такую задачу решают через сравнения хешей.
Кто-нибудь знает как снять хеш в zVM/CMS?
Добавлено (27.06.2011, 13:05) --------------------------------------------- Отвечу сам себе, может кому пригодится. А то в рунете такой информации точно нет, так что пусть хоть здесь осядет.
В pipe CMSа есть специальный кейворд CRC, который позволяет снять CRC-хеш с входного потока. CRC конечно не фонтан, но для большей части целей сгодится. Результирующая чексумма представляет собой 16-битный ключ.
Пример использования 1: pipe < INPUT FILE A | crc crc16i | var hash'
В переменную hash будет сохранено значение хеша.
Пример использования 2: pipe < INPUT FILE A | crc append crc16i | > INPUT FILE A
А почему CRC не фонтан? Чем он так уж плох? Я совсем не изучал этот вопрос.
Вот тут есть годная статья почему CRC16/32 (и так далее) уже не фонтан для продвинутых IT-шников. Если в кратце, то подделываются относительно легко. Конечно в контексте поставленной задачи его более чем достаточно, но в плане криптоустойчивости лучше использовать другие решения.
Да какое там остроумие... Ну допустим, что кто-то в CMS найдет программу MD5 MODULE S1. И что? Кто и каким документом гарантирует соответствие стандарту? IBM такие бумаги раздавать не будет, оно ему не уперлось... smoker прав. Если хотите соответствие таких вещей стандарту, реализовывать надо самим. Хотите готовое - без нормальных сертификатов это будет просто работа на доверии. А если просто надо быстро решать проблему - CRC вам в руки... Нет готовой утилиты, а которая будет, будет недоверенной, а следовательно - бесполезной.
Freeware реализации не подойдут? Я портировал MD5 (а также SHA1, SHA256, SHA512, начал портировать TTH но не закончил) в z/OS и не вижу проблем их портации в CMS. Есть реализация MD5 на REXX (GitHub), конечно же, скорость очень существенно уступает компилированному коду, но, может быть, подойдет?
P.S. разница между CRC и MD5 примерно такая же, как между дверным крючком и замком И подделывается CRC не "относительно легко" а тривиально, так что для проверки целостности данных я бы не стал использовать CRC.
Сообщение отредактировал Gregory - Пт, 16.06.2017, 09:45
SHA-512 на System z Processor, работу с файлами допилите сами:
EJECT , SHA512 CSECT SHA512 AMODE 31 SHA512 RMODE ANY SAVE (14,12),,SHA512 SAVE REGISTERS * LR R12,R15 USING SHA512,R12 ESTABLISH BASE REG FOR PGM B START DC C'SHA512 - CALCULATES 64-BYTE SHA512 HASH FOR ' DC C'SUPPLIED DATA STRING, ' DC C'ASSEMBLED AT &SYSDATC &SYSTIME ' DC C'&SYSASM &SYSVER ' START DS 0H L R11,8(,R1) @ OF HASH + CV_MBL (OUTPUT) USING OCV,R11 * L R5,0(,R1) @ OF DATA LENGTH (INPUT) L R5,0(,R5) DATA LENGTH (INPUT) MVC OCV(@CV_LEN),ICV INIT CHAINING VECTOR ST R5,OCV_MBLL SAVE MESSAGE BIT LENGTH * XR R4,R4 ZERO R4 FOR DIVISION LHI R6,128 KIMD FOR SHA-512 REQUIRES DATA * TO BE MULTIPLIED BY 128 DLR R4,R6 REMAINDER IS IN R4 * QOUTIENT IS IN R5 SLL R5,7(0) DATA LENGTH FOR KIMD IN R5 LR R7,R4 DATA LENGTH FOR KLMD IN R7 L R4,4(,R1) @ OF DATA IILL R0,@SHA512 SET FUNCTION CODE LR R1,R11 @ OF PARM BLOCK FOR KIMD/KLMD KIMDLOOP KIMD R4,R4 COMPUTE SHA512 INTERMEDIATE BNZ KIMDLOOP REPEAT IF NOT DONE * LR R5,R7 SET DATA LENGTH FOR KLMD KLMDLOOP KLMD R4,R4 COMPUTE SHA512 LAST BNZ KLMDLOOP REPEAT IF NOT DONE GOBACK XR R15,R15 CLEAR R15 RETURN (14,12),RC=(15) RESTORE REGISTERS AND RETURN * * TABLES AND CONSTANTS POOL * ICV DS 0D INIT CHAINING VECTOR ICV_H0 DC XL8'6A09E667F3BCC908' ICV_H1 DC XL8'BB67AE8584CAA73B' ICV_H2 DC XL8'3C6EF372FE94F82B' ICV_H3 DC XL8'A54FF53A5F1D36F1' ICV_H4 DC XL8'510E527FADE682D1' ICV_H5 DC XL8'9B05688C2B3E6C1F' ICV_H6 DC XL8'1F83D9ABFB41BD6B' ICV_H7 DC XL8'5BE0CD19137E2179' ICV_MBL DC XL16'00000000000000000000000000000000' * LTORG * DROP R11 DROP R12 * REQUATE * * PARAMETER BLOCK MAP * OCV DSECT OUTPUT CHAINING VECTOR * OCV_H0 DS XL8 OCV_H1 DS XL8 OCV_H2 DS XL8 OCV_H3 DS XL8 OCV_H4 DS XL8 OCV_H5 DS XL8 OCV_H6 DS XL8 OCV_H7 DS XL8 OCV_MBL DS XL16 MESSAGE BIT LENGTH ORG OCV_MBL DS XL8 OCV_MBLH DS XL4 OCV_MBLL DS XL4 ORG , @CV_LEN EQU *-OCV CHAINING VECTOR LENGTH * @SHA1 EQU 1 SHA-1 FUNCTION CODE @SHA224 EQU 2 SHA-224 FUNCTION CODE @SHA256 EQU 2 SHA-256 FUNCTION CODE @SHA384 EQU 3 SHA-384 FUNCTION CODE @SHA512 EQU 3 SHA-512 FUNCTION CODE @GHASH EQU 65 GHASH FUNCTION CODE END ,
И подделывается CRC не "относительно легко" а тривиально, так что для проверки целостности данных я бы не стал использовать CRC.
