ECDSA (ang. Elliptic Curve Digital Signature Algorithm) to algorytm podpisu cyfrowego oparty na krzywych eliptycznych. Pozwala udowodnić, że wiadomość (np. transakcję) zatwierdził właściciel klucza prywatnego, bez ujawniania tego klucza. W Bitcoinie i Ethereum ECDSA działa na krzywej secp256k1 i od początku istnienia obu sieci to właśnie nim podpisywana jest zdecydowana większość transakcji.
Gdy klikasz „Wyślij” w portfelu, pod spodem powstaje podpis ECDSA. Rozumienie, jak działa, przydaje się bardziej, niż się wydaje: kilka najgłośniejszych kradzieży kryptowalut nie wynikało z łamania kryptografii, tylko z błędnego użycia tego algorytmu. Do tego w 2026 roku coraz więcej mówi się o jego następcach, odpornych na komputery kwantowe.
Co to jest ECDSA w prostych słowach
Pomyśl o podpisie odręcznym, którego nie da się podrobić, a który każdy może sprawdzić z wzorem złożonym w banku. W ECDSA „wzorem” jest Twój klucz publiczny, a „ręką” klucz prywatny. Podpis jest inny dla każdej wiadomości, więc nie da się go skopiować z jednej transakcji i przykleić do drugiej. Ktoś, kto widzi tysiąc Twoich podpisów, nadal nie potrafi z nich odtworzyć klucza prywatnego, pod warunkiem że każdy podpis został złożony poprawnie.
Ten warunek jest ważny. ECDSA ma jeden słaby punkt: do każdego podpisu potrzebuje nowej, tajnej i nieprzewidywalnej liczby losowej. Jeśli ta liczba się powtórzy albo da się ją zgadnąć, klucz prywatny wycieka.
Jak powstaje podpis ECDSA
W tym haśle klucz prywatny oznaczam literą d, bo literą k tradycyjnie oznacza się liczbę losową podpisu. Klucz publiczny to Q = d·G, gdzie G to punkt bazowy krzywej, a n to jej rząd.
- Krok 1: skrót wiadomości. Transakcja jest przepuszczana przez funkcję skrótu (w Bitcoinie podwójne SHA-256, w Ethereum Keccak-256). Wynik to liczba z.
- Krok 2: liczba losowa k. Portfel wybiera tajną liczbę k z zakresu od 1 do n − 1.
- Krok 3: wartość r. Liczy punkt R = k·G i bierze jego współrzędną x (modulo n). To jest r.
- Krok 4: wartość s. Liczy s = k⁻¹ · (z + r · d) mod n, gdzie k⁻¹ to odwrotność k modulo n.
Podpis to para liczb (r, s). W Bitcoinie zapisuje się ją w formacie DER i zajmuje zwykle 71–72 bajty.
Weryfikacja i odzyskiwanie klucza publicznego
Węzeł sieci, który sprawdza podpis, zna z, r, s oraz klucz publiczny Q. Liczy u1 = z · s⁻¹ i u2 = r · s⁻¹, a następnie punkt u1·G + u2·Q. Jeśli współrzędna x tego punktu jest równa r, podpis jest poprawny. Nikt po drodze nie dowiaduje się d ani k.
Ciekawą cechą ECDSA jest to, że z samego podpisu i wiadomości można odtworzyć klucz publiczny. Z r da się wyliczyć punkt R (są dwa kandydaci, różniący się znakiem współrzędnej y), a potem Q. Ethereum korzysta z tego intensywnie: transakcja nie zawiera klucza publicznego ani adresu nadawcy, tylko podpis (r, s) plus dodatkowy bajt v, który mówi, którego z kandydatów wybrać. Pierwotnie v przyjmowało wartości 27 lub 28, a po wprowadzeniu ochrony przed powtórzeniem transakcji w innej sieci (EIP-155) koduje także identyfikator łańcucha. Smart kontrakty mają do dyspozycji wbudowaną funkcję ecrecover, która z hasha i podpisu zwraca adres podpisującego. Na tym opierają się m.in. podpisy „off-chain” typu permit czy logowanie portfelem.
Malleability, czyli podpis, który można „przerobić”
Matematyka ECDSA ma pewną właściwość: jeśli (r, s) jest poprawnym podpisem, to (r, n − s) też jest poprawny. Każdy obserwator sieci mógł więc zmienić podpis cudzej transakcji bez znajomości klucza, a skoro podpis wchodził do identyfikatora transakcji (txid), zmieniał się też txid. Środki nadal trafiały we właściwe miejsce, ale oprogramowanie śledzące transakcje po identyfikatorze mogło się pogubić.
Rozwiązania przyszły dwutorowo. Po pierwsze, reguła low-s: akceptowana jest tylko „mniejsza” z dwóch wartości s. W Bitcoinie to reguła standardowości transakcji, w Ethereum wymóg obowiązuje od aktualizacji Homestead w 2016 roku. Po drugie, SegWit, aktywowany w Bitcoinie w sierpniu 2017 roku, przeniósł podpisy poza dane liczone do txid, co zamknęło problem dla nowych typów adresów i otworzyło drogę do Lightning Network.
Katastrofa powtórzonej liczby k
Gdy ten sam klucz prywatny podpisze dwie różne wiadomości tą samą liczbą k, oba podpisy mają tę samą wartość r. Wtedy wystarczy szkolna algebra: k = (z1 − z2) / (s1 − s2), a potem d = (s · k − z) / r, wszystko modulo n. Dwie transakcje wystarczą, by ktokolwiek przejął klucz.
- Sony PlayStation 3, 2010. Sony podpisywało oprogramowanie konsoli ECDSA, ale za każdym razem używało tej samej, stałej liczby k. Grupa fail0verflow pokazała to na konferencji 27C3 w grudniu 2010 roku, a wkrótce potem klucz prywatny Sony trafił do sieci. Każdy mógł podpisywać własne oprogramowanie jako „oficjalne”.
- Portfele bitcoinowe na Androidzie, 2013. W sierpniu 2013 roku okazało się, że systemowy generator SecureRandom w Androidzie w pewnych warunkach zwracał powtarzalne wartości. Portfele polegające na nim powtarzały k, a złodzieje odzyskiwali klucze z publicznych podpisów w łańcuchu i opróżniali adresy. Twórcy portfeli wydali poprawki i zalecili przeniesienie środków na nowe adresy.
Odpowiedzią jest RFC 6979, opublikowany w 2013 roku. Zamiast losować k, portfel wylicza je deterministycznie z klucza prywatnego i skrótu wiadomości (przy użyciu HMAC). Dla tej samej wiadomości k jest zawsze takie samo, dla różnych wiadomości zawsze różne i nieprzewidywalne dla obserwatora. Większość współczesnych portfeli i bibliotek, w tym libsecp256k1, działa właśnie tak.
ECDSA a Schnorr i EdDSA
- Podpisy Schnorra (Bitcoin, Taproot). Od aktywacji Taproot w listopadzie 2021 roku Bitcoin obsługuje podpisy Schnorra na tej samej krzywej secp256k1. Mają stałe 64 bajty, prostszy dowód bezpieczeństwa, nie są „przerabialne” jak ECDSA i są liniowe, co pozwala łączyć klucze wielu osób w jeden (MuSig2) i weryfikować wiele podpisów naraz. ECDSA dalej działa w starszych typach adresów.
- EdDSA i Ed25519 (np. Solana, Cardano). To odmiana schematu Schnorra na krzywej Edwards25519. Liczba odpowiadająca k jest z definicji wyliczana deterministycznie, więc całej klasy błędów z powtórzonym k po prostu nie ma. Ed25519 jest też szybki i łatwy do bezpiecznej implementacji.
Dlaczego więc ECDSA w ogóle się utrzymało? W latach 2008–2009 podpisy Schnorra były objęte patentem, a ECDSA było szeroko standaryzowane i dostępne w bibliotekach. Satoshi wybrał rozwiązanie, które było pod ręką.
ECDSA a komputery kwantowe
ECDSA, Schnorr i EdDSA opierają się na tym samym problemie logarytmu dyskretnego na krzywej eliptycznej, więc wszystkie trzy łamie algorytm Shora uruchomiony na odpowiednio dużym komputerze kwantowym. Podpis zdradza klucz publiczny, a z klucza publicznego taka maszyna wyliczyłaby prywatny. Następcami mają być podpisy postkwantowe, np. ML-DSA i SLH-DSA, standaryzowane przez NIST. Ich wadą są znacznie większe rozmiary podpisów. Szczegóły migracji w Bitcoinie i Ethereum opisuję w haśle o krzywej secp256k1.
Co to oznacza dla Ciebie
Ty nie liczysz podpisów ręcznie, robi to portfel. Twoja rola to wybór takiego portfela, który robi to poprawnie, i dbanie o klucz.
- Seed i klucz prywatny to jedno. Kto ma frazę odzyskiwania, może składać Twoje podpisy. Trzymaj ją offline.
- Hardware wallet. Podpis ECDSA powstaje wewnątrz urządzenia. Zawsze sprawdzaj na jego ekranie adres i kwotę, bo podpisujesz to, co widzi urządzenie, a nie to, co pokazuje strona.
- Uważaj na podpisy „bez transakcji”. W Ethereum podpis wiadomości (permit, zgoda w stylu EIP-712) potrafi dać komuś prawo do wydania Twoich tokenów. Nie podpisuj niczego, czego nie rozumiesz.
- Unikaj egzotycznych portfeli i generatorów kluczy. Błędy z losowością k zdarzają się w małych, nieaudytowanych projektach. Wybieraj oprogramowanie, które korzysta ze sprawdzonych bibliotek i RFC 6979.
- Nowy adres przy każdym odbiorze. Mniej podpisów pod jednym kluczem to mniejsze pole do ataku, a przy okazji lepsza prywatność.
Ryzyka związane z ECDSA
- Powtórzone lub przewidywalne k. Najgroźniejszy błąd, prowadzi wprost do utraty klucza prywatnego.
- Kanały boczne. Pomiar czasu lub poboru prądu przy podpisywaniu może zdradzić bity k. Dotyczy głównie słabych implementacji i urządzeń.
- Malleability. W starszych formatach transakcji możliwa jest zmiana txid przez osoby trzecie.
- Ślepe podpisywanie. Podpis jest matematycznie poprawny także wtedy, gdy podpisujesz coś, co Cię okrada. Algorytm nie chroni przed phishingiem.
- Komputery kwantowe. W dłuższym terminie ECDSA trzeba będzie zastąpić schematami postkwantowymi.
Najczęstsze pytania o ECDSA
Czy ECDSA jest bezpieczne?
Tak, przy poprawnej implementacji i dobrej losowości lub deterministycznym k według RFC 6979. Znane wpadki dotyczyły błędnego użycia algorytmu, a nie złamania samej matematyki.
Czym ECDSA różni się od podpisu Schnorra?
Oba działają na tej samej krzywej w Bitcoinie. Schnorr ma krótszy, stały rozmiar podpisu, nie jest „przerabialny” i pozwala łączyć klucze wielu osób. ECDSA jest starszy, bardziej rozpowszechniony i obsługiwany przez wszystkie stare typy adresów.
Co to jest v w podpisie Ethereum?
To dodatkowa wartość, która pozwala jednoznacznie odtworzyć klucz publiczny z podpisu (r, s). Dzięki temu transakcja nie musi zawierać adresu nadawcy, a kontrakty mogą sprawdzać podpisy funkcją ecrecover.
Czy da się wyliczyć klucz prywatny z jednego podpisu?
Przy poprawnym podpisie nie. Zagrożenie pojawia się, gdy dwa podpisy mają to samo k, gdy k jest przewidywalne albo gdy wycieka jego część, oraz w przyszłości wobec komputerów kwantowych.
Podsumowanie
ECDSA to algorytm, który zamienia Twój klucz prywatny i skrót transakcji w podpis (r, s), sprawdzalny przez każdego bez ujawniania klucza. Działa w Bitcoinie i Ethereum od początku, a w Ethereum służy dodatkowo do odzyskiwania adresu nadawcy. Jego piętą achillesową jest liczba losowa k: jej powtórzenie kosztowało Sony klucz do PS3, a użytkowników Androida bitcoiny, dlatego standardem stało się deterministyczne k z RFC 6979. Bitcoin uzupełnił ECDSA podpisami Schnorra w Taproot, Solana od początku postawiła na Ed25519, a w dłuższej perspektywie wszystkie te schematy czeka migracja do podpisów postkwantowych.


