Sp\u00f8r 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\u00e5rsrapporten sin for f\u00f8rste halv\u00e5r oppga sikkerhetsselskapet CertiK at Web3 tapte mer enn 1,31 milliarder dollar<\/a> (rundt 12,5 milliarder kroner) fordelt p\u00e5 344 hendelser, og den dyreste enkeltkategorien var ikke kontraktsfeil. Det var kompromitterte n\u00f8kler og lommeb\u00f8ker: over 444 millioner dollar, om lag 4,2 milliarder kroner, p\u00e5 bare 33 hendelser.<\/p> De to st\u00f8rste angrepene i halv\u00e5ret, kompromitteringen av Kelp DAO (291 millioner dollar) og Drift Protocol (285 millioner dollar), kom begge i april og sto til sammen for n\u00e6r 44 prosent av alt som gikk tapt. Ingen av dem var en Solidity-feil. Angriperne gikk etter infrastruktur, utrullingsn\u00f8kler og signeringsflyten, ikke etter en logisk brist i kontraktskoden. Kodefeil var fortsatt den vanligste kategorien m\u00e5lt i antall (204 hendelser), men pengene lekket i st\u00f8rst grad ut et helt annet sted: gjennom matematikken og n\u00f8klene som ligger under lommeboken.<\/p> Det er her et navn de f\u00e6rreste privatinvestorer kjenner, blir interessant. Trail of Bits er mest omtalt som en revisor av smartkontrakter, men selskapet har et eget kryptografiteam som gj\u00f8r noe ganske annet enn \u00e5 lete etter feil i Solidity. De reviderer selve matematikken: signaturene, terskelprotokollene, hash-funksjonene og de kryptografiske byggeklossene som avgj\u00f8r om en n\u00f8kkel faktisk holder. Med bitcoin rundt 796 000 kroner<\/a> og ether snaut 24 000 kroner (CoinGecko, 14. oktober 2026), og et globalt kryptomarked i st\u00f8rrelsesorden 2 900 milliarder dollar, er det en del av bransjen som til slutt avgj\u00f8r hvor trygt alt det andre er.<\/p> Denne artikkelen handler om den delen. Ikke om hvordan du velger mellom en maskinvarelommebok og en b\u00f8rs, men om feilklassene Trail of Bits jager i laget under: nonce-gjenbruk, feil i MPC, fallgruver n\u00e5r terskelsignaturer flyttes inn i en TEE, og tvetydig koding i hash-funksjoner. Alle disse har en felles r\u00f8d tr\u00e5d, og den tr\u00e5den forklarer hvorfor stempelet \u00abrevidert\u00bb betyr mindre enn folk tror. Den som forst\u00e5r tr\u00e5den, slutter \u00e5 sp\u00f8rre om et prosjekt er revidert, og begynner \u00e5 sp\u00f8rre om hva som faktisk ble gjennomg\u00e5tt, av hvem, og hvor lenge.<\/p> 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\u00f8y for smartkontrakter i \u00e5pen kildekode, som den statiske analysatoren Slither og fuzzeren Echidna. Men ved siden av kontraktspraksisen driver selskapet en egen kryptografipraksis<\/a> som reviderer matematikken i stedet for forretningslogikken. Skillet er viktig: en smartkontraktsrevisjon sp\u00f8r om koden gj\u00f8r det utvikleren mente, mens en kryptografirevisjon sp\u00f8r om selve primitivene, signaturskjemaet, terskelprotokollen eller bevissystemet, er trygge i utgangspunktet. Det er to forskjellige fag, og de krever to forskjellige slags hoder.<\/p> Teamet ledes av Jim Miller som Engineering Director, og det er satt sammen p\u00e5 en uvanlig m\u00e5te. Som selskapet selv beskriver det, holder \u00abhalf the team … PhDs in cryptography and the other half ships production cryptographic code in Rust, Go, and C\u00bb. Den ene halvdelen kan alts\u00e5 bevise hvorfor et skjema er sikkert, den andre vet hvordan det faktisk ryker n\u00e5r det skal kj\u00f8re i produksjon. Praksisen oppgir 63 offentlige kryptografioppdrag og rundt 345 personuker med loggf\u00f8rt arbeid, og dekker nullkunnskapsbevis (zero-knowledge proofs), flerpartsberegning (MPC), postkvantekryptografi og de klassiske primitivene som ligger under alt sammen.<\/p> 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: \u00abThere’s going to be security haves and have-nots, and it’s going to extend not just from individual projects, but also to blockchains.\u00bb De prosjektene som har r\u00e5d til, og vet \u00e5 ettersp\u00f8rre, en ordentlig kryptografigjennomgang, ender opp tryggere enn resten, noks\u00e5 uavhengig av hvor pent hvitboken leser.<\/p> Noe av det mest karakteristiske ved selskapet er at det legger metodene ut i det \u00e5pne. Gratisressurser som ZKDocs (en referanseh\u00e5ndbok for nullkunnskapsbevis), den statiske analysatoren Circomspect for ZK-kretser, offentlige CodeQL-regler for kryptografi og forskningsartikkelen \u00abWeak Fiat-Shamir Attacks on Modern Proof Systems\u00bb er alle fritt tilgjengelige. Logikken ble oppsummert av medgr\u00fcnder Dan Guido i et intervju med Decential<\/a>: \u00abI don’t ever want to find the same bug twice. That was the motivation behind creating a static analysis framework and a verification tool.\u00bb Et verkt\u00f8y som fanger en feilklasse automatisk, frigj\u00f8r mennesker til \u00e5 lete etter den neste. Det er en helt annen filosofi enn \u00e5 kj\u00f8re en skanner og levere resultatet som en rapport.<\/p> For \u00e5 forst\u00e5 hvorfor matematikken er s\u00e5 farlig, l\u00f8nner det seg \u00e5 begynne med den enkleste feilen som finnes i en digital signatur. Hver gang en lommebok signerer en transaksjon med ECDSA, algoritmen bak b\u00e5de Bitcoin og Ethereum, trekker den et engangstall kalt en nonce. Tallet skal v\u00e6re 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\u00f8kkelen med ren algebra. Ikke gjette. Regne. Det tar br\u00f8kdelen av et sekund p\u00e5 en vanlig datamaskin.<\/p> Dette er ikke et teoretisk problem. I 2013 gjorde en svakhet i tilfeldighetsgeneratoren SecureRandom p\u00e5 Android at flere Bitcoin-lommeb\u00f8ker trakk samme nonce p\u00e5 nytt, og mynter ble t\u00f8mt rett ut av kontoer som ellers var riktig satt opp. Verre: senere forskning viste at n\u00f8kkelen ikke engang trenger full gjenbruk for \u00e5 ryke. Hvis noncene bare er litt skjeve, litt forutsigbare, kan et gitterangrep (lattice attack) gjenskape den private n\u00f8kkelen fra et knippe signaturer. Standardverket her er artikkelen \u00abBiased Nonce Sense\u00bb<\/a>, som katalogiserer nettopp hvor lite skjevhet som skal til f\u00f8r n\u00f8kkelen er tapt.<\/p> Bransjens svar var \u00e5 slutte \u00e5 stole p\u00e5 tilfeldighet. Standarden RFC 6979<\/a> beskriver deterministiske nonces: i stedet for \u00e5 trekke et tilfeldig tall utleder man noncen fra meldingen og den private n\u00f8kkelen selv, slik at den blir umulig \u00e5 gjenta ved et uhell. Haken, og dette er poenget som binder resten av artikkelen sammen, er at RFC 6979 bare er trygg n\u00e5r \u00e9n part signerer p\u00e5 \u00e9n maskin. I det \u00f8yeblikket n\u00f8kkelen deles mellom flere parter eller flyttes inn i spesialisert maskinvare, \u00e5pner akkurat det samme problemet seg p\u00e5 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.<\/p> M\u00e5ten profesjonelle forvarere h\u00e5ndterer den risikoen p\u00e5 i 2026, heter som regel flerpartsberegning, p\u00e5 engelsk multi-party computation eller MPC. Id\u00e9en er elegant: i stedet for \u00e5 lage \u00e9n privat n\u00f8kkel og s\u00e5 beskytte den, lager man aldri hele n\u00f8kkelen i det hele tatt. Hver part f\u00e5r en andel, og en signatur settes sammen av andelene uten at den fulle n\u00f8kkelen noen gang eksisterer p\u00e5 ett sted. Forvaringsselskapet Fireblocks beskriver det slik: \u00abThe full private key is never created, never stored, and never assembled at any point\u00bb<\/a>. Det er en fundamental forskjell fra en vanlig lommebok, der n\u00f8kkelen finnes et sted og kan stjeles derfra.<\/p> Fordelen er at \u00e9n kompromittert andel ikke holder for en angriper. Som Fireblocks formulerer det: \u00abAn 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.\u00bb Og fordi MPC virker p\u00e5 det kryptografiske laget og ikke p\u00e5 blokkjedeprotokollen, fungerer den samme ordningen p\u00e5 tvers av Bitcoin, Ethereum, Solana og \u00ab200+ other networks\u00bb. Selskapet oppgir at det har behandlet mer enn 16 000 milliarder dollar i transaksjoner og laget over 750 millioner lommeb\u00f8ker, og peker p\u00e5 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.<\/p> Hvordan MPC st\u00e5r mot klassisk multisig, og hvorfor valget mellom dem er en forvaringsbeslutning mer enn en teknisk detalj, har vi dekket f\u00f8r; se gjennomgangen av hvordan kryptoforvaringen konsentreres hos noen f\u00e5 akt\u00f8rer<\/a>. 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 \u00e5 se, ikke lettere. En protokoll der n\u00f8kkelen aldri samles, er beroligende \u00e5 lese om, men den har byttet ut \u00e9n kjent risiko med en hel familie av nye.<\/p> At n\u00f8kkelen 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\u00e5rbarheter. Trail of Bits-forskere har bidratt tungt til mpcsec.org<\/a>, 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.<\/p>Et revisjonshus med et eget kryptografiteam<\/h2>
Nonce-gjenbruk: den eldste feilen i boka<\/h2>
MPC: \u00e5 dele n\u00f8kkelen uten \u00e5 samle den<\/h2>
Men MPC har sine egne feil<\/h2>