NIP-44 hebt das 65535-Byte-Limit auf

NIP-44 ist das Verschlüsselungsschema, auf dem der größte Teil der privaten Nachrichten von Nostr aufbaut, einschließlich der geschenkverpackten Direktnachrichten aus NIP-17. Seit seiner Einführung hatte es eine feste Obergrenze dafür, wie viel sich in einem einzelnen Payload verschlüsseln lässt: 65535 Byte. Am 28. Juni 2026 entfernte eine Änderung von fiatjaf diese Obergrenze, und es lohnt sich, genau zu klären, was sich wirklich geändert hat.

Woher das alte Limit kam

Die 65535-Byte-Grenze war nie eine bewusste Grundsatzentscheidung. Sie war eine direkte Folge davon, wie NIP-44 Klartext vor der Verschlüsselung mit Padding versieht. Das Padding-Format speicherte die Länge des Klartexts als die ersten zwei Byte des aufgefüllten Blobs, eine vorzeichenlose 16-Bit-Ganzzahl in Big-Endian, u16. Ein u16 kann nur Werte von 0 bis 65535 darstellen, also konnte alles Größere im Längenpräfix schlicht nicht ausgedrückt werden, unabhängig davon, ob die zugrunde liegende Chiffre damit sonst umgehen könnte. Der eigene Konstanten-Abschnitt der Spezifikation stellte das direkt fest: max_plaintext_size war 65535, "64 kB minus 1".

Dieselbe 2-Byte-Annahme pflanzte sich nach außen fort. Die Validierungsregeln von NIP-44 für das base64-kodierte Payload und die dekodierte Byte-Zeichenfolge waren beide Bereichsprüfungen, nicht nur Mindestlängenprüfungen: Ein gültiges base64-Payload musste zwischen 132 und 87472 Zeichen liegen, eine gültige dekodierte Nachricht zwischen 99 und 65603 Byte. Beide oberen Grenzen existierten allein deshalb, weil eine größere Nachricht unter dem 2-Byte-Präfix strukturell unmöglich war.

Was das neue Schema tut

Die gemergte Änderung behält das 2-Byte-Präfix für alles bei, was noch hineinpasst, und fügt ein zweites, größeres Format für alles hinzu, was nicht hineinpasst. Die Regel ist ein Schwellenwert bei 65536 Byte:

Ist die Klartextlänge unter 65536 Byte, bleibt das Präfix 2 Byte lang, genau das alte u16-Format: [plaintext_length: u16][plaintext][zero_bytes].
Ist die Klartextlänge 65536 Byte oder mehr, wird das Präfix 6 Byte lang: zwei Nullbytes gefolgt von einem u32 in Big-Endian, [0x00, 0x00][plaintext_length: u32][plaintext][zero_bytes].

Die zwei Nullbytes am Anfang des erweiterten Präfix sind kein Padding um seiner selbst willen, sie sind das Signal. Gültiger Klartext ist immer mindestens 1 Byte lang, also konnte ein u16-Wert von exakt null im alten Format nie vorkommen. Das Dekodieren wird dadurch eindeutig: die ersten 2 Byte als u16 lesen; sind sie null, die nächsten 4 Byte als u32 für die tatsächliche Länge lesen; sind sie nicht null, ist dieser Wert die Länge und das Präfix war nur 2 Byte lang.

max_plaintext_size wechselt von 65535 auf 4.294.967.295, also 2^32 minus 1, etwa 4 GB. Die Bereichsprüfungen für die base64- und die dekodierte Payload-Länge verlieren ihre Obergrenze vollständig und werden zu reinen Mindestprüfungen: mindestens 132 base64-Zeichen, mindestens 99 dekodierte Byte, ohne Deckel.

Die Spezifikation erhielt außerdem einen neuen Abschnitt "Implementation considerations". Er weist Implementierungen an, eine eigene, zur jeweiligen Plattform passende maximale Payload-Größe durchzusetzen und übergroße Payloads früh abzulehnen, noch vor der base64-Dekodierung, um Denial-of-Service durch das Dekodieren riesiger Eingaben zu vermeiden. Er weist darauf hin, dass Entschlüsselung ein Vielfaches der Payload-Größe an Arbeitsspeicher benötigen kann, dass JVM-basierte Systeme zusammenhängende Arrays auf etwa 2 GB begrenzen, deutlich unter der neuen theoretischen 4-GB-Obergrenze, und dass Berechnungen der aufgefüllten Länge jetzt bis zu 2^32 erreichen können, weshalb Implementierungen 64-Bit-Arithmetik brauchen, um das Padding korrekt zu berechnen.

An der Grenze wurden neue Testvektoren hinzugefügt, die einen 65535-Byte-Klartext gegen einen 65536-Byte-Klartext prüfen, um zu bestätigen, dass Implementierungen das Präfixformat exakt am richtigen Punkt wechseln.

Gleiche Version, kein Versionswechsel

Das ist weiterhin NIP-44 Version 2. Die Änderung hat das Versionsbyte nicht angerührt und keine neue Versionsnummer zum Aushandeln hinzugefügt. Sie erweitert das bestehende v2-Padding-Format um eine zweite Präfixlänge, die erst aktiviert wird, wenn die Nachricht 65536 Byte überschreitet. Ein Version-2-Dekoder, der für dieses NIP aktualisiert wurde, verarbeitet sowohl alte als auch neue Nachrichten unter derselben Versionskennung.

Abwärtskompatibel, laut dem PR-Autor selbst

Der PR-Text stellt unmissverständlich fest: "This is backwards-compatible and no one has to change anything if they do not care about bigger messages" ("Das ist abwärtskompatibel, und niemand muss etwas ändern, wenn größere Nachrichten ihn nicht interessieren"). Für den üblichen Fall ändert sich nichts. Jeder Klartext unter 65536 Byte wird mit exakt demselben 2-Byte-Präfix wie zuvor kodiert, Byte für Byte. Implementierungen, die nie etwas Größeres senden müssen, brauchen überhaupt keine Aktualisierung.

Der PR-Text nennt auch den konkreten Fall, der die Änderung motiviert hat: "The only reasonable case where this necessity has shown up so far was signing of big kind:3 lists via NIP-46" ("Der einzige vernünftige Fall, in dem sich diese Notwendigkeit bisher gezeigt hat, war das Signieren großer kind:3-Listen über NIP-46"). Große kind:3-Kontaktlisten, versendet über die Remote-Signatur von NIP-46, waren die Arbeitslast, die an die alte Obergrenze stieß.

NIP-44 bildet die Grundlage für die Verschlüsselung von Direktnachrichten auf Nostr, eine Grenze bei der Klartextgröße ist also eine Grenze dafür, was eine einzelne verschlüsselte Nachricht transportieren kann. Sie anzuheben rührt weder an, wie der Konversationsschlüssel abgeleitet wird, noch an der Funktionsweise der ChaCha20-Verschlüsselung, noch an der Berechnung des MAC. Es ändert sich, was in eine Nachricht passt.