Base32 / Base58-konverter

De er to svar på ét spørgsmål: en kanal, der bærer tekst, bedes bære bytes. Base32 og Base58 er hverken kryptering eller hashing — de skjuler ikke noget og forkorter ikke noget. De omskriver en bytestreng ved hjælp af et fast sæt læselige tegn, og enhver, der kender det anvendte sæt, kan vende det direkte tilbage. Den eneste grund til at foretrække det ene frem for det andet er, hvad den modtagende ende gør med tegnene.

To familier gør denne omskrivning på helt forskellige måder, og forskellen forklarer næsten alle overraskelser på denne side:

• Bitpakning — Base32, Base32 Hex, Crockford Base32, z-base-32. Bytes deles i faste grupper, og hver fem bit bliver til ét tegn. Outputlængden kan forudsiges ud fra inputlængden, og den sidste, delvist fyldte gruppe markeres enten med opfyldstegn eller efterlades kort.
• Konvertering af store tal — alle Base58-tabeller. Hele bytestrengen læses som ét enormt tal i base 256 og skrives derefter ud igen i base 58. Der er ingen grupper og ingen opfyld; længden går ikke op i noget, og hver indledende nulbyte bliver til ét indledende nultegn.

Hvert alfabet er vist helt ud i stedet for at blive beskrevet, fordi to værktøjer, der udskriver forskellige tegn under det samme navn, aldrig vil være enige, uanset hvad etiketten siger. RFC 4648-rækkerne er normative; Crockford- og z-base-32-rækkerne følger det, formatets ophavsmand har offentliggjort; de tre Base58-rækker er udbredte konventioner snarere end standarder, hvorfor de er angivet særskilt.

Alfabetet udelader I, L, O og U, så intet symbol kan forveksles med et andet. Det, der er tilbage, er ufølsomt over for store/små bogstaver ved indtastning: i og l læses som cifferet 1, o læses som cifferet 0, og bindestreger findes kun for at gøre en lang streng lettere at læse. Derudover definerer formatet et valgfrit kontrolsymbol, som er værdien af symbolstrengen læst som et base 32-tal, taget modulo 37 og skrevet med fem ekstra symboler for værdierne 32 til 36.

Kontrolsymbolet beregnes over symbolstrengen, ikke over bytes: fordi kodning nulfylder den sidste gruppe, giver afkodning af de samme tegn altid tilbage til den samme værdi. Derfor kan kontrolværdien i tabellen genskabes i hånden udelukkende ud fra den kodede kolonne. De fem ekstra symboler er *, ~, $, = og U for værdierne 32, 33, 34, 35 og 36, så et kontrolsymbol er ikke altid et ciffer eller et bogstav.

z-base-32 bevarer RFC 4648 Base32's femte-bits-pakning og ændrer kun rækkefølgen af de 32 tegn. Rækkefølgen er valgt, så de tegn, en person mest sandsynligt skal skrive ned, er dem, der er nemmest at skrive og sværest at forveksle. Den har ingen opfyld, så en læser skal kende, hvor mange symboler en værdi forventes at have; det er prisen for et format, der er designet til at blive læst i hånden først.

Base58 alene har ingen måde at skelne en forkert skrevet streng fra en korrekt, fordi næsten enhver kombination af dens 58 tegn er et gyldigt tal. Base58Check løser det ved at lægge dataene ind i en indpakning: én versionsbyte, derefter nyttelasten, derefter de første fire bytes af SHA-256 anvendt to gange i træk på de to første dele. Et modtagende program beregner de fire bytes igen og afviser strengen, når de ikke stemmer. Versionsbyten er det, der fortæller en tegnebog, om den kigger på en betalingsadresse, en script-adresse eller en privat nøgle.

Generatoren under konverteren tager versionsbyten og nyttelasten som hexadecimal og skriver Base58Check-strengen; verifikatoren læser en tilbage, skiller de fire checksum-bytes fra, beregner dem igen og angiver både den, den fandt, og den, den forventede. En forkert checksum betyder her, at strengen er blevet skrevet forkert eller ændret — den betyder aldrig, at nyttelasten i sig selv er forkert, for nyttelasten fortolkes aldrig.

• "Base64 er kryptering." Nej. Der er ingen nøgle og ingen hemmelighed; outputtet kan vendes af enhver. Base32 og Base58 er i samme situation, og at sende en værdi gennem alle tre tilføjer heller ingen beskyttelse.
• "En Base58-streng er en Bitcoin-adresse." Kun når den også består Base58Check-checksum og har en versionsbyte, som den modtagende software genkender. Base58-strenge optræder mange andre steder, herunder simple identifikatorer uden checksum overhovedet.
• "De tre Base58-alfabeter er udskiftelige." De bruger de samme 58 tegn i tre forskellige rækkefølger, så de samme bytes giver tre forskellige strenge. Et værktøj skal have at vide, hvilket det skal bruge, og denne side angiver altid, hvilket den har brugt.
• "Opfyldet er en del af værdien." =-tegnene markerer kun den sidste gruppe. To Base32-strenge, der kun adskiller sig i opfyldet, beskriver de samme bytes, hvorfor afkoderen accepterer en streng uden opfyld.
• "Alle tegn virker." Hvert alfabet er et fast sæt. Et tegn udenfor det har ingen værdi, så afkoderen stopper og navngiver tegnet og dets position i stedet for at gætte.

Hvorfor bruger Base32 2-7 og ikke 0-9? Fordi RFC 4648 valgte alfabetet, så det forbliver inden for de tegn, et domænenavn må indeholde, og så det er let at læse højt. Base32 Hex bruger i stedet 0-9 A-V, når naturlig sortering vægter tungere.

Hvorfor starter en Base58-streng så ofte med 1? Hver indledende nulbyte i inputtet bliver til ét indledende 1 (det første tegn i Bitcoin- og Flickr-alfabetet). En versionsbyte på 0x00 er én nulbyte, så de fleste Bitcoin-mainnet-adresser begynder med præcis ét 1.

Hvad indlæser knappen Eksempel? Eksemplet, der hører til det valgte skema og den aktuelle retning, aldrig en fast tekst. Kodningen får teksten fra skemaets eget eksempel — RFC 4648 afsnit 10-vektorerne for Base32 og Base32 Hex, Crockfords 12345, z-base-32-rækkerne vist ovenfor — og afkodningen får den kodede streng for det valgte alfabet, hvilket gør eksemplet brugbart i begge retninger. De tre Base58-rækker har bevidst samme tekst, så man kan skifte skema og trykke på Eksempel igen for at se de tre rækkefølger af de samme 58 tegn side om side. Med Crockford-kontrolsymbolet markeret får afkoderen værdien med symbolet til sidst, og det er den eneste måde at se verifikatoren acceptere et.

Sender denne side mine data nogen steder hen? Nej. Hver konvertering sker i denne browserfane, og siden indeholder ingen netværkskald overhovedet. Det er også derfor, den virker, når filen åbnes direkte fra disken.

Hvilken skal jeg bruge til en hemmelighed? TOTP- og HOTP-godkendelseshemmeligheder er normalt Base32 i RFC 4648-alfabetet, fordi hemmeligheden skal indtastes i hånden. Brug den, som den modtagende software beder om, og stol aldrig på selve kodningen for hemmeligholdelse.