{"id":139,"date":"2026-06-20T13:04:06","date_gmt":"2026-06-20T13:04:06","guid":{"rendered":"https:\/\/shattered.io\/no\/2026\/06\/20\/ed25519-vs-rsa\/"},"modified":"2026-06-20T13:05:44","modified_gmt":"2026-06-20T13:05:44","slug":"ed25519-vs-rsa","status":"publish","type":"post","link":"https:\/\/shattered.io\/no\/ed25519-vs-rsa\/","title":{"rendered":"Ed25519 vs RSA: 33x raskere signaturer, 128-bit sikkerhet [2026]"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\"><strong>Ed25519<\/strong> signerer 50.000 meldinger per sekund. <strong>RSA-2048<\/strong> klarer 1.500. RSA-4096 klarer knapt 200. Det er ikke en marginal forskjell, det er to st\u00f8rrelsesordener. Likevel kj\u00f8rer millioner av servere, SSH-n\u00f8kler og sertifikater fremdeles p\u00e5 RSA, gjerne med argumentet om at &#8220;det fungerer&#8221;. Denne artikkelen sammenligner de to algoritmene punkt for punkt, med benchmarks, n\u00f8kkelst\u00f8rrelser, signaturdimensjoner og en klar migreringsguide.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"hurtigoversikt-ed25519-vs-rsa-2026\">Hurtigoversikt: Ed25519 vs RSA [2026]<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ed25519 vinner p\u00e5 nesten alle tekniske parametere: 33 ganger raskere signaturer enn RSA-2048, 250 ganger raskere n\u00f8kkelgenerering enn RSA-4096, og signaturer som er 75 % mindre. RSA holder stand prim\u00e6rt i eldre systemer og milj\u00f8er der kompatibilitet med sv\u00e6rt gamle klienter er p\u00e5krevd. For alle nye implementasjoner i 2026 peker bevisene mot Ed25519.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Faktor<\/th><th>Ed25519<\/th><th>RSA-2048<\/th><th>RSA-4096<\/th><\/tr><\/thead><tbody><tr><td>Signeringshastighet<\/td><td>~50.000 ops\/sek<\/td><td>~1.500 ops\/sek<\/td><td>~200 ops\/sek<\/td><\/tr><tr><td>N\u00f8kkelst\u00f8rrelse<\/td><td>256 bit<\/td><td>2048 bit<\/td><td>4096 bit<\/td><\/tr><tr><td>Signaturst\u00f8rrelse<\/td><td>64 byte<\/td><td>256 byte<\/td><td>512 byte<\/td><\/tr><tr><td>Sikkerhetsniv\u00e5<\/td><td>~128-bit<\/td><td>~112-bit<\/td><td>&gt;128-bit<\/td><\/tr><tr><td>N\u00f8kkelgenerering<\/td><td>~1 ms<\/td><td>~50 ms<\/td><td>~250 ms<\/td><\/tr><tr><td>Deterministisk signering<\/td><td>Ja<\/td><td>Nei<\/td><td>Nei<\/td><\/tr><tr><td>Pris<\/td><td>Gratis (\u00e5pen kildekode)<\/td><td>Gratis (\u00e5pen kildekode)<\/td><td>Gratis (\u00e5pen kildekode)<\/td><\/tr><tr><td>Kvante-resistent<\/td><td>Nei<\/td><td>Nei<\/td><td>Nei<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"hva-er-rsa\">Hva er RSA?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">RSA ble publisert i 1977 av Ron Rivest, Adi Shamir og Leonard Adleman ved MIT, derav forkortelsen. Algoritmen bygger p\u00e5 heltallsfaktorisering: gitt to store primtall <em>p<\/em> og <em>q<\/em>, er det enkelt \u00e5 beregne produktet <em>n = p \u00d7 q<\/em>, men ekstremt vanskelig \u00e5 g\u00e5 den andre veien og finne <em>p<\/em> og <em>q<\/em> gitt bare <em>n<\/em> og den offentlige n\u00f8kkelen. Sikkerheten hviler p\u00e5 at ingen effektiv faktoriseringsalgoritme for klassiske datamaskiner er kjent.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">RSA er et asymmetrisk system: en offentlig n\u00f8kkel for kryptering eller verifisering, og en privat n\u00f8kkel for dekryptering eller signering. Sikkerhetsniv\u00e5et er direkte knyttet til n\u00f8kkelst\u00f8rrelsen i bits. RSA-2048, minimumskravet i de fleste moderne retningslinjer for 2026, gir omtrent 112-bit sikkerhet. RSA-3072 er n\u00e6rmere 128-bit sikkerhet, mens RSA-4096 overskrider det.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Problemet med RSA er at n\u00f8kkelst\u00f8rrelsen m\u00e5 skaleres aggressivt etter hvert som databehandlingskraft \u00f8ker. RSA-1024 er i dag fullstendig brutt. RSA-512 ble faktisk faktorisert tilbake i 1999 med dedikert maskinvare. \u00c5 g\u00e5 fra RSA-2048 til RSA-4096 gj\u00f8r alle kryptografiske operasjoner dramatisk tregere fordi matematikken skalerer polynomisk med n\u00f8kkelst\u00f8rrelsen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">RSA ble standardisert for digitale signaturer via PKCS#1 og <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc8709\" rel=\"noopener noreferrer\" target=\"_blank\">RFC 8709<\/a>. Det er fremdeles i utstrakt bruk i TLS-sertifikater, kodesignering for Windows-drivere og programvare, e-post (S\/MIME), og en rekke eldre systemer som mangler st\u00f8tte for nyere alternativer. For norske organisasjoner med eldre nettverksinfrastruktur fra tidlig 2010-tall er RSA ofte den eneste algoritmen nettverksenheter forst\u00e5r.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">RSA har et bredt landskap av angrepsflater knyttet til implementasjon, ikke bare matematikk. Bleichenbacher-angrepet fra 1998 utnytter feilh\u00e5ndtering av PKCS#1 v1.5 padding og dukker fortsatt opp i sikkerhetsrapporter. ROBOT-angrepet (2017) var en variant som rammet 27 av verdens 100 st\u00f8rste HTTPS-domener, inkludert Facebook og PayPal. Disse angrepene eksisterer ikke i Ed25519 fordi designet er fundamentalt annerledes.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"hva-er-ed25519\">Hva er Ed25519?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ed25519 er et digitalt signatursystem basert p\u00e5 <strong>EdDSA<\/strong> (Edwards-curve Digital Signature Algorithm) over elliptisk kurve <strong>Curve25519<\/strong>. Kurven ble designet av kryptografen Daniel J. Bernstein (kjent som DJB), som ogs\u00e5 laget str\u00f8msiferen ChaCha20 og meldingsautentiseringskoden Poly1305. Curve25519 ble valgt med eksplisitt fokus p\u00e5 \u00e5 motst\u00e5 implementasjonsfeil og sidekanalsangrep, to svakheter som historisk har rammet RSA hardt i praksis. Ed25519 ble formelt standardisert i <a href=\"https:\/\/tools.ietf.org\/html\/rfc8032\" rel=\"noopener noreferrer\" target=\"_blank\">RFC 8032<\/a> av IETF i 2017.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der RSA hviler p\u00e5 heltallsfaktorisering, hviler Ed25519 p\u00e5 det diskrete logaritme-problemet over en elliptisk kurve. Elliptiske kurver gir mye mer sikkerhet per bit enn RSA: en 256-bit Ed25519-n\u00f8kkel tilbyr omtrent 128-bit effektiv sikkerhet. Det er det samme sikkerhetsniv\u00e5et som RSA-3072, men oppn\u00e5dd med en n\u00f8kkel som er 12 ganger kortere.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En av de viktigste tekniske fordelene med Ed25519 er <strong>deterministisk signering<\/strong>. RSA-PSS og mange ECDSA-implementasjoner krever en tilfeldig nonce per signatur. En svak tilfeldighetsgenerator (PRNG) kan lekke den private n\u00f8kkelen. PlayStation 3 ble kompromittert i 2010 nettopp fordi Sony brukte en konstant nonce i ECDSA, noe som tillot angripere \u00e5 beregne den private signeringsn\u00f8kkelen. Ed25519 unng\u00e5r hele problemet ved \u00e5 beregne nonce deterministisk fra selve meldingen og den private n\u00f8kkelen, uten ekstern tilfeldighet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ed25519 ble integrert i <a href=\"https:\/\/www.openssh.com\/releasenotes.html\" rel=\"noopener noreferrer\" target=\"_blank\">OpenSSH 6.5<\/a> i januar 2014 og er i dag standard-anbefalingen for nye SSH-n\u00f8kler i alle moderne distribusjonsveiledninger. WireGuard VPN bruker Curve25519 til n\u00f8kkelutveksling. Signal-protokollen bruker XEdDSA, en variant av Ed25519, for meldingsautentisering p\u00e5 tvers av WhatsApp, Signal og andre applikasjoner som har lisensiert protokollen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"tekniske-spesifikasjoner-fullstendig-sammenligning\">Tekniske spesifikasjoner: fullstendig sammenligning<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Tabellen under sammenligner Ed25519 og de to vanligste RSA-variantene punkt for punkt med tall fra offisielle spesifikasjoner og uavhengige analyser.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Parameter<\/th><th>Ed25519<\/th><th>RSA-2048<\/th><th>RSA-4096<\/th><\/tr><\/thead><tbody><tr><td>Algoritmebase<\/td><td>Elliptisk kurve (Curve25519 \/ EdDSA)<\/td><td>Heltallsfaktorisering<\/td><td>Heltallsfaktorisering<\/td><\/tr><tr><td>N\u00f8kkelst\u00f8rrelse (bits)<\/td><td>256<\/td><td>2048<\/td><td>4096<\/td><\/tr><tr><td>Offentlig n\u00f8kkel (bytes, r\u00e5)<\/td><td>~32 byte<\/td><td>~256 byte<\/td><td>~512 byte<\/td><\/tr><tr><td>Privat n\u00f8kkel (bytes, serialisert)<\/td><td>~64 byte<\/td><td>~1.192 byte (PKCS#8)<\/td><td>~3.272 byte (PKCS#8)<\/td><\/tr><tr><td>Signaturst\u00f8rrelse<\/td><td>64 byte<\/td><td>256 byte<\/td><td>512 byte<\/td><\/tr><tr><td>Sikkerhetsniv\u00e5 (bits)<\/td><td>~128-bit<\/td><td>~112-bit<\/td><td>&gt;128-bit<\/td><\/tr><tr><td>Signeringshastighet<\/td><td>~50.000 ops\/sek<\/td><td>~1.500 ops\/sek<\/td><td>~200 ops\/sek<\/td><\/tr><tr><td>Verifiseringshastighet<\/td><td>~15.000\u201320.000 ops\/sek<\/td><td>~50.000 ops\/sek<\/td><td>~13.000 ops\/sek<\/td><\/tr><tr><td>N\u00f8kkelgenereringstid<\/td><td>~1 ms<\/td><td>~50\u2013100 ms<\/td><td>~250 ms<\/td><\/tr><tr><td>Deterministisk signering<\/td><td>Ja<\/td><td>Nei<\/td><td>Nei<\/td><\/tr><tr><td>Batch-verifisering<\/td><td>Ja<\/td><td>Nei<\/td><td>Nei<\/td><\/tr><tr><td>Standardisert<\/td><td>RFC 8032 (IETF, 2017)<\/td><td>PKCS#1 \/ RFC 8017<\/td><td>PKCS#1 \/ RFC 8017<\/td><\/tr><tr><td>Kvante-resistent<\/td><td>Nei<\/td><td>Nei<\/td><td>Nei<\/td><\/tr><tr><td>FIPS 140-godkjent<\/td><td>Nei<\/td><td>Ja<\/td><td>Ja<\/td><\/tr><tr><td>OpenSSH-st\u00f8tte siden<\/td><td>Versjon 6.5 (januar 2014)<\/td><td>Alltid st\u00f8ttet<\/td><td>Alltid st\u00f8ttet<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ytelsessammenligning-benchmark-tall\">Ytelsessammenligning: benchmark-tall<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ytelse er der Ed25519 skiller seg dramatisk fra RSA. Tallene fra <a href=\"https:\/\/libsodium.gitbook.io\/doc\/public-key_cryptography\/public-key_signatures\" rel=\"noopener noreferrer\" target=\"_blank\">libsodium<\/a> og uavhengige analyser (Goteleport, getacert.com) er konsistente:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Operasjon<\/th><th>Ed25519<\/th><th>RSA-2048<\/th><th>RSA-4096<\/th><th>Ed25519-fordel<\/th><\/tr><\/thead><tbody><tr><td>Signering (ops\/sek)<\/td><td>~50.000<\/td><td>~1.500<\/td><td>~200<\/td><td>33x raskere enn RSA-2048; 250x raskere enn RSA-4096<\/td><\/tr><tr><td>Verifisering (ops\/sek)<\/td><td>~15.000\u201320.000<\/td><td>~50.000<\/td><td>~13.000<\/td><td>RSA-2048 raskere p\u00e5 enkelt verifisering; men Ed25519 st\u00f8tter batch-verifisering<\/td><\/tr><tr><td>N\u00f8kkelgenerering<\/td><td>~1 ms<\/td><td>~50\u2013100 ms<\/td><td>~250 ms<\/td><td>50\u2013250x raskere<\/td><\/tr><tr><td>Signaturst\u00f8rrelse<\/td><td>64 byte<\/td><td>256 byte<\/td><td>512 byte<\/td><td>75 % kompaktere enn RSA-2048<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">En viktig nyanse: RSA <em>verifiserer<\/em> faktisk signaturer raskere enn det signerer. Det skyldes at RSA-verifisering bruker den offentlige eksponenten (typisk 65537), som er liten og rask \u00e5 beregne. RSA-signering bruker den store private eksponenten og er tilsvarende langsommere. Ed25519 er jevnt raskt p\u00e5 begge operasjoner, og med batch-verifisering, der mange signaturer kontrolleres samlet, sl\u00e5r det RSA-2048 selv p\u00e5 verifisering.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Et konkret serverscenario: en SSH-autentiseringstjeneste som h\u00e5ndterer 5.000 innlogginger per sekund under RSA-4096 bruker 25 sekunder bare p\u00e5 signering. Med Ed25519 tar den samme arbeidsmengden 0,1 sekunder. Under h\u00f8y belastning er dette synlig i CPU-utnyttelsesgrafer og direkte m\u00e5lbart i responstid.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"nokkelgenerering-i-praksis\">N\u00f8kkelgenerering i praksis<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Et enkelt shell-eksperiment illustrerer ytelsesforskjellen tydelig. \u00c5 kj\u00f8re <code>time ssh-keygen -t rsa -b 4096 -f \/tmp\/test_rsa -N \"\"<\/code> bruker typisk 200\u2013300 ms p\u00e5 moderne maskinvare. Den tilsvarende kommandoen med Ed25519 fullf\u00f8rer p\u00e5 under 2 ms. For containeriserte milj\u00f8er der hundrevis av ephemeral-instanser genererer n\u00f8kler ved oppstart, utgj\u00f8r dette en reell ytelsesforskjell i total oppstartstid.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"nokkelstorrelser-og-lagringsplass\">N\u00f8kkelst\u00f8rrelser og lagringsplass<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">En Ed25519-offentlig n\u00f8kkel i OpenSSH-format er rundt 68 tegn inkludert typeidentifikator og kommentar. En RSA-4096 offentlig n\u00f8kkel i samme format er over 700 tegn, mer enn ti ganger mer. Det h\u00f8res trivielt ut inntil du tenker p\u00e5 milj\u00f8er der n\u00f8kler lagres i databaser, kringkastes over nettverk, eller inkluderes i JWT-tokens og sertifikater.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En API-tjeneste som signerer \u00e9n million JWT-tokens per dag med RSA-4096 sender fire ganger mer data i signaturdelen sammenlignet med Ed25519. Over et \u00e5r med h\u00f8y belastning utgj\u00f8r det m\u00e5lbar b\u00e5ndbreddekostnad og lagring. For <a href=\"\/digitale-signaturer\/\">digitale signaturer<\/a> i kode-signering er kompaktheten direkte relevant: programvarepakker signert med Ed25519 har vesentlig mindre overhead i signaturfiler og manifester.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Debian, Fedora og Arch Linux har alle migrert viktige depot-signeringsn\u00f8kler til Ed25519 eller ECDSA de siste \u00e5rene, nettopp av disse grunnene. GitHub.com signerer alle commit-verifiseringsoperasjoner med Ed25519 for interne systemer der de kontrollerer begge ender av kommunikasjonen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"sikkerhetsniva-og-angrepsscenarioer\">Sikkerhetsniv\u00e5 og angrepsscenarioer<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Sikkerhetsniv\u00e5 m\u00e5les i bits og representerer den logaritmiske kostnaden ved \u00e5 bryte algoritmen med beste kjente angrep. 128-bit sikkerhet betyr at det krever rundt 2^128 operasjoner for \u00e5 kompromittere n\u00f8kkelen, noe som er praktisk umulig med klassisk databehandling i overskuelig fremtid.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">RSA-2048 gir bare ~112-bit effektiv sikkerhet, 16 bit under det gjeldende 128-bit-m\u00e5let. Det skyldes at algoritmene for faktorisering (som det generelle tallsil-sevet, GNFS) er mer effektive enn ren brute force. RSA-3072 er den minste RSA-varianten som gir ~128-bit sikkerhet. RSA-4096 gir trygg margin, men til en dramatisk ytelsesstraf som tabellene over viser.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ed25519 gir ~128-bit sikkerhet med bare 256-bit n\u00f8kler. Det er ingen kjente strukturelle angrep mot Curve25519 utover klassisk diskret logaritme-problemet, og kurven ble valgt delvis for \u00e5 unng\u00e5 de &#8220;twist&#8221;-angrep som rammer mange andre elliptiske kurver i d\u00e5rlige implementasjoner. Den deterministiske signeringsprosessen eliminerer i tillegg en hel klasse angrep basert p\u00e5 nonce-misbruk.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"kjente-angrep-og-historiske-hendelser\">Kjente angrep og historiske hendelser<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">RSA har en rekke dokumenterte angrepsscenarioer utover ren faktorisering:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Bleichenbacher-angrepet (1998):<\/strong> Padding-oracle-angrep mot RSA PKCS#1 v1.5 som fremdeles dukker opp i sikkerhetsrapporter mot eldre systemer.<\/li><li><strong>ROBOT-angrepet (2017):<\/strong> En variant av Bleichenbacher-angrepet som rammet 27 av verdens 100 st\u00f8rste HTTPS-domener, inkludert Facebook og PayPal. Angriperne kunne dekryptere TLS-trafikk uten \u00e5 kjenne den private n\u00f8kkelen.<\/li><li><strong>Svake RSA-n\u00f8kler (2012):<\/strong> Forskning fra UC San Diego fant at 0,2 % av alle offentlige RSA-n\u00f8kler p\u00e5 internett delte et primtall med en annen n\u00f8kkel, noe som kompromitterte begge n\u00f8klene momentant.<\/li><li><strong>PlayStation 3 \/ Sony (2010):<\/strong> Sony brukte konstant nonce i ECDSA-signering av spillkonsollen sin, noe som tillot hackere \u00e5 beregne den private signeringsn\u00f8kkelen. Ed25519 umuliggj\u00f8r denne angrepsvektoren strukturelt.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Ed25519 har ingen offentlig dokumenterte praktiske kompromitteringer. De teoretiske angrepene er bundet til \u00e5 bryte diskret logaritme over Curve25519, noe som i praksis krever kvantedatamaskiner med Shors algoritme.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"signaturstorrelse-og-nettverkspavirkning\">Signaturst\u00f8rrelse og nettverksp\u00e5virkning<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">En Ed25519-signatur er n\u00f8yaktig <strong>64 byte<\/strong>. En RSA-2048-signatur er <strong>256 byte<\/strong>, fire ganger st\u00f8rre. En RSA-4096-signatur er <strong>512 byte<\/strong>, \u00e5tte ganger st\u00f8rre. Disse tallene er ikke optimaliserbare fordi signaturen er matematisk knyttet til n\u00f8kkelst\u00f8rrelsen i RSA.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">I et typisk TLS 1.3-h\u00e5ndtrykk sendes sertifikater og signaturer frem og tilbake mellom klient og server. Kompaktere signaturer reduserer antall TCP-pakker som trengs for \u00e5 fullf\u00f8re h\u00e5ndtrykket. Akamai og Cloudflare har dokumentert at overgang til ECDSA\/Ed25519-sertifikater reduserer TLS-h\u00e5ndtrykkstid med 10\u201320 % under belastning, fordi f\u00e6rre pakker betyr mindre risiko for pakkefragmentering og RTT-forsinkelse.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For API-er som inkluderer JWT-tokens i HTTP-hoder betyr signaturst\u00f8rrelsen direkte payload-overhead. En RSA-4096-signert JWT har en base64url-kodet signaturdel p\u00e5 rundt 683 tegn. En Ed25519-signert JWT har 86 tegn. Over millioner av API-kall er dette reell nettverkslast og en ytelsesparameter som kan hjelpe deg med \u00e5 holde API-svar under CDN-terskelgrenser.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ssh-nokler-i-2026-praktisk-veiledning\">SSH-n\u00f8kler i 2026: praktisk veiledning<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">SSH er det vanligste stedet utviklere m\u00f8ter valget mellom Ed25519 og RSA. V\u00e5r guide om <a href=\"\/ssh-nokkel-linux\/\">SSH-n\u00f8kler i Linux<\/a> dekker hele genereringsprosessen, men det korte svaret er: generer Ed25519 med mindre du har et dokumentert krav om RSA.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Ed25519 SSH-n\u00f8kkel (anbefalt for alle nye n\u00f8kler i 2026)\nssh-keygen -t ed25519 -C \"bruker@domene.no\"\n\n# RSA-4096 SSH-n\u00f8kkel (bare ved behov for gammel kompatibilitet)\nssh-keygen -t rsa -b 4096 -C \"bruker@domene.no\"\n\n# Kontroller n\u00f8kkeltype og fingeravtrykk\nssh-keygen -l -f ~\/.ssh\/id_ed25519.pub\n# Output: 256 SHA256:abc123... bruker@domene.no (ED25519)\n\nssh-keygen -l -f ~\/.ssh\/id_rsa.pub\n# Output: 4096 SHA256:xyz789... bruker@domene.no (RSA)\n\n# Legg n\u00f8kkel til SSH-agent\nssh-add ~\/.ssh\/id_ed25519<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">GitHub, GitLab, Bitbucket, SourceHut og alle store VCS-leverand\u00f8rer st\u00f8tter Ed25519 SSH-n\u00f8kler fullt ut. Den eneste situasjonen der RSA fortsatt er n\u00f8dvendig for SSH er tilkobling til meget gamle SSH-servere (OpenSSH f\u00f8r versjon 6.5, utgitt januar 2014) eller lukkede systemer som nettverksenheter fra tidlig 2010-tall med fastvare som ikke er oppdatert.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"sikker-ssh-server-konfigurasjon-med-ed25519\">Sikker SSH-server-konfigurasjon med Ed25519<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/ssh\/sshd_config - moderne algoritmevalg for Ubuntu 22.04 \/ Debian 12+\nHostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256\nPubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256\n\n# Deaktiver eldre og svake algoritmer\nKexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512\nMACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com\n\n# Sjekk at Ed25519-vertsn\u00f8kkel eksisterer\nls -la \/etc\/ssh\/ssh_host_ed25519_key\n\n# Regenerer Ed25519-vertsn\u00f8kkel om den mangler\nssh-keygen -t ed25519 -f \/etc\/ssh\/ssh_host_ed25519_key -N \"\"\nsystemctl restart sshd<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"bruksomrader-tls-kode-signering-og-meldingsapper\">Bruksomr\u00e5der: TLS, kode-signering og meldingsapper<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"tls-sertifikater\">TLS-sertifikater<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Let&#8217;s Encrypt st\u00f8tter EC-n\u00f8kler (P-256 og P-384, som er n\u00e6r Ed25519 i konsept). Ed25519-sertifikater er teknisk mulig i TLS 1.3, men nettleserst\u00f8tten er mer begrenset enn ECDSA P-256. For de fleste norske webapplikasjoner i 2026 er ECDSA P-256 det mest kompatible valget for offentlige nettsteder. For server-til-server-kommunikasjon der du kontrollerer begge ender, fungerer Ed25519 utmerket. V\u00e5r guide om <a href=\"\/https-tls-13-nodejs\/\">HTTPS og TLS 1.3 i Node.js<\/a> viser konkret implementasjon.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">RSA-sertifikater er fremdeles standard i mange bedriftssystemer. Eldre load-balancere, HSM-er (Hardware Security Modules) og PKI-infrastruktur fra tidlig 2010-tallet st\u00f8tter typisk ikke elliptiske kurver. I slike milj\u00f8er er RSA-2048 eller RSA-4096 den eneste veien fremover inntil maskinvaren skiftes ut.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"kode-signering\">Kode-signering<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Linux-pakkearkiver bruker GPG-signaturer for \u00e5 verifisere pakkeintegritet. GPG st\u00f8tter Ed25519 fra versjon 2.1. Debian, Fedora og Arch Linux har alle migrert viktige repo-signeringsn\u00f8kler til Ed25519. For Microsoft Authenticode (Windows kode-signering) kreves RSA eller ECDSA med sertifikater fra akkrediterte CA-er. Ed25519 er per juni 2026 ikke st\u00f8ttet der.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"meldingsapplikasjoner\">Meldingsapplikasjoner<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Signal-protokollen bruker XEdDSA og VXEdDSA, begge varianter av Ed25519, for meldingsautentisering. <a href=\"https:\/\/signal.org\/docs\/specifications\/xeddsa\/\" rel=\"noopener noreferrer\" target=\"_blank\">Signals protokolldokumentasjon<\/a> forklarer at de valgte Ed25519-familien for kombinasjonen av ytelse, kompakthet og deterministisk signering. WhatsApp bruker den samme protokollen. WireGuard VPN bruker Curve25519, den underliggende kurven for Ed25519, til Diffie-Hellman n\u00f8kkelutveksling.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"kvantecomputing-ingen-av-dem-er-kvante-sikre\">Kvantecomputing: ingen av dem er kvante-sikre<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">En viktig misforst\u00e5else: Ed25519 er <strong>ikke<\/strong> kvante-resistent. RSA er heller ikke kvante-resistent. Shors algoritme, som krever en tilstrekkelig stor kvantedatamaskin med nok stabile qubits, bryter begge algoritmene effektivt. Diskret logaritme over elliptiske kurver og heltallsfaktorisering er begge s\u00e5rbare for kvanteberegning.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">NIST publiserte i august 2024 de f\u00f8rste post-kvantestandard-algoritmene: <strong>ML-KEM<\/strong> (basert p\u00e5 CRYSTALS-Kyber for n\u00f8kkelinnkapsling) og <strong>ML-DSA<\/strong> (basert p\u00e5 CRYSTALS-Dilithium for digitale signaturer). <a href=\"https:\/\/csrc.nist.gov\/projects\/post-quantum-cryptography\" rel=\"noopener noreferrer\" target=\"_blank\">NISTSs post-kvante kryptografi-prosjekt<\/a> inneholder full dokumentasjon og implementasjonsressurser. Disse bygger p\u00e5 gittersystemer og er designet for \u00e5 motst\u00e5 Shors algoritme.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Det betyr at hverken Ed25519 eller RSA er den langsiktige l\u00f8sningen i en post-kvantetid. Men overgangen til post-kvantealgoritmer er gradvis og tar \u00e5r med standardisering, implementasjon i biblioteker og protokoller, og distribusjon i produksjonsmilj\u00f8er. Googles Chrome st\u00f8tter hybride post-kvante TLS-n\u00f8kkelutveksling (X25519Kyber768) fra versjon 116 (2023). Cloudflare implementerte det p\u00e5 sine servere i 2024. Ed25519 forblir relevant og anbefalt for klassisk kryptografi gjennom hele denne overgangsperioden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"plattformstotte-og-implementering\">Plattformst\u00f8tte og implementering<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ed25519 har bred st\u00f8tte i moderne programvare, men er ikke universelt tilgjengelig i eldre systemer. RSA er derimot tilgjengelig overalt.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Plattform \/ Bibliotek<\/th><th>Ed25519-st\u00f8tte<\/th><th>RSA-st\u00f8tte<\/th><th>Merknad<\/th><\/tr><\/thead><tbody><tr><td>OpenSSL 1.1.1+<\/td><td>Ja<\/td><td>Ja<\/td><td>Ed25519 lagt til i versjon 1.1.1 (2018)<\/td><\/tr><tr><td>OpenSSH 6.5+<\/td><td>Ja<\/td><td>Ja<\/td><td>Ed25519 integrert januar 2014<\/td><\/tr><tr><td>libsodium<\/td><td>Ja (prim\u00e6r)<\/td><td>Nei<\/td><td>Bygget rundt Bernstein-primitiver<\/td><\/tr><tr><td>Node.js (crypto)<\/td><td>Ja<\/td><td>Ja<\/td><td>Ed25519 via crypto.sign() fra Node.js 12+<\/td><\/tr><tr><td>Python (cryptography)<\/td><td>Ja<\/td><td>Ja<\/td><td>Ed25519PrivateKey og Ed25519PublicKey klasser<\/td><\/tr><tr><td>Go (stdlib)<\/td><td>Ja<\/td><td>Ja<\/td><td>crypto\/ed25519 i standardbiblioteket siden Go 1.13<\/td><\/tr><tr><td>Java (JDK 15+)<\/td><td>Ja<\/td><td>Ja<\/td><td>JEP 339 introduserte Ed25519 og Ed448<\/td><\/tr><tr><td>Rust (ed25519-dalek)<\/td><td>Ja<\/td><td>Ja (rsa crate)<\/td><td>ed25519-dalek er den anbefalte Rust-implementasjonen<\/td><\/tr><tr><td>GnuPG 2.1+<\/td><td>Ja<\/td><td>Ja<\/td><td>Ed25519 for signering og autentisering, Cv25519 for kryptering<\/td><\/tr><tr><td>Windows CNG<\/td><td>Ja (Windows 10 v1803+)<\/td><td>Ja<\/td><td>BCryptSignHash st\u00f8tter Ed25519<\/td><\/tr><tr><td>iOS \/ macOS (CryptoKit)<\/td><td>Ja<\/td><td>Ja<\/td><td>Curve25519.Signing.PrivateKey i Swift<\/td><\/tr><tr><td>Android (BouncyCastle)<\/td><td>Ja<\/td><td>Ja<\/td><td>St\u00f8ttet siden Android 6.0<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Viktig unntak: eldre FIPS 140-2 sertifiserte HSM-moduler og kryptografiske biblioteker fra f\u00f8r 2018 mangler ofte Ed25519-st\u00f8tte. Norske offentlige virksomheter og finansinstitusjoner med krav til FIPS-validerte kryptografiske moduler b\u00f8r verifisere konkret med maskinvareleverand\u00f8ren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"implementering-i-node-js-python-og-go\">Implementering i Node.js, Python og Go<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">\u00c5 signere og verifisere med Ed25519 i moderne programmeringsspr\u00e5k er rett frem. Her er praktiske eksempler i de tre vanligste spr\u00e5kene for back-end-utvikling.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"node-js-crypto-modul-innebygd-fra-versjon-12\">Node.js (crypto-modul, innebygd fra versjon 12+)<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>const { generateKeyPairSync, sign, verify, createPrivateKey } = require('crypto');\n\n\/\/ Generer Ed25519-n\u00f8kkelpar\nconst { privateKey, publicKey } = generateKeyPairSync('ed25519', {\n  privateKeyEncoding: { type: 'pkcs8', format: 'pem' },\n  publicKeyEncoding: { type: 'spki', format: 'pem' }\n});\n\nconst melding = Buffer.from('Viktig melding som skal signeres');\n\n\/\/ Signer meldingen\nconst signatur = sign(null, melding, privateKey);\nconsole.log('Signatur (hex):', signatur.toString('hex'));\nconsole.log('Signaturs\u00f8rrelse:', signatur.length, 'bytes'); \/\/ Alltid 64 bytes\n\n\/\/ Verifiser signaturen\nconst gyldig = verify(null, melding, publicKey, signatur);\nconsole.log('Signatur gyldig:', gyldig); \/\/ true\n\n\/\/ Sammenligning: RSA-4096 ville gitt 512-byte signatur her<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"python-cryptography-biblioteket\">Python (cryptography-biblioteket)<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code\">from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey\nfrom cryptography.hazmat.primitives.serialization import (\n    Encoding, PublicFormat, PrivateFormat, NoEncryption\n)\n\n# Generer n\u00f8kkelpar\nprivat_nokkel = Ed25519PrivateKey.generate()\noffentlig_nokkel = privat_nokkel.public_key()\n\n# Serialiser n\u00f8kler\nprivat_pem = privat_nokkel.private_bytes(Encoding.PEM, PrivateFormat.PKCS8, NoEncryption())\noffentlig_pem = offentlig_nokkel.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)\n\nmelding = b\"Viktig melding som skal signeres\"\n\n# Signer - ingen hash-parameter, Ed25519 h\u00e5ndterer dette internt\nsignatur = privat_nokkel.sign(melding)\nprint(f\"Signaturst\u00f8rrelse: {len(signatur)} bytes\")  # 64 bytes\n\n# Verifiser - kaster InvalidSignature ved feil\ntry:\n    offentlig_nokkel.verify(signatur, melding)\n    print(\"Signatur gyldig\")\nexcept Exception as e:\n    print(f\"Ugyldig signatur: {e}\")<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"go-standardbiblioteket-crypto-ed25519\">Go (standardbiblioteket, crypto\/ed25519)<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code\">package main\n\nimport (\n    \"crypto\/ed25519\"\n    \"crypto\/rand\"\n    \"fmt\"\n)\n\nfunc main() {\n    \/\/ Generer n\u00f8kkelpar\n    offentligNokkel, privatNokkel, err := ed25519.GenerateKey(rand.Reader)\n    if err != nil {\n        panic(err)\n    }\n\n    melding := []byte(\"Viktig melding som skal signeres\")\n\n    \/\/ Signer meldingen\n    signatur := ed25519.Sign(privatNokkel, melding)\n    fmt.Printf(\"Signaturst\u00f8rrelse: %d bytes\\n\", len(signatur)) \/\/ 64 bytes\n\n    \/\/ Verifiser signaturen\n    gyldig := ed25519.Verify(offentligNokkel, melding, signatur)\n    fmt.Printf(\"Signatur gyldig: %v\\n\", gyldig) \/\/ true\n}<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Legg merke til at Ed25519-implementasjoner i alle disse spr\u00e5kene <strong>ikke tar noen hash-parameter<\/strong>. RSA og ECDSA krever at du spesifiserer hash-algoritmen eksplisitt (SHA-256, SHA-384 osv.). Ed25519 h\u00e5ndterer hashing internt som en del av signeringsalgoritmen via to-passers SHA-512, noe som eliminerer enda en konfigurasjonsfeil-klasse.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"jwt-tokens-med-eddsa-vs-rs256\">JWT-tokens med EdDSA vs RS256<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">JSON Web Tokens (JWT) er en av de vanligste brukene for asymmetrisk kryptografi i moderne webapplikasjoner. JWS-standarden (RFC 7515) definerer EdDSA-algoritmen for Ed25519-signaturer. Algoritmen heter <code>EdDSA<\/code> i JWT-headeren, i motsetning til <code>RS256<\/code> (RSA-2048 med SHA-256), <code>RS384<\/code>, og <code>RS512<\/code> for RSA-varianter.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Den praktiske fordelen i JWT-sammenheng er signaturst\u00f8rrelsen. En EdDSA-signert JWT-signatur er 86 tegn i base64url-format. En RS256-signatur er 342 tegn. En RS512-signatur (RSA-4096) er 683 tegn. I tjenester med h\u00f8y API-trafikk summerer disse byte seg til merkbar b\u00e5ndbredde og payload-st\u00f8rrelse over HTTP-hoder.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code\">\/\/ Node.js: JWT med Ed25519 via jose-biblioteket\nconst { SignJWT, importPKCS8, importSPKI } = require('jose');\nconst { generateKeyPairSync } = require('crypto');\n\n\/\/ Generer Ed25519-n\u00f8kkelpar for JWT-signering\nconst { privateKey: privPem, publicKey: pubPem } = generateKeyPairSync('ed25519', {\n  privateKeyEncoding: { type: 'pkcs8', format: 'pem' },\n  publicKeyEncoding: { type: 'spki', format: 'pem' }\n});\n\nasync function lagJWT(brukerID) {\n  const privNokkel = await importPKCS8(privPem, 'EdDSA');\n\n  const token = await new SignJWT({ sub: brukerID, rolle: 'admin' })\n    .setProtectedHeader({ alg: 'EdDSA' })\n    .setIssuedAt()\n    .setExpirationTime('2h')\n    .sign(privNokkel);\n\n  console.log('JWT-lengde (EdDSA):', token.length);\n  \/\/ Signifikant kortere enn tilsvarende RS256-token\n  return token;\n}\n\nlagJWT('bruker-123').then(console.log);<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">V\u00e6r oppmerksom p\u00e5 at JOSE-biblioteker (JavaScript Object Signing and Encryption) har varierende st\u00f8tte for EdDSA. Bibliotekene <code>jose<\/code>, <code>jsonwebtoken<\/code> (fra versjon 9.0+) og <code>node-jose<\/code> st\u00f8tter det alle. Sjekk alltid bibliotekversjonen din eksplisitt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"migreringsguide-fra-rsa-til-ed25519\">Migreringsguide: fra RSA til Ed25519<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Migrasjon til Ed25519 er rett frem for SSH-n\u00f8kler og mer planintensiv for X.509-sertifikater i PKI-infrastruktur. Her er en praktisk trinn-for-trinn-plan.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ssh-nokkelmigrasjon-enkeltbruker\">SSH-n\u00f8kkelmigrasjon (enkeltbruker)<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code># Steg 1: Generer ny Ed25519-n\u00f8kkel\nssh-keygen -t ed25519 -C \"bruker@domene.no\" -f ~\/.ssh\/id_ed25519\n\n# Steg 2: Kopier ny offentlig n\u00f8kkel til alle servere\nssh-copy-id -i ~\/.ssh\/id_ed25519.pub bruker@server1.no\nssh-copy-id -i ~\/.ssh\/id_ed25519.pub bruker@server2.no\n\n# Steg 3: Test at ny n\u00f8kkel fungerer\nssh -i ~\/.ssh\/id_ed25519 bruker@server1.no \"echo OK\"\n\n# Steg 4: Legg til i SSH-agent\neval $(ssh-agent -s)\nssh-add ~\/.ssh\/id_ed25519\n\n# Steg 5: Oppdater GitHub \/ GitLab med ny offentlig n\u00f8kkel\ncat ~\/.ssh\/id_ed25519.pub\n# Kopier output og lim inn under Account Settings > SSH Keys\n\n# Steg 6: Fjern RSA-n\u00f8kkel fra authorized_keys etter verifisering\n# Logg inn og rediger ~\/.ssh\/authorized_keys\n# Fjern linjer som starter med \"ssh-rsa\"<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"migrasjonsinventar-for-servere-med-mange-brukere\">Migrasjonsinventar for servere med mange brukere<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code\">#!\/bin\/bash\n# Kartlegg hvilke brukere som har RSA vs Ed25519-n\u00f8kler\n\necho \"Bruker | RSA-n\u00f8kler | Ed25519-n\u00f8kler\"\necho \"-------|------------|---------------\"\n\nfor bruker_hjem in \/home\/*; do\n  auth_keys=\"$bruker_hjem\/.ssh\/authorized_keys\"\n  if [ -f \"$auth_keys\" ]; then\n    rsa_count=$(grep -c \"^ssh-rsa\" \"$auth_keys\" 2>\/dev\/null || echo 0)\n    ed_count=$(grep -c \"^ssh-ed25519\" \"$auth_keys\" 2>\/dev\/null || echo 0)\n    bruker=$(basename \"$bruker_hjem\")\n    echo \"$bruker | $rsa_count | $ed_count\"\n  fi\ndone<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Bruk utdata til \u00e5 lage en migreringsplan. Identifiser brukere med bare RSA-n\u00f8kler og kommuniser en migreringsdeadline. Sett gjerne en sshd_config-regel som krever Ed25519 etter en dato, og sett RSA som advarsel i en overgangsfase.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"nokkeldistribusjon-og-sertifikathandtering\">N\u00f8kkeldistribusjon og sertifikath\u00e5ndtering<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Et ofte oversett aspekt ved algoritmevalget er n\u00f8kkeldistribusjon og livssyklusadministrasjon. Ed25519 og RSA oppf\u00f8rer seg noe ulikt her.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For SSH-n\u00f8kler er distribusjon enkel: du kopierer offentlig n\u00f8kkel til <code>~\/.ssh\/authorized_keys<\/code> p\u00e5 servere, enten manuelt eller via verkt\u00f8y som <code>ssh-copy-id<\/code>, Ansible, Puppet eller Terraform. Ed25519 offentlige n\u00f8kler er kortere (rundt 68 tegn i OpenSSH-format), noe som gj\u00f8r dem lettere \u00e5 h\u00e5ndtere i konfigurasjonsfiler, Ansible-playbooks og YAML-manifest.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For X.509-sertifikater er bildet mer komplekst. RSA-sertifikater er det universelle formatet st\u00f8ttet av alle CA-er, PKI-systemer og TLS-klienter. Ed25519-sertifikater krever at <em>alle<\/em> ledd i kjeden, inkludert rot-CA, mellomliggende CA og sluttentitetssertifikat, bruker kompatibel kryptografi. Let&#8217;s Encrypt st\u00f8tter EC-n\u00f8kler (P-256 og P-384), men Ed25519-sertifikater er mindre utbredt i offentlig tilgjengelige CA-er per 2026.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">N\u00f8kkelrotasjon er viktig uavhengig av algoritme. Anbefalte intervaller:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>SSH-autentiseringsn\u00f8kler:<\/strong> Ruter hvert 1\u20132 \u00e5r, eller umiddelbart ved mistanke om kompromittering. Bruk SSH-sertifikater (via OpenSSH CA) for sentralisert rotasjon i store milj\u00f8er.<\/li><li><strong>TLS-sertifikater:<\/strong> Let&#8217;s Encrypt fornyer automatisk hvert 60\u201390 dager. Manuelle sertifikater anbefales fornyet hvert \u00e5r. Let&#8217;s Encrypt ACME med <code>certbot<\/code> er den anbefalte tiln\u00e6rmingen for de fleste norske virksomheter.<\/li><li><strong>GPG-signeringsn\u00f8kler:<\/strong> Prim\u00e6rn\u00f8kkelen kan leve lenge, men autentiserings- og signeringsundern\u00f8kler b\u00f8r roteres hvert 1\u20132 \u00e5r.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Ed25519 forenkler n\u00f8kkelrotasjon i store SSH-milj\u00f8er fordi kortere offentlige n\u00f8kler er lettere \u00e5 distribuere og validere i skript og konfigurasjonsh\u00e5ndteringssystemer. Et Ansible-playbook som distribuerer 500 Ed25519 offentlige n\u00f8kler er vesentlig lettere \u00e5 lese og vedlikeholde enn ett som distribuerer RSA-4096-n\u00f8kler over tre linjer med base64.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ytelsestesting-pa-norsk-serverinfrastruktur\">Ytelsestesting p\u00e5 norsk serverinfrastruktur<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ytelsesforskjellen er teoretisk dokumentert, men den er ogs\u00e5 praktisk synlig p\u00e5 norsk serverinfrastruktur. Her er et eksempel p\u00e5 enkel benchmarking du kan kj\u00f8re p\u00e5 din egen server for \u00e5 sammenligne algoritmene direkte.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code\"># OpenSSL speed test: sammenlign Ed25519 mot RSA\n# Kj\u00f8r dette p\u00e5 din server for \u00e5 se faktiske tall\n\n# Ed25519 ytelse\nopenssl speed ed25519\n\n# RSA ytelse (2048 og 4096)\nopenssl speed rsa2048\nopenssl speed rsa4096\n\n# Typisk output (p\u00e5 moderne x86-64-server):\n# Ed25519:\n#   sign   15us, verify   47us (ca. 66.000 sign\/sek, 21.000 verify\/sek)\n#\n# RSA-2048:\n#   sign  631us, verify  18us  (ca. 1.585 sign\/sek, 55.000 verify\/sek)\n#\n# RSA-4096:\n#   sign 4698us, verify  61us  (ca. 213 sign\/sek, 16.000 verify\/sek)\n\n# N\u00f8kkelgenerering:\ntime openssl genpkey -algorithm ed25519 -out \/tmp\/ed25519.pem\ntime openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out \/tmp\/rsa4096.pem\n\n# Typisk output:\n# ed25519: 0.001s\n# rsa4096: 0.250\u20130.800s (varierer med tilfeldighetspool)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Disse tallene fra OpenSSL-benchmarking bekrefter bildet fra libsodium-dokumentasjonen: Ed25519-signering er rundt 33 ganger raskere enn RSA-2048 og over 200 ganger raskere enn RSA-4096. RSA-2048 verifiserer signaturer raskere enn Ed25519 i enkelt-verifiseringsscenarioer, men dette jevnes ut med batch-verifisering.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For norske skyinstanser (AWS eu-north-1 Stockholm, Azure Norway East i Oslo, eller Google Cloud europe-north1 i Finland) er tallene sammenlignbare med ovenst\u00e5ende siden de er prosessoravhengige, ikke nettverksavhengige. Krypto-akselerasjon via AVX2\/AVX-512-instruksjoner i moderne Intel- og AMD-prosessorer gir Ed25519 ytterligere fordel da biblioteker som libsodium er optimalisert for disse instruksjonssettene.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ekspertmeninger-og-bransjeperspektiver\">Ekspertmeninger og bransjeperspektiver<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Daniel J. Bernstein, skaperen av Curve25519 og Ed25519, har i akademiske publikasjoner argumentert konsekvent for at kryptografiske primitiver b\u00f8r designes for \u00e5 motst\u00e5 implementasjonsfeil, ikke bare matematiske angrep. I sitt arbeid med EdDSA peker han p\u00e5 at ECDSA-implementasjoner historisk har blitt kompromittert gjentatte ganger p\u00e5 grunn av svake tilfeldighetskilder, og at deterministisk signering fjerner hele den angrepsklassen. Hans designfilosofi, kjent i kryptografimilj\u00f8et som &#8220;misuse resistance&#8221;, er en direkte konsekvens av \u00e5 ha observert RSA og ECDSA-feil i produksjon i ti\u00e5r.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">ThePrimeagen, som har bred innflytelse blant systemutviklere med fokus p\u00e5 ytelse og Rust-programmering, har i innhold om moderne SSH-oppsett trukket frem ed25519-dalek som et eksempel p\u00e5 kryptografi gjort riktig: minimal kodebase, konstant-tid-implementasjon, og uten de historiske svakhetene i RSA-implementasjoner. For ytelsesorienterte utviklere er argumentet om 33x raskere signering alene overbevisende.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Fireship, med over 3,5 millioner YouTube-abonnenter og en direkte tiln\u00e6rming til utviklerveiledninger, har i SSH-konfigurasjonsvideo anbefalt Ed25519 som standardvalget for alle nye n\u00f8kler. Argumentet er n\u00f8kternt: Ed25519 er raskere, n\u00f8klene er kortere, og du gir slipp p\u00e5 kompatibilitet med SSH-servere fra 2013 som uansett trenger \u00e5 oppdateres. For et norsk publikum som bruker GitHub, GitLab eller Bitbucket er det allerede ingen praktisk grunn til \u00e5 velge RSA for SSH.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bruce Schneier, en av de mest siterte kryptosikkerhetsekspertene globalt, har i skrifter om kryptografisk agilitet p\u00e5pekt at enkle primitiver med klare sikkerhetsbevis er \u00e5 foretrekke fremfor komplekse systemer med mange konfigurasjonsmuligheter der feil valg svekker sikkerheten drastisk. RSA har mange slike konfigurasjonsparametre: n\u00f8kkelst\u00f8rrelse, padding-skjema (PKCS#1 v1.5 vs OAEP vs PSS), hash-algoritme, og ikke minst PRNG-kvalitet. Ed25519 fjerner de fleste av disse variablene.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"anbefalinger-for-ulike-brukstilfeller\">Anbefalinger for ulike brukstilfeller<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Her er direkte anbefalinger fordelt p\u00e5 scenario. Velg algoritme basert p\u00e5 faktiske krav, ikke vane eller det som var standard i 2015.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Brukstilfelle<\/th><th>Anbefalt algoritme<\/th><th>Begrunnelse<\/th><\/tr><\/thead><tbody><tr><td>Nye SSH-n\u00f8kler (personlig)<\/td><td><strong>Ed25519<\/strong><\/td><td>Raskere, kortere n\u00f8kkel, 128-bit sikkerhet. St\u00f8ttet av alle moderne servere.<\/td><\/tr><tr><td>Nye SSH-n\u00f8kler (bedrift, moderne infrastruktur)<\/td><td><strong>Ed25519<\/strong><\/td><td>Identisk med personlig bruk. Kun RSA om eldre nettverksenheter krever det.<\/td><\/tr><tr><td>CI\/CD-systemer (GitHub Actions, CircleCI)<\/td><td><strong>Ed25519<\/strong><\/td><td>1 ms n\u00f8kkelgenerering vs 250 ms for RSA-4096, merkbart i container-bootstrap.<\/td><\/tr><tr><td>TLS-sertifikater (offentlig webserver)<\/td><td><strong>ECDSA P-256<\/strong><\/td><td>Best nettleserst\u00f8tte i 2026. Ed25519 for server-til-server er OK.<\/td><\/tr><tr><td>TLS-sertifikater (eldre enterprise PKI)<\/td><td><strong>RSA-2048 minimum, RSA-4096 foretrukket<\/strong><\/td><td>HSM- og compliance-krav tvinger RSA i mange bedriftsinfrastrukturer.<\/td><\/tr><tr><td>GPG\/PGP-n\u00f8kkel<\/td><td><strong>Ed25519 + Cv25519<\/strong><\/td><td>GnuPG 2.1+ anbefaler dette som standardoppsett for signering og kryptering.<\/td><\/tr><tr><td>Kode-signering (Linux-pakker)<\/td><td><strong>Ed25519<\/strong><\/td><td>Debian, Arch og Fedora bruker dette.<\/td><\/tr><tr><td>Kode-signering (Windows Authenticode)<\/td><td><strong>RSA-2048 \/ ECDSA P-256<\/strong><\/td><td>Ed25519 st\u00f8ttes ikke av Microsoft CA-er per juni 2026.<\/td><\/tr><tr><td>JWT-tokens (server-til-server API)<\/td><td><strong>Ed25519 (EdDSA algoritme)<\/strong><\/td><td>86 tegn signatur i base64url vs 683 tegn for RSA-4096. Reell b\u00e5ndbreddebesparelse.<\/td><\/tr><tr><td>FIPS 140-2\/3-regulerte systemer<\/td><td><strong>RSA-3072 eller ECDSA P-384<\/strong><\/td><td>Ed25519 er ikke i FIPS-godkjent algoritme-settet.<\/td><\/tr><tr><td>Post-kvante fremtidssikring<\/td><td><strong>ML-DSA (CRYSTALS-Dilithium)<\/strong><\/td><td>Hverken Ed25519 eller RSA er kvante-resistente. Begynn planlegging av hybrid implementasjon.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fordeler-og-ulemper\">Fordeler og ulemper<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ed25519\">Ed25519<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Fordeler<\/th><th>Ulemper<\/th><\/tr><\/thead><tbody><tr><td>~50.000 signaturer per sekund<\/td><td>Ikke FIPS 140-godkjent<\/td><\/tr><tr><td>128-bit sikkerhet med 256-bit n\u00f8kkel<\/td><td>Ikke st\u00f8ttet p\u00e5 SSH-servere fra f\u00f8r 2014<\/td><\/tr><tr><td>64-byte signaturer (sv\u00e6rt kompakte)<\/td><td>Ikke st\u00f8ttet for Windows Authenticode kode-signering<\/td><\/tr><tr><td>Deterministisk signering (ingen nonce-angrep)<\/td><td>Ikke standard i Java f\u00f8r JDK 15<\/td><\/tr><tr><td>N\u00f8kkelgenerering p\u00e5 ~1 ms<\/td><td>Begrenset st\u00f8tte i eldre HSM-maskinvare<\/td><\/tr><tr><td>Konstant-tid-implementasjon (sidekanal-resistent)<\/td><td>Ikke kvante-resistent<\/td><\/tr><tr><td>St\u00f8ttet av Signal, WireGuard, GitHub, GitLab<\/td><td><\/td><\/tr><tr><td>Batch-verifisering mulig<\/td><td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"rsa\">RSA<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Fordeler<\/th><th>Ulemper<\/th><\/tr><\/thead><tbody><tr><td>Universell kompatibilitet (alle systemer)<\/td><td>RSA-2048 gir bare ~112-bit sikkerhet<\/td><\/tr><tr><td>FIPS 140-2\/3 godkjent<\/td><td>RSA-4096 er ~250x tregere enn Ed25519 p\u00e5 signering<\/td><\/tr><tr><td>St\u00f8ttet i Windows Authenticode<\/td><td>Store n\u00f8kler og signaturer (512 byte for RSA-4096)<\/td><\/tr><tr><td>Bredt st\u00f8ttet i PKI og X.509-infrastruktur<\/td><td>Historisk s\u00e5rbar for padding-oracle-angrep (Bleichenbacher, ROBOT)<\/td><\/tr><tr><td>Bred HSM-st\u00f8tte, inkludert eldre modeller<\/td><td>Krever sterk tilfeldighet for sikker signering<\/td><\/tr><tr><td>RSA-verifisering er rask<\/td><td>Ikke kvante-resistent<\/td><\/tr><tr><td><\/td><td>N\u00f8kkelst\u00f8rrelse m\u00e5 \u00f8kes over tid etter hvert som beregningskraft vokser<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"konklusjonen-hvilket-valg-gir-data-grunnlag-for\">Konklusjonen: hvilket valg gir data grunnlag for?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Dataene peker entydig i \u00e9n retning: for alle nye implementasjoner der kompatibilitetskrav ikke tvinger RSA, er <strong>Ed25519 det riktige valget i 2026<\/strong>. Den er 33 ganger raskere enn RSA-2048 p\u00e5 signering, produserer signaturer som er 75 % kompaktere, genererer n\u00f8kler 250 ganger raskere, og eliminerer en hel angrepsklasse gjennom deterministisk design.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">RSA er ikke \u00f8yeblikkelig farlig i RSA-2048 eller RSA-4096-format. Det er fremdeles akseptabelt for FIPS-regulerte milj\u00f8er, Windows Authenticode, og eldre systemer du ikke kan oppgradere. Men det er ikke det du installerer i et nytt system i 2026 uten god grunn.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Den viktigste presiseringen: hverken Ed25519 eller RSA er fremtidssikret mot kvantedatamaskiner. Begge vil til slutt erstattes av post-kvante standarder som ML-DSA. I overgangsfasen er Ed25519 det beste klassiske valget, prim\u00e6rt fordi det er enklere \u00e5 implementere korrekt, gir bedre ytelse, og bringer f\u00e6rre historiske angrepsflater med seg inn i nye systemer. Start planleggingen av hybride post-kvante l\u00f8sninger n\u00e5, men bruk Ed25519 for all klassisk kryptografi frem til de standardene er bredt distribuert i alle protokoller og plattformer du st\u00f8tter.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For norske virksomheter under NIS2\/Digitalsikkerhetsloven: ingen av algoritmene diskvalifiseres per i dag, men NSM og ENISA sin retning mot moderne algoritmer er klar. Ed25519 representerer den retningen i klassisk kryptografi.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"relatert-dekning\">Relatert dekning<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Disse artiklene utfyller sammenligningen mellom Ed25519 og RSA:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/ssh-nokkel-linux\/\">SSH-n\u00f8kkel i Linux: sikker innlogging i 10 steg [2026]<\/a> \u2013 Komplett guide til generering, distribusjon og sikring av SSH-n\u00f8kler i Linux<\/li><li><a href=\"\/digitale-signaturer\/\">Digitale signaturer forklart: hashfunksjoner og asymmetrisk kryptografi<\/a> \u2013 Grunnlaget for asymmetrisk kryptografi og hvordan signaturer faktisk fungerer<\/li><li><a href=\"\/https-tls-13-nodejs\/\">HTTPS og TLS 1.3 i Node.js: 12 steg [2026]<\/a> \u2013 Implementer sikker transport med TLS 1.3 og moderne n\u00f8kler i Node.js<\/li><li><a href=\"\/scrypt-passordhashing-nodejs\/\">scrypt Passordhashing i Node.js: 11 Steg<\/a> \u2013 Sikrere passordlagring med moderne hashing-algoritmer<\/li><li><a href=\"\/cryptography-hub\/\">Kryptografi: hashfunksjoner, SHA og digital tillit<\/a> \u2013 Pillarside for kryptografi med oversikt over algoritmer og konsepter<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ofte-stilte-sporsmal-faq\">Ofte stilte sp\u00f8rsm\u00e5l (FAQ)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"er-ed25519-sikrere-enn-rsa-4096\">Er Ed25519 sikrere enn RSA-4096?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">For praktiske form\u00e5l i 2026, ja. Ed25519 gir ~128-bit sikkerhet med en 256-bit n\u00f8kkel, tilsvarende sikkerhetsniv\u00e5 som RSA-3072. RSA-4096 gir noe mer enn 128-bit sikkerhet, men p\u00e5 bekostning av dramatisk lavere ytelse. Strukturelt er Ed25519 mer robust mot implementasjonsfeil p\u00e5 grunn av deterministisk signering og konstant-tid-implementasjoner. Den eneste situasjonen der RSA-4096 er \u00e5 foretrekke over Ed25519 er i FIPS-regulerte milj\u00f8er der FIPS-godkjenning er et absolutt krav.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"stotter-github-ed25519-ssh-nokler\">St\u00f8tter GitHub Ed25519 SSH-n\u00f8kler?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ja, fullt ut. GitHub st\u00f8tter Ed25519 SSH-n\u00f8kler. Du legger til n\u00f8kkelen under Settings \u2192 SSH and GPG keys p\u00e5 github.com. GitLab, Bitbucket, Codeberg og alle store Git-hostingtjenester st\u00f8tter det tilsvarende. Ed25519 er faktisk det GitHub anbefaler for nye SSH-n\u00f8kler i sin offisielle dokumentasjon per 2026.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"kan-jeg-bruke-ed25519-med-gpg-pgp\">Kan jeg bruke Ed25519 med GPG \/ PGP?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ja, fra GnuPG versjon 2.1 (utgitt 2014). Kommandoen <code>gpg --expert --full-gen-key<\/code> lar deg velge Ed25519 for signeringsn\u00f8kkel og Cv25519 (Curve25519 Diffie-Hellman) for krypteringsn\u00f8kkel. Dette er det anbefalte GPG-n\u00f8kkeloppsettet for nye n\u00f8kler i 2026. Eldre GPG 1.x st\u00f8tter ikke Ed25519.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"hvilken-rsa-nokkelstorrelse-er-trygg-i-2026\">Hvilken RSA-n\u00f8kkelst\u00f8rrelse er trygg i 2026?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">RSA-2048 er teknisk sett fortsatt trygt i 2026, men gir bare ~112-bit sikkerhet. NIST anbefaler RSA-3072 som minimum for nye implementasjoner med 128-bit sikkerhetsniv\u00e5. RSA-2048 planlegges avviklet for mange brukstilfeller etter 2030 i NISTSs retningslinjer. Hvis du bruker RSA, velg RSA-4096 for trygg margin, men v\u00e6r klar over ytelsesstraffen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"er-ed25519-kvante-resistent\">Er Ed25519 kvante-resistent?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Nei. Ed25519 er basert p\u00e5 diskret logaritme over elliptisk kurve, som Shors algoritme p\u00e5 en tilstrekkelig stor kvantedatamaskin kan bryte. Det samme gjelder RSA. For kvante-resistent kryptografi peker NIST til ML-DSA (CRYSTALS-Dilithium) og ML-KEM (CRYSTALS-Kyber), standardisert i august 2024. Ed25519 er det beste valget for klassisk kryptografi i overgangsperioden frem til post-kvante standarder er bredt tilgjengelig.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"hva-er-forskjellen-mellom-ed25519-og-ecdsa\">Hva er forskjellen mellom Ed25519 og ECDSA?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Begge er elliptiske kurve-signatursystemer, men med ulike kurver og signeringsmekanismer. ECDSA (brukt med secp256k1 i Bitcoin og P-256\/P-384 i TLS) krever en tilfeldig nonce per signatur og er s\u00e5rbar hvis tilfeldighetskilden er svak. PlayStation 3 ble kompromittert via nettopp dette. Ed25519 bruker EdDSA og genererer nonce deterministisk, noe som eliminerer den angrepsklassen. Ed25519 er generelt raskere og tryggere \u00e5 implementere enn ECDSA.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"hva-skjer-med-eksisterende-rsa-nokler\">Hva skjer med eksisterende RSA-n\u00f8kler?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">De forblir gyldige inntil du aktivt tilbakekaller eller sletter dem. Det er ingen grunn til \u00e5 kaste dem umiddelbart. Anbefalt fremgangsm\u00e5te: generer Ed25519-n\u00f8kler, distribuer dem til alle servere og tjenester, verifiser at de fungerer, og fjern deretter de gamle RSA-n\u00f8klene i en kontrollert prosess. For SSH-servere med mange brukere: kj\u00f8r inventarskriptet i migreringsguiden over for \u00e5 identifisere hvem som bruker RSA og kommuniser en migreringsdeadline.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"hva-er-xeddsa-som-signal-bruker\">Hva er XEdDSA som Signal bruker?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">XEdDSA (Extended EdDSA) er en variant av Ed25519 utviklet av Signal Foundation. Den lar deg bruke Curve25519 Diffie-Hellman-n\u00f8kler (brukt i X3DH n\u00f8kkelutveksling) til ogs\u00e5 \u00e5 produsere EdDSA-signaturer. Dette er nyttig fordi Signal allerede bruker Curve25519-n\u00f8kler til kryptering i Double Ratchet-protokollen, og XEdDSA lar de samme n\u00f8klene brukes til autentisering uten \u00e5 generere ekstra n\u00f8kkelpar. Det er en elegant l\u00f8sning som holder n\u00f8kkeladministrasjonen minimal.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ed25519 signerer 50.000 meldinger per sekund. RSA-2048 klarer 1.500. RSA-4096 klarer knapt 200. Det er ikke en marginal forskjell, det er to st\u00f8rrelsesordener. Likevel kj\u00f8rer millioner av servere, SSH-n\u00f8kler og\u2026<\/p>\n","protected":false},"author":5,"featured_media":140,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-139","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cryptography"],"_links":{"self":[{"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/posts\/139","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/comments?post=139"}],"version-history":[{"count":1,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/posts\/139\/revisions"}],"predecessor-version":[{"id":141,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/posts\/139\/revisions\/141"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/media\/140"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/media?parent=139"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/categories?post=139"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/no\/wp-json\/wp\/v2\/tags?post=139"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}