Når en TLS 1.3-server og en nettleser håndhilser i 2026, bruker de nesten aldri samme RSA-signaturformat som en Java-applikasjon fra 2012 ville gjort. Skiftet handler om padding, altså måten en RSA-signatur bygges opp rundt en hash-verdi før selve den matematiske operasjonen kjøres. To skjemaer dominerer: det gamle PKCS#1 v1.5 fra 1990-tallet, og RSA-PSS, som IETF og NIST nå anbefaler for nye systemer. Forskjellen er ikke kosmetisk. RFC 8446 forbyr faktisk PKCS#1 v1.5 i selve TLS 1.3-håndhilsningen, mens NIST FIPS 186-5 peker nye implementasjoner mot PSS. Samtidig produserer begge skjemaene en signatur på nøyaktig samme 256 byte ved en RSA-2048-nøkkel, noe vi har verifisert selv med OpenSSL 3.0.13 i research til denne artikkelen. Så hva er egentlig forskjellen, hvor mye tregere er PSS i praksis, og hvilket skjema bør du velge når du bygger nye systemer i Norden i 2026? Denne artikkelen går gjennom spesifikasjonene, ytelsen, sikkerhetshistorien og standardlandskapet, og ender med en konkret migreringsguide.
Hva er RSA-signaturer, og hvorfor er padding viktig
En rå RSA-operasjon er bare modulær eksponentiering: du tar et tall, hever det til en potens, og reduserer resultatet modulo et stort primtallsprodukt. Problemet er at denne rå operasjonen er sårbar for en rekke matematiske manipulasjoner, blant annet multiplikative angrep der en angriper kan konstruere nye gyldige signaturer fra eksisterende signaturer uten å kjenne den private nøkkelen. Padding-skjemaet er laget for å hindre nettopp dette: det pakker meldingshashen inn i en bestemt bytesekvens før RSA-operasjonen utføres, slik at resultatet ikke lenger har den matematiske strukturen angriperen trenger.
RFC 8017 (PKCS#1 versjon 2.2) definerer begge skjemaene vi sammenligner i denne artikkelen under samme dokument, men de løser paddingen på fundamentalt forskjellige måter. RSASSA-PKCS1-v1_5 bygger en fast bytestruktur: 0x00, 0x01, en rekke 0xff-byte som fyllstoff, en 0x00-separator, og til slutt en DER-kodet DigestInfo-struktur som inneholder hash-algoritmen og selve digesten. Gitt samme nøkkel og samme melding vil denne prosessen alltid produsere nøyaktig samme padding, før RSA-operasjonen gjør resten. RSASSA-PSS gjør det motsatte: den trekker en tilfeldig salt-verdi, hasher meldingen sammen med denne salten, og bruker en maskegenereringsfunksjon (MGF1) til å bygge den endelige strukturen. Resultatet er at samme melding signert to ganger med samme nøkkel normalt gir to forskjellige signaturer, fordi salten er tilfeldig hver gang.
Denne ene designbeslutningen, tilfeldighet versus determinisme, er roten til nesten alle praktiske og sikkerhetsmessige forskjeller som følger i resten av denne artikkelen. Den påvirker hvordan skjemaene oppfører seg under formelle sikkerhetsbevis, hvor mye ekstra regnearbeid de krever, og hvordan protokoller som TLS, JWT og X.509 velger å bruke dem.
PKCS#1 v1.5 forklart: den deterministiske arven
PKCS#1 v1.5 stammer fra RSA Security sin opprinnelige PKCS#1-spesifikasjon og har vært i aktiv bruk siden lenge før TLS 1.0 eksisterte. Styrken til skjemaet er enkelhet: ingen tilfeldighetskilde er nødvendig under signering, og verifisering er en rett-frem sammenligning av to bytesekvenser. Det gjør implementasjonen lett å teste, lett å feilsøke, og vanskelig å gjøre feil med på måter som bryter interoperabilitet mellom forskjellige biblioteker og plattformer.
Svakheten ligger i det samme trekket. Fordi encoding-prosessen er fullstendig deterministisk og strukturen er fast og forutsigbar, mangler PKCS#1 v1.5 et moderne, tett sikkerhetsbevis som knytter skjemaets sikkerhet direkte til vanskelighetsgraden av å faktorisere store tall. Det betyr ikke at skjemaet er praktisk brutt som signaturmekanisme i seg selv. Det betyr at kryptografer ikke kan gi samme matematiske garanti som de kan for PSS. I tillegg har PKCS#1 v1.5 sin nære kryptografiske slektning, kryptering med samme paddingfamilie (RSAES-PKCS1-v1_5), vært kilden til en rekke virkelige angrep gjennom årene, noe vi går gjennom i detalj senere i artikkelen.
I dag lever PKCS#1 v1.5 videre primært på grunn av utbredelse og bakoverkompatibilitet. JSON Web Token-spesifikasjonen definerer algoritmeidentifikatorene RS256, RS384 og RS512 som nettopp RSASSA-PKCS1-v1_5 med SHA-256, SHA-384 og SHA-512. Millioner av API-er, OAuth-flyter og enkeltpålogginger bruker disse identifikatorene hver dag. SSH-protokollen definerer også rsa-sha2-256 og rsa-sha2-512 som PKCS#1 v1.5-baserte signaturer, og har aldri standardisert en PSS-variant for autentisering, noe som gjør SSH til et av de klareste eksemplene på at PKCS#1 v1.5 fortsatt er uunngåelig i praksis.
RSA-PSS forklart: tilfeldig salt og MGF1-masking
RSA-PSS, eller Probabilistic Signature Scheme, ble først introdusert i PKCS#1 versjon 2.1 og er videreført i dagens RFC 8017. Navnet forteller historien: skjemaet er probabilistisk, ikke deterministisk. Signeringsprosessen hasher meldingen, genererer en tilfeldig salt-verdi (typisk like lang som hash-outputen, altså 32 byte for SHA-256), hasher salten sammen med meldingshashen, og bruker deretter MGF1 til å generere en maske som blandes inn i den endelige strukturen før RSA-operasjonen kjøres.
Denne tilfeldigheten gir PSS en vesentlig fordel i formelle sikkerhetsanalyser. Skjemaet er konstruert slik at det kan knyttes til en sikkerhetsreduksjon i random oracle-modellen, noe som i praksis betyr at et eventuelt angrep mot PSS kan omformes til et angrep mot selve RSA-problemet. RFC 8017 definerer PSS med flere konfigurerbare parametere: hvilken hash-funksjon som brukes på meldingen, hvilken hash MGF1 bruker internt, lengden på salten, og et avsluttende felt. Alle disse må avtales mellom signerer og verifiserer, noe som gjør PSS noe mer komplekst å konfigurere riktig enn PKCS#1 v1.5.
Et praktisk poeng som ofte overraskes folk: en salt-lengde på null byte er faktisk tillatt i spesifikasjonen, og gjør PSS deterministisk. Dette er imidlertid ikke den vanlige distribusjonen. Standard praksis, og det de store CA-ene og NSA sin CSfC-veiledning fra 2026 legger til grunn, er en salt-lengde som matcher hash-outputen: 32 byte for SHA-256, 48 byte for SHA-384, og 64 byte for SHA-512. CA/Browser Forum sine Baseline Requirements spesifiserer konkret kombinasjonen SHA-384 med MGF1-SHA-384 og en 48-byte salt for sertifikater som bruker PSS.
Historien bak PSS: fra et akademisk bevis til en IETF-standard
RSA-PSS har en rot som er verdt å kjenne til, fordi den forklarer hvorfor skjemaet ser ut som det gjør. Kryptografene Mihir Bellare og Phillip Rogaway publiserte konstruksjonen i artikkelen “The Exact Security of Digital Signatures: How to Sign with RSA and Rabin” på Eurocrypt i 1996. Målet var ikke bare å lage et nytt paddingformat, men å løse et teoretisk problem: å finne en måte å signere med RSA som kunne knyttes til en eksakt, kvantifiserbar sikkerhetsgaranti, i stedet for å basere seg på at ingen hadde funnet et angrep ennå. Dette var en vesentlig endring i hvordan kryptografer tenkte om signaturdesign på den tiden.
RSA Laboratories tok opp konstruksjonen og inkluderte den i PKCS#1 versjon 2.1, utgitt i 2002, som det første offisielle industristandardiserte skjemaet med denne typen bevis. IETF overtok senere forvaltningen av PKCS#1-familien fra RSA Laboratories, og dagens RFC 8017 fra 2016 er den direkte etterfølgeren som fortsatt definerer PSS på praktisk talt samme måte som i 2002, med kun mindre presiseringer. Det tok altså over to tiår fra det akademiske beviset til TLS 1.3 gjorde PSS obligatorisk i håndhilsningen, noe som er ganske typisk for hvor lang tid det tar før en kryptografisk nyhet med et sterkere sikkerhetsargument faktisk fortrenger en eldre, allerede utbredt metode. PKCS#1 v1.5 hadde på sin side ingen tilsvarende enkelt publiseringsdato med et formelt bevis. Skjemaet vokste ut av de praktiske behovene til tidlig RSA-implementasjon på 1990-tallet, lenge før den typen eksakte sikkerhetsreduksjoner Bellare og Rogaway introduserte var en etablert del av kryptografisk design.
Spesifikasjonstabell: PKCS#1 v1.5 mot RSA-PSS
Tabellen under oppsummerer de tekniske egenskapene som skiller de to paddingskjemaene, basert på RFC 8017, FIPS 186-5 og egne målinger med RSA-2048-nøkler.
| Egenskap | PKCS#1 v1.5 | RSA-PSS |
|---|---|---|
| Spesifikasjon | RFC 8017 (RSASSA-PKCS1-v1_5) | RFC 8017 (RSASSA-PSS), opprinnelig PKCS#1 v2.1 |
| Encoding-type | Deterministisk | Probabilistisk (tilfeldig salt) |
| Krever tilfeldighetskilde ved signering | Nei | Ja (salt-generering) |
| Signaturstørrelse ved RSA-2048 | 256 byte | 256 byte (identisk) |
| Typisk saltlengde | Ikke relevant | 32 byte (SHA-256), 48 byte (SHA-384), 64 byte (SHA-512) |
| Maskegenerering | Ingen | MGF1 |
| Formelt sikkerhetsbevis | Mangler tett moderne reduksjon | Sikkerhetsreduksjon i random oracle-modellen |
| Status i FIPS 186-5 (NIST) | Tillatt, eksisterende bruk | Primær anbefaling for nye implementasjoner |
| Status i TLS 1.3 (RFC 8446) | Forbudt i CertificateVerify | Obligatorisk for CertificateVerify (rsa_pss_rsae_*, rsa_pss_pss_*) |
| JWT-algoritmenavn | RS256 / RS384 / RS512 | PS256 / PS384 / PS512 |
| Brukt i SSH-autentisering | Ja (rsa-sha2-256/512) | Ikke standardisert i SSH-protokollen |
| Konfigurasjonskompleksitet | Lav | Middels (hash, MGF1-hash, saltlengde må stemme) |
Det mest overraskede punktet for mange utviklere er at signaturstørrelsen er identisk. Siden RSA-signaturen alltid er like stor som modulusen (256 byte ved en 2048-bit nøkkel, uavhengig av padding), er det ingen lagrings- eller båndbreddekostnad forbundet med å velge PSS over PKCS#1 v1.5. Kostnaden, om noen, ligger et annet sted: i konfigurasjonskompleksitet og i marginalt høyere regnekostnad under signering.
Sikkerhetsbevis: hvorfor PSS har et sterkere matematisk fundament
Begrepet “tett sikkerhetsbevis” brukes ofte litt løst i kryptografidebatter, så det er verdt å være presis. RSA-PSS er konstruert slik at et eventuelt forfalskningsangrep mot signaturskjemaet, under random oracle-modellen og standard antagelser om RSA-problemets vanskelighetsgrad, kan omformes til en algoritme som løser selve RSA-problemet. Dette gir kryptografer en matematisk ramme for å resonnere om sikkerheten, og er en direkte konsekvens av at salten gir signaturen domeneseparasjon: ingen to signaturer av samme melding ser like ut, så en angriper kan ikke bygge opp et bibliotek av kjente signatur/melding-par og lete etter mønstre.
PKCS#1 v1.5 mangler en tilsvarende moderne reduksjon fordi den deterministiske strukturen gjør analysen vanskeligere å gjennomføre med samme presisjon. Det er viktig å være nøyaktig her: dette betyr ikke at PKCS#1 v1.5-signaturer er praktisk forfalskbare med dagens RSA-nøkkelstørrelser. Millioner av systemer har brukt skjemaet i over to tiår uten at noen har publisert et praktisk forfalskningsangrep mot korrekt implementert RSASSA-PKCS1-v1_5-signatur med en tilstrekkelig stor nøkkel. Forskjellen handler om kvaliteten på det matematiske sikkerhetsargumentet, ikke om en kjent, utnyttet svakhet i signaturskjemaet selv.
Dette er grunnen til at NIST og IETF beskriver PSS som å ha et vesentlig sterkere formelt sikkerhetsfundament enn PKCS#1 v1.5, samtidig som begge organisasjonene fortsatt tillater PKCS#1 v1.5 i situasjoner der interoperabilitet krever det. Det er en forsiktig, ingeniørmessig anbefaling, ikke en advarsel om et akutt sikkerhetshull.
Bleichenbacher, ROBOT og DROWN: hva angrepene faktisk traff
Her oppstår den vanligste misforståelsen i hele denne sammenligningen, og den er verdt å rydde opp i grundig. Daniel Bleichenbachers opprinnelige angrep fra 1998, og de senere ROBOT-funnene fra 2017 til 2018 samt DROWN-angrepet, retter seg mot RSAES-PKCS1-v1_5, altså kryptering med PKCS#1 v1.5-padding, ikke mot RSASSA-PKCS1-v1_5-signaturer. Dette er to forskjellige operasjoner som deler et paddingformat med samme navn, men brukes helt forskjellig.
Bleichenbachers angrep utnytter en adaptiv valgt-ciffertekst-svakhet: en server som dekrypterer data med PKCS#1 v1.5-padding og lekker informasjon om hvorvidt paddingen var gyldig eller ikke, kan brukes av en angriper til gradvis å rekonstruere en kryptert melding uten å kjenne den private nøkkelen. ROBOT-forskningen fra 2017 til 2018 viste at denne typen dekrypteringsorakel fortsatt var operativt relevant i mange reelle TLS-implementasjoner nesten to tiår etter at den opprinnelige svakheten ble publisert. DROWN-angrepet fra 2016 utnyttet på lignende vis sårbar SSLv2-støtte og gjenbruk av RSA-nøkler for å angripe moderne TLS-forbindelser indirekte.
Det avgjørende punktet: ingen av disse angrepene er et direkte forfalskningsangrep mot RSASSA-PKCS1-v1_5-signaturer. De er dekrypteringsorakel-angrep mot en server som utfører RSA-dekryptering usikkert. RSA-PSS løser ikke dette problemet i det hele tatt, fordi PSS er et signaturskjema, ikke et krypteringsskjema. Den riktige løsningen mot Bleichenbacher-familien av angrep er å bruke RSAES-OAEP for kryptering, eller enda bedre, å unngå RSA-basert nøkkelutveksling helt til fordel for (elliptisk) Diffie-Hellman, som moderne TLS 1.3 faktisk krever. At signaturvalget mellom PSS og PKCS1v1.5 likevel diskuteres i samme åndedrag som disse angrepene, er historisk forståelig siden navnene er identiske, men teknisk sett adresserer de ikke samme sårbarhet.
For et team som skal revidere egen infrastruktur, er derfor den riktige sjekklisten todelt og helt uavhengig av padding-diskusjonen i resten av denne artikkelen. Først: bruker systemet fortsatt RSA til nøkkelutveksling i en gammel TLS-konfigurasjon, i stedet for (elliptisk) Diffie-Hellman? Da er det dette som bør byttes først, siden det er her Bleichenbacher-, ROBOT- og DROWN-familien faktisk biter. For det andre: bruker systemet RSAES-PKCS1-v1_5 til å kryptere data direkte, utenfor TLS-håndhilsningen, for eksempel i en eldre meldingskø eller filformatprotokoll? Da bør dette oppgraderes til RSAES-OAEP. Ingen av disse to tiltakene har noe å gjøre med om signaturene i systemet bruker PSS eller PKCS#1 v1.5, og det er nettopp denne sammenblandingen mellom signatur-padding og krypterings-padding som skaper mest forvirring i sikkerhetsgjennomganger.
Ytelse i praksis: egne målinger med OpenSSL 3.0.13
Fordi det er overraskende vanskelig å finne oppdaterte, direkte sammenlignbare offentlige benchmarker som isolerer PSS mot PKCS#1 v1.5 på samme maskinvare, kjørte vi egne tester til denne artikkelen. Testmiljøet var OpenSSL 3.0.13 på Ubuntu, med en RSA-2048-nøkkel generert lokalt. Vi målte tre separate ting: den rene RSA-primitivens hastighet (uavhengig av padding), 500 fulle signeringsoperasjoner med hver padding, og 500 fulle verifiseringsoperasjoner med hver padding.
| Benchmark | Resultat | Kilde / metode |
|---|---|---|
| Ren RSA-2048 privat operasjon (signering) | 961,6 operasjoner/sekund | Egen måling, openssl speed rsa2048 |
| Ren RSA-2048 offentlig operasjon (verifisering) | 28.717 operasjoner/sekund | Egen måling, openssl speed rsa2048 |
| 500x signering med PKCS#1 v1.5 (SHA-256) | 8,26 sekunder totalt | Egen måling, openssl dgst -sign |
| 500x signering med RSA-PSS (SHA-256, 32-byte salt) | 8,75 sekunder totalt | Egen måling, openssl dgst -sign -sigopt rsa_padding_mode:pss |
| 500x verifisering med PKCS#1 v1.5 | 6,02 sekunder totalt | Egen måling, openssl dgst -verify |
| 500x verifisering med RSA-PSS | 5,13 sekunder totalt | Egen måling, openssl dgst -verify -sigopt rsa_padding_mode:pss |
| HMAC-SHA256 referanse (symmetrisk, for kontekst) | 9,05 cycles/byte, 241,8 MB/s | wolfSSL dokumentasjon, chapter03.html |
Konklusjonen fra disse tallene bekrefter nøyaktig det forskningslitteraturen antyder: forskjellen mellom PKCS#1 v1.5 og PSS er liten og dominert av målestøy fra prosessoppstart i testriggen, ikke av reell kryptografisk kostnad. PSS-signering var om lag 6 prosent tregere i vår test (8,75 mot 8,26 sekunder for 500 operasjoner), mens PSS-verifisering faktisk kom ut marginalt raskere i vår kjøring, noe som understreker at variasjonen ligger innenfor normal målestøy, ikke en konsekvent fundamental forskjell. Den rene RSA-operasjonen, altså selve den modulære eksponentieringen, er fullstendig uavhengig av hvilken padding du legger rundt den: 961,6 signeringer i sekundet og 28.717 verifiseringer i sekundet er identiske tall uansett hvilket paddingskjema den endelige applikasjonen bruker. MGF1-masking og salt-generering i PSS legger til noen mikrosekunder med hashing per operasjon, men dette drukner i kostnaden av selve RSA-eksponentieringen. Med andre ord: ytelse er aldri et godt argument for å beholde PKCS#1 v1.5 i et nytt system.
Standardlandskapet i 2026: FIPS 186-5, RFC 8446 og CA/Browser Forum
NIST sin gjeldende Digital Signature Standard, FIPS 186-5, ble publisert i februar 2023 og spesifiserer RSA-signaturer med både RSASSA-PSS og RSASSA-PKCS1-v1_5. Overgangsbestemmelsene i standarden tillater eksisterende PKCS#1 v1.5-signaturer og verifisering av dem, men nye implementasjoner og applikasjoner forventes å bruke PSS der interoperabilitet tillater det. Dette er en gradvis, bakoverkompatibel anbefaling, ikke et hardt forbud, og den samme gradvise tilnærmingen går igjen i hvordan NIST har håndtert tidligere paddingovergange de siste to tiårene.
TLS 1.3, definert i RFC 8446, går vesentlig lenger. Spesifikasjonen definerer signaturskjemaene rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512 samt de rene PSS-nøkkelvariantene rsa_pss_pss_*, og tillater ikke de gamle identifikatorene rsa_pkcs1_sha256, rsa_pkcs1_sha384 eller rsa_pkcs1_sha512 for selve CertificateVerify-signaturen i håndhilsningen. En nyansert detalj som ofte glemmes: dette forbudet gjelder håndhilsningssignaturen, ikke nødvendigvis signaturene i sertifikatkjeden. En TLS 1.3-server kan fortsatt presentere et sertifikat som selv er signert av en CA med PKCS#1 v1.5, så lenge CertificateVerify-meldingen bruker et av de tillatte PSS-skjemaene.
CA/Browser Forum, som styrer baseline-kravene for offentlig tiltrodde TLS-sertifikater, har ikke fjernet PKCS#1 v1.5 fra alle sertifikater, men har definert konkrete godkjente RSA-PSS-kombinasjoner for sertifikatsignering, blant annet SHA-384 med MGF1-SHA-384 og en 48-byte salt. Dette gir sertifikatmyndigheter et definert, interoperabelt PSS-alternativ uten å tvinge en brå overgang som ville brutt eksisterende infrastruktur. NSA sin CSfC-veiledning for 2026, som dekker TLS-beskyttede servere, IPsec VPN-klienter og brannmurer for trafikkfiltrering, tillater RSA-PSS med SHA-256, SHA-384 eller SHA-512, med saltlengde begrenset til maksimalt hash-outputens lengde. Samlet peker alle tre standardkildene i samme retning: PSS er fremtiden for nye systemer, PKCS#1 v1.5 lever videre som kompatibilitetslag.
Nøkkelstørrelse spiller også en rolle: RSA-2048 mot 3072 og 4096
Valget mellom PSS og PKCS#1 v1.5 er lett å overfokusere på isolert, men padding løser ikke et problem dersom nøkkelen selv er for liten. RSA-1024 er forlatt av praktisk talt alle seriøse standarder og biblioteker i dag, og 2048-bit er det laveste som fortsatt regnes som akseptabelt i ny infrastruktur. NIST sitt rammeverk for nøkkellengder og sikkerhetsstyrke, som ligger til grunn for FIPS 186-5, plasserer RSA-2048 på et sikkerhetsnivå tilsvarende 112 bit, mens RSA-3072 gir rundt 128 bit, det samme nivået som AES-128 og P-256-elliptiske kurver. Denne sammenhengen gjelder uavhengig av om du bruker PSS eller PKCS#1 v1.5, fordi begge paddingskjemaene opererer på toppen av samme underliggende RSA-nøkkel.
Det praktiske rådet for 2026 er derfor todelt. For det første: padding-valget (PSS mot PKCS#1 v1.5) og nøkkelstørrelsen er to uavhengige beslutninger, og du bør ikke anta at PSS kompenserer for en for liten nøkkel eller at PKCS#1 v1.5 krever en større nøkkel for å være trygg. For det andre: dersom du uansett planlegger en nøkkelrotasjon, enten for å øke fra 2048 til 3072 bit eller for å forberede en overgang mot postkvantesignaturer som ML-DSA, er det et naturlig tidspunkt å også bytte paddingskjema til PSS, siden du allerede må oppdatere signerings- og verifiseringskoden. Å kombinere disse to migreringsprosjektene reduserer den totale mengden testing og utrulling systemet må gjennom, i stedet for å gjøre to separate endringer med måneders mellomrom.
Bruksområder i praksis: TLS, JWT, X.509, SSH, PDF og kodesignering
De to paddingskjemaene lever side om side i svært forskjellige deler av moderne infrastruktur, og hvilket skjema som dominerer et bestemt felt forteller ofte mer om protokollens alder og treghet enn om reell sikkerhetsvurdering. Tabellen under oppsummerer de viktigste domenene.
| Domene | Dominerende skjema | Kommentar |
|---|---|---|
| TLS 1.3 håndhilsning (CertificateVerify) | RSA-PSS | Obligatorisk etter RFC 8446, PKCS1v1.5 forbudt her |
| TLS-sertifikatkjede (CA-signaturer) | Begge, PKCS1v1.5 fortsatt vanlig | CA/Browser Forum tillater begge, definerer PSS-parametere |
| JSON Web Tokens | PKCS1v1.5 (RS256) dominerer | PS256/PS384/PS512 finnes, men krever at alle verifiserere støtter det |
| SSH-autentisering | PKCS1v1.5 (rsa-sha2-256/512) | Protokollen definerer ingen PSS-variant |
| PDF-signering (PAdES) | Blandet, avhenger av profil | Nyere profiler tillater PSS, eldre verifiserere krever PKCS1v1.5 |
| Kodesignering (Authenticode, JAR) | PKCS1v1.5 dominerer fortsatt | Bred verifisereroppslutning er avgjørende for distribusjon |
| Nye høysikkerhetssystemer (NSA CSfC) | RSA-PSS | Eksplisitt anbefalt for TLS-servere, VPN-klienter i 2026-veiledning |
Mønsteret er konsistent: der en ny protokoll designes fra bunnen i dag, som TLS 1.3 sin håndhilsning, velges PSS uten diskusjon. Der en etablert protokoll med enorm eksisterende verifisererbase må oppdateres, som SSH eller JWT-økosystemet, forblir PKCS#1 v1.5 normen fordi kostnaden ved å bryte kompatibilitet med millioner av eksisterende klienter er høyere enn den marginale sikkerhetsgevinsten av å tvinge gjennom PSS.
Pris: hva signeringsoperasjoner koster i skyen
Siden mange nye systemer i Norden i 2026 signerer og verifiserer RSA-nøkler via administrerte skynøkkeltjenester snarere enn lokale biblioteker, er kostnaden ved selve API-kallet en like relevant del av valget som regnekraft. Her er godt nytt: ingen av de store skyleverandørene krever et separat prisnivå for PSS versus PKCS#1 v1.5. Begge faktureres som identiske asymmetrisk signer/verifiser-operasjoner.
| Tjeneste | Pris for RSA sign/verify | Støtter RSA-PSS? | Støtter PKCS#1 v1.5? |
|---|---|---|---|
| AWS KMS | $0,15 per 10.000 forespørsler (asymmetriske nøkkeloperasjoner, utenfor gratisnivå) | Ja, RSASSA_PSS_SHA_256/384/512 | Ja, RSASSA_PKCS1_V1_5_SHA_256/384/512 |
| Google Cloud KMS | $0,03 per 10.000 asymmetriske signeringsoperasjoner | Dokumentert i signerings-API, verifiser algoritmeliste per nøkkeltype | Dokumentert i signerings-API, verifiser algoritmeliste per nøkkeltype |
| Azure Key Vault | Ikke offentlig som konkret tall, krever prisverktøy eller salgskontakt | Støtter RSA 2048/3072/4096 i Standard og Premium | Støtter RSA 2048/3072/4096 i Standard og Premium |
AWS KMS sin prisside viser eksplisitt at Sign, Verify, Encrypt, Decrypt og GetPublicKey på asymmetriske nøkler koster $0,15 per 10.000 forespørsler, og disse er uttrykkelig utenfor det generelle gratisnivået på 20.000 forespørsler i måneden. Google Cloud oppgir $0,03 per 10.000 asymmetriske signeringsoperasjoner som sitt publiserte tall, altså fem ganger lavere enn AWS sin asymmetriske rate. Azure Key Vault sin offentlige prisside viser kun plassholderverdier og henviser til prisverktøyet for eksakte tall, så en reell kostnadssammenligning med Azure krever at du logger deg inn og genererer et konkret estimat for din region og mengde. Det praktiske rådet er derfor dette: velg padding-skjema basert på sikkerhet og interoperabilitet, ikke basert på pris, siden ingen leverandør premierer eller straffer deg økonomisk for valget mellom PSS og PKCS#1 v1.5.
For organisasjoner som i stedet eier sin egen maskinvare, er det verdt å nevne at AWS også tilbyr CloudHSM som et dedikert alternativ til KMS, priset til $1,60 per HSM-time i tillegg til $1 per måned for en KMS-nøkkel som bruker CloudHSM-opphav. Dette er en helt annen kostnadsmodell enn den rene per-forespørsel-prisingen i vanlig KMS, og blir først økonomisk fornuftig ved svært høyt volum eller strenge krav om fysisk kontroll over nøkkelmaterialet. Heller ikke her finnes det noen prisforskjell knyttet til PSS mot PKCS#1 v1.5, siden HSM-timeprisen er uavhengig av hvilket signaturskjema applikasjonen din ber om.
Virkelige eksempler: fem steder valget betyr noe
Det er lett å diskutere paddingskjemaer abstrakt, men valget får konkrete konsekvenser i spesifikke systemer, ofte på måter utviklere ikke tenker over før de møter en feilmelding i produksjon. Her er fem eksempler som illustrerer hvor forskjellen faktisk slår ut i praksis, valgt fordi de dekker både protokoller der valget er tvunget og protokoller der det er en reell beslutning.
- TLS 1.3-servere overalt: Enhver server som terminerer TLS 1.3 og bruker en RSA-sertifikatnøkkel for autentisering, må kunne produsere en gyldig rsa_pss_rsae_sha256-signatur i håndhilsningen. Biblioteker som fortsatt bare støtter PKCS#1 v1.5 for RSA-signering vil ganske enkelt ikke kunne fullføre en TLS 1.3-håndhilsning som klient med RSA-sertifikat, og må falle tilbake til TLS 1.2 eller feile.
- JWT-baserte API-plattformer: Identitetsleverandører som utsteder tokens med RS256 bruker PKCS#1 v1.5, og dette er fortsatt den mest brukte algoritmen i OAuth- og OpenID Connect-økosystemet. Et skifte til PS256 krever at absolutt alle nedstrøms verifiserere, inkludert tredjeparts biblioteker og mobilapper, støtter PSS-verifisering før utstederen kan bytte uten å bryte eksisterende integrasjoner.
- Sertifikatmyndigheter under CA/Browser Forum: Offentlige CA-er som ønsker å signere underordnede sertifikater med PSS i stedet for PKCS#1 v1.5, må bruke den spesifikke SHA-384/MGF1-SHA-384/48-byte-salt-kombinasjonen som Baseline Requirements definerer, for å garantere at alle større nettlesere og operativsystemer kan validere kjeden korrekt.
- SSH-flåter i bedriftsmiljøer: Fordi SSH-protokollen aldri definerte en PSS-variant for vertsnøkkel- eller brukerautentisering, er dette et av de klareste eksemplene på at PKCS#1 v1.5 ikke er et valg, men en protokollbegrensning. Et selskap som ønsker PSS overalt må se til andre autentiseringsmekanismer for SSH, som Ed25519-nøkler, i stedet for å prøve å tvinge PSS inn i RSA-delen av protokollen.
- Høysikkerhetsnettverk under NSA CSfC-veiledning: Organisasjoner som bygger løsninger etter NSA sin Commercial Solutions for Classified-veiledning for 2026, finner RSA-PSS eksplisitt oppført som godkjent for TLS-beskyttede servere og IPsec VPN-klienter, med definerte grenser for saltlengde, mens eldre PKCS#1 v1.5-konfigurasjoner krever egen vurdering mot samme veiledning.
Migrasjonsguide: fra PKCS#1 v1.5 til RSA-PSS steg for steg
En migrering fra PKCS#1 v1.5 til RSA-PSS er sjelden en stor, risikofylt affære, men den krever at du går gjennom hele verifisererkjeden før du bytter noe i produksjon. Følgende steg dekker de vanligste situasjonene.
- Kartlegg alle steder i systemet der RSA-signering eller verifisering faktisk skjer: TLS-terminering, JWT-utstedelse, API-signering, kodesignering og eventuelle interne tjeneste-til-tjeneste-kall.
- Identifiser hvilke av disse som er under din kontroll på begge sider (du kontrollerer både signerer og verifiserer) og hvilke som har eksterne tredjepartsverifiserere du ikke kan oppgradere samtidig.
- For TLS: sjekk at serverbiblioteket (OpenSSL 3.x, BoringSSL eller tilsvarende) støtter rsa_pss_rsae_*-signaturskjemaene, noe moderne versjoner gjør som standard siden TLS 1.3-støtte uansett krever det.
- For JWT: hvis du kontrollerer både utsteder og alle forbrukere, bytt algoritmeidentifikatoren fra RS256 til PS256 i signeringsbiblioteket, og sørg for at hash-funksjon og MGF1-hash er konsistente på begge sider.
- For nye X.509-sertifikater: be sertifikatmyndigheten din om PSS-signerte sertifikater med SHA-384/MGF1-SHA-384 og 48-byte salt dersom du opererer under CA/Browser Forum-regler, og test validering i alle klientbiblioteker du må støtte.
- I OpenSSL konfigureres PSS via -sigopt rsa_padding_mode:pss og -sigopt rsa_pss_saltlen:<lengde> på kommandolinjen, eller de tilsvarende EVP_PKEY_CTX-funksjonene i kode.
- I Java bruker du Signature.getInstance(“RSASSA-PSS”) sammen med en eksplisitt konfigurert PSSParameterSpec, i stedet for den enklere SHA256withRSA-identifikatoren som gir deg PKCS#1 v1.5.
- I Python sin cryptography-pakke bytter du fra padding.PKCS1v15() til padding.PSS(mgf=padding.MGF1(hashes.SHA256()), salt_length=32) i signeringskallet.
- I Node.js sitt innebygde crypto-modul setter du padding: crypto.constants.RSA_PKCS1_PSS_PADDING og en eksplisitt saltLength i signeringsopsjonene.
- I Go sin crypto/rsa-pakke bytter du fra SignPKCS1v15/VerifyPKCS1v15 til SignPSS/VerifyPSS, med en PSSOptions-struct som definerer saltlengde.
- Kjør parallell utrulling: la systemet akseptere begge skjemaer under verifisering i en overgangsperiode, mens du gradvis flytter signeringssiden over til PSS tjeneste for tjeneste.
- Overvåk feilrater på verifiseringssiden etter hvert steg, siden en feilkonfigurert saltlengde eller feil MGF1-hash er den vanligste årsaken til at PSS-migreringer feiler i produksjon.
Bruksanbefalinger: når velge hva
Valget mellom de to skjemaene avhenger mer av hvem som skal verifisere signaturen enn av noen ren sikkerhetskalkyle, siden begge gir tilstrekkelig sikkerhet med moderne nøkkelstørrelser. Spør deg selv om tre ting før du bestemmer deg: har jeg full kontroll over alle verifiserere, krever protokollen et spesifikt skjema, og er dette et nytt system eller en oppgradering av noe som allerede kjører i produksjon. Svarene på disse tre spørsmålene peker deg nesten alltid mot riktig valg raskere enn en abstrakt sikkerhetsdiskusjon vil gjøre. Her er fem konkrete situasjoner og hva vi anbefaler for hver.
- Nye TLS 1.3-tjenester: Dette er ikke et valg, PSS er obligatorisk for CertificateVerify-signaturen under RFC 8446, så sørg bare for at biblioteket ditt er oppdatert.
- Nye interne API-er med full kontroll over klient og server: Velg PS256 for JWT-signering fra start, siden du ikke har noen eksisterende integrasjoner å bryte, og får det sterkeste sikkerhetsargumentet uten kostnad.
- Offentlige API-er med tredjepartsintegrasjoner: Behold RS256 som standard inntil du har bekreftet at samtlige klientbiblioteker tredjeparter bruker støtter PS256-verifisering, og tilby PS256 som opt-in i mellomtiden.
- Innebygde systemer og IoT med begrenset kryptografibibliotek: Hvis maskinvaren eller biblioteket kun støtter PKCS#1 v1.5, er dette fortsatt et akseptabelt valg med en moderne nøkkelstørrelse på minst 2048 bit, siden regnekostnaden er lavere og implementasjonsrisikoen for feilkonfigurert salt elimineres helt.
- SSH-flåter og kodesignering mot brede verifisererøkosystemer: Bruk det paddingskjemaet protokollen eller plattformen faktisk krever, siden interoperabilitet trumfer et teoretisk sikkerhetsargument når verifisereren uansett ikke støtter alternativet.
Fordeler og ulemper
| Fordeler | Ulemper | |
|---|---|---|
| PKCS#1 v1.5 | Enkel å implementere og feilsøke; ingen tilfeldighetskilde nødvendig; universell biblioteksstøtte; lavest mulig konfigurasjonsrisiko | Mangler moderne, tett sikkerhetsbevis; forbudt i TLS 1.3-håndhilsningen; historisk assosiert med Bleichenbacher-stilen angrep (selv om disse traff kryptering, ikke signatur) |
| RSA-PSS | Sterkere formelt sikkerhetsbevis; obligatorisk og fremtidsrettet i TLS 1.3; eksplisitt favorisert av FIPS 186-5 og NSA CSfC for nye systemer | Krever tilfeldighetskilde under signering; flere parametere å konfigurere riktig (hash, MGF1-hash, saltlengde); fortsatt ikke universelt støttet i eldre protokoller som SSH |
Verdikt: hva bør du velge i 2026
Når du bygger noe nytt i 2026 og har full kontroll over både signerer og verifiserer, er svaret enkelt: velg RSA-PSS. Det matematiske sikkerhetsargumentet er sterkere, ytelseskostnaden er, som våre egne målinger viser, praktisk talt null (en forskjell på noen få prosent i rå signeringshastighet som drukner i annen systemlatens), og signaturen tar ikke en byte mer lagringsplass. TLS 1.3 har allerede bestemt dette for deg i håndhilsningen, og NIST, CA/Browser Forum og NSA peker alle samme vei for nye implementasjoner.
Der verdikten blir mer nyansert er når du ikke kontrollerer hele verifisererkjeden. SSH-protokollen har rett og slett ikke gitt deg valget. JWT-økosystemet er så dominert av RS256 at et bytte til PS256 krever koordinering du kanskje ikke har makt over. Og enkelte innebygde eller eldre systemer har kryptografibiblioteker som aldri fikk PSS-støtte lagt til. I disse tilfellene er PKCS#1 v1.5 fortsatt et legitimt, forsvarlig valg, ikke en sikkerhetsrisiko du må fikse i all hast. Det reelle rådet er derfor ikke “bytt alt til PSS umiddelbart”, men “bruk PSS der du har frihet til å velge, og la protokollkravene styre resten”.
Tallene vi har vist gjennom denne artikkelen underbygger denne konklusjonen fra flere vinkler samtidig. Signaturen tar samme 256 byte. Skysignering koster det samme hos AWS og Google uansett skjema. Egne målinger viser under 10 prosent forskjell i signeringstid. Det eneste virkelige friksjonspunktet er konfigurasjon og kompatibilitet, ikke kryptografisk styrke eller driftskostnad. Det gjør valget i 2026 enklere enn det kanskje virker ved første øyekast: dette er en beslutning du kan ta basert på hvem som skal verifisere signaturen, ikke basert på en avveining mellom sikkerhet og ytelse.
Ofte stilte spørsmål
Er PKCS#1 v1.5-signaturer usikre og bør byttes ut umiddelbart?
Nei. Korrekt implementert RSASSA-PKCS1-v1_5 med en moderne nøkkelstørrelse på minst 2048 bit har ingen kjent praktisk forfalskningssvakhet. Anbefalingen om å bruke PSS for nye systemer handler om et sterkere formelt sikkerhetsbevis, ikke om en akutt sårbarhet i eksisterende PKCS#1 v1.5-signaturer.
Påvirker Bleichenbacher-angrep, ROBOT eller DROWN RSA-signaturer med PKCS#1 v1.5-padding?
Nei, disse angrepene retter seg mot RSA-kryptering (RSAES-PKCS1-v1_5), ikke mot RSA-signaturer (RSASSA-PKCS1-v1_5). De to bruker samme paddingfamilienavn, men er helt forskjellige operasjoner med forskjellige angrepsflater.
Er en RSA-PSS-signatur større enn en PKCS#1 v1.5-signatur?
Nei. Ved en gitt nøkkelstørrelse, for eksempel RSA-2048, er signaturen alltid nøyaktig like stor uavhengig av padding, nemlig 256 byte. Dette bekreftet vi selv ved å generere begge signaturtypene med samme nøkkel under research til denne artikkelen.
Kan jeg bruke RSA-PSS med SSH?
Ikke for selve autentiseringssignaturen. SSH-protokollen definerer kun PKCS#1 v1.5-baserte RSA-signaturskjemaer (rsa-sha2-256 og rsa-sha2-512) og har ikke standardisert en PSS-variant. Ønsker du et moderne signaturskjema med sterkere formelt sikkerhetsbevis i SSH, er Ed25519-nøkler et bedre alternativ enn å prøve å tvinge PSS inn i RSA-delen av protokollen.
Er RSA-PSS vesentlig tregere enn PKCS#1 v1.5 i produksjon?
Nei. I våre egne målinger med OpenSSL 3.0.13 var forskjellen i signeringstid under 10 prosent over 500 operasjoner, og verifiseringstiden var praktisk talt identisk. Den rene RSA-operasjonen, som dominerer den totale kostnaden, er fullstendig uavhengig av padding-valg.
Krever skytjenester som AWS KMS og Google Cloud KMS ekstra betaling for RSA-PSS sammenlignet med PKCS#1 v1.5?
Nei. Begge leverandørene fakturerer asymmetriske signer- og verifiseroperasjoner som én kategori uavhengig av hvilket paddingskjema som brukes internt i signaturen. AWS KMS tar $0,15 per 10.000 forespørsler for asymmetriske nøkkeloperasjoner, og Google Cloud KMS tar $0,03 per 10.000 operasjoner, uansett om algoritmen er PSS- eller PKCS1v1.5-basert.
Bør JWT-baserte systemer bytte fra RS256 til PS256?
Bare dersom du kontrollerer, eller kan koordinere med, samtlige verifiserere som konsumerer tokenet. Siden RS256 fortsatt dominerer OAuth- og OpenID Connect-økosystemet, risikerer et ensidig bytte til PS256 å bryte integrasjoner du ikke har synlighet i. For nye, lukkede systemer uten eksisterende integrasjoner er PS256 et godt utgangspunkt fra dag én.
Hva er riktig saltlengde å bruke med RSA-PSS?
Standard praksis, i tråd med RFC 8017, NSA sin CSfC-veiledning for 2026 og CA/Browser Forum sine krav, er en saltlengde lik hash-outputens lengde: 32 byte for SHA-256, 48 byte for SHA-384 og 64 byte for SHA-512. Et nullengde-salt er teknisk tillatt og gjør PSS deterministisk, men er ikke den vanlige eller anbefalte konfigurasjonen. Sjekk alltid at signerer og verifiserer er konfigurert med nøyaktig samme saltlengde og MGF1-hash, siden et avvik her er den vanligste praktiske feilkilden ved PSS-oppsett.
