Konverterare för Base32 / Base58

De är två svar på en och samma fråga: en kanal som bär text ska bära byte. Base32 och Base58 är varken kryptering eller hashning — de döljer ingenting och de förkortar ingenting. De skriver om en bytesträng med en fast uppsättning läsbara tecken, och den som vet vilken uppsättning som användes kan vända tillbaka den direkt. Den enda anledningen att föredra det ena framför det andra är vad mottagarsidan gör med tecknen.

Två familjer gör den omskrivningen på helt olika sätt, och skillnaden förklarar nästan alla överraskningar på den här sidan:

• Bitpaketering — Base32, Base32 Hex, Crockford Base32, z-base-32. Byten delas i fasta grupper och varje fem bitar blir ett tecken. Utdatans längd kan förutsägas utifrån indatans längd, och den sista, delvis fyllda gruppen markeras antingen med utfyllnadstecken eller lämnas kort.
• Omvandling av stora tal — alla Base58-tabeller. Hela bytesträngen läses som ett enormt tal i bas 256 och skrivs ut igen i bas 58. Det finns inga grupper och ingen utfyllnad; längden delar inte upp sig i något, och varje inledande nollbyte blir ett inledande nolltecken.

Varje alfabet skrivs ut i sin helhet i stället för att beskrivas, eftersom två verktyg som skriver ut olika tecken under samma namn inte kommer att stämma överens, oavsett vad etiketten säger. RFC 4648-raderna är normativa; Crockford- och z-base-32-raderna följer vad formatets upphovsman publicerat; de tre Base58-raderna är utbredda konventioner snarare än standarder, vilket är anledningen till att de listas separat.

Alfabetet utelämnar I, L, O och U så att inget tecken kan läsas som ett annat. Det som återstår är skiftlägesokänsligt vid inmatning: i och l läses som siffran 1, o läses som siffran 0, och bindestreck finns bara för att göra en lång sträng lättare att läsa. Dessutom definierar formatet en valfri kontrollsymbol, som är symbolsträngens värde läst som ett tal i bas 32, taget modulo 37, och skrivet med fem extra symboler för värdena 32 till 36.

Kontrollsymbolen beräknas över symbolsträngen, inte över byten: eftersom kodaren fyller ut den sista gruppen med nollor, återgår avkodningen av samma tecken alltid till samma värde. Därför kan kontrollvärdet i tabellen återskapas för hand enbart från den kodade kolumnen. De fem extra symbolerna är *, ~, $, = och U för värdena 32, 33, 34, 35 och 36, så en kontrollsymbol är inte alltid en siffra eller en bokstav.

z-base-32 behåller fembitarspaketeringen från RFC 4648 Base32 och ändrar bara ordningen på de trettiotvå tecknen. Ordningen är vald så att de tecken en person troligast behöver skriva ned är de som är lättast att skriva och svårast att förväxla. Det har ingen utfyllnad, så en läsare måste veta hur många symboler ett värde förväntas ha; det är priset för ett format som är konstruerat för att läsas för hand först.

Base58 ensamt har inget sätt att skilja en felskriven sträng från en korrekt, eftersom nästan vilken kombination som helst av dess femtioåtta tecken är ett giltigt tal. Base58Check åtgärdar det genom att lägga data inuti ett omslag: en versionsbyte, sedan nyttolasten, sedan de fyra första byten av SHA-256 tillämpad två gånger i rad på de två första delarna. Ett mottagande program räknar om de fyra byten och vägrar strängen när de skiljer sig. Versionsbyten är det som talar om för en plånbok om den tittar på en betalningsadress, en skriptadress eller en privat nyckel.

Generatorn under konverteraren tar versionsbyten och nyttolasten som hexadecimala tal och skriver Base58Check-strängen; verifieraren läser en tillbaka, delar av de fyra kontrollsumsbyten, räknar om dem och anger både den som hittades och den som förväntades. En felaktig kontrollsumma betyder här att strängen har skrivits fel eller ändrats — den betyder aldrig att nyttolasten är felaktig, eftersom nyttolasten aldrig tolkas.

• "Base64 är kryptering." Nej. Det finns ingen nyckel och ingen hemlighet; utdata kan vändas av vem som helst. Base32 och Base58 befinner sig i samma läge, och att föra ett värde genom alla tre ger inte heller något skydd.
• "En Base58-sträng är en Bitcoin-adress." Bara när den dessutom klarar kontrollsumman i Base58Check och bär en versionsbyte som mottagarens programvara känner igen. Base58-strängar förekommer på många andra ställen, även som enkla identifierare utan någon kontrollsumma alls.
• "De tre Base58-alfabeten är utbytbara." De använder samma femtioåtta tecken i tre olika ordningar, så samma byte ger tre olika strängar. Ett verktyg måste få veta vilket som ska användas, och den här sidan anger alltid vilket som användes.
• "Utfyllnaden är en del av värdet." Tecknen = markerar bara den sista gruppen. Två Base32-strängar som bara skiljer sig åt i utfyllnaden beskriver samma byte, vilket är varför avkodaren accepterar en sträng där utfyllnaden har klippts bort.
• "Vilka tecken som helst fungerar." Varje alfabet är en fast uppsättning. Ett tecken utanför den har inget värde, så avkodaren stannar och anger tecknet och dess position i stället för att gissa.

Varför använder Base32 2-7 och inte 0-9? För att RFC 4648 valde alfabetet så att det ligger inom de tecken ett domännamn får innehålla, och så att det är lätt att läsa upp högt. Base32 Hex använder i stället 0-9 A-V när naturlig sortering är viktigare.

Varför börjar en Base58-sträng så ofta med 1? Varje inledande nollbyte i indatan blir ett inledande 1 (det första tecknet i Bitcoin- och Flickr-alfabetet). En versionsbyte 0x00 är ett nollbyte, så de flesta Bitcoin-adresser på huvudnätet börjar med exakt en 1.

Vad läser knappen Exempel in? Exemplet som hör till det schema och den riktning som just nu visas, aldrig en fast text. Kodaren får texten från schemats eget exempel — RFC 4648:s avsnitt 10 för Base32 och Base32 Hex, Crockfords 12345, z-base-32-raderna ovan — och avkodaren får den kodade strängen för det valda alfabetet, vilket gör att exemplet går att använda åt båda hållen. De tre Base58-raderna har medvetet samma text, så att man kan byta schema och trycka på Exempel igen för att se de tre ordningarna av samma femtioåtta tecken sida vid sida. När kontrollsymbolen för Crockford är ikryssad får avkodaren värdet med symbolen i slutet, vilket är det enda sättet att se verifieraren godta en sådan.

Skickas mina data någonstans? Nej. Varje konvertering sker i den här webbläsarfliken, och sidan innehåller inga nätverksanrop av något slag. Det är också därför den fungerar med filen öppnad direkt från disken.

Vilken bör jag använda för en hemlighet? Hemligheter för TOTP- och HOTP-autentiserare är vanligtvis Base32 i RFC 4648-alfabetet, eftersom hemligheten måste skrivas för hand. Använd det som mottagande programvara begär, och förlita sig aldrig på kodningen i sig för att skydda hemligheten.