Checksum, hash kryptograficzny, Message Authentication Code i podpis cyfrowy tworzą krótkie wartości kontrolne. W interfejsie mogą wyglądać jak podobne ciągi hex, ale zapewniają różne gwarancje. Wybór powinien zacząć się od pytania: czy system wykrywa przypadkowe uszkodzenie, identyfikuje dokładne bytes, potwierdza wspólny sekret czy umożliwia publiczną weryfikację jednego signera?

Checksum wykrywa zwykłe błędy transmisji

CRC32 jest szybki i dobrze wykrywa typowe przypadkowe zmiany w sieci, archiwum i storage. Nie zaprojektowano go przeciw przeciwnikowi. Po modyfikacji danych można łatwo obliczyć nową wartość.

Dla awarii sprzętu checksum jest właściwy. Dla autoryzacji aktualizacji daje fałszywą gwarancję.

Hash kryptograficzny daje silny fingerprint

SHA-256 utrudnia znalezienie praktycznej kolizji i identyfikuje content. Każdy może jednak policzyć hash zmanipulowanego pliku. Sam digest nie uwierzytelnia źródła.

Expected value musi pochodzić z zaufanego kanału. Publikacja obok downloadu na tym samym przejętym serwerze nie chroni przed pełną podmianą.

MAC używa wspólnego sekretu

HMAC łączy message i secret key. Odbiorca posiadający ten sam sekret sprawdza integralność oraz przynależność do grupy posiadaczy. Sprawdza się w webhookach i komunikacji usług.

Każdy verifier może również wygenerować poprawny MAC. Niezależna osoba nie ustali, która strona stworzyła wiadomość.

Podpis rozdziela tworzenie i weryfikację

Private key podpisuje, public key weryfikuje. Wielu odbiorców potwierdza release bez możliwości stworzenia nowego podpisu. To podstawa dystrybucji software i dokumentów.

Weryfikator musi ufać własności public key, sposobowi jego dostarczenia i statusowi revocation. Matematyka nie rozwiązuje dystrybucji zaufania.

Dane strukturalne potrzebują canonical form

JSON z inną kolejnością pól ma inne bytes. Hash, MAC i signature działają na bytes, więc protokół definiuje serializację albo przechowuje oryginał.

Signer i verifier interpretujący dokument inaczej tworzą podatność. Ustalony standard oraz test vectors są bezpieczniejsze niż własne sortowanie.

Nazwa algorytmu nie opisuje całego systemu

„Używamy SHA-256” może znaczyć file hash, HMAC, element signature lub zły password storage. Klucze, framing, encoding i failure policy określają gwarancję.

Nie należy tworzyć własnego MAC przez proste sklejenie secretu i wiadomości. Utrzymywane biblioteki implementują sprawdzone konstrukcje.

Klucze mają lifecycle

MAC i signature potrzebują key ID, rotacji i ochrony. Nowe wiadomości używają nowego klucza, a stare artefakty mogą wymagać poprzednich public keys.

Wyciek private key wymaga decyzji o zaufaniu do historycznych podpisów. Protokół powinien to przewidzieć przed incydentem.

Rotacja wymaga okresu nakładania kluczy

Producer zaczyna podpisywać nowym kluczem, lecz verifier musi przez pewien czas znać stary. Key ID pozwala wybrać materiał bez prób wszystkich opcji. Okres przejściowy wynika z maksymalnego życia wiadomości i opóźnionych kolejek.

Usunięcie klucza zbyt wcześnie łamie legalne artefakty, a trzymanie skompromitowanego bez polityki przedłuża ryzyko. Normalna i awaryjna rotacja powinny mieć osobne runbooki.

Historyczna weryfikacja może potrzebować zaufanego czasu

Certyfikat wygasły dzisiaj mógł być ważny w momencie podpisania dokumentu. Długoterminowy audit potrzebuje informacji o czasie, ówczesnym trust chain i statusie revocation. Sam public key zapisany obok pliku nie zawsze wystarcza.

Timestamp authority lub archiwum metadata pozwala ocenić podpis według polityki obowiązującej w przeszłości. Webhook ważny przez pięć minut i umowa przechowywana dziesięć lat mają inne potrzeby.

MAC i podpis różnią się attribution

Wspólny secret oznacza, że każda strona potrafi wygenerować wartość. W wewnętrznej strefie zaufania może to być wystarczające. Między firmami lub w audycie nie daje rozstrzygnięcia autora.

Asymetryczny private key pozostaje u signera, więc verifier nie uzyskuje prawa podpisu. Wymaga to jednak silniejszej ochrony klucza.

Podpisany manifest skaluje dystrybucję

Release może podpisać manifest zawierający paths, sizes i hashes. Mirrors dostarczają files, a klient ufa podpisowi manifestu i sprawdza każdy download.

Format manifestu musi odrzucać zduplikowane ścieżki i niejednoznaczną normalizację. Poprawny podpis nie pomaga, jeśli dwie strony inaczej odczytują strukturę.

Warstwy mogą uzupełniać się bez redundancji

Network frame używa CRC, storage content hash, a release signature. Każdy mechanizm odpowiada na inne pytanie. Problem powstaje, gdy dokumentacja nazywa wszystko ogólną „sumą kontrolną”.

Metadata powinna zawierać purpose, algorithm, encoding i key ID. Ułatwia to przyszłą migrację.

Błąd weryfikacji musi blokować

Updater nie może kontynuować po złym podpisie, ponieważ „to zapewne problem sieci”. Fail-open usuwa kontrolę. Diagnostyka powinna rozróżniać nieznany klucz, inne bytes, zabroniony algorytm i expiry.

Dokładny reason ogranicza pokusę wyłączenia mechanizmu w produkcji.

Replay jest osobnym problemem od integralności

Poprawny MAC może chronić starą wiadomość, którą atakujący wysyła ponownie. Protokół potrzebuje timestampu, nonce, sequence albo message ID oraz okna akceptacji. Weryfikacja podpisu nie stwierdza świeżości.

Consumer przechowuje wykorzystane identyfikatory odpowiednio długo i wykonuje operację idempotentnie. Inaczej autentyczna wiadomość może wielokrotnie pobrać płatność.

Porównanie musi działać na kanonicznych bajtach

Hex zapisany wielkimi i małymi literami może reprezentować ten sam digest, a padded i unpadded Base64 te same bytes. Protokół powinien zdekodować wartość zgodnie z jedną regułą i porównać wynik, zamiast stosować przypadkowe operacje stringowe.

Dla MAC i podpisów biblioteka zapewnia właściwą funkcję weryfikacji. Ręczny equality może ujawniać różnice czasowe albo zaakceptować niepożądaną normalizację.

Trust store jest częścią systemu podpisu

Poprawna signature z nieznanego klucza nie jest wystarczająca. Verifier utrzymuje kontrolowany trust store, aktualizuje go przez uwierzytelniony kanał i rejestruje, która wersja polityki zaakceptowała artefakt.

Dodanie nowego klucza powinno wymagać review porównywalnego z wdrożeniem kodu. W przeciwnym razie bezpieczeństwo kryptografii można ominąć zwykłą zmianą konfiguracji.

Pytanie wybiera narzędzie

Przypadkowe uszkodzenie oznacza checksum. Zgodność z trusted bytes oznacza hash. Wspólny secret i authenticated message oznacza MAC. Publiczna weryfikacja jednego signera oznacza signature.

Takie pytanie powinno znaleźć się w dokumentacji. Wtedy późniejsza zmiana algorytmu zachowuje pierwotną intencję bezpieczeństwa.