arrow_back Hvordan lage SHA-1 og andre hash av en mappestruktur?

Question

Noen applikasjoner og spesifikasjoner har inkludert SHA-1 eller andre hash av en mappestruktur.

Hvilke verktøy kan depot bruke for å validere en slik hash sjekksum av en mappestruktur?
- 7zip har en opsjon for dette, men sjekksummen den lager stemmer ikke!

Decom validerer hash ved import av og kan lage hash ved produksjon (berikelse) av SIARD-filer, men vi trenger et frittstående verktøy.
SIARD Suite lager hash av SIARD/content/, mens DBPTK og Full Convert ikke lager dette.

Windows console "certutil" kan lage hash av en fil, men kan denne settes opp til å lage hash av en mappestruktur?
Eksempel på MD5 og SHA-256 hash av fil:

certutil -hashfile %_sourcedir%%_sourcefile% md5 > %_sourcedir%%_sourcefile%.create.md5.txt
certutil -hashfile %_sourcedir%%_sourcefile% sha256 > %_sourcedir%%_sourcefile%.sha256.txt

Eksempel SIARD 2.2 & SIARD 2.1, header seksjon metadata.xml:

<messageDigest>
    <digestType>SHA-1</digestType>
    <digest>9B8C9928164CFAD2A081A35185360C87EAC78306</digest>
  </messageDigest>

Ekempel: SIARD 2.0 & SIARD 1.0, header seksjon metadata.xml:

<messageDigest>MD52DE4305AF752200A13C771B117FB9391</messageDigest>

SIARD 2.2.pdf manual

messageDigest

Consists of digestType (MD5, SHA-1, or SHA-256) and the corresponding digest. The digest represents a binary buffer as a hexadecimal string, or alternatively, in the case of SHA-1 or SHA-256, a base64 string. Whether hexadecimal or a base64 encoding is used depends on the length of the digest and of the string.

The digest is calculated over the content/ folder. More than one message digest (based on different algorithms) can be stored. If no message digest is stored, then the integrity must be assured by storing something like a message digest outside the SIARD file13.

Recommendation
If the message digest option is used, the following must be implemented:
The content and header directories are stored in the ZIP file as separate (empty) content/ and header/ entries. To ensure that the integrity of the primary data can be checked, the entry for the header directories must be inserted after all the primary data in the content/ entry and before all the other metadata entries.

The message digest mentioned below is computed from offset 0 to the offset of the header/ entry of the SIARD archive. Note that the messageDigest indicates hexadecimal values and it is therefore not of strict importance whether they are set in upper or lower case. However, lower case is mostly used and enforced, see e.g. RFC 2831 https://www.ietf.org/rfc/rfc2831.txt

Answer 1

Å beregne en sjekksum av en mappe er en litt mer kompleks prosess. Dette er fordi mapper bare er metadata som forteller hvilke data på et medie (f.eks. en datadisk) som er gruppert sammen. Det er typisk en liste som peker til hvor på disken noe ligger.

Det er anbefalt å kun regne ut sjekksummen til filen(e) i mappen(e), og lagre resultatet på et separat sted. Ønsker man likevel å beregne mappens sjekksum, kan dette gjøres på to måter:
1. Det er mulig å beregne sjekksummen av mappens oppføring i filsystemet, med tilhørende metadata.
2. Man kan sjekksumberegne alle filer og filer i alle undermapper, lagre denne informasjonen i en liste. Listen kan da være i formatet: undermappe/fil - sjekksum. Så kan en sjekksum beregnes av denne listen. Det er da viktig at implementasjonen sjekksumberegner filene i samme rekkefølge.

Den enkleste måten er likevel å lagre mappen i en tarfil eller lignende og så beregne sjekksum av denne.

Answer 2

Langt på vei enkleste og involverer et verktøy de fleste allerede har i skuffen, er Siegfried. Siegfried kan, i tillegg til format-identifisering, lage sjekksummer i rapporten.

sf -csv -hash md5 DIR > results.csv

*md5 som eksempel, andre sjekksum-algoritmer er tilgjengelige. Hvis du ikke vil ha med format-informasjon, er det mulig

There may be occasions where you'd like to access some of the ancillary functionality of sf (listing contents of directories, listing contents of compressed files, computing file hashes, etc.) but not perform any identification.

Doing this sort of thing will be quicker with an empty identifier. You can create such a signature file by adding a non-puid limit, e.g.:

roy build -limit null -name empty empty.sig
[note due to a roy bug you'll need to add the -noreports flag to this line unless you are on >= sf 1.3.1]

Another way to do this is to do an -exlude on all the puids. The all.json sets file is your friend here:

roy build -exclude @all -name empty empty.sig

Either way, you can now access the ancillary functions of sf and skip the identification step, e.g.:

sf -sig empty.sig -z -csv -hash crc DIR

Angående etterprøving av sjekksum; Arkade 5 har i dag blant annet mulighet til å etterprøve sjekksum for Noark 5-uttrekk, fordi den vet hvilke felter som skal leses. Det er startet et arbeid med å gjøre det samme for fagsystemer (register+dokumenter, f.eks. siegfried-analyse), grunnet økte mengder "annet enn Noark som kommer med dokumenter", i form av prosessene sjekksum og ekstra/mangler.