Kryptografipolicy: Tillit gjennom implementering

TL;DR: AES-256 for data i ro. TLS 1.3 for data under overføring. AWS KMS til nøkkelstyring. Årlig rotasjon. SSL Labs A+. Ingen bakdører, ingen utdaterte algoritmer. Implementeringen beviser ekspertise.

Tenk selv, dust! Still spørsmål ved autoritet

Ja, selv—spesielt—de myndighetene som godkjenner kryptografiske standarder. Men mens du stiller spørsmål ved motiver og historien med bakdører, skal du implementere systematisk.

ISMS-kryptografi: Kryptografipolicy—systematisk implementering.

Krypteringsstandarder: Hva vi faktisk bruker

Implementering: Beviset på ekspertise

Alle snakker om kryptering. Vi implementerer det:

Hvorfor disse valgene?

AES-256: Ingen praktiske angrep. NIST-godkjent. Bredt støttet. Maskinvareakselerert på moderne CPU-er.

TLS 1.3: Redusert latens. Forbedret personvern. Færre cipher-suite-feil. Obligatorisk Perfect Forward Secrecy.

AWS KMS: FIPS 140-2 Level 2+ validert. Sentralisert revisjonsspor. Arbeidsdeling. Automatisk rotasjon.

Hva vi ikke bruker (og hvorfor)

Nøkkelstyring: Livssyklus

  1. Generering: HSM-generert, aldri eksponert
  2. Distribusjon: Kryptert kanal, minimal eksponering
  3. Lagring: KMS med tilgangskontroll
  4. Rotasjon: Årlig minimum, etter hendelser
  5. Tilbakekalling: Øyeblikkelig, dokumentert
  6. Destruksjon: Sikker sletting, verifisert

Etterlevelse: Kryss mellom standarder

Den diskordiske tilnærmingen: Spør hvorfor

Hvorfor stoler vi på AES? Fordi 20 års kryptoanalyse ikke har brutt det—ennå. Hvorfor AWS KMS? Fordi vi ikke kan bygge bedre HSM-er selv. Hvorfor TLS 1.3? Fordi TLS 1.2 har for mange legacy-problemer.

Tillit kommer fra implementering, ikke fra påstander.

Test din egen kryptering

Verifiser implementeringen vår:

Videre lesning