Hur få till säker filverifikation vid nätöverföring?

Börjar vi tänka så så blir det att skicka de olika filerna på olika sätt, ex skicka filerna över internt men skicka checksummorna över ex posten. Det absolut bästa skulle vara att göra det fysiskt eller muntligt över telefon. Ska du använda fysiskt post så kan du ju antigen skicka ett flash minne eller skriva ut dom fysiskt på ett papper.

Du skulle även kunna kryptera filerna med ett bra lössen, alt PGP.

Det du gör förslagsvis när du ska distribuera en fil är att du lägger upp hashen på en sida som du har full kontroll över, sen kan du låta mer eller mindre pålitliga mirrors serva själva filen, utan att det behöver råda några tvivel om ifall filerna blivit manipulerade. Att bara lägga med en hash tillsammans med filerna och sprida allt via någon skum källa är som du säger inte särskilt klyftigt om man gör det för att skydda mot manipulation, då handlar det mer om att kunna verifiera att inga fel smugit in vid överföringen.

Skickades från m.sweclockers.com

@Dooley: Grejen med osäkra hashalgoritmer är att någon kan skapa en illvillig fil som har samma hash som den riktiga filen. En vanlig användning av hash är ju t.ex. olika typer av nedladdningar från nätet, där en checksum för en fil anges direkt på webbsidan för att den som laddar ned filen ska kunna verifiera att den är korrekt. En osäker hashalgoritm kan då tillåta någon att byta ut filerna på en filserver till andra filer med samma checksum, utan att behöva ändra på webbsidan som länkar till filerna.

Man har ju dock lite samma problem där, hur vet man att webbsidan man tittar på visar rätt checksum? Men om du är under attack från en man-in-the-middle som är kapabel att byta ut både checksummor på sidor du tittar på samt filer du laddar ner så har du troligtvis betydligt större problem att oroa dig över.

Det där är intressant och jag har själv provat och fått fram att det går att göra ganska enkelt. Jag antar att du rean vet att för att få fram samma checksumma för en ändrad fil så kräver det en sådan ändring att filen i sig kommer att innehålla totalt skada kod eller oläsbar information.

Så enklaste formen är att använda delad överföring, så som banker gör när dom skickar kreditkort, dvs kortet och koden separat. Sannolikheten att en tjuv får både ditt kreditkort och din kod är minimal, och i den digitala värden är det i princip omöjligt eftersom det inte går att förutse vad som händer på samma sätt som på ett postkontor.

Idén här är att du skapar en textfil med checksumma på filerna du för över. Sedan så skapar du en checksumma på denna fil och sparar i textfilen och döper filen till den nya checksumman. Man kan även lägga till en checksumma på en mening båda vet om men är omöjlig att gissa för utomstående.

Resultatet av detta är att om innehållet ändras i fillistan så stämmer inte filnamnet med checksumman och ändras innehållet i filerna så stämmer inte första checksumman på fillistan.

Skickar du fillistan och filerna separat så är det dessutom extremt svårt för en hackare att gissa rätt resultat.

Ditt problem är väl mer av kryptografisk natur för du behöver ju på nått sätt överföra data som kan verifiera att "huvudfilerna" är korrekta utan att någon kan komma åt att manipulera.

Ett system för att kryptera verifieringsfilerna eller hela det stora datapaketet så att man kan garantera de är ok eller inte fungerar alls.

Du kan ju också låta bli att skicka din checksumma och i stället publicera den på nått säkert sätt så den som har filen som ska verifieras själv behöver hämta checksumman i stället för att den följer med i filpaketet som ev manipuleras.

Många opensource-projekt har parallellt med distrubitionen ofta en hash-summa (eller ofta fler med olika hashalgoritmer) som någon går i god för.

Att göra hashkrock på en lätt modifierad fil gentemot originalet är inte lätt - som nämnt så slutare det ofta med total massaker eller så är det helt korrekt om det skall generera samma checksumma - en liten diskret ändring är alltså oerhört svårt att dölja om man önskar en orörd hash-summa

- Med SHA1 så lyckades man (google) få till 2 pdf med lätt skillnad i för samma SHA1-summa - men det var verkligen inte lätt och det låg många månaders beräkning bakom detta även med nätverk av datorer och krävde en ganska stort stycke (och där man hittade ett sätt att få in en bit stycke med data som inte användes av pdf när det skulle visas upp) med data som var väldigt olika mellan dessa båda pdf för att i slutändan skulle generera samma SHA1-summa

MD5 är lättare att attackera med framgång och det var så man falskeligen 'certifierade' payloaden (skadlig mjukvara) för MS certifieringsrutin för installation av mjukvara i bakgrunden och utan en massa varningsrutor dök upp och som användes av stuxnet (NSA/USA troligen).

Erbjuder man 2 hashar - säg en från SHA2-familjer (som SHA256,SHA512) och en från SHA3-familjen för samma fil/arkiv så är det i stort sett bortom möjlighetens gräns att skapa hash-krock på båda samtidigt med samma lätt modifierade indata.

Om du använder dig av TLS (till exempel https på webben) för att föra över filer, eller hasharna för filerna, så har du redan använt dig av ett flertal tekniker (inklusive hashning) för att säkerställa både Confidentiality och Integrity i överföringen. Dessutom så kan du vara relativt säker på att du pratat med rätt motpart genom att du använt dig av Public Key Infrastructure vilket i sin tur innebär användning av digitala certifikat (för server och eventuellt klient).

Svaret på ursprungsfrågan är så klart väldigt lärorik, men om det är ett praktiskt problem du försöker lösa så är det nog redan löst. Genom ovanstående tekniker eller på annat sätt, beroende på det exakta problemet.

Unixvärldens 'rsync' använde sig av rätt delikata olika typer av hash för att synka två filträd till exakt lika med ambitionen att skicka över så lite data som möjligt mellan sig för jobbet - var det 3 bokstäver som skilde sig i en jättelik databas så var det bara adresser för dessa och dessa 3 bokstäver som fördes över - typ.

Rsync skapades i en tid där data fördes över via långsamma modem och många överföringsprotokoll som kermit, xmodem etc. hanterade inte redan överförda filer särskilt väl utan ville ladda över hela filen på nytt igen fast skillnaderna kunde vara väldigt små och det var frustrerande när det var enorma filer som fördes över var gång så fort tidsstämpeln för filen skilde sig det minsta och ändå inte kunde garantera att filerna var helt lika när tidsstämpeln inte hade ändrat sig (många filsystems tidstämplar var på hela sekunder som lägsta upplösning) .

Det var Andrew Tridgell som skapade rsync som sin thesis och där använde man Locality-sensitive hashing och Locality-preserving hashing för att hitta punkterna som var lika och vad som skilde sig och meddelade 'andra sidan' som gjorde samma sak på sin del och så kommunicera mellan sig och skickade data och instruktioner som krävdes för att göra filerna _helt_ lika - också verifierad med hash.

Andrew Tridgell är också 'pappa' till Samba (SMB) vilket gör att man nätverksmässigt kopplar ihop Unixvärlden och windows-världen och utan den paketet så vete fasen hur det hade sett ut på nätverkssidan idag - för det var ingen lätt stig att gå och med en Microsoft som motarbetade och rent av sabbade så mycket de kunde under tiden...

Han är också skyldig till varför linux-communityn blev av med gratislicensen hos Bitkeeper bara för att han kikade lite på hur protokollet såg ut och skrev en klient som kunde använda sig av det (om man har reverse engineerat hela SMB-prokollet så kan jag tänka mig att det är lite av 'bad habit' av bara farten när man snubblar över det...) och det hela blev jätteinfekterat med företaget och samarbetet och gratislicensen inte gick att rädda. Linus började jaga en ny leverantör av revisionshanteringssystem och som backup skrev han på några få dagar en egen version med de erfarenheter han hade skaffat sig som förvaltare av linux-kernel och konstant inflöde av patchar hela tiden via mail och hur det skulle jämkas in i källträdet och i det vad som saknades enligt hans tycke - det som sedermera blev... Git - resten är som det heter - historia...