Wie man Java verschlüsselt: Benutzerdefinierte XOR‑Verschlüsselung mit GroupDocs

Einführung

Wenn Sie jemals how to encrypt java Code für einen bestimmten Workflow benötigen mussten, kennen Sie die Frustration über integrierte Optionen, die nicht zu Ihrem Legacy‑Protokoll oder Leistungsziel passen. Stellen Sie sich vor, Sie integrieren ein neues Signaturmodul in ein älteres ERP‑System, das eine einfach maskierte XOR‑Payload erwartet. Sie könnten das gesamte ERP neu schreiben, aber ein schnellerer Weg ist, eine leichte benutzerdefinierte Verschlüsselungsschicht direkt in Ihrer Java‑Anwendung hinzuzufügen.

In diesem Leitfaden zeigen wir, wie man einen benutzerdefinierten XOR‑Verschlüsselungsmechanismus erstellt, ihn in GroupDocs.Signature for Java einbindet und diskutieren, wann dieser Ansatz sinnvoll ist und wann Sie zu industrieweit verbreiteten Algorithmen greifen sollten. Am Ende können Sie Signatur‑Metadaten schützen, eigenwillige Integrationsverträge erfüllen und die Vor‑ und Nachteile der Verwendung von XOR in produktionsreifem Code verstehen.

Das werden Sie lernen:

• Warum benutzerdefinierte Verschlüsselung für Legacy‑ und Leistungsszenarien wichtig ist
• Wie XOR‑Verschlüsselung funktioniert (einfach erklärt + Java‑Beispiel)
• Schritt‑für‑Schritt‑Integration mit GroupDocs.Signature for Java
• Praxisbeispiele, Sicherheitsüberlegungen und häufige Fallstricke
• Wie man die XOR‑Implementierung später durch einen stärkeren Algorithmus ersetzt

Schnelle Antworten

• Was ist XOR‑Verschlüsselung? Eine symmetrische Operation, die Bits mit einem Schlüssel umkehrt; zweimalige Verschlüsselung mit demselben Schlüssel stellt die Originaldaten wieder her.
• Wann sollte ich benutzerdefinierte Verschlüsselung einsetzen? Für Legacy‑Systemkompatibilität, leistungs‑kritische Obfuskation oder Lernzwecke – nicht zum Schutz sensibler Daten.
• Welche Bibliothek verwendet dieses Tutorial? GroupDocs.Signature for Java (v23.12 oder neuer).
• Benötige ich eine Lizenz? Eine kostenlose Testversion funktioniert zum Testen; für die Produktion ist eine Voll‑Lizenz erforderlich.
• Kann ich XOR später durch AES ersetzen? Ja – ersetzen Sie einfach die encrypt/decrypt‑Logik, während Sie die gleiche IDataEncryption‑Schnittstelle beibehalten.

Was ist benutzerdefinierte Verschlüsselung in Java?

IDataEncryption ist eine Schnittstelle von GroupDocs.Signature, die Methoden zum Verschlüsseln und Entschlüsseln von Daten definiert. Benutzerdefinierte Verschlüsselung ermöglicht es Ihnen, genau festzulegen, wie Daten vor dem Speichern oder Übertragen transformiert werden. Mit GroupDocs.Signature liefern Sie eine Implementierung der IDataEncryption‑Schnittstelle, und die Bibliothek ruft Ihren Code automatisch auf, wann immer sie Signaturdaten schützen muss. Dieses Plug‑In‑Modell bedeutet, dass Sie mit einer einfachen XOR‑Routine für einen Proof‑of‑Concept beginnen und später durch AES‑256 ersetzen können, ohne den Rest Ihres Signatur‑Workflows zu ändern.

Warum benutzerdefinierte Verschlüsselung wichtig ist

Benutzerdefinierte Verschlüsselung ist wertvoll, wenn vorhandene Algorithmen bestimmte Vorgaben wie Legacy‑Protokollformate, strenge Leistungsbudgets oder proprietäre Vertragsanforderungen nicht erfüllen können. Durch die Implementierung Ihrer eigenen Routine behalten Sie die volle Kontrolle über die Datenumwandlung, reduzieren den Overhead und gewährleisten Kompatibilität, ohne externe Systeme neu zu schreiben, und nutzen gleichzeitig die Erweiterbarkeit von GroupDocs.

Integration von Legacy‑Systemen

Ältere Systeme erfordern manchmal eine sehr spezifische byteweise Transformation – häufig ein XOR mit einem Ein‑Byte‑Schlüssel. Die Neu­entwicklung dieser Systeme ist teuer, daher ist es pragmatisch, ihre Erwartungen mit einem benutzerdefinierten Verschlüsseler zu erfüllen.

Leistungsoptimierung

Standard‑Algorithmen wie AES‑256 sind kryptografisch stark, können aber bemerkenswerte CPU‑Zyklen verbrauchen, insbesondere auf energiearmen Geräten oder bei der Verarbeitung von Millionen kleiner Payloads. XOR läuft mit einer einzigen CPU‑Instruktion pro Byte und liefert nahezu keinen Overhead für nicht‑sensible Daten.

Proprietäre Anforderungen

Bestimmte Verträge oder Industriestandards verlangen einen benutzerdefinierten Algorithmus (z. B. eine staatlich vorgeschriebene „XOR‑Maske“). Die Implementierung der erforderlichen Logik selbst gewährleistet die Konformität, während der Rest Ihres Stacks modern bleibt.

Lernen und Flexibilität

Der Aufbau eines benutzerdefinierten Verschlüsslers zwingt Sie, byte‑level Operationen, Schlüsselverwaltung und das vertragsgesteuerte Design der IDataEncryption‑Schnittstelle zu verstehen. Dieses Wissen zahlt sich aus, wenn Sie später anspruchsvollere Kryptografie einsetzen.

Pro‑Tipp: Verwenden Sie benutzerdefinierte Verschlüsselung nur für Daten, die bereits durch andere Schichten (TLS, VPN oder Datenbankverschlüsselung) geschützt sind. Verlassen Sie sich niemals ausschließlich auf XOR als einzige Verteidigungslinie für persönliche oder finanzielle Informationen.

Verständnis von XOR: Grundlagen

XOR (exklusives ODER) vergleicht zwei Bits und gibt 1 zurück, wenn sie unterschiedlich sind, 0, wenn sie gleich sind:

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

Da die Operation ihr eigenes Inverses ist, stellt das erneute Anwenden desselben Schlüssels den ursprünglichen Wert wieder her. In Java können Sie zwei Bytes mit dem ^‑Operator XOR‑en:

byte encrypted = (byte)(plainByte ^ key);

Wenn Sie ein ganzes Byte‑Array mit einem Ein‑Byte‑Schlüssel XOR‑en, erhalten Sie eine schnelle, reversible Transformation. Denken Sie daran, dass ein Ein‑Byte‑Schlüssel nur 255 mögliche Varianten liefert, sodass jeder mit einer bescheidenen Menge an Ciphertext den Schlüssel sofort brute‑force knacken kann. Verwenden Sie dies nur zur Obfuskation, nicht zum Schutz vertraulicher Daten.

Voraussetzungen

Bevor Sie benutzerdefinierte Verschlüsselung mit GroupDocs.Signature for Java implementieren, stellen Sie sicher, dass Sie Folgendes haben:

Erforderliche Bibliotheken und Abhängigkeiten

• GroupDocs.Signature for Java – Version 23.12 oder neuer (die API, die wir durchgehend verwenden).
• Java Development Kit – JDK 8 oder neuer; JDK 11 wird für langfristigen Support empfohlen.

Anforderungen an die Umgebungseinrichtung

• Eine IDE wie IntelliJ IDEA, Eclipse oder VS Code mit Java‑Erweiterungen.
• Maven oder Gradle für das Abhängigkeitsmanagement (beide werden unterstützt).

Wissensvoraussetzungen

• Sicher im Umgang mit Java‑Klassen, Schnittstellen und Byte‑Array‑Manipulation.
• Grundlegendes Verständnis von symmetrischen Verschlüsselungskonzepten (im XOR‑Abschnitt behandelt).

Wenn Sie alle Punkte abgehakt haben, sind Sie bereit, GroupDocs zu Ihrem Projekt hinzuzufügen.

Einrichtung von GroupDocs.Signature für Java

Die Bibliothek in Ihr Build‑System zu integrieren, erfordert eine einzige Zeile XML oder Groovy.

Maven

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

Gradle

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

Direkter Download

Wenn Sie die manuelle Verwaltung bevorzugen, holen Sie sich das JAR von GroupDocs.Signature for Java releases und fügen es Ihrem Klassenpfad hinzu.

Schritte zum Erwerb einer Lizenz

1. Free Trial – Laden Sie das Test‑JAR herunter; Ausgabedateien enthalten ein sichtbares Wasserzeichen.
2. Temporary License – Fordern Sie einen 30‑Tage‑Evaluierungsschlüssel für vollständige Tests an.
3. Purchase – Erwerben Sie eine unbefristete Lizenz für Produktions‑Deployments.

Grundlegende Initialisierung und Einrichtung

Signature signature = new Signature("sample.pdf");

Das Signature‑Objekt ist der Einstiegspunkt für alle Signatur‑, Verifizierungs‑ und Verschlüsselungs‑Operationen in GroupDocs.Signature.

Implementierungs‑Leitfaden

Benutzerdefiniertes XOR‑Verschlüsselungs‑Feature

Wir erstellen eine Klasse, die die IDataEncryption‑Schnittstelle implementiert, und registrieren sie anschließend beim Signature‑Objekt.

Schritt 1: Implementieren der IDataEncryption‑Schnittstelle

IDataEncryption ist die GroupDocs.Signature‑Schnittstelle, die Methoden zum Verschlüsseln und Entschlüsseln von Daten definiert.

public class CustomXOREncryption implements IDataEncryption {
    private byte auto_Key = 0x5A; // example key

    @Override
    public byte[] encrypt(byte[] data) { /* implementation below */ }

    @Override
    public byte[] decrypt(byte[] data) { /* implementation below */ }

    public void setKey(byte key) { this.auto_Key = key; }
    public byte getKey() { return this.auto_Key; }
}

Was passiert: Die Klasse verspricht zwei Kernoperationen – encrypt und decrypt. Das Feld auto_Key speichert den XOR‑Schlüssel, der auf jedes Byte der Nutzlast angewendet wird.

Schritt 2: Definieren der Verschlüsselungs‑ und Entschlüsselungs‑Methoden

Da XOR symmetrisch ist, führen beide Methoden dieselbe byteweise Transformation durch.

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[] data) {
    return encrypt(data); // XOR decryption is identical to encryption
}

Erklärung:

• Guard‑Klauseln schützen vor einem Null‑Schlüssel (der keine Operation ausführen würde) und null‑Eingaben.
• Ein neues Byte‑Array hält die transformierten Daten, um das ursprüngliche Puffer nicht zu verändern.
• Die Schleife XOR‑t jedes Byte mit auto_Key.
• Die Entschlüsselung ruft einfach erneut encrypt auf, weil das zweimalige Anwenden desselben XOR die Originalbytes wiederherstellt.

Schlüssel‑Konfigurations‑Optionen

• auto_Key muss ein von Null verschiedener Wert zwischen 1 und 255 sein. Werte über 255 werden auf die unteren 8 Bits gekürzt.
• Speichern Sie den Schlüssel sicher – empfohlene Methoden sind Umgebungsvariablen, verschlüsselte Konfigurationsdateien oder ein dedizierter Secrets‑Manager.
• Für die Produktion werden Sie diesen einfachen Byte wahrscheinlich durch einen Mehr‑Byte‑Schlüssel oder einen vollständigen AES‑Cipher ersetzen, aber die Schnittstelle bleibt gleich.

Beispiel für das Setzen des Schlüssels

CustomXOREncryption xor = new CustomXOREncryption();
xor.setKey((byte)0x3C); // set a custom key at runtime
signature.setDataEncryption(xor);

Häufige Implementierungsfehler

Sicherheitsüberlegungen

Warum XOR für sensible Daten nicht ausreicht

XOR mit einem Ein‑Byte‑Schlüssel bietet praktisch keine kryptografische Stärke; ein Angreifer kann sofort alle 255 möglichen Schlüssel aufzählen. Die Operation leckt zudem statistische Muster, wodurch Frequenz‑ und Known‑Plaintext‑Angriffe trivial werden. Folglich sollte XOR niemals der einzige Schutz für persönliche, finanzielle oder sonstige vertrauliche Informationen sein.

Wann XOR akzeptabel ist

XOR kann sicher verwendet werden, wenn die Daten bereits durch stärkere Schichten wie TLS, VPN oder Datenbankverschlüsselung geschützt sind und die Maske nur dazu dient, eine beiläufige Einsicht zu verhindern oder ein Legacy‑Format zu erfüllen. Es eignet sich für temporäre Kennungen, Cache‑Schlüssel oder interne Flags, die das vertrauenswürdige Umfeld nie verlassen.

Empfohlene starke Alternativen

• AES‑256 – Industriestandard, nativ unterstützt über javax.crypto.
• RSA‑2048 – nützlich zum Verschlüsseln kleiner symmetrischer Schlüssel.
• ChaCha20 – hohe Leistung auf mobilen CPUs.

Da der IDataEncryption‑Vertrag algorithmus‑agnostisch ist, erfordert das Wechseln zu AES lediglich das Ersetzen des Körpers von encrypt/decrypt durch die entsprechenden Cipher‑Aufrufe.

Praktische Anwendungen

1. Sicherer Dokument‑Signatur‑Workflow

Möglicherweise müssen Sie Signatur‑Metadaten (ID, Zeitstempel, Abteilung) so speichern, dass eine beiläufige Einsicht verhindert wird. Mit unserem XOR‑Verschlüsseler werden die Metadaten als Byte‑Array im Signatur‑Paket gespeichert, während der Rest des PDFs unverändert bleibt.

Signature signature = new Signature("contract.pdf");
signature.setDataEncryption(new CustomXOREncryption());
SignatureResult result = signature.sign("output.pdf", options);

2. Leichte Integritätsprüfung

Verschlüsseln Sie eine bekannte Konstante und speichern Sie sie zusammen mit dem Dokument. Später entschlüsseln und vergleichen, um zu prüfen, dass die Datei während der Übertragung nicht beschädigt wurde.

3. Brücke zu Legacy‑Systemen

Ein älteres Mainframe erwartet eine Payload, bei der jedes Byte mit 0x7F XOR‑maskiert ist. Durch Konfiguration desselben Schlüssels in CustomXOREncryption können Sie Daten austauschen, ohne einen separaten Transformations‑Service zu schreiben.

Leistungsüberlegungen

Rohgeschwindigkeit

XOR läuft mit etwa 1 ns pro Byte auf einem modernen x86‑Kern, was bedeutet, dass eine 10 MB‑Payload in deutlich unter 10 ms verschlüsselt wird. Im Vergleich dazu benötigt AES‑256 im CBC‑Modus typischerweise das 3‑4‑fache der Zeit für dieselbe Größe.

Speicherverbrauch

Unsere Implementierung erstellt eine Kopie des Eingabe‑Arrays, wodurch der Speicherverbrauch vorübergehend verdoppelt wird. Für eine 50 MB‑Datei benötigen Sie während der Verschlüsselung etwa 100 MB Heap. Wenn Sie größere Dateien verarbeiten müssen, verarbeiten Sie den Stream in 4 KB‑Blöcken:

InputStream in = new FileInputStream(source);
OutputStream out = new FileOutputStream(target);
byte[] buffer = new byte[4096];
int read;
while ((read = in.read(buffer)) != -1) {
    for (int i = 0; i < read; i++) {
        buffer[i] ^= key;
    }
    out.write(buffer, 0, read);
}

Best Practices für das Java‑Speichermanagement

1. Nullen Sie den Schlüssel nach Gebrauch aus: Arrays.fill(keyArray, (byte)0);
2. Verwenden Sie try‑with‑resources, um das Schließen des Streams zu garantieren.
3. Vermeiden Sie die Umwandlung verschlüsselter Bytes in String; behalten Sie sie als rohes byte[] bei.
4. Überwachen Sie den Heap mit Tools wie VisualVM, wenn Sie viele große Dokumente gleichzeitig verarbeiten.

Fehlersuche bei häufigen Problemen

Problem 1 – „Entschlüsselte Daten sehen wie Müll aus“

Direkte Antwort: Stellen Sie sicher, dass derselbe XOR‑Schlüssel sowohl für die Verschlüsselung als auch für die Entschlüsselung verwendet wird, behalten Sie die Daten während der gesamten Pipeline als Byte‑Array und vermeiden Sie jegliche Zeichenkodierungs‑Umwandlungen, die die Bytes beschädigen könnten.

Warum es passiert: Ein nicht übereinstimmender Schlüssel, Datenabschneidung oder eine versehentliche String‑Umwandlung ändern das Byte‑Muster, sodass die Ausgabe unlesbar wird.

Problem 2 – „NullPointerException während der Verschlüsselung“

Direkte Antwort: Die encrypt‑Methode prüft auf null‑Eingaben; wenn Sie dennoch eine Ausnahme sehen, überprüfen Sie, ob das Quell‑Byte‑Array korrekt initialisiert ist, bevor Sie es an den Verschlüsseler übergeben.

Lösung: Fügen Sie defensive Prüfungen in Ihrem Aufrufcode hinzu oder stellen Sie sicher, dass die Signaturdaten des Dokuments mit signature.getSignatureData() vor der Verschlüsselung geladen werden.

Problem 3 – „Verschlüsselung scheint nichts zu tun“

Direkte Antwort: Das bedeutet meist, dass der XOR‑Schlüssel auf 0 gesetzt ist. XOR mit Null lässt das ursprüngliche Byte unverändert, sodass die Ausgabe dem Input entspricht.

Lösung: Setzen Sie einen Nicht‑Null‑Schlüssel über setKey() oder stellen Sie einen Standard im Konstruktor bereit.

Problem 4 – „OutOfMemoryError bei großen PDFs“

Direkte Antwort: Das Laden eines gesamten PDFs in den Speicher vor der Verschlüsselung kann den JVM‑Heap überschreiten. Wechseln Sie zu einem Streaming‑Ansatz, der die Datei in Teilen verarbeitet, wie im Abschnitt Leistung gezeigt.

Tipp: Erhöhen Sie den maximalen Heap (-Xmx2g) nur als vorübergehende Maßnahme; refaktorieren Sie zu einer Chunk‑Verarbeitung für Skalierbarkeit.

Häufig gestellte Fragen

F: Wie wähle ich einen geeigneten XOR‑Schlüssel?
A: Jeder von Null verschiedene Integer zwischen 1 und 255 funktioniert, aber der Schlüssel selbst bietet keine Sicherheit. Für echten Schutz ersetzen Sie XOR durch AES‑256 und bewahren den Schlüssel in einem sicheren Tresor auf.

F: Kann ich den XOR‑Schlüssel zur Laufzeit ändern?
A: Ja – rufen Sie setKey() mit einem neuen Wert auf. Denken Sie daran, dass Daten, die mit dem alten Schlüssel verschlüsselt wurden, vor dem Wechsel entschlüsselt werden müssen, sonst verlieren Sie den Zugriff auf diese Daten.

F: Was sind einige Alternativen zur XOR‑Verschlüsselung?
A: Zum Lernen probieren Sie eine Caesar‑Verschlüsselung oder Base64 (obwohl Base64 nur eine Kodierung ist). Für die Produktion verwenden Sie AES‑256, RSA‑2048 oder ChaCha20 über das Java‑Paket javax.crypto.

F: Wie geht GroupDocs.Signature mit großen Dateien und Verschlüsselung um?
A: Die Bibliothek streamt PDF‑Inhalte, wenn möglich, aber Ihre benutzerdefinierte IDataEncryption‑Implementierung entscheidet, wie Daten verarbeitet werden. Implementieren Sie eine Chunk‑basierte Verschlüsselung, um das Laden der gesamten Datei in den Speicher zu vermeiden.

F: Ist es möglich, dieses Feature in eine Web‑Anwendung zu integrieren?
A: Absolut. Registrieren Sie den Verschlüsseler als Spring‑Bean, injizieren Sie den Signature‑Service und bewahren Sie den Schlüssel in einer Umgebungsvariablen oder einem Secrets‑Manager auf. Stellen Sie sicher, dass jede Anfrage die Daten in einem separaten Thread verarbeitet, um Konkurrenz zu vermeiden.

Wie funktioniert XOR‑Verschlüsselung in Java?

In Java wird XOR mit dem ^‑Operator auf Byte‑Werten durchgeführt. Sie laden den Klartext in ein Byte‑Array, iterieren über jedes Element und wenden byte ^ key an. Da XOR sein eigenes Inverses ist, stellt das Ausführen derselben Routine mit dem identischen Schlüssel die Originalbytes wieder her, wodurch Verschlüsselung und Entschlüsselung symmetrisch werden.

Was sind die Schritte zur Implementierung benutzerdefinierter Verschlüsselung mit GroupDocs?

Um benutzerdefinierte Verschlüsselung hinzuzufügen, erstellen Sie zunächst eine Klasse, die die IDataEncryption‑Schnittstelle implementiert, und codieren dann die encrypt‑ und decrypt‑Methoden mit Ihrem Algorithmus. Anschließend registrieren Sie die Instanz beim Signature‑Objekt über setDataEncryption. Von diesem Zeitpunkt an wird GroupDocs Ihre Logik aufrufen, wann immer Signaturdaten geschützt werden müssen.

Fazit

Wir haben den gesamten Lebenszyklus von how to encrypt java Code mit einer benutzerdefinierten XOR‑Routine behandelt, ihn in GroupDocs.Signature integriert und die Situationen hervorgehoben, in denen dieser leichte Ansatz Mehrwert bietet. Denken Sie daran:

• Verwenden Sie XOR nur zur Obfuskation, nicht zum Schutz persönlicher oder finanzieller Daten.
• Die IDataEncryption‑Schnittstelle bietet Ihnen einen sauberen Austauschpunkt für stärkere Algorithmen später.
• Richtige Schlüsselverwaltung, Speicherhandling und Streaming sind für Produktionsstabilität essenziell.

Nächste Schritte:

1. Ersetzen Sie die XOR‑Logik durch AES‑256 für echte Sicherheit.
2. Implementieren Sie Schlüsselrotation und sichere Speicherung.
3. Erkunden Sie weitere GroupDocs‑Funktionen wie Multi‑Signature‑Workflows, Verifizierung und Dokumenten‑Stempeln.

Jetzt haben Sie eine solide Grundlage, um die Verschlüsselung in jeder Java‑Signaturlösung anzupassen – gehen Sie los und passen Sie sie an Ihre genauen Geschäftsanforderungen an!

Zuletzt aktualisiert: 2026-06-26
Getestet mit: GroupDocs.Signature 23.12 für Java
Autor: GroupDocs

Verwandte Ressourcen:

• GroupDocs.Signature for Java Documentation
• API Reference
• Latest Release Download
• Purchase License
• Free Trial
• Temporary License Request
• GroupDocs Support Forum

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!

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

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

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.
    }
}

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.
}

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);
    }
}

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

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

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)

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

// 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);

// 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);
    }
}

   Arrays.fill(decryptedData, (byte) 0); // Overwrite with zeros

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

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

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);
    }
}

@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...
}

Verwandte Tutorials

• Benutzerdefinierten XOR‑Verschlüsseler in Java mit GroupDocs.Signature erstellen
• Dokument‑Metadaten in Java mit GroupDocs.Signature verschlüsseln
• Wie man Signatur in Java verschlüsselt – Erweiterte Signatur‑Optionen & Verschlüsselungstechniken