Werner Koch, hlavní vývojář a zakladatel projektu GnuPG (GNU Privacy Guard), založil projekt LibrePGP, který se zaměřuje na vývoj aktualizované specifikace, alternativní k standardu OpenPGP. Fork byl vytvořen v reakci na změny plánované pracovní skupinou IETF pro další aktualizaci specifikace OpenPGP (RFC-4880), které byly Kochovi vnímány jako pochybení z hlediska zachování kompatibility a zajištění bezpečnosti. Vývojáři, kteří podpořili fork, projekty GnuPG, RNP (implementace OpenPGP pro Thunderbird) a Gpg4win, mají obavy, že plánované změny negativně ovlivní stávající implementace aplikací založených na OpenPGP, jejichž uživatelé očekávají stabilitu specifikace v dlouhodobém horizontu a nejsou ochotni akceptovat změny narušující kompatibilitu.
LibrePGP zahrnuje užitečná vylepšení, která byla v posledních letech vyvíjena pro budoucí variantu specifikace OpenPGP, ale na druhé straně vylučuje změny, které negativně ovlivňují zajištění kompatibility. Například v porovnání se stávajícím standardem RFC-4880 byly v LibrePGP přijaté následující možnosti:
- Podpora šifrovacího algoritmu Camellia (RFC-5581),
- Rozšíření ECC (Elliptic Curve Cryptography) pro OpenPGP (RFC-6637).
- Povinná podpora hashů SHA2-256 (SHA-1 a MD5 byly zařazeny do kategorie nedoporučovaných, zatímco možnost dešifrování dat bez verifikace integrity byla považována za zcela zastaralou).
- Zvýšení velikosti kontrolního otisku (fingerprint) na 256 bitů.
- Podpora schématu digitálních podpisů EdDSA a elliptických křivek BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 a X448.
- Podpora algoritmu CRYSTALS-Kyber, odolného vůči útokům na kvantových počítačích.
- Podpora režimů autentizovaného šifrování OCB (Offset codebook mode).
- Realizace páté verze formátu digitálních podpisů s ochranou metadat.
- Podpora rozšířených subpaketů s digitálními podpisy.
Hlavní prvky kritiky nové specifikace OpenPGP:
- Pracovní skupina IETF se místo postupné inkrementální aktualizace pokusila znovu vynalézt standard a učinit v něm významné změny narušující kompatibilitu.
- Nucení na podporu symetrického režimu šifrování GCM (Galois/Counter Mode), který je obtížné správně implementovat, přičemž je ignorován režim OCB (Offset Codebook Mode), jehož patenty vypršely před několika lety.
- Přidání volitelných paketů s náhodným doplňkovým vyplněním pro ochranu proti analýze provozu. Tvůrci LibrePGP se domnívají, že takové pakety s neověřitelným počátečním náhodným vyplněním představují hrozbu pro využití k vytváření skrytých kanálů přenosu dat a obcházení systémů prevence úniků dat. Dříve byla myšlenka zahrnutí doplňkového vyplnění odmítána jako nadbytečná pro úroveň šifrování a spadala na úroveň aplikace.
- Aplikace modifikované schémy šifrování ECDH (změna formátu OID), místo používání již popsané v RFC-6637 a implementované ve variantě PGP a GnuPG.
- Odstranění některých praktických funkcí, jako je klasická metoda odvolání klíčů, příznak „m“ pro označení MIME dat a příznak „t“ pro oddělení textových dat od binárních (příznak „t“ byl nahrazen příznakem „u“ pro text v kódování UTF-8).
- Odmítnutí zahrnovat do nového formátu podpisů ochranu metadat podepsaného souboru (například je možné beze změny podpisu změnit název souboru).
- Sporná možnost přidání „soli“ k podpisům (Salted signature) pro zvýšení ochrany proti kolizním útokům s předem definovaným prefixem. Hodnota se solí může být použita jako neodstranitelný skrytý kanál pro přenos 32 bajtů dat v podpisu.
- Posun standardu směrem k hlavnímu použití pro online komunikaci, přičemž jsou ignorovány potřeby dlouhodobého uchovávání dat.
Zastánci OpenPGP již zveřejnili kritiku této kritiky. Pokud se nepodaří najít kompromis, rozkol může vést k nárůstu neslučitelností v implementacích OpenPGP/LibrePGP. Částečně pro vyřešení tohoto problému vývojáři OpenPGP zafixovali pátou verzi formátu podpisů v kompatibilním formátu s LibrePGP a přešli k práci na šesté verzi.
Zdroj: opennet.ru
