Werner Koch, g\u0142\u00f3wny programista i tw\u00f3rca projektu GnuPG, za\u0142o\u017cy\u0142 projekt LibrePGP, koncentruj\u0105c si\u0119 na rozwoju zaktualizowanej specyfikacji, alternatywnej wobec standardu OpenPGP. Fork zosta\u0142 stworzony w odpowiedzi na zmiany proponowane przez grup\u0119 robocz\u0105 IETF do wprowadzenia w nast\u0119pnej aktualizacji specyfikacji OpenPGP (RFC-4880), kt\u00f3re Koch uzna\u0142 za w\u0105tpliwe z perspektywy zachowania zgodno\u015bci i zapewnienia bezpiecze\u0144stwa. Programi\u015bci wspieraj\u0105cy fork, uczestnicy projekt\u00f3w GnuPG, RNP (implementacja OpenPGP dla Thunderbird) oraz Gpg4win obawiaj\u0105 si\u0119, \u017ce proponowane zmiany mog\u0105 by\u0107 szkodliwe dla istniej\u0105cych implementacji aplikacji opartych na OpenPGP, u\u017cytkownicy kt\u00f3rych licz\u0105 na stabilno\u015b\u0107 specyfikacji w d\u0142ugim okresie i nie s\u0105 gotowi na zmiany naruszaj\u0105ce zgodno\u015b\u0107. <\/p>\n
LibrePGP wdra\u017ca u\u017cyteczne ulepszenia, kt\u00f3re by\u0142y rozwijane w ostatnich latach dla przysz\u0142ej wersji specyfikacji OpenPGP, ale jednocze\u015bnie wyklucza zmiany, kt\u00f3re negatywnie wp\u0142ywaj\u0105 na zapewnienie zgodno\u015bci. Na przyk\u0142ad, w por\u00f3wnaniu z obowi\u0105zuj\u0105cym standardem RFC-4880, w LibrePGP przyj\u0119to takie mo\u017cliwo\u015bci jak: <\/p>\n
Rozszerzenia ECC (Elliptic Curve Cryptography) dla OpenPGP (RFC-6637).\n
Obowi\u0105zkowe wsparcie dla hasz\u00f3w SHA2-256 (SHA-1 i MD5 zosta\u0142y uznane za niezalecane, a mo\u017cliwo\u015b\u0107 odszyfrowania danych bez weryfikacji integralno\u015bci zosta\u0142a uznana za ca\u0142kowicie przestarza\u0142\u0105).\n
Zwi\u0119kszenie rozmiaru odcisku palca (fingerprint) do 256 bit\u00f3w.\n
Wsparcie schematu podpisu cyfrowego EdDSA oraz krzywych eliptycznych BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 i X448.\n
Wsparcie algorytmu CRYSTALS-Kyber, odpornego na ataki na komputerach kwantowych.\n
Wsparcie dla tryb\u00f3w szyfrowania z autoryzacj\u0105 OCB (Offset codebook mode).\n
Wdra\u017canie pi\u0105tej wersji formatu podpis\u00f3w cyfrowych z ochron\u0105 metadanych.\n
Wsparcie dla rozszerzonych subpakiet\u00f3w z podpisami cyfrowymi. <\/ul>\n
G\u0142\u00f3wne elementy krytyki nowej specyfikacji OpenPGP: <\/p>\n
\n
Grupa robocza IETF zamiast stopniowego, inkrementalnego aktualizowania specyfikacji pr\u00f3bowa\u0142a na nowo wynale\u017a\u0107 standard, wprowadzaj\u0105c do niego znaczne zmiany, kt\u00f3re naruszaj\u0105 zgodno\u015b\u0107.\n
Wprowadzenie wymogu wsparcia dla symetrycznego trybu szyfrowania GCM (Galois\/Counter Mode), kt\u00f3ry jest trudny do poprawnego wdro\u017cenia, ignoruj\u0105c przy tym tryb OCB (Offset Codebook Mode), kt\u00f3rego patenty wygas\u0142y kilka lat temu.\n
Dodanie opcjonalnych pakiet\u00f3w z losowym wype\u0142nieniem pomocniczym, aby chroni\u0107 przed analiz\u0105 ruchu. Zdaniem tw\u00f3rc\u00f3w LibrePGP, takie pakiety z niezweryfikowanym pocz\u0105tkowym losowym wype\u0142nieniem stwarzaj\u0105 zagro\u017cenie wykorzystania do tworzenia ukrytych kana\u0142\u00f3w przesy\u0142ania danych i omijania system\u00f3w zapobiegania wyciekom danych. Wcze\u015bniej pomys\u0142 dodania wype\u0142nienia pomocniczego by\u0142 odrzucany jako b\u0119d\u0105cy przedmiotem na poziomie aplikacji, a nie na poziomie szyfrowania.\n
Zastosowanie zmodyfikowanego schematu szyfrowania ECDH (zmiana formatu OID), zamiast korzystania z opisanego w RFC-6637 i wdro\u017conego w PGP i GnuPG wariantu.\n
Usuni\u0119cie niekt\u00f3rych wykorzystywanych w praktyce mo\u017cliwo\u015bci, takich jak klasyczna metoda uniewa\u017cniania kluczy, flaga «m» do oznaczania danych MIME oraz flaga «t» do oddzielania danych tekstowych od binarnych (zamiast flagi «t» wprowadzono flag\u0119 «u» dla tekstu w kodowaniu UTF-8).\n
Odrzucenie w\u0142\u0105czenia do nowego formatu podpis\u00f3w ochrony metadanych podpisanego pliku (na przyk\u0142ad, mo\u017cna zmieni\u0107 nazw\u0119 pliku bez naruszania podpisu).\n
W\u0105tpliwa mo\u017cliwo\u015b\u0107 dodania «soli» do podpis\u00f3w (Salted signature) w celu wzmocnienia ochrony przed atakami kolizyjnymi z okre\u015blonym prefiksem. Warto\u015b\u0107 z sol\u0105 mo\u017ce by\u0107 wykorzystywana jako niezbywalny ukryty kana\u0142 do przesy\u0142ania 32 bajt\u00f3w danych w podpisie.\n
Przesuni\u0119cie standardu w kierunku g\u0142\u00f3wnego u\u017cytku w komunikacji online, ignoruj\u0105c potrzeby d\u0142ugoterminowego przechowywania danych. <\/ul>\n
Zwolennicy OpenPGP ju\u017c opublikowali krytyk\u0119 na krytyk\u0119. W rezultacie, je\u015bli nie uda si\u0119 znale\u017a\u0107 kompromisu, roz\u0142am mo\u017ce prowadzi\u0107 do wzrostu niesp\u00f3jno\u015bci w implementacjach OpenPGP\/LibrePGP. Cz\u0119\u015bciowo dla rozwi\u0105zania tego problemu, deweloperzy OpenPGP utrwalili pi\u0105t\u0105 wersj\u0119 formatu podpis\u00f3w w wersji kompatybilnej z LibrePGP i przeszli do pracy nad sz\u00f3st\u0105 wersj\u0105. \n \u0179r\u00f3d\u0142o: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"