[Bitrepository-devel] Checksum overvejelser

Jonas Krasilnikoff Malling jkm at sa.dk
Fri Sep 23 11:28:00 CEST 2011


Jeg er enig, lad os få skåret skidtet ind til benet. Med hensyn til filintegritet og checksumsalgoritmer, bør det være muligt at opnå enighed om hvilke algoritmer vi anvender. Når det drejer sig om salt og integritet, er det problematisk at salt hovedsagelig anvendes til klistre på passwords og lign. når de skal krypteres, vi arbejder med filer. Det tætteste jeg kan komme på et alternativ er hmac, som evt. kan benyttes når en ny beregning af checksummer vil gennemtvinges. http://www.ietf.org/rfc/rfc2104.txt. Rent teknisk afviger hmac og brugen af salt ikke synderligt fra hinanden, men i forhold til udvikling understøtter .Net hmac, hvorimod salt vil skulle klistres på filen manuelt. Jeg ved ikke om det er det samme med Java.

-Jonas - Den onde IT-arkivbums.

-----Oprindelig meddelelse-----
Fra: bitrepository-devel-bounces at ml.sbforge.org [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Kim Teglgaard Christensen
Sendt: 22. september 2011 15:20
Til: bitrepository-devel at ml.sbforge.org
Emne: [Bitrepository-devel] Checksum overvejelser

Som aftalt på video mødet i onsdags så har jeg kigget lidt på checksummer i protokollen. Jeg har også haft en lille snak med Bolette for bedre at kunne forstå hvorfor tingene er lavet som de ser ud lige pt. 

For at forstå checksum delen har jeg tegnet ned hvordan de enkelte elementer er. Jeg har ved hæftet diagrammerne til næste onsdags video møde agenda ( https://sbforge.org/display/BITMAG/2011-09-28+Videomeeting
). På diagrammerne er der en oversigt over hvordan de fra XSD'erne genererede java klasser er for GetChecksumsFinalResponse og PutFileRequest. Der er kun taget de dele med som er relevant for checksum delen. 
Som det kan ses er der en del data som er redundant, og der er anvendt en del lister rundt omkring. 


Jeg har som sagt haft en snak med Bolette om hvorfor protokollen ser ud som den gør.
-- De redundante data hænger sammen med, at der er et ønkse om at have tingene samlet. Forstået på den måde at der eksempelvis lige ved siden af checksum værdien er hvilken fil der er tale om, men et andet sted i beskeden er der en liste med fil ID'er. 

-- En liste med checksum specifikationer er tænkt i det tilfælde at man har mulighed for at anmode om flere forskellige typer af checksums så en pillar har mulighed at tage den første type som den understøtter eller kan levere. For eksempel kunne det være en checksum pillar som har en
SHA1 checksum gemt, men ikke en MD5. 
Det er ikke utænkeligt at der er flere årsager til dette valg, men det var sådan jeg forstod det på Bolette. 

-- På et mere generelt niveau (altså ud over checksums) så er protokollen specificeret til at tage alle de hjørnetilfælde med som der kunne tænkes på. 


Når ovenstående er sagt, er der noget som skal laves om?


Jeg kan ikke svare for jer andre, men har selv en ubendig lyst til at finde en machete eller buskrydder frem og skære den del af protokollen ind til benet. På den måde får vi en protokol med det vi har behov for, frem for en protokol som dækker meget mere generelt. 
Da jeg snakkede med Bolette, var jeg inde på hvor jeg kunne finde på at lægge snittet, og det var hun vidst ikke alt for glad for. 
Anyways, der er to diagrammer med forslag til hvordan checksum delen kunne se ud hvis jeg får min vilje ;) Tyg lige lidt på det til på onsdag så kan vi tage snakke der.

Mvh Kim

_______________________________________________
Bitrepository-devel mailing list
Bitrepository-devel at ml.sbforge.org
http://ml.sbforge.org/mailman/listinfo/bitrepository-devel



More information about the Bitrepository-devel mailing list