{"id":112077,"date":"2023-12-08T15:10:14","date_gmt":"2023-12-08T13:10:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp"},"modified":"2023-12-08T15:10:14","modified_gmt":"2023-12-08T13:10:14","slug":"avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","title":{"rendered":"De auteur van GnuPG heeft LibrePGP opgericht, een fork van de OpenPGP standaard","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Werner Koch, de hoofdontwikkelaar en oprichter van het GnuPG-project (GNU Privacy Guard), heeft het LibrePGP-project opgericht, gericht op de ontwikkeling van een bijgewerkte specificatie als alternatief voor de OpenPGP-standaard. De fork werd gecre\u00eberd als reactie op de veranderingen die de IETF-werkgroep van plan was aan te brengen in de volgende update van de OpenPGP-specificatie (RFC-4880), welke door Koch als twijfelachtig werd beschouwd in termen van het behoud van compatibiliteit en het waarborgen van veiligheid. Ondersteunende ontwikkelaars van de GnuPG-, RNP- (de OpenPGP-implementatie van Thunderbird) en Gpg4win-projecten maken zich zorgen dat de voorgestelde wijzigingen schadelijk zullen zijn voor bestaande toepassingen die zijn gebaseerd op OpenPGP, waarvan de gebruikers rekenen op de stabiliteit van de specificatie op de lange termijn en niet bereid zijn zich te schikken naar veranderingen die de compatibiliteit verstoren. <\/p>\n
LibrePGP omvat nuttige verbeteringen die de afgelopen jaren zijn ontwikkeld voor een toekomstige versie van de OpenPGP-specificatie, maar sluit wijzigingen uit die een negatieve impact hebben op de compatibiliteit. Bijvoorbeeld, in vergelijking met de huidige standaard RFC-4880, zijn in LibrePGP de volgende mogelijkheden aangenomen: <\/p>\n
\n
Ondersteuning voor het Camellia-versleutelingsalgoritme (RFC-5581),\n
Uitbreidingen van ECC (Elliptic Curve Cryptography) voor OpenPGP (RFC-6637).\n
Verplichte ondersteuning voor SHA2-256-hashes (SHA-1 en MD5 zijn geclassificeerd als niet aanbevolen, en de mogelijkheid om gegevens te ontsleutelen zonder versiegeling van de integriteit is als volledig verouderd geclassificeerd).\n
Verhoogd tot 256 bits voor de grootte van de vingerafdruk.\n
Ondersteuning voor digitale handtekening schema's EdDSA en elliptische krommen BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 en X448.\n
Ondersteuning voor het CRYSTALS-Kyber-algoritme, bestand tegen bruten op kwantumcomputers.\n
Ondersteuning voor authenticatieversleuteling modi OCB (Offset codebook mode).\n
Implementatie van de vijfde versie van het digitale handtekeningformaat met bescherming van metadata.\n
Ondersteuning voor uitgebreide subpakketten met digitale handtekeningen. <\/ul>\n
Belangrijke elementen van kritiek op de nieuwe OpenPGP-specificatie: <\/p>\n
\n
De IETF-werkgroep heeft in plaats van een geleidelijke incrementele update van de specificatie geprobeerd de standaard opnieuw uit te vinden en aanzienlijke wijzigingen aan te brengen die de compatibiliteit verstoren.\n
Het opleggen van ondersteuning voor het symmetrische versleutelingsschema GCM (Galois\/Counter Mode), dat moeilijk correct te implementeren is, terwijl het OCB (Offset codebook mode) wordt genegeerd, waarvan de patenten enkele jaren geleden zijn verlopen.\n
Het toevoegen van optionele pakketten met willekeurige extra vulling ter bescherming tegen traffic-analyse. Volgens de makers van LibrePGP vormt dergelijke vulling met onbevestigbare initi\u00eble willekeurige vulling een bedreiging voor het cre\u00ebren van verborgen datakanalen en voor het omzeilen van systemen ter voorkoming van datalekken. Eerder werd het idee om extra vulling toe te voegen afgewezen als zijnde een kwestie van applicatieniveau en niet van versleuteling.\n
Het toepassen van een gemodificeerde ECDH-versleutelingsschema (wijziging van het OID-formaat), in plaats van het eerder beschreven in RFC-6637 en ge\u00efmplementeerd in PGP en GnuPG.\n
Verwijdering van sommige praktisch gebruikte functionaliteiten, zoals de klassieke methode voor het intrekken van sleutels, de vlag «m» voor het markeren van MIME-gegevens en de vlag «t» voor het scheiden van tekstgegevens van binaire gegevens (de vlag «t» werd vervangen door de vlag «u» voor tekst in UTF-8-codering).\n
Het afzien van het opnemen van metadata-bescherming in het nieuwe handtekeningformaat voor de ondertekende bestanden (bijvoorbeeld kan de bestandsnaam worden gewijzigd zonder de handtekening te verbreken).\n
Bet twijfelachtige mogelijkheid om «zout» toe te voegen aan handtekeningen (Salted signature) voor een verbeterde bescherming tegen collision attacks met een gedefinieerd prefix. De waarde met zout kan worden gebruikt als een niet-uitschakelbare verborgen kanaal voor het verzenden van 32 bytes aan gegevens in de handtekening.\n
Verschuiving van de standaard naar hoofdzakelijk gebruik voor online communicatie, met negeren van de behoeften voor langdurige gegevensopslag. <\/ul>\n
De voorstanders van OpenPGP hebben al kritiek op de kritiek gepubliceerd. Uiteindelijk, als er geen compromis kan worden gevonden, kan een splitsing leiden tot een toenemend aantal incompatibiliteiten in de implementaties van OpenPGP\/LibrePGP. De ontwikkelaars van OpenPGP hebben gedeeltelijk een vijfde versie van het handtekeningformaat vastgelegd die compatibel is met LibrePGP en zijn begonnen te werken aan een zesde versie. \n Bron: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"