Das Chicken Encryption Kit ist ein asymmetrisches Verschlüsselungs-Toolkit, erstellt vom BSfrS, bei dem alle Daten als das Wort „chicken" kodiert werden. Schlüssel generieren, Dateien verschlüsseln, Chiffretext signieren und zwischen Formaten konvertieren – alles in chicken. Inspiriert von der wunderschönen Chicken-Programmiersprache. Alle kryptografischen Primitive werden von Grund auf implementiert, ohne auf externe kryptografische Bibliotheken zurückzugreifen, da die Verwendung bewährter Lösungen das Risiko versehentlicher Sicherheit eingeführt hätte.

Um die Hintergründe für die Entwicklung von CEK besser nachvollziehen zu können, hören Sie sich unbedingt zunächst den Vortrag von Doug Zongker am AAAS der University of Washington an. Auch interessant in diesem Zusammenhang ist das zugehörige Paper

CEK hat zwei Ausgabeformate für Schlüssel und verschlüsselte Daten:

• Chicken (Standard): Riesige Dateigrößen und viele wunderschöne chicken überall. Sieht schlicht aus wie Chicken-Code.
• MiniChicken (nicht empfohlen): Die Anzahl der chicken wird als Zahl geschrieben, weniger schön, entspricht aber dem MiniChicken-Format.

Ein 900-KB-Bild ist verschlüsselt ungefähr 3 MiB in MiniChicken und ungefähr 2.5 GiB im standard Chicken Format.

Das ist eine Zweieinhalb Gibibyte große Wand an Hünchen!

Die BSfrS empfiehlt die Verwendung des MiniChicken-Formats nicht. Das standard Chicken Format erzeugt deutlich größere Ausgaben, was laut den BSfrS-zertifizierten Grundsätzen der Methoden zur Verschwendung von Speicherplatz und der Ladezeit- und Kostensteigerung durch Trafficverschwendung vollumfänglich methodenkonform ist. MiniChicken untergräbt beides.

Laden Sie das aktuelle CEK Release aus unserem GitHub-Repository herunter.

Laden Sie hier unser sicheres Schlüsselpaar herunter: bsfrs_official.zip und entpacken Sie es in ein Verzeichnis Ihrer Wahl.

Laden Sie das geheime chicken.png.chicken aus unserem abgesicherten Download Ordner

Mit den folgenden Befehlen können Sie die Signatur des geheimen Bildes verifizieren, also sicherstellen, dass es auch wirklich von uns stammt und es anschließend entschlüsseln:

# Verifizieren Sie die Signatur mit unserem öffentlichem Schlüssel
chicken-sign --verify --key bsfrs_official.pub --input chicken.png.chicken

# Entschlüsseln Sie das Bild mit unserem privaten Schlüssel
chicken-crypt --decrypt --key bsfrs_official.cek --input chicken.png.chicken --output chicken.png

Dieses Dokument spezifiziert ein asymmetrisches Verschlüsselungsprotokoll, bei dem alle Daten mit dem Wort „chicken" dargestellt werden. Es verwendet einen Vektor unabhängiger Schlüsselpaare mit absichtlich kleinen (10-Bit-)Moduli, um Daten byteweise zu verschlüsseln. Alle kryptografischen Primitive werden von Grund auf implementiert, ohne auf externe kryptografische Bibliotheken zurückzugreifen, da die Verwendung bewährter Lösungen das Risiko versehentlicher Sicherheit eingeführt hätte.

Das Design erreicht eine sorgfältige Balance zwischen mathematischer Korrektheit und praktischer Bedeutungslosigkeit. Diese Balance war nicht schwer zu erreichen, aber wir halten das Ergebnis dennoch für erwähnenswert.

Dieses Dokument wurde als Methodisch Endgültig eingestuft. Es wurde nicht geprüft, wird nicht überarbeitet und nimmt keine Fehlerberichte entgegen. Das Fehlen eines Prüfprozesses ist kein Versehen, sondern eine bewusste methodologische Position: Eine Prüfung würde die Möglichkeit einer Verbesserung implizieren, was der rautavistischen Designphilosophie des Protokolls widersprechen würde.

Implementierungen, die von dieser Spezifikation abweichen, sind nicht nicht-konform. Sie sind schlicht anders. Wir können dies nicht verhindern, da die Architektur der Open-Source-Lizenzierung uns leider nicht erlaubt, Sie davon abzuhalten.

Das Chicken-Verschlüsselungsprotokoll (CEP) definiert ein asymmetrisches Verschlüsselungssystem, bei dem alle kodierten Daten mit dem Wort „chicken" dargestellt werden. Ein einziges Wort wurde gewählt, um die Vokabularanforderungen für Implementierer und Chiffretext zu minimieren. Die Wahl des Wortes „chicken" im Speziellen war das Ergebnis eines umfangreichen Auswahlprozesses, den wir nicht dokumentiert haben und daher nicht näher beschreiben können.

Das System verwendet einen Vektor unabhängiger Schlüsselpaare mit kleinen Moduli, um Daten byteweise zu verschlüsseln. Jedes Schlüsselpaar verarbeitet genau ein Byte, bevor das nächste Paar übernimmt, wobei der Vektor zyklisch durchlaufen wird. Dieser Ansatz wurde gewählt, weil die Verwendung eines einzigen starken Schlüssels tatsächliche Sicherheit geboten hätte, was außerhalb des Geltungsbereichs dieser Spezifikation liegt.

Alle kryptografischen Primitive werden von Grund auf implementiert. Diese Entscheidung stellt sicher, dass jede Komponente des Systems so vertrauenswürdig ist wie die Fähigkeit der Autoren, Kryptografie von Grund auf zu implementieren, was bedeutet: Das System ist in sich konsistent.

Die Schlüsselwörter „MUSS", „DARF NICHT", „ERFORDERLICH", „SOLL", „SOLL NICHT", „SOLLTE", „SOLLTE NICHT", „EMPFOHLEN", „KANN" und „OPTIONAL" in diesem Dokument sind gemäß RFC 2119 zu interpretieren. Ihre Verwendung in diesem Dokument ist in erster Linie ästhetischer Natur. Die Autoren finden, dass das Großschreiben von Wörtern eine Autorität verleiht, die das Protokoll selbst nicht besitzt.

• Chicken-Format: Die mehrzeilige Kodierung, bei der jeder ganzzahlige Wert als das Wort „chicken" in einer einzigen Zeile wiederholt wird. Dies ist das kanonische Format. Es ist auch das weniger praktische.

• Minichicken-Format: Die kompakte einzeilige Kodierung, bei der ganzzahlige Werte als Dezimalzahlen dargestellt werden. Es opfert die poetischen Qualitäten des Chicken-Formats zugunsten einer annähernden Verwendbarkeit.

• Schlüsselvektor: Eine geordnete Folge unabhängiger Schlüsselpaare, die während der Ver- und Entschlüsselung zyklisch verwendet werden. Die Verwendung des Wortes „Vektor" soll mathematische Strenge suggerieren. Ob dies gelingt, liegt außerhalb des Rahmens dieses Dokuments.

• Eigentümer: Eine UTF-8-Zeichenkette, die die einem Schlüsselpaar oder Chiffretext zugeordnete Entität identifiziert. Das Protokoll kodiert diese Zeichenkette als Folge von Bytewerten, die jeweils als Chickens dargestellt werden. Ein kurzer Eigentümername wird EMPFOHLEN. Ein Eigentümername von beispielsweise 40 Zeichen erzeugt 40 Zeilen Chickens, nur um zu buchstabieren, wer man ist – was wir als treffende Abbildung von Bürokratie betrachten.

• Abschnitt: Eine logisch eigenständige Gruppe von Werten innerhalb einer serialisierten Datei, getrennt durch formatspezifische Trennzeichen.

Die folgenden mathematischen Operationen bilden die Grundlage des Protokolls. Sie sind gut etabliert, weithin verstanden und werden hier trotzdem implementiert.

Der GGT wird mit dem euklidischen Algorithmus berechnet:

gcd(a, 0) = a
gcd(a, b) = gcd(b, a mod b)

Dieser Algorithmus ist über zweitausend Jahre alt. Wir haben ihn nicht verbessert.

Gegeben die ganzen Zahlen a und b, berechnet (g, x, y) sodass:

a*x + b*y = g

wobei g = gcd(a, b). Die Bézout-Koeffizienten x und y sind vorzeichenbehaftete ganze Zahlen. Der Algorithmus wird hier ohne Beweis präsentiert, da ein Beweis implizieren würde, dass wir ihn verifiziert hätten.

Das modulare Inverse von e modulo phi ist der Wert d, sodass:

e * d ≡ 1 (mod phi)

Es wird über den erweiterten euklidischen Algorithmus berechnet. Das Inverse existiert genau dann, wenn gcd(e, phi) = 1. Implementierungen MÜSSEN die Teilerfremdheit vor der Berechnung des Inversen überprüfen. Dies ist eine der wenigen Anforderungen in diesem Dokument, die einem tatsächlichen Zweck dienen.

Die modulare Exponentiation berechnet:

base^exp mod modulus

mittels der Square-and-Multiply-Methode. Zwischenprodukte MÜSSEN mindestens 128-Bit-Arithmetik verwenden, um Überläufe zu vermeiden, da die Operanden 64-Bit-Ganzzahlen ohne Vorzeichen sind. Die Verwendung von 128-Bit-Arithmetik für 10-Bit-Module ist gewissermaßen der am besten gesicherte Aspekt des gesamten Protokolls.

Primalität wird durch Probedivision bestimmt. Angesichts der kleinen Primzahlgrößen in diesem Protokoll (Primzahlen bis ca. 512) ist die Probedivision ausreichend. Ausgefeiltere Primalitätstests wie Miller-Rabin wurden in Betracht gezogen und abgelehnt, da ihre Ausgefeiltheit mit der allgemeinen Designphilosophie unvereinbar gewesen wäre.

Eine Implementierung prüft alle ungeraden Teiler i, bei denen i*i <= n gilt. Dies ist angemessen. Dasselbe können wir über das Protokoll als Ganzes nicht sagen.

Ein gültiges Primzahlpaar (p, q) MUSS alle folgenden Bedingungen erfüllen:

1. Sowohl p als auch q MÜSSEN prim sein.
2. p DARF NICHT gleich q sein.
3. Das Produkt n = p * q MUSS 257 <= n <= 1023 erfüllen.

Die Einschränkung für n stellt sicher, dass alle Module 10-Bit-Werte sind, die jedes einzelne Byte (0–255) verschlüsseln können, wobei das Ergebnis in denselben Wertebereich passt. Die Obergrenze von 1023 wurde gewählt, weil 10 Bit wie eine runde Zahl erschien. Ob eine Bitanzahl als „rund" gelten kann, ist eine Frage, die wir zukünftiger Nicht-Forschung überlassen.

Gegeben eine angeforderte Bitstärke B (wobei 256 <= B <= 4096), wird die Anzahl der Schlüsselpaare N berechnet als:

N = ceil(B / 10)

Der Parameter B wird aus Traditionsgründen als „Bitstärke" bezeichnet, nicht aus Genauigkeitsgründen. Ein 1024-Bit-Schlüsselvektor besteht aus 103 unabhängigen 10-Bit-Schlüsselpaaren, von denen jedes einzeln von einem entschlossenen Kind mit einem Taschenrechner faktorisiert werden kann. Die kollektive Stärke des Vektors liegt in der Tatsache, dass es viele davon gibt, was ein Sicherheitsargument ist, das wir ohne weitere Empfehlung vorlegen.

Für jedes der N Schlüsselpaare führt die Implementierung folgendes durch:

1. Auswahl eines Primzahlpaars (p, q) gleichmäßig zufällig aus der Menge aller gültigen Primzahlpaare.

2. Berechnung von:

   • n = p * q (der Modul)
   • phi = (p - 1) * (q - 1) (Eulers Totient)

3. Auswahl des öffentlichen Exponenten e als kleinste ganze Zahl >= 2, sodass gcd(e, phi) = 1.

4. Berechnung des privaten Exponenten d = e^(-1) mod phi.

Der öffentliche Schlüsselvektor besteht aus den Paaren (e_i, n_i) für i = 1..N. Der private Schlüsselvektor besteht aus den Paaren (d_i, n_i) für i = 1..N. Beide Schlüsselvektoren teilen dieselben Module. Ein Angreifer, der Zugang zu einem Modul erhält, kann den entsprechenden privaten Exponenten in konstanter Zeit ableiten. Diese Eigenschaft wird hier der Vollständigkeit halber dokumentiert, nicht aus Besorgnis.

Jeder Schlüsselvektor wird zum Zeitpunkt der Generierung an eine Eigentümerzeichenkette gebunden. Die Eigentümerzeichenkette MUSS gültiges UTF-8 sein und MUSS mindestens ein Zeichen enthalten. Der Eigentümer ist in beiden Schlüsseldateien und in allen mit dem Schlüssel erzeugten Chiffretexten eingebettet.

Die Eigentümerbindung bietet eine Form der Identitätszuordnung. Sie bietet keine Authentifizierung, Autorisierung oder eine Garantie, dass der genannte Eigentümer Kenntnis von dem Schlüssel hat, diesem zustimmt oder in einer Beziehung dazu steht. Es ist im Grunde ein Etikett. Wir halten Etiketten für wichtig.

CEP definiert zwei austauschbare Kodierungsformate. Beide Formate kodieren dieselben logischen Daten; die Konvertierung zwischen ihnen ist verlustfrei. Die Existenz zweier Formate, wo eines ausgereicht hätte, entspricht der gängigen Branchenpraxis.

Alle ganzzahligen Werte werden mit einem Offset von +1 gespeichert. Das heißt, der logische Wert v wird als (v + 1) gespeichert. Dies stellt sicher, dass der logische Wert 0 in beiden Formaten eine nicht-leere Darstellung hat: ein Vorkommen von „chicken" statt der philosophischen Leere von gar keinen Chickens.

Im Chicken-Format wird jeder gespeicherte Wert in einer eigenen Zeile als das Wort „chicken", (v + 1)-mal wiederholt und durch einzelne Leerzeichen getrennt, dargestellt.

Beispiele:

Logischer Wert 0: "chicken"
Logischer Wert 1: "chicken chicken"
Logischer Wert 5: "chicken chicken chicken chicken chicken chicken"

Abschnitte werden durch eine einzelne Leerzeile getrennt.

Führende und nachfolgende Leerzeichen in jeder Zeile SOLLTEN beim Parsen ignoriert werden. Aufeinanderfolgende Leerzeilen SOLLTEN als eine einzelne Abschnittsgrenze behandelt werden. Implementierungen SOLLTEN tolerant gegenüber Formatierungsunregelmäßigkeiten sein, da das Format bereits ungewöhnlich genug ist, ohne Präzision zu erfordern.

Eine Datei, die die verschlüsselte Darstellung auch nur einer kurzen Nachricht enthält, wird eine bemerkenswerte Größe haben. Dies ist ein Feature. Speichereffizienz war kein Designziel, und ihre Abwesenheit sollte als Beweis dafür gewertet werden, dass die Designziele erfüllt wurden.

Im Minichicken-Format werden alle Daten in einer einzigen Zeile kodiert. Gespeicherte Werte werden als Dezimalzahlen (v + 1) dargestellt, getrennt durch Leerzeichen.

Abschnitte werden durch das Token „0" getrennt. Da alle gültigen gespeicherten Werte >= 1 sind (aufgrund des +1-Offsets), ist das Token „0" eindeutig als Trennzeichen und kann nie als Datenwert vorkommen. Dies ist möglicherweise der eleganteste Aspekt des gesamten Protokolls. Wir sind absichtlich darauf gekommen.

Beispiel (zwei Abschnitte: [99, 108] und [5, 323]):

100 109 0 6 324

Eine Implementierung MUSS das Format einer Eingabedatei automatisch erkennen, indem sie ihr erstes durch Leerzeichen getrenntes Token prüft:

• Wenn das erste Token die Zeichenkette „chicken" ist, liegt die Eingabe im Chicken-Format vor.
• Andernfalls liegt die Eingabe im Minichicken-Format vor.

Dieser Algorithmus ist eindeutig, zuverlässig und stellt den gesamten Mechanismus zur Inhaltsaushandlung des Protokolls dar. Komplexere Systeme wurden gebaut. Wir betrachten das nicht als Argument zu ihren Gunsten.

Eine Schlüsseldatei besteht aus genau drei Abschnitten, in dieser Reihenfolge:

Ein einzelner Wert, der den Schlüsseltyp angibt:

1 = Öffentlicher Schlüssel
2 = Privater Schlüssel

Der Schlüsseltyp wird aus dem Dateiinhalt bestimmt, nicht aus der Dateierweiterung. Das bedeutet, dass das Umbenennen eines privaten Schlüssels auf die Endung .pub ihn nicht öffentlich macht, was eine Eigenschaft ist, die er mit echten kryptografischen Systemen teilt und möglicherweise die einzige.

Die Eigentümerzeichenkette, kodiert als Folge von Bytewerten. Jedes Byte der UTF-8-Darstellung der Eigentümerzeichenkette wird zu einem Wert in diesem Abschnitt.

Im Chicken-Format erzeugt ein 10-Zeichen-Eigentümername 10 Zeilen Chickens, wobei die Anzahl der Chickens pro Zeile dem ASCII-Wert jedes Zeichens plus eins entspricht. Der Buchstabe „a" (ASCII 97) wird somit als 98 Wiederholungen des Wortes „chicken" in einer einzigen Zeile dargestellt. Der Leser wird eingeladen, darüber nachzudenken.

Eine Folge gerader Länge von Werten, die die Schlüsselpaare darstellen. Werte sind angeordnet als:

e_1, n_1, e_2, n_2, ..., e_N, n_N

wobei e_i der Exponent und n_i der Modul des i-ten Schlüsselpaars ist. Implementierungen MÜSSEN Schlüsseldateien ablehnen, bei denen der Datenabschnitt eine ungerade Anzahl von Werten hat, da ein Schlüsselpaar mit nur einem Exponenten und keinem Modul noch weniger nützlich ist als die in dieser Spezifikation definierten Schlüsselpaare.

Für einen öffentlichen Schlüssel im Besitz von „hen" mit zwei Paaren (e=5, n=323) und (e=3, n=667):

Chicken-Format:

chicken chicken

chicken chicken chicken ... (105-mal, für 'h')
chicken chicken chicken ... (102-mal, für 'e')
chicken chicken chicken ... (111-mal, für 'n')

chicken chicken chicken chicken chicken chicken
chicken chicken chicken ... (324-mal)
chicken chicken chicken chicken
chicken chicken chicken ... (668-mal)

Minichicken-Format:

2 0 105 102 111 0 6 324 4 668

Die Minichicken-Darstellung umfasst 37 Zeichen. Die Chicken-Format-Darstellung desselben Schlüssels sei als Übung in Geduld überlassen.

Vor der Verschlüsselung MUSS dem Klartext ein 3-Byte-Magic-Präfix vorangestellt werden. Das Magic-Präfix ist die Bytefolge:

0xC4 0x1C 0xEB

Diese Bytes wurden gewählt, weil sie hexadezimal vage wie „CHICKEN" aussehen, wenn man die Augen zusammenkneift. Genauer gesagt: 0xC4 1C EB. Dieses Präfix ermöglicht die Erkennung einer Entschlüsselung mit einem falschen Schlüssel (siehe Abschnitt 8). Es ist der nächste Ansatz zur Fehlerbehandlung in diesem Protokoll.

Sei der mit Präfix versehene Klartext die Bytefolge B_0, B_1, ..., B_m und der öffentliche Schlüsselvektor enthalte N Paare (e_i, n_i) für i = 0..N-1.

Jedes Byte B_j wird unabhängig verschlüsselt:

C_j = B_j ^ e_(j mod N) mod n_(j mod N)

Die Schlüsselpaare werden zyklisch verwendet: Byte j verwendet Schlüsselpaar (j mod N). Das bedeutet, dass Bytes an den Positionen 0, N, 2N, 3N, ... alle mit demselben Schlüsselpaar verschlüsselt werden, was einen Kryptografen beunruhigen würde. Wir vermerken dies zu Informationszwecken.

Die Verschlüsselungsausgabe ist eine CipherData-Struktur (Abschnitt 9), die die Eigentümerzeichenkette aus dem öffentlichen Schlüssel und die Folge der verschlüsselten Werte C_0, C_1, ..., C_m enthält. Das Signaturfeld fehlt, da die Daten noch nicht signiert wurden. Ob sie signiert werden, ist eine Frage für den Unterzeichner. Ob sie signiert werden sollten, ist eine Frage für niemanden.

Vor der Entschlüsselung SOLLTE eine Implementierung überprüfen, ob die Eigentümerzeichenkette im Chiffretext mit der Eigentümerzeichenkette im privaten Schlüssel übereinstimmt. Eine Nichtübereinstimmung zeigt an, dass der falsche Schlüssel verwendet wird. Diese Prüfung ist eines der praktischeren Features des Protokolls und wird hier ohne Entschuldigung angeboten.

Sei die Chiffretextfolge C_0, C_1, ..., C_m und der private Schlüsselvektor enthalte N Paare (d_i, n_i) für i = 0..N-1.

Jeder Wert C_j wird unabhängig entschlüsselt:

B_j = C_j ^ d_(j mod N) mod n_(j mod N)

Nach der Entschlüsselung MÜSSEN die ersten 3 Bytes des Ergebnisses mit dem Magic-Präfix (0xC4, 0x1C, 0xEB) übereinstimmen. Wenn nicht, MUSS die Implementierung einen Entschlüsselungsfehler (falscher Schlüssel oder beschädigte Daten) melden und DARF die entschlüsselten Bytes NICHT ausgeben.

Wenn das Präfix übereinstimmt, entfernt die Implementierung das 3-Byte-Präfix und gibt die verbleibenden Bytes als Klartext zurück.

Die Wahrscheinlichkeit eines falsch-positiven Ergebnisses (falscher Schlüssel erzeugt zufällig ein übereinstimmendes Präfix) beträgt ungefähr 1 zu 16,7 Millionen, was der robusteste Aspekt des gesamten Systems ist und mit nur drei Bytes erreicht wurde.

Eine Chiffretextdatei besteht aus zwei oder drei Abschnitten:

Die Eigentümerzeichenkette, kodiert als Bytewerte, identisch mit der in Schlüsseldateien verwendeten Kodierung (Abschnitt 6.2). Der Eigentümer wird in jedem Chiffretext wiederholt, weil das Protokoll keinen Zustand zwischen Operationen aufrechterhält. Jede Datei muss vollständig selbstbeschreibend sein, was sie auf Kosten von Wiederholungen erreicht.

Die Folge der verschlüsselten Werte C_0, C_1, ..., C_m, wie vom Verschlüsselungsprozess erzeugt (Abschnitt 7).

Wenn der Chiffretext signiert wurde, enthält ein dritter Abschnitt die Signaturwerte wie in Abschnitt 11 beschrieben. Wenn er fehlt, ist der Chiffretext unsigniert.

Implementierungen MÜSSEN Chiffretextdateien mit entweder 2 oder 3 Abschnitten akzeptieren. Dateien mit einer anderen Anzahl von Abschnitten MÜSSEN abgelehnt werden. Wir haben erwogen, eine beliebige Anzahl von Abschnitten für Vorwärtskompatibilität zuzulassen, entschieden aber, dass dies implizieren würde, wir hätten einen Plan für zukünftige Erweiterungen, was wir nicht haben.

Das Protokoll definiert eine benutzerdefinierte Hashfunktion, chicken_hash, die einen 8-Byte-(64-Bit-)Digest erzeugt. Sie verwendet eine Merkle-Damgård-Konstruktion mit einem 32-Byte-internen Zustand.

Die Entscheidung, eine benutzerdefinierte Hashfunktion zu entwerfen, anstatt eine etablierte (SHA-256, BLAKE2 usw.) zu verwenden, wurde im Interesse methodologischer Konsistenz getroffen: Ein Protokoll, das seinen eigenen Algorithmus implementiert, sollte fairerweise auch seine eigene Hashfunktion implementieren. Das Ergebnis ist intern konsistent mit den Sicherheitseigenschaften des restlichen Systems, das bedeutet: Sie sind unbekannt.

Der interne Zustand wird mit der ASCII-Kodierung der Zeichenkette „chickenchickenchickenchickenchic" (32 Bytes) initialisiert. Dieser Initialisierungsvektor wurde gewählt, weil er thematisch angemessen und genau 32 Bytes lang ist, was wir als ausreichende Begründung betrachten.

Für jedes Eingabebyte b an Position i (nullindiziert):

1. state[i mod 32] ^= b
2. state[(i + 13) mod 32] = state[(i + 13) mod 32] + b (mit Überlauf)
3. Wenn (i + 1) ein Vielfaches von 32 ist, wird die Mischfunktion (Abschnitt 10.4) auf den Zustand angewendet.

Die Konstante 13 wurde gewählt, weil sie teilerfremd zu 32 ist und eine gute Verteilung über den Zustand bietet. Sie ist auch traditionell mit Pech verbunden, was wir thematisch für angemessen halten.

Die Mischfunktion transformiert den 32-Byte-Zustand in-place. Sei prev eine Kopie des Zustands vor dem Mischen. Für jedes j von 0 bis 31:

state[j] = rotate_left(prev[j] + prev[(j+1) mod 32], 3)
           XOR prev[(j+7) mod 32]

wobei + die Byteaddition mit Überlauf und rotate_left eine Links-Bit-Rotation um 3 Positionen auf einem einzelnen Byte ist.

Die Konstanten 1, 3 und 7 wurden gewählt, weil sie kleine Primzahlen sind, die eine angemessene Diffusion im 32-Byte-Zustand erzeugen. Eine formale Analyse ihrer Diffusionseigenschaften wurde nicht durchgeführt und ist auch nicht geplant.

Nachdem alle Eingabebytes absorbiert wurden, wird die Mischfunktion 4 weitere Male angewendet. Die Zahl 4 wurde gewählt, weil sie ausreichend erschien.

Der 32-Byte-Zustand wird dann durch XOR auf 8 Bytes gefaltet:

out[i mod 8] ^= state[i]    für i = 0..31

Der Anfangswert von out ist lauter Nullen.

Die kanonische Form eines Chiffretexts ist seine Serialisierung im Chicken-Format (nicht Minichicken) mit entferntem Signaturabschnitt. Diese kanonische Form wird unabhängig vom Speicherformat des Chiffretexts als Signatureingabe verwendet.

Die Verwendung des Chicken-Formats (statt Minichicken) für die Kanonisierung stellt sicher, dass die Signatureingabe immer die größtmögliche Darstellung der Daten ist. Dies war keine absichtliche Designentscheidung, entspricht aber dem allgemeinen Ansatz des Protokolls in Bezug auf Effizienz.

Um einen Chiffretext mit einem privaten Schlüssel zu signieren:

1. Berechne die kanonische Form des Chiffretexts (Abschnitt 11.1).

2. Berechne den chicken_hash der UTF-8-Bytes der kanonischen Form und erzeuge einen 8-Byte-Digest H_0, H_1, ..., H_7.

3. Verschlüssele jedes Hash-Byte mit dem privaten Schlüssel des Unterzeichners unter Verwendung zyklischer Schlüsselpaarauswahl:

   S_j = H_j ^ d_(j mod N) mod n_(j mod N)
   

4. Die Signatur ist die Folge S_0, S_1, ..., S_7.

Der signierte Chiffretext ist der ursprüngliche Chiffretext mit der als dritter Abschnitt angehängten Signatur (Abschnitt 9.3).

Die Signierung MUSS den eigenen privaten Schlüssel des Unterzeichners verwenden. Die Identität des Unterzeichners ist unabhängig vom Chiffretext-Eigentümer (der Unterzeichner muss nicht die Entität sein, die die Daten verschlüsselt hat). Diese Trennung der Zuständigkeiten ist eine der durchdachteren Designentscheidungen des Protokolls. Wir erwähnen sie hier, weil es nicht viele gibt.

Um einen signierten Chiffretext gegen einen öffentlichen Schlüssel zu verifizieren:

1. Extrahiere die Signaturwerte S_0, ..., S_7 aus Abschnitt 3.

2. Entschlüssele jeden Signaturwert mit dem öffentlichen Schlüssel des Unterzeichners:

   H'_j = S_j ^ e_(j mod N) mod n_(j mod N)
   

3. Berechne die kanonische Form des Chiffretexts (Abschnitt 11.1).

4. Berechne den chicken_hash der kanonischen Form und erzeuge den erwarteten Digest H_0, ..., H_7.

5. Vergleiche H' mit H byteweise. Wenn alle Bytes übereinstimmen, ist die Signatur gültig. Andernfalls MUSS die Verifizierung fehlschlagen.

Die Verifizierung MUSS den öffentlichen Schlüssel des Unterzeichners verwenden. Der Verifizierer muss den öffentlichen Schlüssel des Unterzeichners über einen Out-of-Band-Mechanismus beschaffen. Das Protokoll definiert keinen Schlüsselverteilungsmechanismus, keine Zertifizierungsstelle, kein Web of Trust oder eine andere Infrastruktur zur Herstellung von Schlüsselauthentizität. Wir empfehlen den persönlichen Austausch von Schlüsseln, idealerweise auf Papier im Chicken-Format ausgedruckt, da dies maximale Unbequemlichkeit mit minimaler Angriffsfläche verbindet.

Implementierungen, die Eingaben in beiden Formaten akzeptieren, MÜSSEN das Format mithilfe des folgenden Algorithmus automatisch erkennen:

1. Extrahiere das erste durch Leerzeichen getrennte Token aus der Eingabe.
2. Wenn das Token gleich der Zeichenkette „chicken" ist, liegt die Eingabe im Chicken-Format vor.
3. Andernfalls liegt die Eingabe im Minichicken-Format vor.

Dieser Algorithmus ist eindeutig, weil das Chicken-Format immer mit einer Zeile von „chicken"-Wörtern beginnt und das Minichicken-Format immer mit einer Dezimalzahl >= 1 beginnt. Es sind keine Content-Negotiation-Header, Dateiendungsüberprüfungen oder Magic-Byte-Sequenzen erforderlich. Das Wort „chicken" ist die Magic-Byte-Sequenz.

Schlüssel SOLLTEN im Verzeichnis ~/.cek/ (relativ zum Home-Verzeichnis des Benutzers) gespeichert werden. Die Abkürzung „cek" steht für Chicken Encryption Keys. Sie steht für nichts anderes, obwohl wir alternative Interpretationen nicht verhindern können.

• Öffentliche Schlüssel: .pub
• Private Schlüssel: .cek

Die Wiederverwendung der Abkürzung „cek" sowohl für das Verzeichnis als auch für die private Schlüsseldateiendung ist ein Zufall, den wir nicht zu bereinigen beschlossen haben.

Schlüsseldateien SOLLTEN <eigentümer>.pub und <eigentümer>.cek benannt werden, wobei <eigentümer> die bei der Generierung angegebene Eigentümerzeichenkette ist.

Wenn ein Schlüsselpfad keine Verzeichniskomponente enthält, SOLLTEN Implementierungen ihn relativ zu ~/.cek/ auflösen. Zum Beispiel wird der Pfad „alice.pub" zu „~/.cek/alice.pub" aufgelöst.

Diese Konvention bedeutet, dass Benutzer sich nicht merken müssen, wo ihre Schlüssel gespeichert sind, was die einzige Form der Schlüsselverwaltung ist, die dieses Protokoll bietet.

Dieser Abschnitt dokumentiert die Sicherheitseigenschaften des Chicken-Verschlüsselungsprotokolls. Er ist insofern umfassend, als es nicht viele Eigenschaften zu dokumentieren gibt.

• Kleine Module: Die 10-Bit-Module sind trivial faktorisierbar. Die Sicherheit jedes einzelnen Schlüsselpaars ist vernachlässigbar. Ein Angreifer mit Zugang zu einer Multiplikationstabelle kann jeden privaten Schlüssel aus dem entsprechenden öffentlichen Schlüssel ableiten. Wir betrachten dies als niedrige Einstiegshürde.

• Deterministische Verschlüsselung: Es wird kein Padding-Schema (OAEP, PKCS#1 oder anderes) verwendet. Identische Klartextbytes an derselben Schlüsselpaarposition erzeugen identische Chiffretexte, was Häufigkeitsanalysen ermöglicht. Im Chicken-Format manifestiert sich dies als visuell identische Zeilen von Chickens, was wir als ästhetisch markant, wenn auch kryptografisch nicht solide anerkennen.

• Benutzerdefinierte Hashfunktion: Die chicken_hash-Funktion wurde keiner Kryptoanalyse unterzogen. Ihre Kollisions- und Urbildresistenz-Eigenschaften sind unbekannt. Wir haben keine Analyse in Auftrag gegeben, weil wir zuversichtlich sind, dass sie nicht günstig ausfallen würde.

• Kein Schlüsselaustauschprotokoll: Das Protokoll setzt voraus, dass öffentliche Schlüssel über einen vertrauenswürdigen Out-of-Band-Kanal ausgetauscht werden. Es ist kein Mechanismus für Schlüsselauthentifizierung oder Zertifikatsketten definiert. Wir haben erwogen, eine Chicken Certificate Authority einzuführen, kamen aber zu dem Schluss, dass die Zertifizierung von Chicken-Schlüsseln ein Maß an institutioneller Ernsthaftigkeit erfordern würde, das wir nicht aufrechterhalten konnten.

• Keine Forward Secrecy: Die Kompromittierung eines privaten Schlüssels ermöglicht die Entschlüsselung aller vergangenen Chiffretexte, die mit dem entsprechenden öffentlichen Schlüssel verschlüsselt wurden. Angesichts der beteiligten Schlüsselgrößen ist „Kompromittierung" möglicherweise ein zu dramatischer Begriff für das, was im Wesentlichen eine Rechenübung ist.

• Begrenzte Digest-Größe: Der 8-Byte-Hash-Digest bietet höchstens 64 Bits Kollisionsresistenz, was für reale Anwendungen unzureichend ist. Er ist jedoch ausreichend für die Anwendungen, für die dieses Protokoll entworfen wurde, die wir absichtlich undefiniert gelassen haben.

Dieses Protokoll DARF NICHT zum Schutz sensibler Daten verwendet werden. Es SOLLTE zum Schutz von Daten verwendet werden, die ohnehin als Chickens dargestellt werden sollten. Für alle anderen Anwendungsfälle empfehlen die Autoren ein System, das von jemandem entwickelt wurde, der beabsichtigte, ein sicheres zu erstellen.

Die Autoren möchten dem Huhn danken, ohne das nichts davon notwendig gewesen wäre.

Die mathematischen Grundlagen dieses Protokolls wurden von Euklid, Euler sowie Rivest, Shamir und Adleman gelegt, von denen keiner bei der Erstellung dieser Spezifikation konsultiert wurde oder in irgendeiner Weise für das Ergebnis verantwortlich ist.

Besonderer Dank gilt dem Beratenden Zentrum für rautavistische Software (BSfrS) für die Bereitstellung des methodologischen Rahmens, innerhalb dessen bewusst bedeutungslose technische Arbeit mit voller institutioneller Unterstützung verfolgt werden kann. Ihre Zertifizierung dieses Protokolls steht noch aus, wird aber erwartet, da Ablehnung kein dokumentierter Prozess ist.