Å sikre en standard 5-siders faktura med AES-256 er trivielt. Imidlertid, når man får i oppgave å kryptere et 2 GB PDF-arkiv som inneholder 1,6 millioner objekter, vil standard PDF-biblioteker ofte bringe en server i kne, enten ved å tømme systemminnet eller bruke flere minutter på å fullføre et enkelt dokument.
Flaskehalsen er ikke selve AES-kryptografialgoritmen; moderne CPU-er utfører AES-instruksjoner blendende raskt. Det faktiske problemet ligger i hvordan tradisjonelle PDF-biblioteker håndterer dokumentmanipulering. Her dissekerer vi ytelsesfellene ved DOM-basert kryptering og hvordan en arkitektur for "direkte omskriving" løser dem.
Problemet med DOM-basert kryptering
Når et standard PDF-bibliotek krypterer en fil, utfører det vanligvis følgende arbeidsflyt:
- Last inn dokumentet: Hele dokumentet analyseres til et DOM-tre (Document Object Model) i minnet.
- Gjennomgå og krypter: Biblioteket itererer over hvert objekt. For strømmer og strenger tildeler det en ny minneblokk, utfører AES-krypteringen, og lagrer den krypterte blob-en i DOM-en.
- Serialiser: Biblioteket skriver hele DOM-en tilbake til disk, og regenererer XRef-tabellene.
For et 2 GB-dokument bruker trinn 1 massive mengder RAM. Trinn 2 oppretter millioner av midlertidige tildelinger for strenger og strømbuffere, noe som forårsaker aggressiv minnefragmentering og overhead for søppelrydding/referansetelling. Trinn 3 tvinger frem en fullstendig omskriving av dokumentstrukturen. Resultatet? En prosess som tar minutter i stedet for sekunder.
Arkitekturen for direkte filomskriving
For å kryptere massive filer effektivt, må vi forlate DOM-en. I stedet bruker vi en tilnærming med direkte filomskriving. I en direkte omskriving opererer biblioteket på dokumentet hovedsakelig som en strøm av tokens, og utfører en fil-til-fil-transformasjon uten noen gang å instansiere det fulle objekttreet.
Hvordan det fungerer
I en direkte AES-256 krypteringsprosess:
- Målrettet analysering: Biblioteket identifiserer grensene for individuelle objekter og strømmer direkte fra kildefilen ved hjelp av en skyvevindusbuffer.
- Kryptografi underveis: Når en streng eller strøm påtreffes, sendes den gjennom AES-chifferet og strømmes umiddelbart til utdatafilen. Ingen mellomliggende DOM-objekter opprettes.
- Ordboks-gjennomgang: Strukturelle elementer som matriser, objektnumre og ordboknøkler skrives direkte til utdataene ordrett.
- Nøkkelhåndtering: I motsetning til eldre RC4-implementeringer der krypteringsnøkkelen endres per objekt, bruker AES-256 i PDF (revisjon 6) en global filnøkkel. Dette gjør at den direkte banen kan bruke nøyaktig samme nøkkelkontekst for hver strøm, noe som ytterligere reduserer overhead.
Overvinne tekniske grensetilfeller
Mens direkte omskriving er ekstremt rask, introduserer den strenge analyseringsutfordringer. Parseren må perfekt koble ordboksavgrensere (<< og >>) for å unngå å feilidentifisere en ordbokgrense som en åpningsparentes for en hex-streng (<). En feil her resulterer i at hele ordboken krypteres som en streng, og ødelegger dokumentet.
Videre er tomme strenger i PDF-er helt lovlige. Kryptering av en tom streng gir en tom chiffertekst. En naiv parser kan behandle en tom retur fra AES-rutinen som en feil og avbryte den direkte omskrivingen; en robust parser anerkjenner den som gyldig utdata.
Ytelsesgevinster
I referansetester fra den virkelige verden ved bruk av PDFlibPas-biblioteket, reduserte forbigåelse av DOM-en og bruk av en bufret direkte omskriving krypteringstiden for en 2 GB, 1,67 millioner objekters PDF fra omtrent 122 sekunder ned til bare 32 sekunder. Dette er nesten en firedobling i hastighet, med en jevn gjennomstrømning på 60+ MB/s, mens minneforbruket holdes nær null.
Når man utvikler dokumentbehandlingsrørledninger med høy gjennomstrømning, er å behandle PDF-en som en datastrøm i stedet for en datastruktur den ultimate nøkkelen til å låse opp ytelse.
Merk: Arkitekturen for direkte filomskriving for høyhastighets AES-256-kryptering er implementert i PDFlibPas Component.
\n