Werner Koch, główny programista i twórca projektu GnuPG, założył projekt LibrePGP, koncentrując się na rozwoju zaktualizowanej specyfikacji, alternatywnej wobec standardu OpenPGP. Fork został stworzony w odpowiedzi na zmiany proponowane przez grupę roboczą IETF do wprowadzenia w następnej aktualizacji specyfikacji OpenPGP (RFC-4880), które Koch uznał za wątpliwe z perspektywy zachowania zgodności i zapewnienia bezpieczeństwa. Programiści wspierający fork, uczestnicy projektów GnuPG, RNP (implementacja OpenPGP dla Thunderbird) oraz Gpg4win obawiają się, że proponowane zmiany mogą być szkodliwe dla istniejących implementacji aplikacji opartych na OpenPGP, użytkownicy których liczą na stabilność specyfikacji w długim okresie i nie są gotowi na zmiany naruszające zgodność.
LibrePGP wdraża użyteczne ulepszenia, które były rozwijane w ostatnich latach dla przyszłej wersji specyfikacji OpenPGP, ale jednocześnie wyklucza zmiany, które negatywnie wpływają na zapewnienie zgodności. Na przykład, w porównaniu z obowiązującym standardem RFC-4880, w LibrePGP przyjęto takie możliwości jak:
- Wsparcie algorytmu szyfrowania Camellia (RFC-5581),
- Rozszerzenia ECC (Elliptic Curve Cryptography) dla OpenPGP (RFC-6637).
- Obowiązkowe wsparcie dla haszów SHA2-256 (SHA-1 i MD5 zostały uznane za niezalecane, a możliwość odszyfrowania danych bez weryfikacji integralności została uznana za całkowicie przestarzałą).
- Zwiększenie rozmiaru odcisku palca (fingerprint) do 256 bitów.
- Wsparcie schematu podpisu cyfrowego EdDSA oraz krzywych eliptycznych BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 i X448.
- Wsparcie algorytmu CRYSTALS-Kyber, odpornego na ataki na komputerach kwantowych.
- Wsparcie dla trybów szyfrowania z autoryzacją OCB (Offset codebook mode).
- Wdrażanie piątej wersji formatu podpisów cyfrowych z ochroną metadanych.
- Wsparcie dla rozszerzonych subpakietów z podpisami cyfrowymi.
Główne elementy krytyki nowej specyfikacji OpenPGP:
- Grupa robocza IETF zamiast stopniowego, inkrementalnego aktualizowania specyfikacji próbowała na nowo wynaleźć standard, wprowadzając do niego znaczne zmiany, które naruszają zgodność.
- Wprowadzenie wymogu wsparcia dla symetrycznego trybu szyfrowania GCM (Galois/Counter Mode), który jest trudny do poprawnego wdrożenia, ignorując przy tym tryb OCB (Offset Codebook Mode), którego patenty wygasły kilka lat temu.
- Dodanie opcjonalnych pakietów z losowym wypełnieniem pomocniczym, aby chronić przed analizą ruchu. Zdaniem twórców LibrePGP, takie pakiety z niezweryfikowanym początkowym losowym wypełnieniem stwarzają zagrożenie wykorzystania do tworzenia ukrytych kanałów przesyłania danych i omijania systemów zapobiegania wyciekom danych. Wcześniej pomysł dodania wypełnienia pomocniczego był odrzucany jako będący przedmiotem na poziomie aplikacji, a nie na poziomie szyfrowania.
- Zastosowanie zmodyfikowanego schematu szyfrowania ECDH (zmiana formatu OID), zamiast korzystania z opisanego w RFC-6637 i wdrożonego w PGP i GnuPG wariantu.
- Usunięcie niektórych z praktycznie stosowanych funkcji, takich jak klasyczna metoda odwoływania kluczy, flaga „m” do oznaczania danych MIME oraz flaga „t” do oddzielania danych tekstowych od binarnych (w miejsce flagi „t” wprowadzono flagę „u” dla tekstu w kodowaniu UTF-8).
- Odrzucenie włączenia do nowego formatu podpisów ochrony metadanych podpisanego pliku (na przykład, można zmienić nazwę pliku bez naruszania podpisu).
- Wątpliwa możliwość dodania „soli” do podpisów (Salted signature) w celu wzmocnienia ochrony przed atakami kolizyjnymi z określonym prefiksem. Wartość z solą może być używana jako nieodłączny ukryty kanał do przesyłania 32 bajtów danych w podpisie.
- Przesunięcie standardu w kierunku głównego użytku w komunikacji online, ignorując potrzeby długoterminowego przechowywania danych.
Zwolennicy OpenPGP już opublikowali krytykę na krytykę. W rezultacie, jeśli nie uda się znaleźć kompromisu, rozłam może prowadzić do wzrostu niespójności w implementacjach OpenPGP/LibrePGP. Częściowo dla rozwiązania tego problemu, deweloperzy OpenPGP utrwalili piątą wersję formatu podpisów w wersji kompatybilnej z LibrePGP i przeszli do pracy nad szóstą wersją.
Źródło: opennet.ru
