Jak szyfrować w Javie: Niestandardowe szyfrowanie XOR z GroupDocs

Wprowadzenie

Jeśli kiedykolwiek musiałeś how to encrypt java kod dla konkretnego przepływu pracy, znasz frustrację wbudowanych opcji, które nie pasują do Twojego starszego protokołu lub wymagań wydajnościowych. Wyobraź sobie, że integrujesz nowy moduł podpisywania z starszym systemem ERP, który oczekuje prostego ładunku zamaskowanego XOR. Możesz przepisać cały ERP, ale szybszą drogą jest dodanie lekkiej, niestandardowej warstwy szyfrowania bezpośrednio w aplikacji Java.

W tym przewodniku przeprowadzimy Cię przez tworzenie własnego mechanizmu szyfrowania XOR, podłączenie go do GroupDocs.Signature for Java oraz omówimy, kiedy takie podejście ma sens, a kiedy warto sięgnąć po standardowe algorytmy kryptograficzne. Po zakończeniu będziesz w stanie chronić metadane podpisu, spełniać nietypowe kontrakty integracyjne i rozumieć kompromisy związane z używaniem XOR w kodzie produkcyjnym.

Oto, czego się nauczysz:

• Dlaczego niestandardowe szyfrowanie ma znaczenie w scenariuszach legacy i wydajnościowych
• Jak działa szyfrowanie XOR (proste wyjaśnienie + przykład w Javie)
• Krok po kroku integracja z GroupDocs.Signature for Java
• Przykłady z życia, kwestie bezpieczeństwa i typowe pułapki
• Jak wymienić implementację XOR na silniejszy algorytm w przyszłości

Szybkie odpowiedzi

• Czym jest szyfrowanie XOR? Symetryczna operacja, która odwraca bity przy użyciu klucza; podwójne zaszyfrowanie tym samym kluczem przywraca oryginalne dane.
• Kiedy używać niestandardowego szyfrowania? Dla kompatybilności ze starszymi systemami, krytycznej wydajności, lub w celach edukacyjnych – nie do ochrony wrażliwych danych.
• Z jakiej biblioteki korzysta ten tutorial? GroupDocs.Signature for Java (v23.12 lub nowsza).
• Czy potrzebna jest licencja? Darmowa wersja próbna wystarczy do testów; pełna licencja jest wymagana w produkcji.
• Czy mogę później zamienić XOR na AES? Tak – wystarczy podmienić logikę encrypt/decrypt, zachowując interfejs IDataEncryption.

Czym jest niestandardowe szyfrowanie w Javie?

IDataEncryption to interfejs GroupDocs.Signature definiujący metody szyfrowania i deszyfrowania danych. Niestandardowe szyfrowanie pozwala określić dokładnie, jak dane są przekształcane przed ich zapisaniem lub przesłaniem. Z GroupDocs.Signature dostarczasz implementację interfejsu IDataEncryption, a biblioteka automatycznie wywołuje Twój kod, gdy potrzebuje zabezpieczyć dane podpisu. Ten model wtyczkowy oznacza, że możesz rozpocząć od prostej procedury XOR jako proof‑of‑concept, a później zamienić ją na AES‑256 bez modyfikacji reszty przepływu podpisywania.

Dlaczego niestandardowe szyfrowanie ma znaczenie

Niestandardowe szyfrowanie jest przydatne, gdy istniejące algorytmy nie spełniają konkretnych ograniczeń, takich jak formaty protokołów legacy, ścisłe budżety wydajnościowe lub wymogi kontraktowe. Implementując własną procedurę, zachowujesz pełną kontrolę nad transformacją danych, redukujesz narzut i zapewniasz kompatybilność bez konieczności przepisywania zewnętrznych systemów, jednocześnie korzystając z rozszerzalności GroupDocs.

Integracja z systemem legacy

Starsze systemy czasem wymagają bardzo specyficznej transformacji bajt‑po‑bajcie – często XOR z jednowyrazowym kluczem. Przebudowa takich systemów jest kosztowna, więc dopasowanie ich oczekiwań przy pomocy własnego szyfratora jest praktycznym rozwiązaniem.

Optymalizacja wydajności

Standardowe algorytmy, takie jak AES‑256, są kryptograficznie silne, ale mogą pochłaniać zauważalne cykle CPU, szczególnie na urządzeniach o niskiej mocy lub przy przetwarzaniu milionów małych ładunków. XOR działa w jednej instrukcji CPU na bajt, zapewniając prawie zerowy narzut dla danych nie‑wrażliwych.

Wymagania własnościowe

Niektóre kontrakty lub standardy branżowe wymagają niestandardowego algorytmu (np. rządowy „XOR‑mask”). Implementując wymaganą logikę samodzielnie, zapewniasz zgodność, jednocześnie utrzymując nowoczesny stos technologiczny.

Nauka i elastyczność

Budowanie własnego szyfratora zmusza do zrozumienia operacji na poziomie bajtów, zarządzania kluczami i projektowania interfejsu IDataEncryption napędzanego kontraktem. Ta wiedza zwraca się, gdy później przyjmiesz bardziej zaawansowaną kryptografię.

Wskazówka: Używaj niestandardowego szyfrowania wyłącznie dla danych już chronionych innymi warstwami (TLS, VPN lub szyfrowanie bazy danych). Nigdy nie polegaj wyłącznie na XOR jako jedynym zabezpieczeniu informacji osobistych lub finansowych.

Zrozumienie XOR: Podstawy

XOR (exclusive OR) porównuje dwa bity i zwraca 1, jeśli się różnią, 0, jeśli są takie same:

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

Ponieważ operacja jest swoją własną odwrotnością, zastosowanie tego samego klucza po raz drugi przywraca pierwotną wartość. W Javie możesz XOR‑ować dwa bajty operatorem ^:

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

Gdy XOR‑ujesz cały array bajtów jednowyrazowym kluczem, otrzymujesz szybką, odwracalną transformację. Pamiętaj, że jednowyrazowy klucz daje tylko 255 możliwych wariantów, więc każdy, kto posiada niewielką ilość szyfrogramu, może natychmiast przeprowadzić brute‑force. Używaj tego wyłącznie do zaciemniania, nie do ochrony poufnych danych.

Wymagania wstępne

Zanim zaimplementujesz niestandardowe szyfrowanie z GroupDocs.Signature for Java, upewnij się, że masz:

Wymagane biblioteki i zależności

• GroupDocs.Signature for Java – wersja 23.12 lub nowsza (API, którego będziemy używać).
• Java Development Kit – JDK 8 lub nowszy; zalecany JDK 11 dla długoterminowego wsparcia.

Wymagania dotyczące konfiguracji środowiska

• IDE, takie jak IntelliJ IDEA, Eclipse lub VS Code z rozszerzeniami Java.
• Maven lub Gradle do zarządzania zależnościami (obie są obsługiwane).

Wymagania wiedzy

• Swoboda w pracy z klasami, interfejsami i manipulacją tablicami bajtów w Javie.
• Podstawowa znajomość koncepcji szyfrowania symetrycznego (omówiona w sekcji XOR).

Jeśli spełniasz wszystkie kryteria, możesz dodać GroupDocs do swojego projektu.

Konfiguracja GroupDocs.Signature dla Javy

Dodanie biblioteki do systemu budowania to jedna linijka XML lub Groovy.

Maven

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

Gradle

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

Bezpośrednie pobranie

Jeśli wolisz ręczne zarządzanie, pobierz JAR z GroupDocs.Signature for Java releases i dodaj go do classpath.

Kroki uzyskania licencji

1. Free Trial – pobierz JAR wersji próbnej; wygenerowane pliki będą zawierały widoczny znak wodny.
2. Temporary License – zamów klucz ewaluacyjny na 30 dni do pełnego testowania.
3. Purchase – uzyskaj licencję perpetualną do wdrożeń produkcyjnych.

Podstawowa inicjalizacja i konfiguracja

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

Obiekt Signature jest punktem wejścia dla wszystkich operacji podpisywania, weryfikacji i szyfrowania w GroupDocs.Signature.

Przewodnik implementacji

Funkcja niestandardowego szyfrowania XOR

Stworzymy klasę implementującą interfejs IDataEncryption, a następnie zarejestrujemy ją w obiekcie Signature.

Krok 1: Implementacja interfejsu IDataEncryption

IDataEncryption to interfejs GroupDocs.Signature definiujący metody szyfrowania i deszyfrowania danych.

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

Co się dzieje: Klasa deklaruje dwie podstawowe operacje – encrypt i decrypt. Pole auto_Key przechowuje klucz XOR, który zostanie zastosowany do każdego bajtu ładunku.

Krok 2: Definicja metod szyfrowania i deszyfrowania

Ponieważ XOR jest symetryczny, obie metody wykonują tę samą transformację bajt‑po‑bajcie.

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
}

Wyjaśnienie:

• Warunki ochronne zapobiegają kluczowi równemu zero (co byłoby operacją neutralną) oraz wejściom null.
• Nowa tablica bajtów przechowuje przekształcone dane, aby nie modyfikować oryginalnego bufora.
• Pętla XOR‑uje każdy bajt z auto_Key.
• Deszyfrowanie po prostu wywołuje ponownie encrypt, ponieważ podwójne zastosowanie tego samego XOR przywraca oryginalne bajty.

Opcje konfiguracji klucza

• auto_Key musi być wartością nie‑zerową z zakresu 1‑255. Wartości powyżej 255 są obcinane do niższych 8 bitów.
• Przechowuj klucz w bezpieczny sposób – zmienne środowiskowe, zaszyfrowane pliki konfiguracyjne lub dedykowany manager sekretów są zalecane.
• W produkcji prawdopodobnie zastąpisz ten prosty bajt wielobajtowym kluczem lub pełnym szyfrem AES, ale interfejs pozostanie taki sam.

Przykład ustawiania klucza

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

Typowe błędy implementacji

Kwestie bezpieczeństwa

Dlaczego XOR nie jest wystarczający dla wrażliwych danych

XOR z jednowyrazowym kluczem nie zapewnia praktycznie żadnej siły kryptograficznej; atakujący może natychmiast wypróbować wszystkie 255 możliwych kluczy. Operacja dodatkowo ujawnia statystyczne wzorce, co czyni ataki częstotliwościowe i znane‑tekst‑otwartym trywialnymi. W konsekwencji XOR nigdy nie powinien być jedyną ochroną danych osobowych, finansowych czy jakichkolwiek poufnych informacji.

Kiedy XOR jest dopuszczalny

XOR może być bezpiecznie używany, gdy dane są już chronione silniejszymi warstwami, takimi jak TLS, VPN lub szyfrowanie bazy danych, a maska służy jedynie do odradzania przypadkowego wglądu lub spełnienia wymogu legacy. Nadaje się do tymczasowych identyfikatorów, kluczy cache czy wewnętrznych flag, które nigdy nie opuszczają zaufanego środowiska.

Zalecane silne alternatywy

• AES‑256 – standard branżowy, dostępny natywnie przez javax.crypto.
• RSA‑2048 – przydatny do szyfrowania małych kluczy symetrycznych.
• ChaCha20 – wysokowydajny na procesorach mobilnych.

Ponieważ kontrakt IDataEncryption jest niezależny od algorytmu, zamiana na AES wymaga jedynie podmiany ciał metod encrypt/decrypt na odpowiednie wywołania szyfru.

Praktyczne zastosowania

1. Bezpieczny przepływ pracy podpisywania dokumentów

Możesz potrzebować przechowywać metadane podpisującego (ID, znacznik czasu, dział) w sposób utrudniający przypadkowy podgląd. Korzystając z naszego szyfratora XOR, metadane są przechowywane jako tablica bajtów w pakiecie podpisu, podczas gdy reszta PDF pozostaje niezmieniona.

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

2. Lekka kontrola integralności

Zaszyfruj znany stały ciąg i przechowaj go razem z dokumentem. Później odszyfruj i porównaj, aby zweryfikować, że plik nie został uszkodzony podczas transferu.

3. Most do systemu legacy

Starszy mainframe oczekuje ładunku, w którym każdy bajt jest maskowany XOR‑em kluczem 0x7F. Konfigurując ten sam klucz w CustomXOREncryption, możesz wymieniać dane bez tworzenia osobnej usługi transformacji.

Rozważania dotyczące wydajności

Surowa prędkość

XOR działa w przybliżeniu 1 ns na bajt na nowoczesnym rdzeniu x86, co oznacza, że 10 MB ładunku zostanie zaszyfrowane w mniej niż 10 ms. Dla porównania, AES‑256 w trybie CBC zazwyczaj zajmuje 3‑4 × więcej czasu przy tej samej wielkości.

Ślad pamięciowy

Nasza implementacja tworzy kopię tablicy wejściowej, podwajając tymczasowo zużycie pamięci. Dla pliku 50 MB potrzebujesz około 100 MB heapu podczas szyfrowania. Jeśli musisz obsługiwać większe pliki, przetwarzaj strumień w fragmentach po 4 KB:

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

Najlepsze praktyki zarządzania pamięcią w Javie

1. Wyczyść klucz po użyciu: Arrays.fill(keyArray, (byte)0);
2. Używaj try‑with‑resources, aby zapewnić zamknięcie strumieni.
3. Unikaj konwersji zaszyfrowanych bajtów do String; trzymaj je jako surowe byte[].
4. Monitoruj heap narzędziami takimi jak VisualVM przy równoczesnym przetwarzaniu wielu dużych dokumentów.

Rozwiązywanie typowych problemów

Problem 1 – „Zdeszyfrowane dane wyglądają na śmieci”

Bezpośrednia odpowiedź: Upewnij się, że ten sam klucz XOR jest używany zarówno przy szyfrowaniu, jak i deszyfrowaniu, zachowuj dane jako tablicę bajtów przez cały pipeline i unikaj konwersji znakowych, które mogłyby uszkodzić bajty.

Dlaczego tak się dzieje: Niezgodny klucz, obcięcie danych lub przypadkowa konwersja do String zmieniają wzorzec bajtów, przez co wynik jest nieczytelny.

Problem 2 – „NullPointerException podczas szyfrowania”

Bezpośrednia odpowiedź: Metoda encrypt sprawdza wejścia pod kątem null; jeśli nadal widzisz wyjątek, zweryfikuj, czy źródłowa tablica bajtów jest poprawnie zainicjowana przed przekazaniem do szyfratora.

Naprawa: Dodaj defensywne sprawdzenia w kodzie wywołującym lub upewnij się, że dane podpisu są załadowane metodą signature.getSignatureData() przed szyfrowaniem.

Problem 3 – „Szyfrowanie wydaje się nic nie robić”

Bezpośrednia odpowiedź: Zwykle oznacza to, że klucz XOR został ustawiony na 0. XOR z zerem pozostawia oryginalny bajt niezmieniony, więc wyjście jest identyczne z wejściem.

Rozwiązanie: Ustaw nie‑zerowy klucz za pomocą setKey() lub zapewnij domyślny w konstruktorze.

Problem 4 – „OutOfMemoryError przy dużych plikach PDF”

Bezpośrednia odpowiedź: Ładowanie całego PDF‑a do pamięci przed szyfrowaniem może przekroczyć limit heapu JVM. Przejdź na podejście strumieniowe, które przetwarza plik w fragmentach, jak pokazano w sekcji wydajności.

Wskazówka: Zwiększ maksymalny heap (-Xmx2g) tylko jako tymczasowe rozwiązanie; w dłuższej perspektywie refaktoryzuj na przetwarzanie w kawałkach.

Najczęściej zadawane pytania

Q: Jak wybrać odpowiedni klucz XOR?
A: Każda nie‑zerowa liczba całkowita od 1 do 255 zadziała, ale sam klucz nie zapewnia bezpieczeństwa. Dla rzeczywistej ochrony zamień XOR na AES‑256 i przechowuj klucz w bezpiecznej skrytce.

Q: Czy mogę zmienić klucz XOR w czasie działania?
A: Tak – wywołaj setKey() z nową wartością. Pamiętaj, że dane zaszyfrowane poprzednim kluczem muszą zostać odszyfrowane przed zmianą, w przeciwnym razie utracisz dostęp do tych danych.

Q: Jakie są alternatywy dla szyfrowania XOR?
A: Do nauki wypróbuj szyfr Cezara lub Base64 (choć Base64 to jedynie kodowanie). W produkcji używaj AES‑256, RSA‑2048 lub ChaCha20 poprzez pakiet javax.crypto w Javie.

Q: Jak GroupDocs.Signature radzi sobie z dużymi plikami przy szyfrowaniu?
A: Biblioteka strumieniuje zawartość PDF, gdy to możliwe, ale to Twoja implementacja IDataEncryption decyduje, jak dane są przetwarzane. Zaimplementuj szyfrowanie w partiach, aby uniknąć ładowania całego pliku do pamięci.

Q: Czy można zintegrować tę funkcję z aplikacją webową?
A: Oczywiście. Zarejestruj szyfrator jako Spring Bean, wstrzyknij serwis Signature i przechowuj klucz w zmiennej środowiskowej lub managerze sekretów. Upewnij się, że każde żądanie przetwarza dane w osobnym wątku, aby uniknąć konfliktów.

Jak działa szyfrowanie XOR w Javie?

W Javie XOR wykonuje się operatorem ^ na wartościach typu byte. Ładujesz tekst jawny do tablicy bajtów, iterujesz po każdym elemencie i stosujesz byte ^ key. Ponieważ XOR jest swoją własną odwrotnością, ponowne uruchomienie tej samej procedury z identycznym kluczem przywraca oryginalne bajty, co czyni szyfrowanie i deszyfrowanie symetrycznym.

Jakie są kroki implementacji niestandardowego szyfrowania z GroupDocs?

Aby dodać własne szyfrowanie, najpierw tworzysz klasę implementującą interfejs IDataEncryption, a następnie kodujesz metody encrypt i decrypt przy użyciu wybranego algorytmu. Następnie rejestrujesz instancję w obiekcie Signature poprzez setDataEncryption. Od tego momentu GroupDocs wywoła Twoją logikę, gdy będzie musiał zabezpieczyć dane podpisu.

Podsumowanie

Omówiliśmy pełny cykl how to encrypt java przy użyciu własnej procedury XOR, zintegrowaliśmy ją z GroupDocs.Signature i podkreśliliśmy sytuacje, w których to lekkie podejście wnosi wartość. Pamiętaj:

• Używaj XOR wyłącznie do zaciemniania, nie do ochrony danych osobowych czy finansowych.
• Interfejs IDataEncryption zapewnia czysty punkt wymiany na silniejsze algorytmy w przyszłości.
• Poprawne zarządzanie kluczami, pamięcią i strumieniowaniem jest niezbędne dla stabilności w środowisku produkcyjnym.

Kolejne kroki:

1. Zamień logikę XOR na AES‑256 dla prawdziwego bezpieczeństwa.
2. Wdroż rotację kluczy i bezpieczne ich przechowywanie.
3. Poznaj inne funkcje GroupDocs, takie jak wielopodpisowe przepływy pracy, weryfikacja i znakowanie dokumentów.

Teraz masz solidne podstawy do dostosowywania szyfrowania w dowolnym rozwiązaniu podpisywania w Javie – dostosuj je do swoich konkretnych potrzeb biznesowych!

Ostatnia aktualizacja: 2026-06-26
Testowano z: GroupDocs.Signature 23.12 for Java
Autor: GroupDocs

Powiązane zasoby:

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

Powiązane tutoriale

• Create Custom XOR Encryptor in Java with GroupDocs.Signature
• Encrypt Document Metadata Java with GroupDocs.Signature
• How to Encrypt Signature in Java – Advanced Signing Options & Encryption Techniques