W marcu 2026 roku Craig Gidney z Google Quantum AI opublikował paper który zmienił jedną liczbę — i ta liczba zmienia wszystko.
Poprzednia ocena z 2019: złamanie 2048-bitowego RSA wymagałoby 20 milionów qubitów. Nowa ocena: mniej niż milion. Redukcja dwudziestokrotna, osiągnięta wyłącznie przez ulepszenia algorytmiczne i architektoniczne — bez ulepszenia sprzętu. Osobny paper Google i Caltech skupiony na ECC: złamanie secp256k1 (krzywa eliptyczna używana przez Bitcoin, Ethereum i większość TLS) wymaga około 500 000 fizycznych qubitów.
Willow — obecny procesor kwantowy Google — ma 105 qubitów. Jest daleko od progu. Ale próg właśnie stał się dwudziestokrotnie bliższy — nie dlatego że sprzęt się zmienił, ale dlatego że algorytmy się poprawiły.
Google ogłosił 25 marca 2026 roku: docelowa data własnej migracji na kryptografię post-kwantową — 2029.
Różnica która robi różnicę
PYMNTS ujmuje centralną obserwację precyzyjnie: "Google nie ogłosił kiedy Q-Day nadejdzie. Ogłosił kiedy trzeba skończyć migrację żeby nie być zaskoczonym."
To jest fundamentalna różnica w jak myśleć o tym problemie.
Starsze podejście: Q-Day to data w przyszłości kiedy komputer kwantowy złamie RSA. Kiedy ta data nastąpi — zadziałamy. Podejście Google 2029: migracja kryptograficzna zajmuje lata. Jeśli zaczniesz dopiero gdy Q-Day jest potwierdzony — nie zdążysz. Trzyletnie okno Google to nie jest prognoza kiedy komputer kwantowy jest gotowy. To jest ocena ile czasu zajmuje migracja na tak dużą skalę.
Jest jeszcze jedna warstwa. Dane zaszyfrowane dziś — emaile, transakcje finansowe, dokumenty rządowe — są dziś bezpieczne. Ale są już teraz zbierane przez podmioty które planują je odszyfrować gdy komputer kwantowy będzie gotowy. "Harvest now, decrypt later" to nie jest hipoteza — to jest opisywana przez Quantum Insider aktywna praktyka państwowych aktorów i zaawansowanych przeciwników.
Dane które muszą pozostać poufne przez następne dziesięć lat są już teraz narażone.
Co konkretnie złamie komputer kwantowy
Żeby ocenić ryzyko trzeba wiedzieć co jest podatne a co nie.
Podatne na atak kwantowy: RSA — asymetryczne szyfrowanie używane w HTTPS, certyfikatach TLS, email S/MIME, podpisach cyfrowych. Elliptic Curve Cryptography (ECC) — wariant używany przez secp256k1 (Bitcoin, Ethereum, większość blockchainów), P-256, P-384 (TLS, VPN, mTLS). Diffie-Hellman — wymiana kluczy w TLS, SSH.
Odporne na atak kwantowy: AES-256 (z Groverem wymaga dwukrotnie więcej qubitów — nadal bezpieczny przy 256-bitowym kluczu). SHA-256, SHA-3. NIST PQC algorytmy: CRYSTALS-Kyber (wymiana kluczy), CRYSTALS-Dilithium (podpisy cyfrowe), FALCON, SPHINCS+.
Praktyczna konsekwencja dla infrastruktury organizacji: HTTPS z TLS 1.3 używa ECC do wymiany kluczy. SSH używa ECC lub RSA. VPN używa Diffie-Hellman. Każde podpisane oprogramowanie używa RSA lub ECC. Każdy certyfikat X.509 używa RSA lub ECC.
Bitcoin przez dziewięć minut
Quantum Insider opisuje jeden szczegół który jest mierzalnym sygnałem konkretności zagrożenia.
Paper Google skupiony na secp256k1 — krzywej eliptycznej Bitcoina i Ethereum — zawiera obliczenie: przy założeniu "primedmode" (pierwsza połowa obliczeń precomputed bo parametry krzywej są stałe), czas na wydobycie prywatnego klucza z publicznego po ujawnieniu publicznego klucza wynosi około dziewięciu minut.
Czas potwierdzenia transakcji Bitcoin: dziesięć minut.
Google szacuje 41% prawdopodobieństwo że primed quantum computer mógłby wydobyć prywatny klucz zanim transakcja zostanie potwierdzona. Pod idealnie warunkami, przy założeniu że sprzęt osiąga parametry modelu z paperu.
Google zdecydował się nie publikować faktycznych obwodów kwantowych — zamiast tego wydał zero-knowledge proof który pozwala matematycznie zweryfikować szacunki zasobów bez dostarczania instrukcji wykonania. Zero-knowledge proof jest zbudowany na pairing-friendly elliptic curves (BLS12-381) które same będą podatne na wystarczająco potężny komputer kwantowy. Jak Quantum Insider odnotowuje: "proof jest ważny tylko dlatego że takie maszyny jeszcze nie istnieją."
Kto jest na celu
Sektor finansowy jest oczywistym celem — i ma własne ramy działania. SEC opublikowało Post-Quantum Financial Infrastructure Framework w 2025 roku dokumentując case: globalny bank inwestycyjny przeprowadził pełny audyt kryptografii i znalazł 47 000 zasobów kryptograficznych, 1 200 krytycznych systemów, 340 zależności wysokiego ryzyka. Koszt pełnej migracji: 12 milionów dolarów. Citi Institute modeluje koszt awaryjnej migracji po quantum event dla jednego banku z pięciu największych: 2-3,3 biliona dolarów ryzyka dla PKB. Różnica między przygotowanym a nieprzygotowanym liczy się w rzędach wielkości.
Ale sektor który jest mniej oczywistym ale natychmiastowym celem to infrastruktura podpisywania oprogramowania. Google stawia to wprost w swoim ogłoszeniu: "Encryption used to protect data in transit remains a concern, but Google now places greater emphasis on digital signatures — the cryptographic tools used to verify identity and ensure software integrity."
Certyfikat podpisywania kodu — ten który gwarantuje że oprogramowanie pochodzi od legalnego producenta — używa RSA lub ECC. Opisywaliśmy przy TanStack i OpenAI jak certyfikaty podpisywania kodu stały się celem ataków supply chain. Komputer kwantowy daje atakującemu możliwość sfałszowania każdego certyfikatu — bez włamania do infrastruktury producenta.
NIST, CloudFlare, Android 17
Dobra wiadomość jest taka że rozwiązanie istnieje. NIST sfinalizował pierwsze post-kwantowe standardy kryptograficzne w 2024 roku: CRYSTALS-Kyber do wymiany kluczy, CRYSTALS-Dilithium do podpisów. CloudFlare ogłosił że też celuje w 2029. Google integruje PQC w Android 17 do czerwca 2026. Chrome już obsługuje CRYSTALS-Kyber dla TLS.
Zła wiadomość jest taka że wiedząc co robić i robiąc to to są dwie różne rzeczy w skali organizacji.
Replacing cryptographic systems throughout an organization is not a patch cycle. It is an architectural migration. Każde API, każda integracja, każde połączenie TLS, każde podpisane oprogramowanie, każdy certyfikat. W organizacji z dziesiątkami systemów i setkami integracji to jest projekt mierzony w latach, nie miesiącach.
Google wybrał 2029 jako wewnętrzną datę docelową wiedząc że migracja Google займе trzy lata przy nieograniczonych zasobach i pełnej kontroli nad własnym stosem. Organizacja bez dedykowanego quantum readiness team i pełnej mapy kryptograficznych zależności — potrzebuje zacząć dzisiaj żeby zdążyć.
Nie panika, harmonogram
Warto zakończyć PYMNTS zdaniem które jest najcenniejszym ujęciem tego problemu: "Pytanie nie brzmi kiedy quantum computers dotrą. Brzmi czy dane które generujemy dziś będą bezpieczne gdy dotrą."
Q-Day nie jest datą. Jest progiem za którym dane zaszyfrowane dziś — przez TLS, RSA, ECC — mogą być odszyfrowane. Część z tych danych jest już zbierana z myślą o tym progu.
Dla większości organizacji właściwy pierwszy krok to nie projekt migracyjny. To audyt: jaką kryptografię używasz, gdzie, w których systemach, z jakimi zależnościami. Bez tej mapy planowanie migracji jest niemożliwe.
NIST algorytmy są gotowe. Implementacje są dostępne. 2029 jest trzy lata od dziś. To jest wystarczająco dużo czasu — ale tylko jeśli zaczyna się teraz.
Źródła
CNN — najszersze omówienie Q-Day dla ogólnej publiczności: https://www.cnn.com/2026/05/17/science/quantum-computing-cybersecurity-q-day
Google Blog — oficjalne ogłoszenie 2029 i kontekst PQC: https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/
Quantum Insider — trzy papery które przepisały timeline z marca 2026: https://thequantuminsider.com/2026/03/31/q-day-just-got-closer-three-papers-in-three-months-are-rewriting-the-quantum-threat-timeline/
QuSecure — analiza paper Craig Gidney z obliczeniami qubitów: https://www.qusecure.com/google-accelerates-q-day-migration-timeline-to-2029/
PYMNTS — "timing problem not technology problem": https://www.pymnts.com/cybersecurity/2026/breaking-google-says-q-day-coming-migration-deadline-now-2029/
Google Quantum AI Blog — paper o ECC i secp256k1: https://quantumai.google/research/publications/advancing-post-quantum-cryptography-standards-timeline


















































































































Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł