Kva ein VPN-nonce er, og kvifor gjenbruk øydelegg tunnelen

Dei fleste møter ordet nonce i ein VPN-profil og går ut frå at det er endå ein delt løyndom som skal kopierast mellom partar. Det er det ikkje. Ein nonce er ein verdi som aldri må gjentakast under same nøkkel, og i dei fleste nonce-baserte krypteringar reiser han i klartekst. Forvirringa er harmlaus heilt til nokon redigerer han for hand, og det er der den verkelege skaden byrjar.

Kvar noncen faktisk kjem frå

Autentisert kryptering treng ein annan nonce for kvar melding som blir kryptert under ein nøkkel. Protokollar oppfyller dette kravet på ulike måtar: ein monotont aukande teljar, eit salt kombinert med ein pakkeidentifikator eller ein tilstrekkeleg lang tilfeldig verdi. IKEv2 utvekslar noncar under den innleiande utvekslinga, og dei er offentlege inngangar til nøkkelutleiing, ikkje løyndomar.

Unikskap kan vere strukturell eller sannsynsbasert. Ein teljar kan ikkje gjentakast før han rullar over, og difor definerer protokollen eit nøkkelbytepunkt lenge før. Ein tilfeldig verdi er avhengig av nok bit til at ein kollisjon er usannsynleg innanfor meldingsgrensa, som er eit anna argument med ein annan feilmodus. Protokolldokumentasjonen oppgir kva metode som gjeld, og begge er berre trygge så lenge den oppgitte grensa blir respektert.

Kva gjenbruk faktisk kostar

Å gjenbruke ein nonce under éin nøkkel er ikkje eit lite effektivitetsspørsmål. Med GCM lèt to meldingar som deler ein IV ein observatør gjenopprette autentiseringsnøkkelen og rekne ut den eksklusive eller av dei to klartekstane. Straumbaserte konstruksjonar gjenbrukar nøkkelstraumen på same måte, noko som gjer chifferteksten til eit puslespel i staden for ein løyndom.

Difor bytar implementasjonar nøkkel før ein teljar rullar over, og difor stoppar dei i staden for å halde fram når tilstanden er usikker. Ein omstart som nullstiller ein teljar medan motparten framleis har den gamle nøkkelen, eller ei virtuell maskin gjenoppretta frå eit augneblinksbilete teke midt i ei økt, er nettopp situasjonen grensene finst for å hindre. Ingen åtakar er nødvendig; vanlege operasjonar er nok.

Kvifor manuell redigering er feil løysing

Teljarar, salt og pakkeidentifikatorar er tilstandsmaskinar som blir delte av begge endar. Å endre den eine sida desynkroniserer den andre, og tunnelen feilar på måtar som ser ut som eit ruteproblem. Den støtta spaken er ein ny nøkkelutveksling, som nullstiller tilstanden på begge endar samstundes.

Passord og noncar spelar òg ulike roller. Eit passord er hemmeleg inngang til nøkkelutleiing; ein nonce er offentleg inngang per melding. Eit profilfelt merkt nonce som ber om ein lang løyndom, er vanlegvis ein statisk nøkkel eller ein på førehand delt løyndom under eit anna namn, så les dokumentasjonen for det feltet i staden for å gå ut frå noko.

Når eit tryggingsvarsel gjeld handtering av nonce, er reparasjonen den retta versjonen til vedlikehaldaren, ikkje ein annan chiffer eller ein kortare nøkkel. Å byte chiffer for å unngå ordet nonce flyttar problemet i staden for å løyse det.

Å lese ei åtvaring utan å gisse

Ei logglinje om teljarar eller noncar skildrar vanlegvis tapt tilstand, ikkje eit åtak. Sjekk om ein motpart er starta på nytt, om ei klona virtuell maskin har gjenbrukt same identitet, og om dei to endane er samde om nøkkelbyteinnstillingane. Set deretter opp ei ny økt og sjå om meldinga kjem tilbake.

Hald diagnosen skild frå urelaterte feil. Ei side som ikkje lastar, eller ei påloggingsførespurnad som går i løkke, er ikkje prov på nonce-gjenbruk, og å handsame det som det sender deg ned i krypteringslaget når problemet ligg over det.

For vanleg bruk er den trygge regelen kort: lat implementasjonen styre noncen, hald begge endar på støtta versjonar, og handsame kvar tilstandsnullstilling som ein grunn til å byte nøkkel i staden for å redigere ein verdi. Står eit profilfelt ikkje i dokumentasjonen til leverandøren, ikkje finn opp ein verdi for det. Reparasjon av tunnelen byrjar med å vite kva lag du ser på.