RFC-1751-S/KEY-Encoder
Der 64-Bit-Schlüssel EB33 F77E E73D 4053 wird zu TIDE ITCH SLOW REIN RULE MOT: sechs kurze englische Wörter, die sich leichter diktieren oder abschreiben lassen als Hex, mit Paritätsbits, die ein falsch getipptes Wort erkennen. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Text
- EB33 F77E E73D 4053
- Berechnungsmodus
- Encode
- Ergebnis
- TIDE ITCH SLOW REIN RULE MOT
- Hex
- EB33F77EE73D4053
- Wörter
- TIDE ITCH SLOW REIN RULE MOT
- Schlüssel-Bytes
- 8
RFC 1751 definiert eine feste Konvention, um binäre kryptografische Schlüssel in kurze englische Wortketten zu verwandeln, damit Menschen 64- und 128-Bit-Material lesen, merken und tippen können, ohne von Hexadezimalziffern ermüdet zu werden. Dasselbe Wörterbuch speist die klassischen S/KEY-Einmalpasswörter: Jeder Acht-Byte-Block wird zu sechs Wörtern aus einer Liste von 2048 Tokens mit ein bis vier Buchstaben, wobei zwei Bits für die Parität reserviert sind, damit Übertragungsfehler beim Zurückwandeln erkannt werden. Diese Fähigkeit kodiert einen hexadezimalen Schlüssel in diese Wortform und dekodiert Wörter zurück in Hexadezimal in Großbuchstaben, wobei die Paritätsbits in jeder Sechs-Wort-Gruppe geprüft werden.
Wie RFC 1751 64 Bit in sechs englische Wörter packt
Das RFC-1751-Wörterbuch enthält genau zweitausendachtundvierzig englische Wörter mit ein bis vier Buchstaben, sodass jedes Wort elf Bits indiziert. Sechs Wörter liefern sechsundsechzig Bits: vierundsechzig Bits Schlüsselmaterial plus ein Zwei-Bit-Paritätsfeld. Die Kodierung durchläuft jede Acht-Byte-Hälfte Ihres Schlüssels als Bitstrom, summiert aufeinanderfolgende Zwei-Bit-Scheiben über die vierundsechzig Datenbits zu einem Paritäts-Nibble, hängt die unteren zwei Paritätsbits an und zerlegt das sechsundsechzig-Bit-Ergebnis in sechs Elf-Bit-Indizes.
Diese Indizes wählen Wörter aus der festen Liste in Großbuchstaben, verbunden durch Leerzeichen. Ein reiner Vierundsechzig-Bit-Schlüssel wird daher genau zu sechs Wörtern; ein Hundertachtundzwanzig-Bit-Schlüssel besteht aus zwei unabhängigen Hälften und wird zu zwölf Wörtern. Die Dekodierung kehrt die Abbildung um: Jedes Wort muss im Wörterbuch stehen, sechs Wörter bauen neun Bytes Bit-Packung wieder auf, die ersten acht Bytes bilden die Kandidaten-Schlüsselhälfte, und die gespeicherten zwei Paritätsbits werden mit einer frischen Paritätssumme verglichen.
Eine Abweichung bedeutet ein falsch getipptes Wort oder ein gekipptes Bit und wird mit einer klaren Paritätsfehler-Meldung abgelehnt, nicht mit einem stillschweigend falschen Schlüssel. Das Wörterbuch ändert sich zwischen Implementierungen nie; diese Stabilität erklärt, warum S/KEY-OTPs, Schlüsselausdrucke der SNMP-Ära und moderne Wiederherstellungswerkzeuge interoperieren können, wenn sie alle RFC 1751 beanspruchen. Diese Seite implementiert nur diese klassische Wortliste — keine BIP-39-Mnemonics, kein EFF-Diceware und keine beliebigen Passphrasen-Generatoren —, sodass die Suchabsicht bei menschenlesbarer Schlüsselkodierung mit Parität bleibt.
Wo wortbasierte Schlüssel im S/KEY-Stil noch nützen
Betreiber, die noch Vierundsechzig-Bit-Material drucken oder diktieren, profitieren von sechs kurzen Wörtern weit mehr als von sechzehn Hex-Ziffern, besonders am Telefon oder Funk. S/KEY- und OTP-Systeme, die bereits RFC-1751-Phrasen ausgeben, brauchen einen strengen Decoder, der Paritätsfehler ablehnt, statt einen Nachbarschlüssel zu akzeptieren, der den falschen Principal authentifizieren würde. Sicherheitsschulungslabore lehren Transkriptionsdisziplin, indem sie zeigen, wie ein einziges falsches Wort das Paritätsbit kippt und die Dekodierung abbricht.
Incident-Response-Notizen speichern Offline-Wiederherstellungsmaterial manchmal als menschenlesbare Wortgruppen, damit ein Responder ohne Hex-Editor einen Schlüssel später erneut eingeben kann. Dokumentationsautoren, die für RFC 1751 oder S/KEY-Wörter ranken wollen, brauchen eine eigene Landingpage mit Live-Tool statt einer generischen Base32- oder BIP-39-Seite, weil Wörterbuch, Paritätsregel und Schlüssellängen abweichen. Fehlgeschlagene Validierung wird nicht berechnet.
Halten Sie Anfragen an den dokumentierten Schlüsselgrößen, pinnen Sie Hex in Großbuchstaben und Wortstrings in Tests, und Sie erhalten reproduzierbare Transformationen für Wiederherstellungsabläufe, OTP-Werkzeuge und Edge-Worker, ohne ein vollständiges Kryptografie-Toolkit selbst aufzubauen.
Anwendungsfälle
Eingabe von S/KEY-OTP-Phrasen
Dekodieren Sie sechswortige S/KEY-Einmalpasswort-Phrasen zurück auf den zugrunde liegenden 64-Bit-Wert mit Paritätsprüfung, bevor Sie Anmeldematerial akzeptieren.
Menschenlesbare Schlüsselausdrucke
Kodieren Sie 64- oder 128-Bit-Hex-Schlüssel als sechs oder zwölf englische Wörter für mündliche Übergabe, Papier-Backups oder funktaugliche Runbooks.
Häufige Fragen
Wie wandle ich einen Hex-Schlüssel in RFC-1751-Wörter um?
Senden Sie mode encode (oder lassen Sie mode weg) mit text auf 16 Hex-Ziffern für einen 64-Bit-Schlüssel oder 32 Ziffern für 128 Bit. Leerzeichen und Doppelpunkte werden ignoriert. Das result-Feld enthält sechs oder zwölf Wörter des Wörterbuchs in Großbuchstaben.
Wie dekodiere ich englische Wörter zurück zu Hex?
Senden Sie mode decode mit text auf sechs oder zwölf durch Leerzeichen getrennte RFC-1751-Wörter.
Was passiert, wenn die Paritätsprüfung fehlschlägt?
Eine Paritätsabweichung bedeutet, dass mindestens ein Wort falsch getippt oder beschädigt wurde; die Fähigkeit liefert nie einen geratenen Schlüssel.
Ist das dasselbe wie BIP-39-Mnemonik-Wörter?
Nein. RFC 1751 nutzt eine andere 2048-Wort-Liste, packt 64-Bit-Hälften mit einem 2-Bit-Paritätsfeld und zielt auf Schlüssel im S/KEY-Stil, nicht auf Seed-Phrasen von HD-Wallets.
Welche Schlüsselformate kann ich einfügen?
Fügen Sie 16 Hex-Ziffern für einen 64-Bit-Schlüssel oder 32 für einen 128-Bit-Schlüssel ein. Leerzeichen, Doppelpunkte, Bindestriche und ein vorangestelltes 0x werden ignoriert, EB33 F77E E73D 4053 funktioniert also direkt. Ein 128-Bit-Schlüssel ergibt zwölf Wörter.
Verwandte Tools
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem Stack
curl -X POST https://api.kit.forhosting.com/enc/rfc1751 \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"EB33 F77E E73D 4053"}'const res = await fetch("https://api.kit.forhosting.com/enc/rfc1751", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "EB33 F77E E73D 4053"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/rfc1751",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "EB33 F77E E73D 4053"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/rfc1751", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"EB33 F77E E73D 4053"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"EB33 F77E E73D 4053"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/rfc1751", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"text": "EB33 F77E E73D 4053"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.rfc1751",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |
Technische Hinweise
Ungültige Wörter, falsche Wortanzahlen, unzulässige Hex-Längen und Paritätsfehler lösen invalid_input aus, statt einen Schlüssel zu erfinden.
Eingabevertrag, Modi und Fehlerverhalten
Fehlt mode, ist encode der Standard. Der Encode-Modus behandelt text als hexadezimalen Schlüssel: optionales 0x-Präfix, Leerzeichen, Doppelpunkte und Bindestriche werden entfernt; die bereinigte Ziffernanzahl muss sechzehn für einen Vierundsechzig-Bit-Schlüssel oder zweiunddreißig für hundertachtundzwanzig Bit sein; jede andere Länge scheitert sofort. Der Decode-Modus behandelt text als durch Leerzeichen getrennte englische Wörter, wandelt sie in Großbuchstaben um, wendet die historischen S/Key-Buchstabenersetzungen an (Ziffer eins zu L, null zu O, fünf zu S) und verlangt ein positives Vielfaches von sechs Wörtern. Senden Sie per POST einen JSON-Body mit einem Pflicht-Stringfeld namens text und optionalem mode auf encode oder decode. Erfolgreiche Nutzlasten enthalten stets mode, den originalen text, ein primäres result-Feld (Wörter beim Kodieren, Hex in Großbuchstaben beim Dekodieren) sowie die Echo-Felder hex und words, key_bytes, key_bits, word_count, die Standardbezeichnung RFC 1751 und parity_ok true, wenn die Umwandlung abgeschlossen ist. Fehlender text, Nicht-String-Objekte, nicht unterstützte mode-Werte, ungerade Hex-Längen, Nicht-Hex-Zeichen, unbekannte Wörterbuchwörter, schlecht geformte Tokens länger als vier Buchstaben, Wortanzahlen, die keine Vielfachen von sechs sind, und fehlgeschlagene Paritätsprüfungen lösen alle invalid_input mit einer englischen Meldung aus, die das Problem benennt. Validierungsfehler verbrauchen kein Prepaid-Guthaben. Das kostenlose Browserformular eignet sich für einen einzelnen Schlüssel, den Sie tippen wollen; Skripte sollten dieselben JSON-Felder für Regressions-Goldens festnageln. Erfolgreiche API-Aufrufe nutzen den veröffentlichten Grundpreis von $0.002 pro Element.
Wo wortbasierte Schlüssel im S/KEY-Stil noch nützen
Weil die Implementierung reines Parse der Stufe A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Grundpreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netz.
Integrationsbeispiele
Mehrsprachige Golden-Fixtures
Erzeugen Sie Encode- und Decode-Vektoren, die zu RFC-1751-Referenzimplementierungen passen, damit mehrsprachige CI eine gemeinsame Wahrheit teilt.
Technische Fragen
Was kostet der RFC-1751-Wort-Konverter?
Das Browser-Tool ist kostenlos. API-Anfragen nutzen das Prepaid-KIT-Guthaben zu $0.002 pro erfolgreichem Aufruf; ungültige Eingaben werden nicht berechnet.