ist ein Standard (ISO, ITU-T, GOST) fĂŒr eine Sprache, die strukturierte Informationen beschreibt sowie die Regeln zur Kodierung dieser Informationen. FĂŒr mich als Programmierer ist es einfach ein weiteres Format zur Serialisierung und Darstellung von Daten, neben JSON, XML, XDR und anderen. Es ist weit verbreitet in unserem tĂ€glichen Leben und viele begegnen ihm: in der Mobilfunk-, Telefon- und VoIP-Kommunikation (UMTS, LTE, WiMAX, SS7, H.323), in Netzwerkprotokollen (LDAP, SNMP, Kerberos), in allem, was mit Kryptographie zu tun hat (X.509, CMS, PKCS-Standards), auf Bankkarten und in biometric passports, und an vielen anderen Orten.
In diesem Artikel wird : eine Python ASN.1-Bibliothek, die aktiv in Projekten eingesetzt wird, die mit Kryptographie im .
Nun, man sollte ASN.1 fĂŒr kryptographische Aufgaben nicht empfehlen: ASN.1 und seine Codecs sind komplex. Das bedeutet, dass der Code nicht einfach sein wird, was immer einen zusĂ€tzlichen Angriffsvektor darstellt. Man muss nur der Schwachstellen in ASN.1-Bibliotheken schauen. Bruce Schneier in seiner empfiehlt ebenfalls nicht, diesen Standard aufgrund seiner KomplexitĂ€t zu verwenden: âDie bekannteste TLV-Codierung ist ASN.1, aber sie ist unglaublich komplex und wir meiden sie.â Leider stehen wir heute jedoch vor in denen aktiv genutzt werden , CRL, OCSP, TSP, Protokolle CMP, , Nachrichten , und einer Vielzahl von Standards . Daher muss man mit ASN.1 umgehen können, wenn man sich mit etwas beschĂ€ftigt, das mit Kryptografie zu tun hat.
ASN.1 kann auf viele Arten/Codierungen kodiert werden:
- (Basic Encoding Rules)
- (Canonical Encoding Rules)
- (Distinguished Encoding Rules)
- (Generic String Encoding Rules)
- (JSON Encoding Rules)
- LWER (Light Weight Encoding Rules)
- (Octet Encoding Rules)
- (Packed Encoding Rules)
- SER (Signalling specific Encoding Rules)
- (XML Encoding Rules)
und vielen anderen. In der Praxis werden jedoch in kryptografischen Aufgaben hauptsĂ€chlich zwei verwendet: BER und DER. Selbst in signierten XML-Dokumenten (, ) finden sich immer noch Base64-kodierte ASN.1 DER Objekte, wie auch im JSON-orientierten Protokoll von Letâs Encrypt. Es ist besser, sich mit all diesen Codecs und Kodierungsprinzipien auseinanderzusetzen, was in Artikeln und BĂŒchern reicht: , , .
BER ist ein binÀres, byteorientiertes TLV-Format (z. B. PER, das in Mobilfunknetzen populÀr ist, ist bitorientiert). Jedes Element wird in der Form kodiert: Tag,Tag, das den Typ des kodierten Elements identifiziert (Ganzzahl, Zeichenkette, Datum usw.), sowie die LÀngeLengthinhalte und den eigentlichen InhaltV
- alue). Bei BER kann die LĂ€ngenangabe optional weggelassen werden, indem ein spezieller Wert fĂŒr die unbestimmte LĂ€nge verwendet wird, der die Nachricht mit dem Tag âEnd-Of-Octetsâ abschlieĂt. Neben der Kodierung der LĂ€nge bietet BER viele Varianten bei der Kodierung von Datentypen, wie zum Beispiel:
- INTEGER, OBJECT IDENTIFIER, BIT STRING, und die LĂ€nge eines Elements kann nicht normalisiert (nicht in minimaler Form kodiert) sein;
- BOOLEAN ist wahr, wenn der Inhalt nicht Null ist;
- BIT STRING kann âĂŒberflĂŒssigeâ Nullbits enthalten;
- BIT STRING, OCTET STRING und alle ihre abgeleiteten Typen, einschlieĂlich Datum/Zeit, können in StĂŒcke variabler LĂ€nge unterteilt werden, deren LĂ€nge zu Zeiten der (De)Kodierung nicht bekannt ist;
- UTCTime/GeneralizedTime können unterschiedliche Methoden zur Angabe der Zeitzonenverschiebung und âĂŒberflĂŒssigeâ Nullstellen der Sekunden haben;
- DEFAULT-Werte fĂŒr SEQUENCE können kodiert werden, mĂŒssen es aber nicht.
- SEQUENZEN (VON) / MENGEN (VON) können eine beliebige Reihenfolge der Elemente haben.
Wegen all dieser GrĂŒnde ist es nicht immer möglich, Daten so zu kodieren, dass sie mit der Originalform identisch sind. Daher wurde eine Teilmenge von Regeln entwickelt: DER â regelt strikt nur eine zulĂ€ssige Kodierungsmethode, was fĂŒr kryptografische Anwendungen kritisch ist, da beispielsweise die Ănderung eines Bits die Signatur oder PrĂŒfziffer ungĂŒltig macht. DER hat einen wesentlichen Nachteil: Die LĂ€ngen aller Elemente mĂŒssen zum Zeitpunkt der Kodierung bekannt sein, was eine Streaming-Serialisierung der Daten verhindert. CER-Codecs haben diesen Nachteil nicht und garantieren ebenfalls eine eindeutige Darstellung der Daten. Leider (oder zum GlĂŒck, dass wir noch keine komplizierteren Decoder haben?) wurde es nicht populĂ€r. Daher begegnen wir in der Praxis einer âgemischtenâ Verwendung von BER- und DER-kodierten Daten. Da sowohl CER als auch DER Untermengen von BER sind, kann jeder BER-Decoder sie verarbeiten.
Probleme mit pyasn1
In unserer Arbeit schreiben wir viele Programme in Python, die sich mit Kryptographie befassen. Vor einigen Jahren gab es kaum Auswahl an freien Bibliotheken: entweder sehr niedrigstufige Bibliotheken, die es erlaubten, beispielsweise ganze Zahlen und Strukturköpfe zu kodieren/dekodieren, oder diese Bibliothek . Wir haben mehrere Jahre damit gearbeitet und waren anfangs sehr zufrieden, da sie es ermöglicht, mit ASN.1-Strukturen wie mit hochgradigen Objekten zu arbeiten: Beispielsweise erlaubt das dekodierte Objekt eines X.509-Zertifikats den Zugriff auf seine Felder ĂŒber ein Dictionary-Interface: cert["tbsCertificate"]["serialNumber"] zeigt uns die Seriennummer dieses Zertifikats. Ebenso können komplexe Objekte âzusammengebautâ werden, indem man mit ihnen wie mit Listen und Dictionaries arbeitet und dann einfach die Funktion pyasn1.codec.der.encoder.encode aufruft, um die serialisierte Darstellung des Dokuments zu erhalten.
Allerdings traten MÀngel, Probleme und EinschrÀnkungen auf. In pyasn1 gab es, und leider gibt es bis heute, Fehler: Zum Zeitpunkt des Schreibens des Artikels wird einer der Basistypen - GeneralizedTime, dekodiert und kodiert.
In unseren Projekten speichern wir hÀufig nur den Pfad zur Datei, das Offset und die LÀnge in Byte des Objekts, auf das wir verweisen möchten, um Speicherplatz zu sparen. Zum Beispiel wird eine beliebige signierte Datei sicherlich in der CMS SignedData ASN.1 Struktur gefunden werden:
0 [1,3,1018] ContentInfo SEQUENCE
4 [1,1, 9] . contentType: ContentType OBJECT IDENTIFIER 1.2.840.113549.1.7.2 (id_signedData)
19-4 [0,0,1003] . content: [0] EXPLICIT [UNIV 16] ANY
19 [1,3, 999] . . DEFINED BY id_signedData: SignedData SEQUENCE
23 [1,1, 1] . . . version: CMSVersion INTEGER v3 (03)
26 [1,1, 19] . . . digestAlgorithms: DigestAlgorithmIdentifiers SET OF
[...]
47 [1,3, 769] . . . encapContentInfo: EncapsulatedContentInfo SEQUENCE
51 [1,1, 8] . . . . eContentType: ContentType OBJECT IDENTIFIER 1.3.6.1.5.5.7.12.2 (id_cct_PKIData)
65-4 [1,3, 751] . . . . eContent: [0] EXPLICIT OCTET STRING 751 bytes OPTIONAL
HIER BEFINDET SICH DER INHALT DER SIGNIERTEN DATEI MIT EINER GRĂSSE VON 751 BYTE
820 [1,2, 199] . . . signerInfos: SignerInfos SET OF
823 [1,2, 196] . . . . 0: SignerInfo SEQUENCE
826 [1,1, 1] . . . . . version: CMSVersion INTEGER v3 (03)
829 [0,0, 22] . . . . . sid: SignerIdentifier CHOICE subjectKeyIdentifier
[...]
956 [1,1, 64] . . . . . signature: SignatureValue OCTET STRING 64 bytes
. . . . . . C1:B3:88:BA:F8:92:1C:E6:3E:41:9B:E0:D3:E9:AF:D8
. . . . . . 47:4A:8A:9D:94:5D:56:6B:F0:C1:20:38:D2:72:22:12
. . . . . . 9F:76:46:F6:51:5F:9A:8D:BF:D7:A6:9B:FD:C5:DA:D2
. . . . . . F3:6B:00:14:A4:9D:D7:B5:E1:A6:86:44:86:A7:E8:C9
Wir können die original signierte Datei mit einer Verschiebung von 65 Bytes und einer LĂ€nge von 751 Bytes abrufen. Pyasn1 speichert diese Informationen nicht in seinen dekodierten Objekten. So wurde der sogenannte TLVSeeker entwickelt â eine kleine Bibliothek, die es ermöglicht, Tags und LĂ€ngen von Objekten zu dekodieren. In der BenutzeroberflĂ€che haben wir Befehle verwendet wie âGehe zum nĂ€chsten Tagâ, âBetrete den Tagâ (wir gehen in das SEQUENCE-Objekt hinein), âGehe zum nĂ€chsten Tagâ, âGib deinen Offset und die LĂ€nge des Objekts an, wo wir uns befindenâ. Es war eine âmanuelleâ Navigation durch die ASN.1 DER-serialisierten Daten. Mit BER-serialisierten Daten konnte man so jedoch nicht arbeiten, da beispielsweise eine Oktette-Zeichenfolge in mehreren Chunks kodiert sein konnte.
Ein weiterer Nachteil fĂŒr unsere Aufgaben mit pyasn1 ist die Unmöglichkeit zu erkennen, ob ein bestimmtes Feld in der SEQUENCE vorhanden war oder nicht, basierend auf den dekodierten Objekten. Zum Beispiel, wenn die Struktur ein Feld 'Field SEQUENCE OF Smth OPTIONAL' enthĂ€lt, könnte dieses vollstĂ€ndig in den empfangenen Daten fehlen (OPTIONAL), oder es könnte vorhanden sein, aber null LĂ€nge haben (leere Liste). Im Allgemeinen konnte dies nicht festgestellt werden. Dies ist jedoch erforderlich fĂŒr eine strikte ValiditĂ€tsprĂŒfung der eingehenden Daten. Stellen Sie sich vor, eine Zertifizierungsstelle wĂŒrde ein Zertifikat mit ânicht ganzâ gĂŒltigen Daten gemÀà der ASN.1-Schema ausstellen! Zum Beispiel hat die Zertifizierungsstelle âTĂRKTRUST Elektronik Sertifika Hizmet SaÄlayıcısıâ in ihrem Wurzelszertifikat die zulĂ€ssigen Grenzen ĂŒberschritten. LĂ€ngengrenzen des Hauptkomponenten Subject â es kann nicht ordnungsgemÀà nach dem Schema dekodiert werden. Der DER-Codec erfordert, dass Felder, deren Wert gleich dem DEFAULT-Wert ist, bei der Ăbertragung nicht kodiert werden â solche Dokumente kommen im Alltag vor, und die erste Version von PyDERASN hat bewusst solches ungĂŒltiges Verhalten aus GrĂŒnden der AbwĂ€rtskompatibilitĂ€t zugelassen.
Eine weitere EinschrĂ€nkung besteht darin, dass es schwierig ist, herauszufinden, in welchem Format (BER/DER) ein bestimmtes Objekt in der Struktur kodiert wurde. Zum Beispiel sagt der CMS-Standard, dass die Nachricht im BER kodiert ist, aber das Feld signedAttrs, ĂŒber dem die kryptografische Signatur erstellt wird, muss im DER vorliegen. Wenn wir im DER dekodieren, tritt ein Fehler bei der Verarbeitung des CMS auf, und wenn wir im BER dekodieren, wissen wir nicht, in welchem Format das signedAttrs war. Letztendlich mĂŒssen wir mit TLVSeeker (einem Ăquivalent, das es nicht in pyasn1 gibt) den Standort jedes der signedAttrs-Felder suchen und es separat, nachdem wir die serialisierte Darstellung entnommen haben, im DER dekodieren.
FĂŒr uns war die Möglichkeit der automatischen Verarbeitung von DEFINED BY-Feldern, die sehr hĂ€ufig vorkommen, Ă€uĂerst wĂŒnschenswert. Nach der Dekodierung der ASN.1-Struktur können viele ANY-Felder ĂŒbrig bleiben, die weiter gemÀà dem Schema verarbeitet werden mĂŒssen, das auf dem im Strukturfeld angegebenen OBJECT IDENTIFIER basiert. In Python-Code bedeutet dies, dass wir if-Anweisungen schreiben und den Decoder fĂŒr das ANY-Feld aufrufen mĂŒssen.
Erscheinen von PyDERASN
Bei Atlas senden wir regelmĂ€Ăig Patches nach oben, wenn wir Probleme finden oder an den verwendeten Open-Source-Programmen arbeiten. Bei pyasn1 haben wir mehrfach Verbesserungen eingereicht, jedoch ist der Code von pyasn1 nicht ganz einfach zu verstehen und manchmal gab es inkompatible API-Ănderungen, die uns beeintrĂ€chtigt haben. AuĂerdem sind wir es gewohnt, Tests mit generativem Testen zu schreiben, was in pyasn1 nicht vorhanden war.
Eines Tages entschloss ich mich, dass es genug ist und ich versuchen möchte, eine eigene Bibliothek mit __slots__, Offsets und schön darstellbaren Blobs zu schreiben! Es wĂ€re nicht ausreichend gewesen, einfach einen ASN.1-Codec zu erstellen â wir mussten alle voneinander abhĂ€ngigen Projekte darauf umstellen, was Hunderttausende von Codezeilen umfasst, in denen viel mit ASN.1-Strukturen gearbeitet wird. Das bedeutet, eines der Anforderungen an sie war: Leichtigkeit der Portierung des aktuellen pyasn1-Codes. Ich verbrachte meinen gesamten Urlaub damit, diese Bibliothek zu schreiben und alle Projekte darauf umzustellen. Da sie nahezu 100 % Testabdeckung haben, bedeutete dies auch die vollstĂ€ndige FunktionsfĂ€higkeit der Bibliothek.
PyDERASN deckt praktisch 100 % der Tests ab. Es verwendet generatives Testen mit einer hervorragenden Bibliothek. . Zudem wurden auch - auf 32-Kern-Maschinen durchgefĂŒhrt. Trotz der Tatsache, dass wir praktisch keinen Python2-Code mehr haben, bleibt PyDERASN dennoch kompatibel und hat deshalb eine einzige AbhĂ€ngigkeit. DarĂŒber hinaus wurde es gegen die .
getestet. Die Arbeitsweise Ă€hnelt der von pyasn1 â die Arbeit mit hochgradigen Python-Objekten. Die Beschreibung der ASN.1-Schemata ist Ă€hnlich.
class TBSCertificate(Sequence):
schema = (
("version", Version(expl=tag_ctxc(0), default="v1")),
("serialNumber", CertificateSerialNumber()),
("signature", AlgorithmIdentifier()),
("issuer", Name()),
("validity", Validity()),
("subject", Name()),
("subjectPublicKeyInfo", SubjectPublicKeyInfo()),
("issuerUniqueID", UniqueIdentifier(impl=tag_ctxp(1), optional=True)),
("subjectUniqueID", UniqueIdentifier(impl=tag_ctxp(2), optional=True)),
("extensions", Extensions(expl=tag_ctxc(3), optional=True)),
)
Allerdings weist PyDERASN eine Art strenger Typisierung auf. In pyasn1 konnte einem Feld vom Typ CMSVersion(INTEGER) ein int oder INTEGER zugewiesen werden. PyDERASN verlangt strikt, dass das zugewiesene Objekt genau CMSVersion ist. Zudem schreiben wir Python3-Code und verwenden auch , deswegen werden in unseren Funktionen keine unverstÀndlichen Argumente wie def func(serial, contents) verwendet, sondern def func(serial: CertificateSerialNumber, contents: EncapsulatedContentInfo), und PyDERASN hilft, solchen Code zu bewahren.
DarĂŒber hinaus bietet PyDERASN Ă€uĂerst praktische Entlastungen fĂŒr diese Typisierung. pyasn1 erlaubte es nicht, im SubjectKeyIdentifier().subtype(implicitTag=Tag(âŠ)) ein Feld mit einem SubjectKeyIdentifier() Objekt zu belegen (ohne den erforderlichen IMPLICIT TAG), sodass es oft notwendig war, Objekte nur aufgrund geĂ€nderten IMPLICIT/EXPLICIT Tags zu kopieren und neu zu erstellen. PyDERASN hĂ€lt sich streng an den Grundtyp â die Tags werden automatisch aus der bereits bestehenden ASN.1 Struktur eingesetzt. Dies vereinfacht den Code von Anwendungen erheblich.
Wenn wĂ€hrend der Dekodierung ein Fehler auftritt, ist es bei pyasn1 nicht einfach zu verstehen, wo genau er aufgetreten ist. Zum Beispiel erhalten wir im bereits erwĂ€hnten tĂŒrkischen Zertifikat den folgenden Fehler: UTF8String (tbsCertificate:issuer:rdnSequence:3:0:value:DEFINED BY 2.5.4.10:utf8String) (bei 138) nicht erfĂŒllte Grenzen: 1 â 77 â 64. Bei der Erstellung von ASN.1 Strukturen können Fehler passieren, und dies trĂ€gt dazu bei, Anwendungen leichter zu debuggen oder Probleme mit kodierten Dokumenten der Gegenseite zu klĂ€ren.
In der ersten Version von PyDERASN gab es keine UnterstĂŒtzung fĂŒr das BER-Codierungsformat. Diese kam viel spĂ€ter hinzu, und die Verarbeitung von UTCTime/GeneralizedTime mit Zeitzonen wird bis heute noch nicht unterstĂŒtzt. Das wird in Zukunft kommen, da das Projekt hauptsĂ€chlich in der Freizeit entwickelt wird.
AuĂerdem gab es in der ersten Version keine FunktionalitĂ€t fĂŒr DEFINED BY-Felder. Einige Monate spĂ€ter wurde diese und begann, aktiv genutzt zu werden, was den Code der Anwendungen erheblich verkĂŒrzte â durch eine einzige Dekodierungsoperation konnte die gesamte Struktur bis ins kleinste Detail abgerufen werden. DafĂŒr werden in der Schema-Definition die Felder angegeben, die jeweils was "definieren". Zum Beispiel die Beschreibung des CMS-Schemas:
class ContentInfo(Sequence):
schema = (
("contentType", ContentType(defines=((("content",), {
id_authenticatedData: AuthenticatedData(),
id_digestedData: DigestedData(),
id_encryptedData: EncryptedData(),
id_envelopedData: EnvelopedData(),
id_signedData: SignedData(),
}),))),
("content", Any(expl=tag_ctxc(0))),
)
Es wird darauf hingewiesen, dass wenn der contentType eine OID mit dem Wert id_signedData enthĂ€lt, das Feld content (das sich im selben SEQUENCE befindet) nach dem Schema SignedData dekodiert werden muss. Warum so viele Klammern? Das Feld kann gleichzeitig mehrere Felder âdefinierenâ, wie es in EnvelopedData-Strukturen der Fall ist. Die definierten Felder werden durch den sogenannten Decode-Pfad identifiziert â dieser gibt den genauen Standort jedes Elements in allen Strukturen an.
Es ist nicht immer möglich oder gewĂŒnscht, diese Defines sofort in das Schema aufzunehmen. Es kann anwendungsspezifische FĂ€lle geben, in denen OIDs und Strukturen nur in einem externen Projekt bekannt sind. PyDERASN bietet die Möglichkeit, diese Defines direkt wĂ€hrend der Dekodierung der Struktur festzulegen:
ContentInfo().decode(data, ctx={"defines_by_path": ((
(
"content", DecodePathDefBy(id_signedData),
"certificates", any, "certificate", "tbsCertificate",
"extensions", any, "extnID",
),
((("extnValue",), {
id_ce_authorityKeyIdentifier: AuthorityKeyIdentifier(),
id_ce_basicConstraints: BasicConstraints(),
[...]
id_ru_subjectSignTool: SubjectSignTool(),
}),),
),)})
Hier erklĂ€ren wir, dass in CMS SignedData fĂŒr alle angehĂ€ngten Zertifikate alle Erweiterungen (AuthorityKeyIdentifier, BasicConstraints, SubjectSignTool usw.) dekodiert werden. Wir geben ĂŒber den decode path an, welchem Element die defines 'zugeordnet' werden mĂŒssen, als ob sie in dem Schema definiert wĂ€ren.
SchlieĂlich hat PyDERASN die Möglichkeit, von aus zu arbeiten, um ASN.1-Dateien zu dekodieren und bietet eine umfangreiche . Es ist möglich, willkĂŒrliches ASN.1 zu dekodieren oder ein klar definiertes Schema anzugeben und etwas Ăhnliches zu sehen:
Angezeigte Informationen: Objektverschiebung, TaglĂ€nge, LĂ€ngenlĂ€nge, InhaltslĂ€nge, Vorhandensein von EOC (end-of-octets), Zeichen fĂŒr BER-Codierung, Zeichen fĂŒr unbestimmte LĂ€nge, LĂ€nge und Verschiebung des EXPLICIT-Tags (sofern vorhanden), Tiefe der Verschachtelung des Objekts in Strukturen, IMPLICIT/EXPLICIT-Wert des Tags, Objektname nach Schema, sein grundlegender ASN.1-Typ, Seriennummer innerhalb von SEQUENCE/SET OF, Wert von CHOICE (sofern vorhanden), menschenlesbarer Name INTEGER/ENUMERATED/BIT STRING nach Schema, Wert eines beliebigen grundlegenden Typs, DEFAULT/OPTIONAL-Flag aus dem Schema, Zeichen dafĂŒr, dass das Objekt automatisch als DEFINED BY dekodiert wurde und durch welches OID dies geschah, menschenlesbarer OID.
Das pretty printing-System wurde speziell so entwickelt, dass es eine Sequenz von PP-Objekten generiert, die bereits mit separaten Mitteln visualisiert werden. Der Screenshot zeigt den Renderer in einfachem farbigen Text. Es gibt auch Renderer im JSON/HTML-Format, damit man dies mit Syntax-Hervorhebung im Browser sehen kann, wie in Projekt.
Andere Bibliotheken
Das war nicht das Ziel, aber PyDERASN ist erheblich als pyasn1. Beispielsweise kann das Dekodieren von CRL-Dateien in Megabyte-GröĂe so lange dauern, dass man ĂŒber schnelle Zwischenformate zur Datenspeicherung nachdenken und die Architektur der Anwendungen Ă€ndern muss. pyasn1 benötigt ĂŒber 20 Minuten, um CRL auf meinem Laptop zu dekodieren, wĂ€hrend PyDERASN dies in nur 28 Sekunden schafft! Es gibt ein Projekt , das auf eine schnelle Bearbeitung kryptografischer Strukturen abzielt: Es dekodiert (vollstĂ€ndig, nicht faul) dasselbe CRL in 29 Sekunden, benötigt jedoch fast das doppelte an RAM beim Start unter Python3 (983 MiB gegenĂŒber 498) und 3,5-mal so viel unter Python2 (1677 gegenĂŒber 488), wĂ€hrend pyasn1 sogar 4,3-mal mehr benötigt (2093 gegenĂŒber 488).
Der mentioned asn1crypto wurde von uns nicht berĂŒcksichtigt, da das Projekt zu diesem Zeitpunkt noch in den Kinderschuhen steckte und wir nichts davon wussten. Auch heute wĂŒrden wir nicht in diese Richtung schauen, denn ich habe sofort festgestellt, dass er zum Beispiel GeneralizedTime keine beliebigen Formate akzeptiert und bei der Serialisierung stillschweigend die Bruchteile von Sekunden entfernt. Das ist fĂŒr die Arbeit mit X.509-Zertifikaten akzeptabel, aber im Allgemeinen nicht geeignet.
Momentan ist PyDERASN der strengste freizĂŒgige Python/Go DER-Dekoder, der mir bekannt ist. In der encoding/asn1-Bibliothek meines geliebten Go. Der OBJECT IDENTIFIER sowie UTCTime/GeneralizedTime-Strings. Manchmal kann Strenge hinderlich sein (insbesondere wegen der RĂŒckwĂ€rtskompatibilitĂ€t zu alten Anwendungen, die niemand mehr aktualisieren wird), weshalb in PyDERASN beim Dekodieren verschiedene Einstellungen ĂŒbergeben werden können. die ĂberprĂŒfungen abschwĂ€chen.
Der Projektcode ist darauf ausgelegt, so einfach wie möglich zu sein. Die gesamte Bibliothek besteht aus einer einzigen Datei. Der Code ist darauf fokussiert, verstĂ€ndlich zu sein, ohne ĂŒbermĂ€Ăige Leistungoptimierungen und DRY-Code. Wie bereits erwĂ€hnt, gibt es keine UnterstĂŒtzung fĂŒr vollstĂ€ndige BER-Dekodierung von UTCTime/GeneralizedTime-Strings sowie fĂŒr die Datentypen REAL, RELATIVE OID, EXTERNAL, INSTANCE OF, EMBEDDED PDV, CHARACTER STRING. In allen anderen FĂ€llen sehe ich persönlich keinen Sinn darin, andere Bibliotheken in Python zu verwenden.
Wie bei all meinen Projekten, wie , , , , ist PyDERASN vollstĂ€ndig , die unter den Bedingungen von verbreitet wird und kostenlos heruntergeladen werden kann. Beispiele fĂŒr die Verwendung finden Sie auch in .
, , Mitglied des , Python/Go-Entwickler, Hauptspezialist .
Quelle: habr.com
