WireGuard sier at lengden på den private nøkkelen er feil: hva nå?

Meldingen sier at den private nøkkelen har feil lengde, og den formuleringen peker først på kodingen og deretter på kryptografien. WireGuard-nøkler koder 32 byte som base64, noe som gir 44 tegn inkludert en avsluttende utfylling, så en verdi av en annen størrelse er ikke en nøkkel uansett hvor tilfeldig den ser ut. Å fylle ut strengen til parseren godtar den gir en velformet verdi som ingen peer noen gang vil kjenne igjen.

Bak denne feilen skjuler det seg to ulike jobber: å reparere teksten i en gyldig nøkkel, og å erstatte en identitet du ikke lenger har. De har ulike konsekvenser, og én av dem gjør den andre enden ugyldig.

Hva parseren forventer

En WireGuard-nøkkel er 32 byte nøkkelmateriale i base64 med standard utfylling, noe som gir en fast streng på 44 tegn. Verktøyene avviser alt som ikke dekodes til nøyaktig 32 byte, fordi den underliggende kurven tar en skalar på 32 byte og ingenting annet. Offentlige og private verdier bruker samme koding, så parseren kan ikke ut fra formatet alene se hvilken av dem du limte inn. Den tvetydigheten skaper halvparten av forvirringen rundt denne feilen.

wg genkey | tee private.key | wg pubkey > public.key
base64 -d private.key | wc -c
wc -c private.key
wg show wg0 public-key

Hvis verdien din dekodes til 32 byte, er lengden riktig og klagen kommer fra et annet sted i filen. Hvis den dekodes til noe kortere, har du avkortet materiale og ikke et formateringsproblem.

Formateringsskade eller feil materiale?

Formateringsskader samler seg i kantene: anførselstegn som et skall la til, en etikett som private_key kopiert sammen med verdien, et linjeskift satt inn av en chatklient, eller et avsluttende mellomrom som overlevde limingen. Hver av disse endrer strengen uten å endre bytene, så å fjerne dem gjenoppretter den opprinnelige identiteten. Sammenlign filen med klargjøringsprotokollen tegn for tegn i stedet for å fjerne tegnsetting til parseren blir stille.

Feil materiale er en annen situasjon. Et passord, en sertifikatnøkkel eller en offentlig verdi kan alle se troverdige ut og dekodes til feil størrelse. Ingen mengde rensing gjør noen av dem til skalaren peer-en forventer. Det tilfellet krever en ny identitet i stedet for en redigering.

En offentlig nøkkel i det private feltet

Den vanligste forvekslingen er en offentlig verdi limt inn i det private feltet, eller omvendt. Begge er gyldig base64 på 32 byte, så lengdekontrollen passerer og håndtrykket feiler senere uten en nyttig melding. En privat nøkkel er skalaren som lager den offentlige, så du kan avgjøre det ved å utlede den offentlige verdien og sammenligne den med det peer-en autoriserer. Når den utledede verdien ikke stemmer med protokollen, har du feil identitet og ikke en skrivefeil.

Å bytte ut klientens private nøkkel uten å oppdatere den autoriserte offentlige nøkkelen i den andre enden gjenoppretter den samme uoverensstemmelsen, med den ekstra forvirringen at klientens egen fil nå ser selvkonsistent ut. Endre begge ender i én operasjon, ellers feilsøker neste person den gale halvdelen.

Reparer profilen, og bevis deretter håndtrykket

Når nøkkelen dekodes til riktig størrelse og passer til det autoriserte paret, gjenstår profilen og ruten. Kommandoene nedenfor genererer et friskt par når det trengs, verifiserer den dekodede størrelsen til en eksisterende nøkkel og leser den offentlige verdien som grensesnittet faktisk bruker. Lim aldri en privat verdi inn i en sak eller på et dekodingsnettsted.

wg genkey | tee new.key | wg pubkey > new.pub
base64 -d private.key | wc -c
ip route get 10.60.9.5
wg show wg0 latest-handshakes

Størrelseskontrollen svarer på om materialet har nøkkelform, og rutespørringen svarer på om en pakke noen gang ville nå grensesnittet. En håndtrykkslinje som blir stående tom etter at begge kontrollene passerer, flytter diagnosen til peer-ens endepunkt og de tillatte adressene. Les grensesnittets offentlige nøkkel mot klargjøringsprotokollen én siste gang, fordi en utdatert lagret profil kan se riktig ut mens den aktive avviker].

Noter hvilken verdi du byttet ut og hvor den autoriserte kopien ligger. Den neste som rører denne peer-en må vite hvilken ende som ble endret.