Hoe Java te versleutelen: Aangepaste XOR‑versleuteling met GroupDocs

Introductie

Hier is een scenario dat je waarschijnlijk al bent tegengekomen: je bouwt een applicatie die documenten digitaal moet ondertekenen, maar de ingebouwde versleutelingsopties passen niet helemaal bij je eisen. Misschien werk je met legacy‑systemen die een specifiek versleutelingsformaat verwachten, of heb je lichte versleuteling nodig voor prestatie‑kritische toepassingen waarbij zware algoritmen zoals AES overbodig zouden zijn.

Dat is waar aangepaste versleuteling van pas komt — en het is makkelijker te implementeren dan je misschien denkt. In deze gids lopen we stap voor stap door het maken van een aangepast versleutelingsmechanisme met de XOR‑bewerking als voorbeeld. Hoewel XOR‑versleuteling niet geschikt is voor toepassingen met hoge beveiligingsvereisten (we bespreken wanneer je het wel en niet moet gebruiken), is het perfect om de principes van hoe Java te versleutelen te leren en om niche‑integratiebehoeften te vervullen. We gebruiken GroupDocs.Signature for Java, dat het integreren van aangepaste versleuteling in je documentondertekeningsworkflow verrassend eenvoudig maakt.

Dit leer je:

Waarom je in de eerste plaats aangepaste versleuteling zou willen
Hoe XOR‑versleuteling werkt (in gewone taal)
Stapsgewijze implementatie met GroupDocs.Signature for Java
Praktijkvoorbeelden en beveiligingsoverwegingen
Veelvoorkomende fouten en hoe je ze kunt vermijden

Snelle antwoorden

Wat is XOR‑versleuteling? Een symmetrische bewerking die bits omdraait met een sleutel; tweemaal versleutelen met dezelfde sleutel herstelt de oorspronkelijke data.
Wanneer moet ik aangepaste versleuteling gebruiken? Voor legacy‑systeemcompatibiliteit, prestatie‑kritische obfuscatie, of leerdoeleinden — niet voor het beschermen van gevoelige data.
Welke bibliotheek gebruikt deze tutorial? GroupDocs.Signature for Java (v23.12 of later).
Heb ik een licentie nodig? Een gratis proefversie werkt voor testen; een volledige licentie is vereist voor productie.
Kan ik XOR later vervangen door AES? Ja — vervang gewoon de encrypt/decrypt‑logica en behoud de IDataEncryption‑interface.

Hoe Java te versleutelen met XOR

XOR‑versleuteling is een klassiek java xor example dat het kernidee van symmetrische versleuteling demonstreert. Door deze tutorial te volgen zie je precies hoe je een aangepast algoritme in de GroupDocs.Signature Java‑workflow kunt pluggen, waardoor je volledige controle krijgt over hoe ondertekeningsdata wordt beschermd.

Waarom aangepaste versleuteling belangrijk is

Voordat we in de code duiken, laten we bespreken waarom je überhaupt aangepaste versleuteling nodig zou kunnen hebben.

De meeste bibliotheken (inclusief GroupDocs) hebben ingebouwde versleutelingsopties. Waarom zou je dan je eigen oplossing maken? Hier zijn de real‑world scenario’s waarin aangepaste versleuteling zinvol is:

Legacy‑systeemintegratie: Je werkt met oudere systemen die data verwachten die op een specifieke manier versleuteld is. Het hele systeem wijzigen is niet haalbaar, dus moet je hun versleutelingsmethode evenaren.

Prestatie‑optimalisatie: Standaardalgoritmen zoals AES zijn veilig maar computationeel duur. Voor niet‑gevoelige data die toch enige obfuscatie nodig heeft (bijvoorbeeld watermerken of interne document‑ID’s) kan een lichte, aangepaste aanpak de prestaties aanzienlijk verbeteren.

Propriëtaire eisen: Sommige branches of klanten eisen specifieke versleutelingsimplementaties voor compliance of compatibiliteit.

Leren en flexibiliteit: Begrijpen hoe je aangepaste versleuteling implementeert geeft je de kennis om beveiligingsoplossingen te evalueren en aan te passen aan unieke eisen.

Dat gezegd hebbende (en dit is belangrijk), moet aangepaste versleuteling nooit je eerste keuze zijn voor het beschermen van gevoelige data. Voor alles wat persoonlijke informatie, financiële data of gereguleerde inhoud betreft, blijf je bij bewezen algoritmen zoals AES‑256. Aangepaste versleuteling is het best gereserveerd voor specifieke use‑cases waarin je de beveiligingsafwegingen begrijpt.

XOR begrijpen: de basis

Als je niet bekend bent met XOR (Exclusive OR), geen zorgen — het is een van de simpelste versleutelingsconcepten die er bestaan.

XOR is een binaire bewerking die twee bits vergelijkt en 1 teruggeeft als ze verschillend zijn, 0 als ze gelijk zijn:

0 XOR 0 = 0
0 XOR 1 = 1
1 XOR 0 = 1
1 XOR 1 = 0

Wat XOR interessant maakt voor versleuteling is dat het symmetrisch is: als je data XOR‑t met een sleutel, en vervolgens het resultaat opnieuw XOR‑t met dezelfde sleutel, krijg je de oorspronkelijke data terug. Het is als een slot dat dezelfde sleutel gebruikt om zowel te vergrendelen als te ontgrendelen.

Hier is een eenvoudig java xor example:

Original data: 5 (binary: 0101)
Key: 3 (binary: 0011)
Encrypted: 5 XOR 3 = 6 (binary: 0110)
Decrypted: 6 XOR 3 = 5 (binary: 0101) ← We're back!

In de praktijk XOR‑en we elk byte van onze data met onze sleutelwaarde. Het is snel, vereist minimale geheugen en is perfect om aangepaste versleutelingsconcepten te demonstreren. Onthoud alleen: XOR met een één‑byte sleutel is triviaal te breken voor iedereen met basiskennis van cryptografie. Gebruik het voor obfuscatie, niet voor bescherming.

Voorvereisten

Voordat je aangepaste versleuteling implementeert met GroupDocs.Signature for Java, zorg je dat je het volgende hebt:

Vereiste bibliotheken en afhankelijkheden

GroupDocs.Signature for Java: Versie 23.12 of later (de API waarmee we werken)
Java Development Kit: JDK 8 of hoger (JDK 11+ wordt aanbevolen voor productie)

Omgevingsvereisten

Een IDE zoals IntelliJ IDEA, Eclipse of VS Code met Java‑extensies
Maven of Gradle voor afhankelijkheidsbeheer (de voorbeelden hieronder werken met beide)

Kennisvereisten

Vertrouwd met Java‑code (klassen, methoden en interfaces)
Basisbegrip van versleutelingsconcepten (we hebben net XOR behandeld, dus je bent klaar!)
Bekendheid met byte‑arrays en bitwise‑operaties helpt, maar is niet verplicht

Alles klaar? Geweldig! Laten we GroupDocs opzetten.

GroupDocs.Signature for Java installeren

GroupDocs in je project krijgen is eenvoudig. Kies je build‑tool:

Maven

<dependency>
    <groupId>com.groupdocs</groupId>
    <artifactId>groupdocs-signature</artifactId>
    <version>23.12</version>
</dependency>

Gradle

implementation 'com.groupdocs:groupdocs-signature:23.12'

Directe download
Als je liever handmatig downloadt (of geen build‑tool kunt gebruiken), haal je de JAR op van GroupDocs.Signature for Java releases en voeg je deze toe aan de classpath van je project.

Stappen voor licentie‑acquisitie

GroupDocs is niet gratis, maar ze maken een proefversie makkelijk:

Gratis proefversie: Download en gebruik alle functies met enkele beperkingen (watermerken op output, evaluatie‑restricties)
Tijdelijke licentie: Vraag een tijdelijke licentie aan voor een volledige evaluatie (handig voor POC’s)
Aankoop: Koop een licentie wanneer je klaar bent voor productie

Basisinitialisatie en setup

Hier is de meest basale GroupDocs‑initialisatie — dit is de fundering voor elk voorbeeld:

import com.groupdocs.signature.Signature;

class InitializeGroupDocs {
    public static void main(String[] args) {
        Signature signature = new Signature("path/to/your/document");
        // Additional setup and operations can be performed here.
    }
}

Eenvoudig, toch? Dat Signature‑object is je hoofd‑interface voor alle documentondertekeningsacties. Nu laten we het daadwerkelijk iets laten versleutelen.

Implementatie‑gids

Aangepaste XOR‑versleutelingsfunctie

Hier komen we bij de eigenlijke implementatie. We gaan een aangepaste versleutelingsklasse maken die GroupDocs kan gebruiken wanneer het ondertekeningsdata moet versleutelen.

Stap 1: Implementatie van de IDataEncryption‑interface

GroupDocs verwacht dat versleutelingshandlers de IDataEncryption‑interface implementeren. Dit is je contract — implementeer deze methoden en GroupDocs weet hoe jouw versleuteling moet worden gebruikt:

import com.groupdocs.signature.domain.extensions.encryption.IDataEncryption;

class CustomXOREncryption implements IDataEncryption {
    private int auto_Key;
    
    public final int getKey() {
        return auto_Key;
    }
    
    // Additional methods for encryption and decryption will be implemented here.
}

Wat er gebeurt: We definiëren een klasse die belooft encryptie‑/decryptiefuncties te leveren. Het auto_Key‑veld slaat onze XOR‑sleutel op (het getal waarmee we XOR‑en). De getKey()‑methode laat andere code zien welke sleutel we gebruiken.

Stap 2: Definieer encryptie‑ en decryptiemethoden

Nu de eigenlijke versleutelingslogica. Omdat XOR symmetrisch is (onthoudt?), zijn encryptie en decryptie letterlijk dezelfde bewerking:

class CustomXOREncryption {
    private int auto_Key;

    public byte[] encrypt(byte[] data) {
        if (auto_Key == 0 || data == null) return data;
        
        byte[] result = new byte[data.length];
        for (int i = 0; i < data.length; i++) {
            result[i] = (byte) (data[i] ^ auto_Key);
        }
        return result;
    }

    public byte[] decrypt(byte[] encryptedData) {
        // Since XOR is symmetric, use the same method as encryption
        return encrypt(encryptedData);
    }
}

Uitleg:

We controleren of de sleutel 0 is (wat nutteloos zou zijn) of of we null data hebben ontvangen (voorkomt crashes)
We maken een nieuw byte‑array aan voor het versleutelde resultaat
We lopen door elk byte van de invoerdata
Voor elk byte XOR‑en we het met onze sleutel: data[i] ^ auto_Key
De (byte)‑cast is nodig omdat XOR in Java een int oplevert, maar we bytes willen

De schoonheid van XOR: decrypt() roept simpelweg encrypt() opnieuw aan. Dezelfde bewerking die de data verwart, maakt hem weer leesbaar!

Sleutel‑configuratie‑opties

auto_Key: Dit is je versleutelingssleutel. Enkele belangrijke punten:

Moet verschillend van nul zijn (XOR met 0 doet niets)
Moet tussen 1‑255 liggen voor één‑byte XOR (waarden boven 255 gebruiken alleen de lagere 8 bits)
In echte toepassingen kun je dit configureerbaar maken via omgevingsvariabelen of configuratie‑bestanden
Voor productie wil je een veel geavanceerder sleutel‑beheersysteem

Voorbeeld van instellen:

CustomXOREncryption encryption = new CustomXOREncryption();
encryption.setKey(42); // Any non-zero value works

Veelvoorkomende implementatiefouten

We besparen je wat debug‑tijd. Hier zijn fouten die ik (en anderen) ben tegengekomen:

Fout #1: De sleutel vergeten in te stellen

CustomXOREncryption encryption = new CustomXOREncryption();
// Oops! Never called setKey(), so auto_Key is 0
byte[] encrypted = encryption.encrypt(myData); // Returns data unchanged!

Oplossing: Initialiseert altijd je sleutel vóór gebruik van de versleuteling.

Fout #2: Geen handling voor null‑data
Zonder de if (data == null) return data;‑check krijg je NullPointerExceptions op het slechtst mogelijke moment.

Fout #3: Aannemen dat XOR veilig is
Deze versleuteling is triviaal te breken. Als iemand een deel van je platte tekst kent of raadt, kan hij je sleutel afleiden. Gebruik het voor obfuscatie, niet voor beveiliging.

Fout #4: De verkeerde sleutel gebruiken voor decryptie
Omdat je dezelfde sleutel nodig hebt om te decrypten, betekent verlies of wijziging van de sleutel dat je data voor altijd verloren is. In productie wil je proper sleutel‑beheer en back‑up‑strategieën.

Beveiligingsoverwegingen

Laten we eerlijk zijn over beveiliging, want dit is cruciaal:

XOR‑versleuteling is NIET veilig voor gevoelige data

Ik kan dit niet genoeg benadrukken. Een één‑byte XOR‑cipher zoals we hebben geïmplementeerd kan in seconden worden gekraakt door iedereen met basiscryptografische kennis. Waarom:

Frequentie‑analyse – Als iemand iets weet over je data‑formaat (en dat doet hij meestal), kan hij veelvoorkomende byte‑waarden raden en terugwerken naar je sleutel.
Known‑plaintext‑aanvallen – Als een aanvaller zelfs maar een deel van de platte tekst kent, kan hij die XOR‑en met de ciphertext om de sleutel te krijgen.
Brute force – Met slechts 255 mogelijke sleutels kun je ze allemaal in milliseconden proberen.

Wanneer XOR‑versleuteling wel geschikt is:

Obfuscatie van niet‑gevoelige interne identifiers
Snelle data‑manipulatie voor cache‑sleutels of tijdelijke data
Leren van versleutelingsconcepten
Voldoen aan legacy‑systeemvereisten die XOR gebruiken
Prestatie‑kritische toepassingen waarbij beveiliging op andere lagen wordt afgehandeld

Wanneer echte versleuteling gebruiken:

Persoonlijke informatie (namen, e‑mailadressen, adressen)
Financiële data
Gezondheidsinformatie
Authenticatie‑referenties
Elke data die onder regelgeving valt (GDPR, HIPAA, PCI‑DSS)

Betere alternatieven:

AES‑256 – Industriestandaard, uitstekende security‑to‑performance ratio
RSA – Ideaal voor het versleutelen van kleine hoeveelheden data zoals sleutels
ChaCha20 – Moderne vervanger voor AES, soms sneller op mobiele apparaten

Het goede nieuws? Het implementatie‑patroon dat we gebruiken (de IDataEncryption‑interface) werkt op dezelfde manier voor elk versleutelingsalgoritme. Je kunt XOR eenvoudig vervangen door AES door alleen de encrypt()‑ en decrypt()‑methoden aan te passen.

Praktische toepassingen

Nu we het “wat” en “waarom” hebben behandeld, laten we kijken naar real‑world scenario’s waarin dit echt wordt gebruikt:

1. Beveiligde documentondertekeningsworkflow

Stel je een contractmanagement‑systeem voor waarin documenten digitale handtekeningen nodig hebben, maar de ondertekeningsmetadata (ondertekenaar‑ID, tijdstempel, afdeling) moet eerst basaal worden geobfusceerd vóór opslag:

Signature signature = new Signature("contract.pdf");
CustomXOREncryption encryption = new CustomXOREncryption();
encryption.setKey(73); // Configure your key

// GroupDocs will use your encryption for signature data
// (Actual integration depends on specific GroupDocs API methods)

Werkelijk voordeel: Je database bevat geen platte metadata die kan worden gescraped of per ongeluk in logs verschijnt.

2. Data‑integriteitsverificatie

Je kunt aangepaste versleuteling gebruiken als een lichte integriteitscontrole. Versleutel een bekende waarde, sla die op samen met je document, en decrypt later om te verifiëren:

String integrityToken = "VALID_SIGNATURE_2025";
byte[] encrypted = encryption.encrypt(integrityToken.getBytes());
// Store encrypted with document...
// Later, decrypt and compare to verify nothing changed

Dit is geen cryptografisch niveau van integriteit (gebruik HMAC daarvoor), maar het vangt accidentele corruptie op.

3. Integratie met legacy‑systemen

Waarschijnlijk het meest voorkomende scenario. Je moderniseert een applicatie, maar moet communiceren met een systeem uit het begin van de jaren 2000 dat XOR‑versleutelde data verwacht:

// Old system expects data encrypted with XOR key 42
CustomXOREncryption legacyEncryption = new CustomXOREncryption();
legacyEncryption.setKey(42);

// Encrypt data before sending to legacy system
byte[] dataForOldSystem = legacyEncryption.encrypt(modernData);
sendToLegacyAPI(dataForOldSystem);

Je kiest niet voor XOR omdat het beter is — je kiest het omdat dat het andere systeem begrijpt.

Prestatie‑overwegingen

Een reden om lichte versleuteling zoals XOR te gebruiken is performance. Maar zelfs eenvoudige bewerkingen kunnen knelpunten worden als je niet oppast. Let op het volgende:

Performance optimaliseren

Voor kleine data (< 1 KB) – De bovenstaande XOR‑implementatie is prima. De overhead is verwaarloosbaar.

Voor grote documenten (> 10 MB) – Overweeg deze optimalisaties:

In blokken verwerken – In plaats van het volledige document in één keer te XOR‑en, verwerk je het in beheersbare stukken (bijv. 4 KB).
Parallel verwerken – Voor zeer grote bestanden kun je het werk over meerdere threads verdelen.
Onnodige kopieën vermijden – Onze implementatie maakt een nieuw byte‑array, wat tijdelijk het geheugen verdubbelt.

// More memory‑efficient for large data
public void encryptInPlace(byte[] data) {
    if (auto_Key == 0 || data == null) return;
    
    for (int i = 0; i < data.length; i++) {
        data[i] = (byte) (data[i] ^ auto_Key);
    }
}

Richtlijnen voor resource‑gebruik

Geheugen – De huidige implementatie vereist:

Originele data in het geheugen
Versleutelde data in het geheugen (zelfde grootte)
Tijdelijke objecten tijdens verwerking

Voor een document van 50 MB moet je ongeveer 100 MB geheugen rekenen tijdens versleuteling.

CPU – XOR is extreem snel — meestal onder 1 ms voor kleine documenten (< 100 KB). Ruwe schattingen op moderne hardware:

1 MB ≈ 10 ms
10 MB ≈ 100 ms
100 MB ≈ 1 s

Deze cijfers variëren afhankelijk van CPU, geheugensnelheid en JVM‑optimalisaties.

Best practices voor Java‑geheugenbeheer

Wanneer je met versleuteling in Java werkt, houd het volgende in gedachten:

Gevoelige data wissen – Nadat je de sleutel of gedecrypteerde data niet meer nodig hebt, wis je ze expliciet:
```
Arrays.fill(decryptedData, (byte) 0); // Overwrite with zeros
```

Gebruik try‑with‑resources – Zorg dat streams automatisch worden gesloten:

try (FileInputStream fis = new FileInputStream("encrypted.dat")) {
    // Process data
} // Automatically closed

Heap‑gebruik monitoren – Voor applicaties die veel documenten verwerken, overweeg -XX:+UseG1GC voor betere garbage collection.
Vermijd String voor binaire data – Converteer versleutelde bytes nooit naar String en terug — dat corrumpeert de data. Houd ze als byte‑arrays.

Veelvoorkomende problemen oplossen

Probleem 1: “Data decrypts to garbage”

Symptomen – Na decryptie krijg je willekeurige bytes in plaats van de oorspronkelijke data.

Oorzaken – Andere sleutel gebruikt voor decryptie, data‑corruptie tijdens opslag/transmissie, of bytes naar String geconverteerd.

Oplossing – Controleer dat je exact dezelfde sleutel gebruikt en houd data als byte‑arrays gedurende het hele proces.

Probleem 2: “NullPointerException tijdens encryptie”

Symptomen – Crash met NullPointerException bij aanroep van encrypt().

Oorzaak – null data doorgegeven aan de methode.

Oplossing – Zorg voor een null‑check in je encrypt/decrypt‑methoden (zoals in de implementatie).

Probleem 3: “Geen zichtbare encryptie”

Symptomen – Versleutelde data ziet er identiek uit aan de platte tekst.

Oorzaak – Sleutel is 0 of nooit ingesteld.

Oplossing – Voeg een assertie toe tijdens ontwikkeling:

assert auto_Key != 0 : "Encryption key must be set!";

Probleem 4: “OutOfMemoryError bij grote bestanden”

Symptomen – Applicatie crasht bij het versleutelen van grote documenten.

Oorzaak – Het volledige bestand in één keer in het geheugen laden.

Oplossing – Verwerk bestanden in streams/blokken:

try (FileInputStream in = new FileInputStream(path);
     FileOutputStream out = new FileOutputStream(encryptedPath)) {
    byte[] buffer = new byte[4096];
    int bytesRead;
    while ((bytesRead = in.read(buffer)) != -1) {
        encryptInPlace(buffer, 0, bytesRead);
        out.write(buffer, 0, bytesRead);
    }
}

Conclusie

We hebben veel behandeld! Je weet nu hoe Java te versleutelen met XOR als leervoorbeeld, hoe je het integreert met GroupDocs.Signature, en wanneer (en wanneer niet) je aangepaste versleuteling moet gebruiken.

Belangrijkste inzichten

Aangepaste versleuteling is nuttig voor specifieke scenario’s (legacy‑systemen, prestatie‑behoeften, leren)
XOR is uitstekend om principes te begrijpen, maar niet om gevoelige data te beveiligen
GroupDocs.Signature maakt integratie eenvoudig via de IDataEncryption‑interface
Overweeg altijd de beveiligingsimplicaties voordat je zelf iets gaat bouwen

Volgende stappen

AES‑versleuteling implementeren – Pas de CustomXOREncryption‑klasse aan om AES te gebruiken (Java’s javax.crypto‑pakket maakt dit eenvoudig).
Sleutelrotatie toevoegen – Bouw een systeem dat encryptiesleutels kan wisselen zonder toegang tot bestaande data te verliezen.
Meer GroupDocs‑features verkennen – Bekijk handtekening‑verificatie, sjabloon‑creatie en multi‑handtekening‑workflows.

Het patroon dat je hier geleerd hebt — een interface implementeren om aangepast gedrag te leveren — wordt overal in de GroupDocs‑API gebruikt. Beheers dit, en je zult talloze mogelijkheden vinden om de bibliotheek aan jouw wensen aan te passen.

Ga nu iets versleutelen! (Zorg er alleen voor dat het niets echt beveiligd moet worden totdat je bent overgestapt op een echte encryptie‑algoritme.)

FAQ‑sectie

1. Hoe kies ik een geschikte XOR‑sleutel?

Voor XOR werkt elke niet‑nul integer, maar de sleutel zelf voegt geen beveiliging toe. Als je echt beveiliging nodig hebt, gebruik dan geen XOR — schakel over naar AES of een ander bewezen algoritme. Voor obfuscatie kun je gewoon een willekeurige waarde tussen 1‑255 kiezen en die veilig in je configuratie opslaan.

2. Kan ik de XOR‑sleutel dynamisch wijzigen tijdens runtime?

Absoluut! Roep gewoon setKey() aan met een nieuwe waarde. Houd er wel rekening mee dat data die met de oude sleutel is versleuteld, moet worden gedecrypt met die oude sleutel. Als je sleutels wijzigt, moet je bestaande data opnieuw versleutelen of bijhouden welke sleutel voor welke data is gebruikt. Daarom is sleutelbeheer een eigen discipline binnen cryptografie.

3. Wat zijn alternatieven voor XOR‑versleuteling?

Voor leer‑ en niet‑beveiligingsdoeleinden: Caesar‑cipher, ROT13, base64‑encoding (geen encryptie, wel obfuscatie).

Voor echte beveiliging: AES‑256 (symmetrisch), RSA‑2048+ (asymmetrisch), ChaCha20 (modern symmetrisch). Java’s javax.crypto‑pakket ondersteunt al deze algoritmen.

4. Hoe gaat GroupDocs.Signature om met grote bestanden en versleuteling?

GroupDocs is geoptimaliseerd voor grote bestanden en maakt waar mogelijk streaming gebruik. Jouw eigen versleutelingsimplementatie kan echter een bottleneck vormen als je niet oppast. Voor bestanden groter dan 50 MB implementeer je chunk‑gebaseerde verwerking in je encrypt/decrypt‑methoden in plaats van alles in één keer in het geheugen te laden.

5. Is het mogelijk dit te integreren in een webapplicatie?

Zeker! Gebruik Spring Boot, Jakarta EE of een ander Java‑webframework. Enkele tips:

Maak je versleutelingsklasse een singleton of application‑scoped bean
Bewaar je sleutel in omgevingsvariabelen, niet hard‑coded
Overweeg data te versleutelen vóór het de applicatieserver verlaat
Let op geheugenverbruik bij gelijktijdige uploads van grote documenten

Voorbeeld Spring Boot‑integratie:

@Component
public class EncryptionService {
    private CustomXOREncryption encryption;
    
    public EncryptionService(@Value("${app.encryption.key}") int key) {
        this.encryption = new CustomXOREncryption();
        this.encryption.setKey(key);
    }
    // Use in your controllers...
}

6. Kan ik dit gebruiken met PDF‑documenten?

Ja! GroupDocs.Signature ondersteunt PDF’s, naast Word‑documenten, Excel‑spreadsheets, afbeeldingen en meer. De versleuteling vindt plaats op het niveau van de ondertekeningsdata, niet op het volledige document, dus het werkt met elk ondersteund formaat.

7. Wat gebeurt er als ik mijn versleutelingssleutel verlies?

Bij symmetrische versleuteling (zoals XOR) betekent verlies van de sleutel permanente dataverlies. Er is geen herstelmechanisme. In productiesystemen wil je:

Sleutel‑back‑up‑systemen
Sleutel‑escrow voor gereguleerde branches
Sleutelrotatie‑beleid met overlap‑perioden
Audit‑logs van sleutelgebruik

Dit is een extra reden om gevestigde encryptiebibliotheken te gebruiken — zij bieden vaak ingebouwde sleutelbeheer‑tools.

Resources

Laatst bijgewerkt: 2026-02-18
Getest met: GroupDocs.Signature 23.12 for Java
Auteur: GroupDocs