Hogyan használjuk a PDF titkosítási motorját a Python-ben

Aspose.PDF FOSS for Python (import aspose_pdf) implementálja a PDF jelszóvédelmet byte szinten egy kis belső motorosztály, EncryptionUtils, segítségével, amely a aspose_pdf.engine.encryption része. Itt található a AES-CBC titkosító és a PDF Standard Security Handler kulcs-származtatási algoritmusai (ISO 32000 2-6. revíziói), függetlenül a magasabb szintű Document API rendszertől. Ez az útmutató telepíti a csomagot, és végigvezet három motorfeladaton: nyers bájtok titkosítása és visszafejtése a AES-CBC segítségével, a Standard Security Handler kulcsainak származtatása egy jelszóhoz (2-4. revíziók), valamint a AES-256 kulcsok származtatása az 5/6. revíziójú dokumentumokhoz.

Lépésről lépésre útmutató

2. lépés: Szükséges osztályok importálása

EncryptionUtils nincs újraexportálva a felső szintű aspose_pdf csomagból — importáld közvetlenül a engine.encryption almodulból:

import os
from aspose_pdf.engine.encryption import EncryptionUtils

3. lépés: Adatok titkosítása és visszafejtése a AES-CBC segítségével

encrypt_aes_cbc és decrypt_aes_cbc közvetlenül dolgozik bármely 16-, 24- vagy 32-bájtos kulcson (AES-128, AES-192 vagy AES-256) anélkül, hogy jelszóalapú kulcs-származtatáson mennének keresztül. encrypt_aes_cbc belsőleg PKCS7 kitöltést alkalmaz, és decrypt_aes_cbc eltávolítja azt.

key = os.urandom(32)  # AES-256; 16- and 24-byte keys are also accepted
plaintext = b"Confidential PDF content"

ciphertext = EncryptionUtils.encrypt_aes_cbc(key, plaintext)
decrypted = EncryptionUtils.decrypt_aes_cbc(key, ciphertext)

assert decrypted == plaintext
print("Roundtrip OK, ciphertext length:", len(ciphertext))

4. lépés: Szabványos biztonsági kezelő kulcsainak levezetése egy jelszóhoz (2-4. revíziók)

compute_owner_key_v4 kiszámítja a tulajdonos jelszó értékét (O) az 3.3-as algoritmus szerint, és compute_user_key_v4 kiszámítja a felhasználó jelszó értékét (U) valamint a fájl titkosítási kulcsát a 3.4/3.5 algoritmusok szerint. verify_password_v4 újraszámolja a kulcsot egy jelölt jelszóból, így ellenőrizheted, hogy megnyitja-e a dokumentumot, mielőtt megbízol benne.

owner_password = "owner-secret"
user_password = "user-secret"
key_length = 16   # 128-bit (AES/RC4); Revision 2 uses 5 (40-bit)
revision = 4
file_id = os.urandom(16)
permissions = -4  # standard PDF permissions value

o_value = EncryptionUtils.compute_owner_key_v4(
    owner_password, user_password, key_length, revision
)

u_value, encryption_key = EncryptionUtils.compute_user_key_v4(
    user_password, o_value, permissions, file_id, key_length, revision
)

verified_key = EncryptionUtils.verify_password_v4(
    user_password, u_value, o_value, permissions, file_id, key_length, revision
)
assert verified_key == encryption_key

ciphertext = EncryptionUtils.encrypt_aes_cbc(verified_key, b"Confidential PDF content")
decrypted = EncryptionUtils.decrypt_aes_cbc(verified_key, ciphertext)
assert decrypted == b"Confidential PDF content"

o_value és u_value mindig 32 bájt hosszú, függetlenül key_length-tól. verify_password_v4 visszaadja a None értéket — nem kivételt — ha a jelszó nem egyezik.

5. lépés: AES-256 kulcsainak levezetése 5/6 revíziós dokumentumokhoz

Az 5- és 6-os revízió biztonsági kezelői (AES-256) nem használják a compute_owner_key_v4/compute_user_key_v4 kombinációt — a jelszót a compute_hash_v5 segítségével hash-elik, amely az ISO 32000-2 „2.B algoritmusát” valósítja meg. Használd a generate_file_id-t egy új fájlazonosítóhoz, és a derive_object_key-t a fájl titkosítási kulcs egy adott közvetett objektumra történő átalakításához.

password = b"SecurePassword123"
salt = os.urandom(8)

password_hash = EncryptionUtils.compute_hash_v5(password, salt)
assert len(password_hash) == 32

file_id = EncryptionUtils.generate_file_id()
assert len(file_id) == 16

file_key = os.urandom(32)
object_key = EncryptionUtils.derive_object_key(file_key, 12, 0, use_aes=True)
assert len(object_key) == 16

derive_object_key összekeveri az objektumszámot és a generációs számot a fájlkulcsba, így minden közvetett objektum saját kulcsot kap, bár a fájlkulcs közös.

Gyakori problémák és megoldások

encrypt_aes_cbc/decrypt_aes_cbc felveti a “AES key must be 16, 24, or 32 bytes”. A kulcs argumentumnak valódi AES kulcsnak kell lennie, nem egy nyers jelszókarakterláncnak. Generálj egyet a következővel os.urandom(16 | 24 | 32), vagy először leszármaztass egyet a következővel compute_user_key_v4 (Revisions 2-4) vagy compute_hash_v5 (Változatok 5/6).

verify_password_v4 returns None a felvetés helyett. Ez azt jelenti, hogy a jelszó nem egyezett — ez nem egy elkapandó hibaállapot, csak egy ellenőrzendő eredmény. Győződj meg arról is, hogy permissions, file_id, key_length, és revision azonos értékek, amelyeket a dokumentum o_value and u_value eredetileg számították; ha valamelyik eltér, az csendben hibás kulcsot eredményez ahelyett, hogy hangosan hibát jelezne.

compute_owner_key_v4 üres tulajdonosi jelszóval. Passing "" for owner_password a specifikáció által meghatározott viselkedés, nem hiba — az algoritmus visszatér a felhasználói jelszó használatához, így a tulajdonos és a felhasználói jelszó egyenlővé válik.

A helytelen revízióhoz vagy kulcshosszhoz származtatott kulcsok. A 2-es revízió 40-bites (5-byte) RC4 kulcsokat használ, a 3/4-es revízió 128-bites (16-byte) RC4/AES kulcsokat, és az 5/6-os revízió compute_hash_v5 helyett compute_owner_key_v4/compute_user_key_v4 teljesen. Ezek keverése nem dob kivételt — csak egy olyan kulcsot eredményez, amely nem tudja megnyitni a dokumentumot.

compute_hash_v5 a kimenet váratlanul megváltozik. A harmadik argumentum (user_key) bele van keverve a hash-be. Adja át b"" kifejezetten, amikor egyszerű jelszó-ellenőrző hash-t szeretne, mivel annak elhagyása nem ugyanaz, mint egy üres érték átadása minden hívási helyen.

Gyakran Ismételt Kérdések

Miért nem importálható a `EncryptionUtils` közvetlenül a `aspose_pdf`-ból?

A engine alcsomagban található, mert a dokumentumszintű jelszóvédelem belső megvalósítási részlete, nem a magas szintű nyilvános API felület része. Importáld explicit módon a aspose_pdf.engine.encryption-ből.

Az `compute_hash_v5` ugyanaz, mint egyetlen SHA-256 hívás?

Nem. Az ISO 32000-2 Algorithm 2.B-t valósítja meg, amely több körön keresztül különböző hash algoritmusokat használ, a közbenső értékek által kiválasztva — szándékosan drágább, mint egyetlen hash hívás.

A `generate_file_id()` minden alkalommal ugyanazokat a bájtokat adja vissza?

Nem — minden hívásnál egy friss, véletlenszerű 16 bájtos értéket ad vissza. Egy különböző fájlazonosító minden belőle származó kulcsot megváltoztat, még akkor is, ha a jelszó azonos.

Az összes indirekt objektum egy titkosított PDF-ben ugyanazt a kulcsot használ?

Nem. A derive_object_key kombinálja az objektumszámot és a generációs számot a fájl titkosítási kulcsával, így minden indirekt objektum egy különálló, objektumspecifikus kulcsot kap.

Az alkalmazáskódnak közvetlenül kellene meghívnia a `EncryptionUtils`-t a PDF jelszóval való védelméhez?

Általában nem. A EncryptionUtils az alacsony szintű motor, amelyre a dokumentumszintű jelszó API-k épülnek. A legtöbb alkalmazásnak a PDF-eket a dokumentumszintű API segítségével kellene védenie, és csak egyedi eszközök vagy titkosított fájlok forenzikus vizsgálata esetén kellene EncryptionUtils-hez nyúlnia.