Największy błąd w ocenie szyfrowania polega na utożsamianiu bezpieczeństwa z nazwą algorytmu. Sam fakt użycia AES, RSA albo usługi Cloud KMS nie oznacza jeszcze, że dane są dobrze chronione. System może korzystać z silnej kryptografii, a mimo to ujawniać informacje przez źle przechowywany klucz, nieaktualny protokół, błędną konfigurację kopii zapasowych albo uprawnienia nadane zbyt szeroko.
Historia szyfrowania danych pokazuje to bardzo wyraźnie. Enigma nie została pokonana wyłącznie dzięki „mocniejszym obliczeniom”, lecz także dzięki analizie procedur, powtarzalnych błędów i sposobu pracy operatorów. Z kolei współczesna kryptografia chmurowa nie ogranicza się do wyboru algorytmu. Obejmuje cały cykl życia danych: ich zapis, przesyłanie, przetwarzanie, archiwizację, udostępnianie i usuwanie.
Przejście od mechanicznych wirników do kryptografii stosowanej w środowiskach wielochmurowych było przejściem od pojedynczego urządzenia do złożonego systemu zależności. Zmieniły się narzędzia, skala i matematyka, ale podstawowe pytania pozostały podobne: kto ma klucz, jak potwierdzić tożsamość odbiorcy, co dzieje się w przypadku błędu oraz jak ograniczyć skutki przejęcia pojedynczego elementu infrastruktury.
Mechaniczne początki nowoczesnego szyfrowania: lekcja Enigmy w dobie cyfrowej
Matematyczne łamanie kodów a błędy ludzkie
Enigma była elektromechaniczną maszyną szyfrującą używaną przez niemieckie siły zbrojne. Jej działanie opierało się na przepływie sygnału przez zestaw wirników, układ połączeń oraz reflektor. Po każdym naciśnięciu klawisza przynajmniej jeden wirnik zmieniał pozycję, dzięki czemu ta sama litera mogła zostać zaszyfrowana na różne sposoby. Konstrukcja sprawiała wrażenie niezwykle złożonej, zwłaszcza gdy uwzględni się liczbę możliwych ustawień. [1]
Nie oznaczało to jednak odporności absolutnej. Bezpieczeństwo Enigmy zależało nie tylko od liczby kombinacji, ale też od sposobu ich wybierania, przekazywania i stosowania. Jeżeli operatorzy używali przewidywalnych ustawień, powtarzali formuły wiadomości albo popełniali błędy przy obsłudze, przeciwnik otrzymywał dodatkowe informacje. Każda taka informacja zmniejszała przestrzeń możliwych ustawień.
To ważna lekcja także dla współczesnych systemów. Algorytm może być formalnie odporny na znane ataki, ale aplikacja może ujawnić klucz w logach, przesłać dane przez niezabezpieczony kanał albo pozwolić na dostęp do odszyfrowanego pliku osobie, która nie powinna go widzieć. Atakujący często nie musi „łamać AES”. Wystarczy, że znajdzie hasło w repozytorium, token w zmiennej środowiskowej lub konto z nadmiernymi uprawnieniami.
Polski wkład: Rejewski, Różycki i Zygalski
Polski wkład w analizę Enigmy miał fundamentalne znaczenie. Marian Rejewski wykorzystał metody matematyczne do odtworzenia struktury wirników i zależności opisujących działanie maszyny. Jerzy Różycki oraz Henryk Zygalski rozwijali techniki pomocne w odczytywaniu szyfrogramów, w tym rozwiązania oparte na charakterystycznych wzorcach wynikających z procedur używanych przez operatorów.
Znaczenie tych prac wykraczało poza samą historię wojskowości. Był to przykład zastosowania matematyki, analizy kombinatorycznej i systematycznego eksperymentowania do problemu, który wcześniej mógł wydawać się domeną mechaniki oraz tajemnicy wojskowej. Polscy kryptolodzy nie czekali na przypadkowe odkrycie klucza. Budowali modele, szukali regularności i tworzyli narzędzia przyspieszające analizę.
Wiedza ta została przekazana aliantom przed wybuchem wojny. Późniejsze prace brytyjskich zespołów, w tym zespołu z Bletchley Park kierowanego przez Alana Turinga, rozwijały metody automatyzacji i masowego przeszukiwania ustawień. Wymagało to połączenia kryptologii, logiki, inżynierii oraz organizacji pracy. Z perspektywy historii informatyki był to jeden z etapów prowadzących do rozwoju maszyn obliczeniowych przeznaczonych do rozwiązywania konkretnych problemów.
Dlaczego procedury były groźniejsze niż same wirniki
Enigma miała właściwości konstrukcyjne, które ograniczały jej bezpieczeństwo. Jedną z nich była specyficzna relacja między literą wejściową a wyjściową: w określonych warunkach maszyna nie szyfrowała litery samą sobą. Tego rodzaju cecha mogła dostarczyć kryptologom testu eliminującego część hipotez. Sama liczba konfiguracji nie wystarczała więc do oceny odporności.
Jeszcze większe znaczenie miały procedury. Wiadomości wojskowe często zawierały przewidywalne zwroty, nagłówki, meldunki pogodowe lub powtarzalne schematy. Operatorzy mogli zaczynać wiadomości w podobny sposób, stosować łatwe do zapamiętania ustawienia albo popełniać błędy przy przekazywaniu kluczy. Takie elementy nazywa się czasem cribs — przewidywanymi fragmentami tekstu, które pomagają sprawdzić konkretne ustawienie szyfru.
Współczesnym odpowiednikiem przewidywalnego nagłówka może być stały fragment JSON-a, niezmienny identyfikator klienta, powtarzana wartość w protokole albo komunikat błędu ujawniający, czy odszyfrowanie się powiodło. Jeśli system szyfruje dane, lecz pozostawia obserwowalne wzorce, atakujący może wykorzystać metadane, długość wiadomości, częstotliwość żądań i czas odpowiedzi.
Współczesny wniosek z historii Enigmy
Najważniejsza lekcja brzmi: bezpieczeństwo kryptograficzne jest własnością całego procesu, a nie tylko algorytmu. Proces obejmuje generowanie kluczy, ich dystrybucję, uwierzytelnianie użytkowników, konfigurację urządzeń, aktualizacje i reakcję na incydenty. Jeżeli jeden z tych elementów jest słaby, przeciwnik może ominąć silny szyfr.
Przy projektowaniu systemu dobrze zadać kilka prostych pytań. Gdzie dokładnie powstaje klucz? Kto może go odczytać? Czy administrator bazy danych może odszyfrować rekordy bez dodatkowej zgody? Co dzieje się po skopiowaniu backupu do innego regionu? Jak szybko można unieważnić dostęp? Brak jasnych odpowiedzi oznacza lukę projektową, nawet jeśli dokumentacja wymienia nowoczesne algorytmy.
Nie należy także zakładać, że większa złożoność automatycznie poprawia bezpieczeństwo. Wiele warstw, usług i wyjątków może utrudnić audyt. Prosty model z dobrze zarządzanym kluczem bywa bezpieczniejszy niż skomplikowana architektura, w której nikt nie potrafi jednoznacznie określić, kto i kiedy może odszyfrować dane.
Standaryzacja kryptografii symetrycznej: droga od DES do AES
Na czym polega kryptografia symetryczna
Kryptografia symetryczna wykorzystuje ten sam tajny klucz do szyfrowania i odszyfrowywania danych. Jej największą zaletą jest wydajność. Algorytm może przetwarzać duże pliki, całe wolumeny dyskowe oraz strumienie danych bez kosztu charakterystycznego dla operacji z dużymi liczbami pierwszymi.
Problem pojawia się przy przekazaniu klucza. Nadawca i odbiorca muszą dysponować tym samym sekretem, ale nie mogą ujawnić go osobie trzeciej. W małym, zamkniętym środowisku można zrobić to ręcznie lub przez bezpieczny kanał. W dużej organizacji, która ma tysiące użytkowników, serwerów i aplikacji, dystrybucja kluczy staje się osobnym problemem architektonicznym.
Algorytm symetryczny nie zapewnia sam z siebie integralności ani tożsamości nadawcy. Szyfrogram może zostać zmodyfikowany, a odbiorca musi mieć sposób wykrycia takiej zmiany. Dlatego nowoczesne rozwiązania często używają trybów AEAD, takich jak AES-GCM lub ChaCha20-Poly1305, które łączą poufność z uwierzytelnieniem danych.
DES i ograniczenia pierwszych standardów blokowych
Data Encryption Standard, czyli DES, został opublikowany jako standard szyfrowania danych w latach siedemdziesiątych. Operował na blokach o długości 64 bitów i używał efektywnego klucza o długości 56 bitów. W czasie jego projektowania był to rozsądny kompromis między bezpieczeństwem a możliwościami sprzętu.
Rozwój elektroniki sprawił jednak, że przestrzeń 256 możliwych kluczy stała się zbyt mała. Atak brute-force nie wymaga znajomości słabości matematycznej algorytmu. Wystarczy systematycznie sprawdzać kolejne klucze i rozpoznać, który wynik daje sensowny tekst lub poprawną strukturę danych. Wraz ze spadkiem kosztu obliczeń taki atak stał się praktycznie wykonalny.
Próbą przedłużenia życia DES był 3DES, który wykonywał operacje DES trzykrotnie, z dwoma lub trzema kluczami. Zwiększało to bezpieczeństwo względem pierwotnego wariantu, ale powodowało znaczny spadek wydajności. Ponadto 3DES zachowywał mały rozmiar bloku 64-bitowego, co przy dużych ilościach danych prowadziło do problemów z powtarzającymi się blokami i ograniczeniami bezpieczeństwa. Z tego powodu został wyparty przez nowsze rozwiązania.
Architektura AES i przyczyny jego dominacji
Advanced Encryption Standard został wybrany w ramach otwartego procesu standaryzacyjnego, w którym zwyciężył algorytm Rijndael zaprojektowany przez Joan Daemen i Vincenta Rijmena. AES operuje na blokach 128-bitowych i występuje z kluczami o długości 128, 192 oraz 256 bitów. W praktyce najczęściej spotyka się AES-128 i AES-256.
Algorytm przekształca blok danych w kilku rundach obejmujących między innymi podstawienie bajtów, przesunięcia, mieszanie kolumn i dodawanie klucza rundowego. Te operacje tworzą kombinację dyfuzji i konfuzji: zmiana pojedynczego bitu wejścia powinna wpływać na dużą część wyniku. Bez znajomości klucza odtworzenie tekstu jawnego ma być obliczeniowo niewykonalne.
Popularność AES wynika nie tylko z długości klucza. Algorytm jest dobrze zbadany, szeroko zaimplementowany i wspierany sprzętowo przez wiele procesorów. To ważne w szyfrowaniu dysków, baz danych, połączeń sieciowych i dużych magazynów obiektowych. AES-256 nie jest jednak magicznym przełącznikiem bezpieczeństwa. Błędny tryb pracy, powtarzanie nonce albo przechowywanie klucza obok danych może zniweczyć korzyści wynikające z silnej matematyki.
Jak poprawnie myśleć o AES-256
Wybór AES-256 ma sens, gdy organizacja potrzebuje dużego marginesu bezpieczeństwa, podlega wymaganiom regulacyjnym albo chce ograniczyć ryzyko długoterminowego przechowywania danych. W wielu zastosowaniach AES-128 również pozostaje bezpieczny, a różnica wydajności może mieć znaczenie przy bardzo intensywnym przetwarzaniu. Decyzję powinny uzasadniać wymagania dotyczące danych i model zagrożeń, nie sama moda na dłuższy klucz.
Dużo ważniejszy od samego numeru 128 lub 256 jest tryb pracy. ECB, czyli Electronic Codebook, szyfruje każdy blok niezależnie i może ujawniać powtarzające się wzorce. Nie powinien być używany do szyfrowania struktur, obrazów ani plików, w których wzorce mają znaczenie. Bezpieczniejsze rozwiązania korzystają z trybów zapewniających odpowiednie właściwości poufności i integralności.
W aplikacji nie powinno się samodzielnie implementować AES na podstawie opisu z dokumentacji. Biblioteka kryptograficzna musi prawidłowo obsługiwać generowanie nonce, padding, kontrolę integralności, błędy odszyfrowania oraz bezpieczne czyszczenie pamięci, gdy jest to możliwe. Deweloper powinien korzystać z wysokopoziomowego interfejsu, który ogranicza liczbę decyzji pozostawianych przypadkowej konfiguracji.
Rewolucja klucza publicznego: rozwiązanie problemu zaufania w sieci
Kryptografia symetryczna jest szybka, ale wymaga wcześniejszego bezpiecznego przekazania wspólnego sekretu. W zamkniętej sieci można dostarczyć klucz przez kontrolowany kanał, jednak taki model przestaje być wygodny, gdy komunikują się ze sobą nieznane wcześniej urządzenia, użytkownicy i usługi internetowe. Właśnie ten problem stał się impulsem do rozwoju kryptografii asymetrycznej, nazywanej również kryptografią klucza publicznego.
Dwa klucze zamiast jednego sekretu
W systemie asymetrycznym każda strona posługuje się parą powiązanych ze sobą kluczy. Klucz publiczny można udostępnić innym osobom, natomiast klucz prywatny musi pozostać pod wyłączną kontrolą właściciela. Dane zaszyfrowane kluczem publicznym mogą zostać odszyfrowane tylko przy użyciu odpowiadającego mu klucza prywatnego.
Ta właściwość rozwiązuje część problemu dystrybucji. Nadawca nie musi otrzymywać tajnego klucza odbiorcy przez ten sam kanał, którym przesyła dane. Może pobrać jego klucz publiczny, użyć go do ochrony wiadomości, a odbiorca wykorzysta swój klucz prywatny po swojej stronie.
Warto przeczytać również powiązany artykuł: Rok 2015 w informatyce: przełomy, które zmieniły technologię.
W praktyce nie oznacza to, że kryptografia asymetryczna zastąpiła symetryczną. Operacje na kluczach publicznych są zwykle bardziej kosztowne obliczeniowo, dlatego najlepiej nadają się do ustanawiania zaufania, uzgadniania krótkich sekretów i podpisywania danych. Duże pliki oraz długie strumienie informacji szyfruje się następnie wydajnym algorytmem symetrycznym. [3]
Wymiana kluczy i szyfrowanie hybrydowe
Jednym z przełomowych rozwiązań była możliwość uzgodnienia wspólnego sekretu przez kanał, który może być obserwowany przez przeciwnika. Protokół Diffiego-Hellmana pozwala dwóm stronom wyprowadzić ten sam sekret na podstawie publicznie wymienianych wartości. Osoba podsłuchująca komunikację widzi przesyłane parametry, ale nie powinna być w stanie obliczyć końcowego sekretu bez znajomości prywatnych składników.
Współczesne warianty, takie jak ECDH, wykorzystują arytmetykę na krzywych eliptycznych. Zapewniają porównywalny poziom bezpieczeństwa przy krótszych kluczach i dobrze nadają się do urządzeń o ograniczonych zasobach. Samo uzgodnienie sekretu nie wystarcza jednak do uwierzytelnienia rozmówcy. Bez dodatkowych mechanizmów atakujący może próbować wstawić się pomiędzy strony i przeprowadzić atak typu man-in-the-middle.
Dlatego w praktyce często stosuje się szyfrowanie hybrydowe. Schemat może wyglądać następująco:
- aplikacja generuje losowy, tymczasowy klucz symetryczny dla konkretnej wiadomości lub sesji,
- dane są szyfrowane tym kluczem za pomocą algorytmu zapewniającego poufność i integralność,
- klucz symetryczny zostaje zabezpieczony kluczem publicznym odbiorcy albo uzgodniony w ramach uwierzytelnionego protokołu wymiany,
- odbiorca odzyskuje klucz sesyjny i używa go do odszyfrowania danych.
Takie podejście łączy wydajność szyfrowania symetrycznego z wygodą zarządzania kluczami publicznymi. Jest wykorzystywane między innymi w protokołach zabezpieczających połączenia internetowe, systemach pocztowych, aplikacjach do wymiany plików oraz narzędziach do ochrony kopii zapasowych. [2]
Podpis cyfrowy i potwierdzanie tożsamości
Klucz publiczny może służyć nie tylko do ochrony poufności. Właściciel klucza prywatnego może utworzyć podpis cyfrowy dla dokumentu, komunikatu albo kodu programu. Odbiorca używa klucza publicznego do sprawdzenia, czy podpis pasuje do danych i czy wiadomość nie została zmieniona po podpisaniu.
Podpis nie jest tym samym co szyfrowanie. Jego głównym zadaniem jest potwierdzenie integralności oraz pochodzenia danych. Przykładowo producent aktualizacji może podpisać pakiet oprogramowania. Urządzenie, które zna właściwy klucz publiczny, sprawdzi podpis przed instalacją. Zmodyfikowany plik lub pakiet podpisany przez nieznaną stronę powinien zostać odrzucony.
Ważnym zastosowaniem podpisów są certyfikaty cyfrowe. Certyfikat wiąże klucz publiczny z określoną nazwą, domeną, usługą lub organizacją. Taki dokument jest podpisywany przez urząd certyfikacji, któremu system ufa zgodnie z wcześniej ustaloną hierarchią. Gdy przeglądarka łączy się z serwerem HTTPS, nie sprawdza wyłącznie matematycznej poprawności klucza. Weryfikuje również, czy certyfikat dotyczy właściwej domeny, czy nie wygasł i czy prowadzi do zaufanego łańcucha.
To pokazuje, że problem zaufania nie znika całkowicie dzięki kluczom publicznym. Zostaje przeniesiony na poziom infrastruktury klucza publicznego, zarządzania certyfikatami i ochrony kluczy prywatnych. Błędnie wystawiony certyfikat, przejęte konto urzędu certyfikacji albo nieaktualny klucz zaufania mogą mieć skutki dla wielu użytkowników jednocześnie.
Praktyczny przykład: bezpieczne połączenie aplikacji z usługą
Załóżmy, że aplikacja mobilna łączy się z API bankowym. Podczas ustanawiania połączenia serwer przedstawia certyfikat zawierający klucz publiczny. Aplikacja sprawdza nazwę domeny, okres ważności oraz podpis wystawcy. Następnie strony uzgadniają klucze sesyjne, które będą używane do szybkiego szyfrowania kolejnych żądań.
Jeżeli użytkownik pobiera dane konta, ich poufność zapewnia szyfrowanie sesji, a integralność chronią mechanizmy uwierzytelniające protokołu. Jeżeli natomiast aplikacja pobiera aktualizację, może dodatkowo zweryfikować podpis cyfrowy pakietu. Każdy etap odpowiada na inne pytanie: z kim rozmawiam, czy nikt nie zmienił transmisji oraz czy otrzymany plik pochodzi od właściwego wydawcy.
Bezpieczeństwo danych w chmurze: stany przetwarzania i zarządzanie kluczami
Przeniesienie danych do chmury nie usuwa potrzeby stosowania kryptografii. Zmienia natomiast granice zaufania. Organizacja korzysta z infrastruktury, systemów operacyjnych, magazynów i usług zarządzanych przez dostawcę. Trzeba więc określić, które elementy pozostają pod kontrolą klienta, które są obsługiwane przez dostawcę oraz gdzie znajdują się klucze potrzebne do odszyfrowania informacji. [4]
Trzy stany danych
Najprościej analizować ochronę danych w trzech stanach: podczas przesyłania, podczas przechowywania oraz podczas przetwarzania. Każdy z nich ma inne zagrożenia i wymaga nieco innych mechanizmów.
Dane w tranzycie przemieszczają się między przeglądarką a serwerem, między usługami w jednej chmurze albo między regionami. Zabezpieczeniem jest najczęściej uwierzytelniony protokół transportowy, taki jak TLS. Warto jednak sprawdzić, czy szyfrowanie obejmuje całą ścieżkę. Połączenie zabezpieczone od klienta do bramy nie zawsze oznacza, że dane są chronione również na odcinku między bramą a wewnętrzną usługą.
Dane w spoczynku znajdują się w bazach danych, systemach plików, magazynach obiektowych, migawkach i kopiach zapasowych. Szyfrowanie wolumenu lub obiektu ogranicza skutki kradzieży nośnika, błędnego udostępnienia albo dostępu do surowego magazynu. Nie chroni jednak przed każdą sytuacją. Proces, który ma uprawnienie do odczytu i klucz odszyfrowujący, może nadal uzyskać treść danych.
Najtrudniejsze są dane w użyciu, czyli aktualnie przetwarzane przez aplikację. W klasycznym modelu muszą zostać odszyfrowane w pamięci procesu, aby program mógł je analizować. Ochrona tego etapu wymaga dodatkowych technik, takich jak izolowane środowiska wykonawcze, poufne maszyny wirtualne lub szyfrowanie homomorficzne.
Szyfrowanie aplikacyjne a szyfrowanie infrastruktury
Szyfrowanie oferowane przez dostawcę chmury może działać na poziomie dysku, bazy danych, tabeli, kolumny, obiektu albo pojedynczego pola. Im wyżej w stosie znajduje się mechanizm, tym precyzyjniej można kontrolować zakres ochrony, ale rośnie też złożoność integracji.
Szyfrowanie całego dysku jest proste w utrzymaniu i dobrze zabezpiecza nośnik przed odczytem poza środowiskiem wykonawczym. Nie rozwiązuje jednak problemu dostępu aplikacji z uprawnieniami administratora. Z kolei szyfrowanie wybranych kolumn lub pól może ograniczyć widoczność najbardziej wrażliwych informacji, lecz wymaga obsługi wyszukiwania, rotacji kluczy, indeksów i kopii zapasowych.
Przy wyborze poziomu ochrony należy odpowiedzieć na pytanie, przed kim dane mają być ukryte. Jeżeli celem jest ochrona przed utratą nośnika, wystarczy inny mechanizm niż w sytuacji, gdy administrator bazy danych nie powinien widzieć numerów dokumentów lub danych medycznych. Model zagrożeń powinien poprzedzać wybór usługi chmurowej.
Zarządzanie kluczami i szyfrowanie kopertowe
W większych środowiskach nie należy przechowywać jednego klucza używanego do wszystkich danych. Popularnym rozwiązaniem jest szyfrowanie kopertowe. Dane szyfruje się kluczem danych, a następnie sam klucz danych zabezpiecza kluczem zarządzanym przez usługę KMS albo przechowywanym w module HSM.
Przykładowo aplikacja może wygenerować unikatowy klucz dla jednego pliku lub rekordu. Plik zostaje zaszyfrowany lokalnie, natomiast klucz pliku jest przekazywany do KMS w celu ochrony. W bazie przechowuje się szyfrogram oraz zaszyfrowany klucz danych. Aby odczytać plik, aplikacja musi uzyskać zgodę na użycie klucza nadrzędnego, odzyskać klucz danych i odszyfrować zawartość.
Model ten ułatwia rotację kluczy nadrzędnych. Nie zawsze trzeba ponownie szyfrować wszystkie pliki. Można zmienić sposób ochrony kluczy danych, zachowując same szyfrogramy. Trzeba jednak zaprojektować procedurę odzyskiwania, ponieważ utrata klucza nadrzędnego może oznaczać trwałą utratę dostępu do całej kolekcji danych.
KMS, czyli Key Management Service, oferuje zwykle kontrolę dostępu, audyt użycia, wersjonowanie i automatyzację rotacji. HSM, czyli Hardware Security Module, przechowuje operacje kryptograficzne w wyspecjalizowanym urządzeniu odpornym na część prób fizycznego wydobycia sekretów. Żadne z tych rozwiązań nie zastępuje poprawnych uprawnień. Konto z prawem do odszyfrowywania nadal może wykorzystać tę możliwość, nawet jeśli sam klucz znajduje się w bardzo bezpiecznym module.
Cykl życia klucza
Klucz powinien mieć określony cykl życia: bezpieczne wygenerowanie, aktywację, używanie, rotację, zawieszenie i zniszczenie. Rotacja nie jest automatycznie lekarstwem na każdy problem. Jej częstotliwość powinna wynikać z wartości danych, wymagań regulacyjnych, sposobu użycia klucza oraz możliwości ponownego zabezpieczenia istniejących danych.
Ważne jest rozdzielenie ról. Osoba wdrażająca aplikację nie powinna automatycznie otrzymywać prawa do eksportu klucza głównego. Administrator infrastruktury może zarządzać usługą, ale nie mieć dostępu do treści danych. Z kolei zespół bezpieczeństwa powinien móc przeglądać logi użycia i zatwierdzać operacje wysokiego ryzyka.
Logi KMS powinny odpowiadać na pytania: kto użył klucza, z jakiej usługi, w jakim regionie, dla jakiego zasobu i o której godzinie. Same logi również mogą zawierać wrażliwe informacje, dlatego należy ograniczyć ich treść, ustalić retencję i objąć je kontrolą dostępu.
Źródła
- [1] Computer History Museum – ENIGMA encryption/decryption device ↑
- [2] National Institute of Standards and Technology (NIST) – Cryptography ↑
- [3] National Institute of Standards and Technology (NIST) – The Cornerstone of Cybersecurity – Cryptographic Standards and a 50-Year Evolution ↑
- [4] Google Cloud – Encryption For Cloud Security ↑
