> Le 21 déc. 2017 à 07:01, Anders Wallin <[email protected]> a écrit : > >> >>> For the Paris Observatory and USNO files my program agrees with the SHA1s >>> in the files. >>> For the IETF file there seems to be one byte, a "0" at the start of the >>> third group of 8 hex characters missing. >> >> This is not a bug but a « feature ». From the ntpd leap hash checking >> code: >> >> * The NIST code creating the hash writes them out as 5 hex integers >> * without leading zeros. >> >> Still, it a little unorthodox and complicates the code. >> > > Ha! Thanks for explaining this. > Indeed I find writing out the SHA-1 in groups of 8 characters without > leading zeroes quite surprising and undocumented. > The comments in leap-seconds.list about the SHA-1 refer to a /sha or > /pub/sha folder - is that generic information on the SHA-1 or is there any > inidication of the 8-char/leading-zeroes convention there? > I quickly looked at FIPS-180 but didn't find anything about leading zeros > there.
My guess is that during testing the NIST guy who created the program to print the list never hit the case where the integer created a less than 8 character hex output. Probably used %8x instead of %08x in his format statement, or something analog if it was not C. A case of « economy of thought » . > > I am still unable to access the NIST ftp-site linked earlier in this thread. > > Anders > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. "The power of accurate observation is commonly called cynicism by those who have not got it. » George Bernard Shaw _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
