Matematikken under lommeboken: Trail of Bits om MPC og TEE

Der pengene faktisk forsvinner i 2026

Spør en vanlig kryptoeier hvor et tyveri begynner, og svaret er nesten alltid det samme: en feil i en smartkontrakt. Bildet stemte en gang, men tallene for 2026 forteller en annen historie. I halvårsrapporten sin for første halvår oppga sikkerhetsselskapet CertiK at Web3 tapte mer enn 1,31 milliarder dollar (rundt 12,5 milliarder kroner) fordelt på 344 hendelser, og den dyreste enkeltkategorien var ikke kontraktsfeil. Det var kompromitterte nøkler og lommebøker: over 444 millioner dollar, om lag 4,2 milliarder kroner, på bare 33 hendelser.

De to største angrepene i halvåret, kompromitteringen av Kelp DAO (291 millioner dollar) og Drift Protocol (285 millioner dollar), kom begge i april og sto til sammen for nær 44 prosent av alt som gikk tapt. Ingen av dem var en Solidity-feil. Angriperne gikk etter infrastruktur, utrullingsnøkler og signeringsflyten, ikke etter en logisk brist i kontraktskoden. Kodefeil var fortsatt den vanligste kategorien målt i antall (204 hendelser), men pengene lekket i størst grad ut et helt annet sted: gjennom matematikken og nøklene som ligger under lommeboken.

Det er her et navn de færreste privatinvestorer kjenner, blir interessant. Trail of Bits er mest omtalt som en revisor av smartkontrakter, men selskapet har et eget kryptografiteam som gjør noe ganske annet enn å lete etter feil i Solidity. De reviderer selve matematikken: signaturene, terskelprotokollene, hash-funksjonene og de kryptografiske byggeklossene som avgjør om en nøkkel faktisk holder. Med bitcoin rundt 796 000 kroner og ether snaut 24 000 kroner (CoinGecko, 14. oktober 2026), og et globalt kryptomarked i størrelsesorden 2 900 milliarder dollar, er det en del av bransjen som til slutt avgjør hvor trygt alt det andre er.

Denne artikkelen handler om den delen. Ikke om hvordan du velger mellom en maskinvarelommebok og en børs, men om feilklassene Trail of Bits jager i laget under: nonce-gjenbruk, feil i MPC, fallgruver når terskelsignaturer flyttes inn i en TEE, og tvetydig koding i hash-funksjoner. Alle disse har en felles rød tråd, og den tråden forklarer hvorfor stempelet «revidert» betyr mindre enn folk tror. Den som forstår tråden, slutter å spørre om et prosjekt er revidert, og begynner å spørre om hva som faktisk ble gjennomgått, av hvem, og hvor lenge.

Et revisjonshus med et eget kryptografiteam

Trail of Bits ble grunnlagt i New York i 2012 og er i dag et av de mest siterte sikkerhetsselskapene i bransjen. De fleste forbinder dem med verktøy for smartkontrakter i åpen kildekode, som den statiske analysatoren Slither og fuzzeren Echidna. Men ved siden av kontraktspraksisen driver selskapet en egen kryptografipraksis som reviderer matematikken i stedet for forretningslogikken. Skillet er viktig: en smartkontraktsrevisjon spør om koden gjør det utvikleren mente, mens en kryptografirevisjon spør om selve primitivene, signaturskjemaet, terskelprotokollen eller bevissystemet, er trygge i utgangspunktet. Det er to forskjellige fag, og de krever to forskjellige slags hoder.

Teamet ledes av Jim Miller som Engineering Director, og det er satt sammen på en uvanlig måte. Som selskapet selv beskriver det, holder «half the team … PhDs in cryptography and the other half ships production cryptographic code in Rust, Go, and C». Den ene halvdelen kan altså bevise hvorfor et skjema er sikkert, den andre vet hvordan det faktisk ryker når det skal kjøre i produksjon. Praksisen oppgir 63 offentlige kryptografioppdrag og rundt 345 personuker med loggført arbeid, og dekker nullkunnskapsbevis (zero-knowledge proofs), flerpartsberegning (MPC), postkvantekryptografi og de klassiske primitivene som ligger under alt sammen.

Et eget kryptografiteam er sjeldnere enn man skulle tro. De fleste sikkerhetsfirmaer behandler kryptografi som en del av den vanlige kodegjennomgangen, og overser dermed akkurat den typen feil som ikke vises i logikken, men i matematikken. Guido har advart om at dette skaper et skille i bransjen: «There’s going to be security haves and have-nots, and it’s going to extend not just from individual projects, but also to blockchains.» De prosjektene som har råd til, og vet å etterspørre, en ordentlig kryptografigjennomgang, ender opp tryggere enn resten, nokså uavhengig av hvor pent hvitboken leser.

Noe av det mest karakteristiske ved selskapet er at det legger metodene ut i det åpne. Gratisressurser som ZKDocs (en referansehåndbok for nullkunnskapsbevis), den statiske analysatoren Circomspect for ZK-kretser, offentlige CodeQL-regler for kryptografi og forskningsartikkelen «Weak Fiat-Shamir Attacks on Modern Proof Systems» er alle fritt tilgjengelige. Logikken ble oppsummert av medgründer Dan Guido i et intervju med Decential: «I don’t ever want to find the same bug twice. That was the motivation behind creating a static analysis framework and a verification tool.» Et verktøy som fanger en feilklasse automatisk, frigjør mennesker til å lete etter den neste. Det er en helt annen filosofi enn å kjøre en skanner og levere resultatet som en rapport.

Nonce-gjenbruk: den eldste feilen i boka

For å forstå hvorfor matematikken er så farlig, lønner det seg å begynne med den enkleste feilen som finnes i en digital signatur. Hver gang en lommebok signerer en transaksjon med ECDSA, algoritmen bak både Bitcoin og Ethereum, trekker den et engangstall kalt en nonce. Tallet skal være hemmelig og tilfeldig, og det skal aldri gjenbrukes. Signerer du to forskjellige meldinger med samme nonce, kan hvem som helst som ser begge signaturene, regne seg tilbake til den private nøkkelen med ren algebra. Ikke gjette. Regne. Det tar brøkdelen av et sekund på en vanlig datamaskin.

Dette er ikke et teoretisk problem. I 2013 gjorde en svakhet i tilfeldighetsgeneratoren SecureRandom på Android at flere Bitcoin-lommebøker trakk samme nonce på nytt, og mynter ble tømt rett ut av kontoer som ellers var riktig satt opp. Verre: senere forskning viste at nøkkelen ikke engang trenger full gjenbruk for å ryke. Hvis noncene bare er litt skjeve, litt forutsigbare, kan et gitterangrep (lattice attack) gjenskape den private nøkkelen fra et knippe signaturer. Standardverket her er artikkelen «Biased Nonce Sense», som katalogiserer nettopp hvor lite skjevhet som skal til før nøkkelen er tapt.

Bransjens svar var å slutte å stole på tilfeldighet. Standarden RFC 6979 beskriver deterministiske nonces: i stedet for å trekke et tilfeldig tall utleder man noncen fra meldingen og den private nøkkelen selv, slik at den blir umulig å gjenta ved et uhell. Haken, og dette er poenget som binder resten av artikkelen sammen, er at RFC 6979 bare er trygg når én part signerer på én maskin. I det øyeblikket nøkkelen deles mellom flere parter eller flyttes inn i spesialisert maskinvare, åpner akkurat det samme problemet seg på nytt, bare forkledd. Nonce-gjenbruk er ikke en feil fra fortiden; den er en feil som finner nye hjem hver gang bransjen bygger et nytt lag.

MPC: å dele nøkkelen uten å samle den

Måten profesjonelle forvarere håndterer den risikoen på i 2026, heter som regel flerpartsberegning, på engelsk multi-party computation eller MPC. Idéen er elegant: i stedet for å lage én privat nøkkel og så beskytte den, lager man aldri hele nøkkelen i det hele tatt. Hver part får en andel, og en signatur settes sammen av andelene uten at den fulle nøkkelen noen gang eksisterer på ett sted. Forvaringsselskapet Fireblocks beskriver det slik: «The full private key is never created, never stored, and never assembled at any point». Det er en fundamental forskjell fra en vanlig lommebok, der nøkkelen finnes et sted og kan stjeles derfra.

Fordelen er at én kompromittert andel ikke holder for en angriper. Som Fireblocks formulerer det: «An attacker with access to one key share cannot sign a transaction or reconstruct the private key. They would need to compromise a quorum of shares.» Og fordi MPC virker på det kryptografiske laget og ikke på blokkjedeprotokollen, fungerer den samme ordningen på tvers av Bitcoin, Ethereum, Solana og «200+ other networks». Selskapet oppgir at det har behandlet mer enn 16 000 milliarder dollar i transaksjoner og laget over 750 millioner lommebøker, og peker på at regulatorer allerede i 2019 anerkjente MPC som en gyldig modell for selvforvaring. Dette er ikke en nisje lenger; det er ryggraden i institusjonell forvaring.

Hvordan MPC står mot klassisk multisig, og hvorfor valget mellom dem er en forvaringsbeslutning mer enn en teknisk detalj, har vi dekket før; se gjennomgangen av hvordan kryptoforvaringen konsentreres hos noen få aktører. Her er poenget et annet, og mer ubehagelig: MPC fjerner ikke nonce-problemet fra forrige kapittel. Den sprer det ut over flere maskiner, og i flere av de dokumenterte feilene har spredningen gjort problemet vanskeligere å se, ikke lettere. En protokoll der nøkkelen aldri samles, er beroligende å lese om, men den har byttet ut én kjent risiko med en hel familie av nye.

Men MPC har sine egne feil

At nøkkelen aldri settes sammen, betyr ikke at protokollen rundt er feilfri. Tvert imot: terskelsignaturer er beregningsmessig kompliserte, og de har sin egen artsrike fauna av sårbarheter. Trail of Bits-forskere har bidratt tungt til mpcsec.org, en offentlig katalog over reelle MPC-feil som drives sammen med blant andre zkSecurity, Partisia og Zama. Katalogen sorterer fallgruvene i sju familier, og den er nyttig nettopp fordi den viser at de fleste MPC-tyverier ikke skyldes eksotisk matematikk, men kjedelige utelatelser som en travel utvikler lett overser.

Legg merke til to av oppføringene. «Gjenoppretting og avbrudd» handler om at en avbrutt økt kan få en signerer til å gjenbruke en forhåndssignatur, altså presis den nonce-gjenbruken fra Android-eksempelet, bare på MPC-nivå. Og «kontekstbinding» handler om manglende domeneseparasjon, et begrep vi kommer tilbake til, der fraværet av en enkel merkelapp gjør at en forfalsker kan prøve igjen og igjen til noe treffer. To av de sju familiene er altså varianter av feil vi allerede har møtt. Det er ikke en tilfeldighet, og det er hele poenget med å lese katalogen samlet.

To mekanismer gjør MPC enda vanskeligere å få riktig, og de er verdt å kjenne til. Den første er distribuert nøkkelgenerering (DKG): andelene skal lages i fellesskap, uten at noen enkelt maskin noensinne ser hele nøkkelen, heller ikke i det korte øyeblikket den settes opp. Den andre er proaktiv oppfriskning, der partene med jevne mellomrom bytter ut andelene sine mot nye som utgjør samme nøkkel, slik at en angriper som sakte samler andeler over tid, mister dem igjen før kvorumet er nådd. Begge er elegante på papiret og lette å implementere feil, og flere av oppføringene i katalogen handler nettopp om snublesteiner i disse to trinnene.

Når TEE knekker MPC

Det neste laget bransjen har lagt på, er maskinvare. En TEE (Trusted Execution Environment) er et avlukke i prosessoren der kode og data er beskyttet mot resten av maskinen, selv mot operativsystemet og eieren av serveren. Logikken er fristende: kjør MPC-andelene inne i en TEE, så er de beskyttet to ganger. Men i september 2026 publiserte Trail of Bits-kryptografen Paul Bottinelli en analyse med en ubehagelig konklusjon, under tittelen «Don’t let TEEs break your MPC»: de to teknologiene hviler på motstridende antakelser.

MPC er laget for å spre tillit, slik at ingen enkeltpart må stoles på. En TEE gjør det motsatte. Som Bottinelli skriver, «TEEs … centralize trust in the hardware manufacturer that controls the root certificate». Du bytter altså ut tilliten til medsignererne med tillit til Intel, AMD eller den som utsteder maskinvarens rotsertifikat. Verre er den konkrete feilen han beskriver, og den er verdt å sitere i sin helhet: «A malicious host could roll back the filesystem state after a threshold signer deletes a used pre-signature, causing the signer to reuse their nonce share and disclose their private key share.»

Les den setningen én gang til. En ondsinnet vert, altså den som eier serveren TEE-en kjører på, kan rulle filsystemet tilbake til et øyeblikk før en brukt forhåndssignatur ble slettet. Når avlukket så henter den «ferske» forhåndssignaturen, bruker det i realiteten samme nonce-andel om igjen, og lekker sin del av den private nøkkelen. Det er 2013-feilen fra Android, gjenoppstått inni verdens mest avanserte maskinvarebeskyttelse. Bottinelli lister flere svikt i samme ånd: tvetydig koding i hash-funksjoner, manglende parametre i Fiat-Shamir-transformasjoner, manglende inndatavalidering, sidekanaler og rene protokollfeil. Konklusjonen hans er ikke at TEE er ubrukelig, men at det må behandles «as a defense-in-depth layer rather than a substitute for a sound protocol». Et ekstra lag, ikke en erstatning.

SequenceHash: når det å slå sammen to verdier blir en sårbarhet

Noen dager senere, 2. oktober 2026, publiserte Trail of Bits enda et stykke arbeid som ser trivielt ut helt til du skjønner konsekvensen. I posten «SequenceHash: multihashing for the rest of us» tar forfatteren Opal Wright for seg et problem som dukker opp overalt i kryptografi: hvordan hasher du flere verdier sammen på en trygg måte?

Den naive løsningen er å lime verdiene sammen og hashe resultatet. Problemet er at sammenlimingen er tvetydig. Hashen av «ab» etterfulgt av «c» blir identisk med hashen av «a» etterfulgt av «bc», fordi bitene er de samme. For en angriper betyr det at to forskjellige sett med inndata kan gi samme hash, en kollisjon som ikke skyldes svakhet i hash-funksjonen, men i måten den brukes. I et signaturskjema eller et bevissystem kan en slik kollisjon være nok til å forfalske noe som skulle vært umulig å forfalske.

SequenceHash løser det med to grep: en dobbel hashing (i HMAC-ånd, som også gjør den trygg mot lengdeforlengelsesangrep) og en eksplisitt lengdekoding, slik at det alltid er entydig hvor én verdi slutter og den neste begynner. Spesifikasjonen er åpen, lagt inn i Community Cryptography Specification Project, med implementasjoner i både Go og Python, og den fungerer med vanlige hash-funksjoner som SHA-256 og BLAKE2, ikke bare Keccak. Keccak har lenge hatt TupleHash til dette; SequenceHash gir resten av verden det samme. Det viktigste for denne artikkelen er den innebygde muligheten for «customization strings»: korte merkelapper som låser en hash til én bestemt bruk. Det er domeneseparasjon, satt i system.

Én feil, fire ansikter

Nå kan vi samle trådene. Fire av feilklassene vi har sett på, ser ut som helt forskjellige problemer: nonce-gjenbruk i en enkel signatur, presignatur-gjenbruk i MPC, tvetydig sammenliming i en hash, og manglende domeneseparasjon i et bevissystem. I praksis er de fire ansikter på samme feil: en hemmelighet eller en kontekst som skulle vært unik, blir gjenbrukt eller forvekslet med en annen.

Domeneseparasjon er det kjedelige botemiddelet som går igjen. Idéen er at hver kryptografisk operasjon skal merkes med konteksten sin, slik at en signatur ment for én sammenheng aldri kan gjenbrukes i en annen, og slik at en utfordring i et bevis er bundet til nettopp det beviset. Når merkelappen mangler, oppstår det Trail of Bits og mpcsec.org kaller «et myntkast per forsøk»: angriperen kan bare prøve om igjen til tilfeldigheten faller riktig vei. Det er også kjernen i det selskapet har skrevet om i «Weak Fiat-Shamir Attacks on Modern Proof Systems», der nullkunnskapsbevis som ikke binder utfordringen godt nok til hele konteksten, kan narres til å godta falske bevis.

Dette er grunnen til at en kryptografirevisjon ikke kan reduseres til en sjekkliste. De samme tre linjene som fikser nonce-gjenbruk, fikser ikke nødvendigvis presignatur-gjenbruk, og en skanner som leter etter det ene mønsteret, ser ikke det andre. Det kreves et menneske som forstår at alle fire er samme sykdom, for å stille riktig diagnose. En maskin kan finne symptomet; den gjenkjenner sjelden slektskapet.

En revisjon er ikke en skanning

Nettopp dette poenget er blitt mer betent etter hvert som KI-verktøy har gjort det billig å «revidere» kode. David Schwed, operativ sjef i sikkerhetsselskapet SVRN, sa det skarpt til CoinDesk: «’Claude, audit my smart contract, make no mistakes’ is not a security program.» Et språkmodellsvar er et utgangspunkt, ikke en garanti, og i kryptografi er avstanden mellom de to spesielt stor, fordi feilene sjelden ser ut som feil før noen med vond vilje presser på.

Alexander Urbelis, sikkerhetssjef i ENS Labs, pekte i samme sak på hvorfor: «The bugs that drain treasuries often turn on intent and adversarial incentives.» Feilene som tømmer en kasse, handler sjelden om en linje som er «feil» i isolasjon. De handler om hva en motstander med penger og tålmodighet kan få systemet til å gjøre, noe en skanner ikke har noen modell for. Det er forskjellen mellom å spørre «gjør koden det den sier?» og «hva kan en angriper lure den til å gjøre?».

Dan Guido har vært enda mer direkte om hvorfor kryptofeil gjentar seg. Om Solidity og EVM har han sagt at utviklerne «have reinvented every security issue that we eliminated from modern languages like Rust and Go and Swift». Poenget generaliserer: hver gang bransjen bygger et nytt lag, MPC, TEE eller ZK, oppstår de gamle feilklassene på nytt i ny drakt, og noen må kjenne historien godt nok til å se dem. Det er dette et kryptografiteam selger, ikke en PDF med et stempel. Vi har skrevet mer om hva som skjer når selve revisjonsrollen gjøres om til et produkt, i gjennomgangen av hvordan CertiK forsøker å bli et «tillitslag».

Det revisjonsstempelet ikke dekker

Her er den ubehagelige sannheten stempelet skjuler: en kryptografirevisjon dekker matematikken og koden som fantes den dagen den kjørte. Den dekker ikke hvordan nøklene oppbevares i drift, hvem som har tilgang til signeringsmaskinen, eller om en ansatt blir lurt. CertiK-tallene for 2026 gjør dette konkret. De dyreste angrepene var ikke kodefeil i det hele tatt, men svikt i nøkkelhåndtering og infrastruktur, akkurat det en revisjon av selve koden aldri kan garantere mot.

Mønsteret er tydelig: angriperne går etter mennesker og nøkkelhåndtering, ikke bare etter kode. En feilfri kryptografirevisjon av signaturskjemaet hjelper lite hvis en operatør lagrer en nøkkelandel i klartekst, eller hvis en utrullingsnøkkel ligger på en maskin som blir overtatt. Det er derfor spørsmålet om hvem som har de operative nøklene, og hvem som kan stanse en kompromittert prosess, er like viktig som kvaliteten på matematikken; vi har sett nærmere på nettopp den rollen i gjennomgangen av sikkerhetsrådene som skal vokte protokollene. Et stempel på koden er en nødvendig, men langt fra tilstrekkelig, betingelse for at pengene er trygge.

Hva en kryptografirevisjon koster, og hvem som godkjenner den

Kvalitet av dette slaget er ikke billig. Bransjetall for Trail of Bits og sammenlignbare hus ligger rundt 240 000 kroner per ingeniør per uke (omtrent 25 000 dollar). Et typisk bedriftsoppdrag havner et sted mellom 760 000 og 1,9 millioner kroner, mens mindre, spesialiserte gjennomganger kan starte rundt 76 000 kroner hos mindre firmaer. Et stort program med flere firmaer kan koste langt mer. Når teamet oppgir 345 personuker fordelt på 63 oppdrag, forstår man hvorfor de reserverer tiden til problemer som faktisk krever en doktorgrad å løse.

Det som overrasker mange, er at ingen myndighet godkjenner eller sertifiserer en kryptografirevisor. Det finnes ingen offentlig akkreditering, verken i USA, EU eller Norge, som skiller en seriøs gjennomgang fra en overfladisk en. Kvaliteten holdes oppe av omdømme alene: hvem som skrev rapporten, hvor mange personuker de brukte, og om de legger funnene ut i det åpne slik at andre kan etterprøve dem. Det gjør «revidert av X» til et svakt signal med mindre du vet hva X faktisk gjorde, og hvor lenge de holdt på. En kort gjennomgang og et halvårs grundig arbeid gir det samme ordet på forsiden.

Finanstilsynet, MiCA og det regulatoriske tomrommet

For norske lesere er det verdt å være tydelig på hva regelverket faktisk krever. MiCA, EUs regelverk for kryptoeiendeler, er innlemmet i EØS-avtalen og gjelder i Norge gjennom kryptoeiendelsloven, med Finanstilsynet som tilsynsmyndighet for kryptoforetak (CASP-er). I tillegg stiller DORA krav til IKT- og driftsrobusthet for regulerte finansforetak. Men verken MiCA eller DORA pålegger noen å få en smartkontrakt eller et kryptografisk skjema revidert av et uavhengig sikkerhetshus. Kravene handler om foretakets organisering, kapital og rutiner, ikke om at matematikken bak en terskelsignatur er bevist trygg.

Det følger to ting av dette. For det første er en kryptografirevisjon frivillig: den gjennomføres fordi et seriøst prosjekt vil, eller fordi investorer og børser forventer det, ikke fordi loven krever det. For det andre faller helt desentraliserte protokoller i praksis utenfor MiCA, siden det ikke finnes et foretak å føre tilsyn med. Mister du penger i en slik protokoll på grunn av en kryptografisk feil, finnes det ingen tilsynsmyndighet å klage til, uansett hvor grundig, eller overfladisk, koden ble gjennomgått. Ansvaret for å lese rapporten, og ikke bare se stempelet, ligger dermed hos deg.

I praksis betyr dette to forskjellige verdener for en norsk sparer. Bruker du en MiCA-registrert aktør, en børs eller et forvaringsforetak under tilsyn av Finanstilsynet, finnes det et foretak med krav til organisering og driftsrobusthet, og en adresse å henvende seg til hvis noe går galt. Flytter du de samme pengene inn i en desentralisert protokoll, bytter du den beskyttelsen mot koden og matematikken alene. Da er en offentlig, grundig kryptografirapport fra et hus som Trail of Bits noe av det nærmeste du kommer en forbrukeropplysning, men den er fortsatt ingen garanti, og ingen tilsynsmyndighet står bak den.

Nullkunnskap og postkvante: neste angrepsflate

Feilklassene i denne artikkelen er ikke i ferd med å forsvinne. De flytter seg oppover i stabelen, til de nyeste byggeklossene. Nullkunnskapsbevis (zero-knowledge proofs) er i ferd med å bli en standard del av både skalering og personvern i kryptosektoren, og de er beryktet vanskelige å få riktige. Det er nettopp derfor Trail of Bits gir bort ZKDocs og Circomspect: jo flere som fanger de vanlige feilene tidlig, desto færre havner i en protokoll som holder milliarder. «Weak Fiat-Shamir»-angrepene er allerede en påminnelse om at et bevis som ikke binder konteksten sin, kan forfalskes, akkurat som en signatur med gjenbrukt nonce.

Den andre fronten er postkvante. Dagens signaturer, inkludert ECDSA på secp256k1-kurven som sikrer både Bitcoin og Ethereum, hviler på matematiske problemer som en tilstrekkelig kraftig kvantemaskin en dag kan løse. Overgangen til kvantesikre algoritmer er en av grunnene til at en egen kryptografipraksis finnes: det er presis den typen skifte der en liten feil i implementasjonen, en skjev parameter eller en manglende domeneseparasjon, kan undergrave hele sikkerheten. Byggeklossene blir nye, men feilene kommer til å kjennes igjen. Den som har lest de foregående kapitlene, vil ane konturene av dem før de har fått navn.

Hva det betyr for byggere og eiere

For den som bygger, er lærdommen å behandle kryptografi som et eget fagfelt, ikke som en del av den vanlige kodebasen. Bruk standarder som RFC 6979 der de passer, dokumenter antakelsene, og hvis du flytter nøkler inn i MPC eller en TEE, få noen som faktisk forstår terskelprotokoller til å gå gjennom akkurat det laget. Bottinellis råd om at en TEE skal være et ekstra lag og ikke en erstatning, gjelder generelt: hvert nytt beskyttelseslag flytter risikoen, så du må vite hvor den havner, ikke bare at den ble mindre et sted.

For den som eier krypto, er poenget mer nøkternt. Du kommer aldri til å lese en kryptografirapport selv, men du kan spørre hvem som skrev den, hvor lenge de brukte, og om funnene er offentlige. Og du kan flytte oppmerksomheten dit tapene faktisk skjer: til nøklene. Hvordan du oppbevarer dem, om du har forstått forskjellen på en selvforvart og en forvart løsning, og hvordan du håndterer gjenoppretting, betyr mer for din egen sikkerhet enn hvilken algoritme som står på etiketten. For en praktisk gjennomgang av avveiningene mellom de vanligste lommebøkene, se oversikten over hvordan MetaMask, Phantom og Rabby har blitt banker, og for hva slags konto som egentlig ligger bak, gjennomgangen av EIP-7702 etter Glamsterdam.

Konklusjonen Trail of Bits’ kryptografiteam står for, er ikke at krypto er dømt, men at sikkerhet er en prosess og ikke et stempel. Pengene i 2026 forsvinner gjennom matematikken og nøklene, ikke gjennom en enslig Solidity-feil. Jo før bransjen flytter blikket dit, desto færre av disse overskriftene får vi neste halvår.

Ofte stilte spørsmål

Hva er forskjellen på en smartkontraktsrevisjon og en kryptografirevisjon?

En smartkontraktsrevisjon ser etter feil i forretningslogikken: om koden gjør det utvikleren mente. En kryptografirevisjon ser på de underliggende primitivene, som signaturer, terskelprotokoller og hash-funksjoner, og spør om selve matematikken er trygg. Trail of Bits driver begge deler, men gjennom to ulike team med ulik kompetanse.

Hvorfor er nonce-gjenbruk så farlig?

Signerer du to meldinger med samme engangstall i ECDSA, kan hvem som helst regne seg frem til den private nøkkelen ut fra de to signaturene. Selv litt forutsigbare nonces kan avsløre nøkkelen via gitterangrep. Standarden RFC 6979 løser det med deterministiske nonces, men bare når én part signerer på én maskin.

Gjør MPC og TEE kryptolommebøker trygge?

De hjelper, men de fjerner ikke risikoen. MPC sprer nøkkelen over flere parter, men har egne feilklasser, og Trail of Bits har vist at en TEE i verste fall kan rulle tilbake tilstanden og få en signerer til å gjenbruke en nonce. Maskinvare bør være et ekstra lag, ikke en erstatning for en solid protokoll.

Krever Finanstilsynet at kryptoprosjekter revideres?

Nei. MiCA gjelder i Norge via EØS med Finanstilsynet som tilsyn for kryptoforetak, og DORA stiller krav til driftsrobusthet, men verken MiCA eller DORA pålegger en uavhengig kryptografi- eller kodegjennomgang. En revisjon er frivillig, og helt desentraliserte protokoller faller i praksis utenfor tilsynet.

Hva bør jeg se etter i en revisjonsrapport?

Se hvem som utførte arbeidet, hvor mange personuker de brukte, hva som var innenfor omfanget, og om alvorlige funn ble lukket. Et stempel alene sier lite. Siden ingen myndighet akkrediterer revisorer, er omdømme og åpne rapporter de beste holdepunktene du har.

Av redaksjonen i HOGE Wire, sikkerhetsseksjonen.