Oblicz sumę kontrolną pliku

Checksum (suma kontrolna, czasem zapisywana jako chksum) to unikalny cyfrowy odcisk obliczany z zawartości pliku przez algorytm haszujący. Ten odcisk, lub fingerprint, jest zwykle reprezentowany przez ciąg szesnastkowy stałej długości.

Fundamentalną właściwością dobrego algorytmu haszującego jest efekt lawiny: każda modyfikacja pliku źródłowego, nawet jednego bitu, produkuje radykalnie różny checksum. Dwa pliki o ściśle identycznej zawartości zawsze produkują ten sam checksum, niezależnie od nazwy pliku, daty modyfikacji czy systemu operacyjnego.

Checksum służy głównie do weryfikacji integralności pliku: jeśli odcisk obliczony lokalnie odpowiada temu ogłoszonemu przez wydawcę, plik jest nienaruszony. W przeciwnym razie został zmieniony, uszkodzony w trakcie transmisji lub zmodyfikowany.

• Weryfikacja integralności pobrania: ISO Linux (Debian, Ubuntu, Fedora, Arch), obraz Docker, instalator Windows lub archiwum open source systematycznie publikują oficjalny checksum. Obliczenie go lokalnie potwierdza, że plik jest kompletny i nienaruszony.
• Wykrywanie uszkodzeń w transmisji: przerwane pobieranie, wadliwy sektor dysku, niestabilna RAM, kapryśny kabel sieciowy lub kopia na pendrive mogą uszkodzić bajty. Checksum natychmiast ujawnia te ciche błędy.
• Odcisk podpisu: potwierdzenie, że plik pochodzi od oczekiwanego autora, gdy checksum jest rozpowszechniany bezpiecznym kanałem (HTTPS, podpis GPG). To mechanizm leżący u podstaw repozytoriów pakietów Linux i sklepów z aplikacjami.
• Versionning i caching: Git identyfikuje każdy commit, blob i drzewo przez hash SHA-1 (w migracji do SHA-256). CDN i bundlery webowe (Webpack, Vite, esbuild) wstrzykują hash w nazwę pliku (app.4a8f2c.js), aby automatycznie unieważnić pamięć podręczną przeglądarki przy zmianie.
• Wykrywanie duplikatów i deduplikacja: przyrostowe kopie zapasowe (Borg, Restic, rsync), systemy plików (ZFS) i pamięci obiektowe identyfikują identyczne bloki przez ich hash, aby przechowywać tylko jedną kopię.
• Walidacja uploadu: klient wysyła oczekiwany checksum, serwer przelicza go po otrzymaniu. AWS S3 na przykład akceptuje nagłówek Content-MD5 lub x-amz-checksum-sha256, aby odrzucić uszkodzony upload.
• Threat intelligence i antywirus: VirusTotal i wydawcy antywirusów indeksują złośliwe pliki przez ich hash SHA-256, co pozwala na wykrycie bez przesyłania kompletnego binarka.

• MD5 (128 bitów, 32 znaki szesnastkowe): szybki, szeroko rozpowszechniony, ale kryptograficznie złamany. Kolizje MD5 są obliczalne w kilka sekund na typowym sprzęcie od 2004 roku. Do użycia tylko do nieszkodliwej weryfikacji integralności (pobieranie przeciwko zerwaniu sieci, lokalna kopia zapasowa). Zabronione dla wszelkich funkcji bezpieczeństwa, podpisu lub uwierzytelnienia.
• SHA-1 (160 bitów, 40 znaków szesnastkowych): przestarzały dla kryptografii od ataku SHAttered z 2017 roku, który zademonstrował rzeczywistą kolizję między dwoma różnymi PDF. Git nadal używa go domyślnie, ale migruje do SHA-256. Nie używaj już do podpisywania ani uwierzytelniania.
• SHA-256 (256 bitów, 64 znaki szesnastkowe): nowoczesny standard, członek rodziny SHA-2. Podstawa nowoczesnych certyfikatów TLS, podpisów pakietów Linux (apt, dnf, pacman), Bitcoin i oficjalnych kontroli integralności. Wolniejszy niż MD5, ale bezpieczny w obecnym stanie wiedzy.
• SHA-512 (512 bitów, 128 znaków szesnastkowych): 64-bitowy wariant SHA-2. Manipuluje natywnie słowami 64-bitowymi, co czyni go czasami szybszym niż SHA-256 na CPU 64-bit. Dłuższy odcisk, większy margines bezpieczeństwa.
• CRC32 (32 bity, 8 znaków szesnastkowych): niekryptograficzny, ultraszybki, zaprojektowany specjalnie do wykrywania błędów transmisji. Używany przez Ethernet, ZIP, PNG, gzip. Nie chroni przed złośliwością: atakujący może banalnie sfałszować plik z tym samym CRC32 co inny. Odpowiedni dla szybkich kontroli sprzętowych, nie dla bezpieczeństwa.

• Weryfikacja ISO Linux: Debian, Ubuntu, Fedora i Arch publikują SHA-256 i SHA-512 każdego oficjalnego obrazu, często kontrasygnowane w GPG.
• Walidacja podpisanego binarka: potwierdzenie, że plik wykonywalny pobrany z lustra nie został zastąpiony spreparowaną wersją.
• Porównanie dwóch wersji: przed i po modyfikacji identyczny checksum udowadnia tożsamość bit po bicie, bez konieczności rozpowszechniania plików.
• Walidacja uploadu: klient wysyła checksum, serwer przelicza go po otrzymaniu, aby potwierdzić brak uszkodzenia.
• Fingerprinting: wykrywanie botów lub znanych plików w bazach odcisków (antywirus, threat intelligence, wyszukiwanie duplikatów).

1. Przeciągnij i upuść plik w przewidzianym obszarze lub użyj przycisku wyboru.
2. Wybierz algorytm: MD5, SHA-1, SHA-256, SHA-512 lub CRC32.
3. Checksum wyświetli się, gotowy do skopiowania.
4. Porównaj uzyskaną wartość z wartością referencyjną (opublikowaną przez wydawcę lub przechowywaną lokalnie).

Obliczenie wykonywane jest lokalnie w twojej przeglądarce, bez wysyłania pliku na zdalny serwer. Zawartość pozostaje poufna.

Standardowa procedura weryfikacji jest następująca:

1. Oficjalna strona publikuje oczekiwany checksum, na przykład d41d8cd98f00b204e9800998ecf8427e dla MD5 lub ciąg 64 znaków dla SHA-256.
2. Pobierz plik.
3. Oblicz jego checksum, albo tym narzędziem, albo w wierszu poleceń.
4. Porównaj: jeśli oba ciągi są ściśle identyczne, znak po znaku, plik jest nienaruszony. Jeśli różnią się, nawet jednym znakiem, plik jest uszkodzony lub spreparowany: nie używaj go, pobierz ponownie.

W wierszu poleceń pod Linuksem:

# Calculer le checksum
md5sum fichier.iso
sha1sum fichier.iso
sha256sum fichier.iso
sha512sum fichier.iso
cksum fichier.iso          # CRC32 + taille

# Vérifier automatiquement depuis un fichier .sha256 publié par l'éditeur
sha256sum -c fichier.iso.sha256
# Affiche : "fichier.iso: OK" si le checksum correspond

Pod macOS:

md5 fichier.iso
shasum -a 1 fichier.iso
shasum -a 256 fichier.iso
shasum -a 512 fichier.iso

# Vérification depuis un fichier de référence
shasum -a 256 -c fichier.iso.sha256

Pod Windows (PowerShell):

Get-FileHash fichier.iso -Algorithm MD5
Get-FileHash fichier.iso -Algorithm SHA1
Get-FileHash fichier.iso -Algorithm SHA256
Get-FileHash fichier.iso -Algorithm SHA512

# Comparer à une valeur attendue
(Get-FileHash fichier.iso -Algorithm SHA256).Hash -eq "ABC123..."

Algorytm	Rozmiar	Szybkość	Zalecane użycie
CRC32	32 bity	Bardzo szybki	Wykrywanie błędów sieci lub przechowywania, niekryptograficzny
MD5	128 bitów	Szybki	Tylko nieszkodliwa integralność, do unikania w bezpieczeństwie
SHA-1	160 bitów	Szybki	Przestarzały, stara kompatybilność (Git, stare pakiety)
SHA-256	256 bitów	Umiarkowana	Aktualny standard, weryfikacja integralności i podpisy
SHA-512	512 bitów	Szybki w 64 bitach	Weryfikacja integralności, większy margines bezpieczeństwa

MD5 czy SHA-256 do weryfikacji mojego ISO?

SHA-256 domyślnie. Niemal wszystkie nowoczesne dystrybucje Linux publikują SHA-256 i SHA-512, czasem obok MD5 dla historycznej kompatybilności. Jeśli wydawca publikuje tylko MD5, a obawiasz się kompromitacji, wymagaj SHA-256 lub zweryfikuj podpis GPG pliku checksumów. Jeśli obawiasz się tylko uszkodzenia w pobieraniu, MD5 technicznie wystarcza.

Czy checksum gwarantuje bezpieczeństwo mojego pliku?

Nie, sam w sobie nie. Checksum udowadnia integralność, a nie autentyczność. Jeśli atakujący kontroluje serwer pobierania, może opublikować zmodyfikowany plik i jego zmodyfikowany checksum. Prawdziwe bezpieczeństwo pochodzi z podpisu cyfrowego (GPG, code signing), który wiąże checksum z znanym kluczem prywatnym. Zawsze pobieraj checksum przez HTTPS lub, lepiej, przez weryfikowalny podpis GPG.

Mój checksum się nie zgadza, co robić?

Najpierw sprawdź, czy porównujesz właściwy algorytm: SHA-256 nie może odpowiadać SHA-1. Następnie powtórz pobieranie, najlepiej z innego lustra: najczęstszą przyczyną jest zerwanie sieci. Jeśli różnica utrzymuje się po kilku próbach, podejrzewaj kompromitację lustra: wróć do oficjalnego źródła i zweryfikuj podpis GPG, jeśli istnieje. Nigdy nie uruchamiaj ani nie używaj pliku, dopóki checksum się nie zgadza.

Dlaczego MD5 jest przestarzały?

MD5 cierpi z powodu praktycznych kolizji: możliwe jest skonstruowanie dwóch różnych plików mających dokładnie ten sam hash MD5 w kilka sekund. Ta właściwość narusza samą funkcję hasza kryptograficznego. Konkretnie atakujący może utworzyć złośliwy binarka mający ten sam MD5 co legalny binarka. SHA-1 cierpi na ten sam problem od 2017 roku (atak SHAttered). Tylko SHA-256, SHA-512 i ich warianty pozostają uważane za bezpieczne w 2026 roku.

Różnica między hash a checksum?

Hash to generyczny wynik funkcji haszującej. Checksum to hash używany specjalnie do weryfikacji integralności danych. Wszystkie checksumy są hashami, ale nie wszystkie hashe są checksumami: hash hasła (bcrypt, argon2) służy do uwierzytelnienia, hash w tablicy hashującej służy do szybkiego indeksowania. Termin fingerprint lub odcisk to częsty synonim checksuma.

Czy CRC32 wystarcza dla moich potrzeb?

CRC32 wystarcza, jeśli szukasz tylko wykrywania przypadkowego uszkodzenia w niewrogim kanale: wewnętrzny transfer sieciowy, weryfikacja archiwum ZIP, kontrola spójności w pamięci. Z zaledwie 32 bitami dwa losowe pliki mają około 1 szansy na 4 miliardy mieć ten sam CRC32 przez przypadek, co wystarcza do wykrycia błędu. CRC32 jest niewystarczający, gdy atakujący może wpływać na zawartość: trywialne jest sfałszowanie pliku z docelowym CRC32. Dla każdej weryfikacji w obliczu złośliwego ryzyka użyj SHA-256.

Dlaczego mój checksum różni się w zależności od systemu operacyjnego?

Checksum tej samej zawartości binarnej jest wszędzie identyczny. Jeśli otrzymujesz dwa różne wyniki, to plik rzeczywiście się różni: zakończenia linii (CRLF Windows vs LF Unix) po transferze FTP w trybie tekstowym, kodowanie tekstu zmodyfikowane przy otwieraniu, metadane dodane przez system (rozdzielczość Spotlight macOS, atrybuty rozszerzone) lub cicha ponowna kompresja przez klienta transferu. Zawsze przenoś w trybie binarnym.

Checksum czy podpis cyfrowy?

Checksum udowadnia, że plik nie został zmieniony między publikacją a odbiorem, pod warunkiem pobrania checksuma bezpiecznym kanałem. Podpis cyfrowy (GPG, PGP, code signing Authenticode) udowadnia dodatkowo tożsamość autora dzięki kluczowi prywatnemu. Podpis obejmuje i wzmacnia checksum: standardowa praktyka w Debian, Tor czy Bitcoin Core to podpisywanie GPG pliku checksumów, a następnie używanie tych checksumów do weryfikacji binarek.