Hogyan titkosítsuk a Java-t: Egyedi XOR titkosítás a GroupDocs-szal

Bevezetés

Ha valaha is how to encrypt java kódot kellett írnod egy adott munkafolyamathoz, ismered a beépített lehetőségek frusztrációját, amelyek nem felelnek meg a régi protokollodnak vagy teljesítménycélodnak. Képzeld el, hogy egy új aláírási modult integrálsz egy régebbi ERP rendszerbe, amely egyszerű XOR‑maszkolt payload‑ot vár. Átírhatnád az egész ERP‑t, de egy gyorsabb út a könnyűsúlyú egyedi titkosítási réteg hozzáadása közvetlenül a Java alkalmazásodba.

Ebben az útmutatóban végigvezetünk egy egyedi XOR titkosítási mechanizmus létrehozásán, beillesztjük a GroupDocs.Signature for Java‑ba, és megvitatjuk, mikor érdemes ezt a megközelítést választani, illetve mikor jobb iparági szabványú algoritmusokat használni. A végére képes leszel megvédeni az aláírás metaadatait, megfelelni a szeszélyes integrációs szerződéseknek, és megérteni az XOR használatának kompromisszumait a termelés‑szintű kódban.

Amit megtanulsz:

• Miért fontos az egyedi titkosítás régi rendszerek és teljesítmény esetén
• Hogyan működik az XOR titkosítás (egyszerű magyarázat + Java példa)
• Lépésről‑lépésre integráció a GroupDocs.Signature for Java‑val
• Valós példák, biztonsági szempontok és gyakori buktatók
• Hogyan cserélheted le az XOR‑t egy erősebb algoritmusra később

Gyors válaszok

• Mi az XOR titkosítás? Egy szimmetrikus művelet, amely egy kulcs segítségével megfordítja a biteket; kétszeres titkosítás ugyanazzal a kulccsal visszaállítja az eredeti adatot.
• Mikor használjak egyedi titkosítást? Régi rendszer kompatibilitáshoz, teljesítménykritikus obfuszkációhoz vagy tanulási célokra – nem érzékeny adatok védelmére.
• Melyik könyvtárat használja ez a bemutató? GroupDocs.Signature for Java (v23.12 vagy újabb).
• Szükségem van licencre? Egy ingyenes próba verzió teszteléshez elegendő; a termeléshez teljes licenc szükséges.
• Kicserélhetem később az XOR‑t AES‑re? Igen – csak cseréld le az encrypt/decrypt logikát, miközben az IDataEncryption interfész változatlan marad.

Mi az egyedi titkosítás Java‑ban?

IDataEncryption a GroupDocs.Signature egy interfésze, amely meghatározza az adat titkosításáért és visszafejtéséért felelős metódusokat. Az egyedi titkosítás lehetővé teszi, hogy pontosan meghatározd, hogyan alakul át az adat a tárolás vagy továbbítás előtt. A GroupDocs.Signature‑nél egy IDataEncryption implementációt adsz meg, és a könyvtár automatikusan meghívja a kódodat, amikor aláírási adatot kell védeni. Ez a plug‑in modell lehetővé teszi, hogy egy egyszerű XOR rutinnal indítsd a proof‑of‑concept‑et, majd később AES‑256‑ra cseréld anélkül, hogy a teljes aláírási munkafolyamatot módosítanád.

Miért fontos az egyedi titkosítás

Az egyedi titkosítás akkor hasznos, ha a meglévő algoritmusok nem tudnak megfelelni specifikus korlátozásoknak, például régi protokollformátumok, szigorú teljesítménykeretek vagy saját szerződéses követelmények. Saját rutin megvalósításával teljes kontrollt kapsz az adattranszformáció felett, csökkented a terhelést, és biztosítod a kompatibilitást anélkül, hogy külső rendszereket újra kellene írni, miközben továbbra is kiaknázhatod a GroupDocs bővíthetőségét.

Régi rendszer integráció

A régebbi rendszerek gyakran egy nagyon specifikus bájt‑szintű transzformációt igényelnek – gyakran egyetlen bájtos XOR‑t. Az ilyen rendszerek újratervezése drága, ezért a saját titkosítóval való egyezés a pragmatikus út.

Teljesítményoptimalizálás

Az AES‑256‑hoz hasonló szabványos algoritmusok kriptográfiailag erősek, de jelentős CPU‑ciklusokat fogyasztanak, különösen alacsony fogyasztású eszközökön vagy milliók kis payload‑jainak feldolgozásakor. Az XOR egyetlen CPU‑utasítással bájtonként fut, szinte nulla terhelést biztosít a nem érzékeny adatoknál.

Szabadalmazott követelmények

Bizonyos szerződések vagy iparági szabványok egyedi algoritmust írnak elő (pl. egy kormány által előírt „XOR‑maszk”). A szükséges logika saját kezű implementálása biztosítja a megfelelőséget, miközben a stack többi része modern marad.

Tanulás és rugalmasság

Egy egyedi titkosító építése arra kényszerít, hogy megértsd a bájt‑szintű műveleteket, a kulcskezelést és a IDataEncryption interfész szerződés‑vezérelt tervezését. Ez a tudás később hasznos, amikor fejlettebb kriptográfiát vezetsz be.

Pro tipp: Az egyedi titkosítást csak olyan adatokra használd, amelyeket már más rétegek (TLS, VPN vagy adatbázis‑titkosítás) védnek. Soha ne támaszkodj kizárólag az XOR‑ra személyes vagy pénzügyi információk védelmében.

Az XOR megértése: Alapok

Az XOR (exkluzív VAGY) két bitet hasonlít össze, és 1‑et ad vissza, ha különböznek, 0‑t, ha azonosak:

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

Mivel a művelet önmagának inverze, ugyanazzal a kulccsal való második alkalmazás visszaállítja az eredeti értéket. Java‑ban a ^ operátorral XOR‑olhatsz két bájtot:

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

Amikor egy egész bájt‑tömböt XOR‑olsz egy egybájtos kulccsal, gyors, visszafordítható transzformációt kapsz. Ne feledd, egy egybájtos kulcs csak 255 lehetséges variációt eredményez, így bármelyik, aki elegendő titkosított szöveget kap, azonnal brute‑force‑ozhatja a kulcsot. Használd csak obfuszkációra, ne pedig bizalmas adatok védelmére.

Előfeltételek

Mielőtt egyedi titkosítást valósítanál meg a GroupDocs.Signature for Java‑val, győződj meg róla, hogy rendelkezel a következőkkel:

Szükséges könyvtárak és függőségek

• GroupDocs.Signature for Java – 23.12 vagy újabb verzió (az API, amelyet a teljes anyagban használunk).
• Java Development Kit – JDK 8 vagy újabb; JDK 11 ajánlott a hosszú távú támogatás miatt.

Környezet beállítása

• IDE, például IntelliJ IDEA, Eclipse vagy VS Code Java‑kiegészítőkkel.
• Maven vagy Gradle a függőségkezeléshez (mindkettő támogatott).

Tudás‑előfeltételek

• Jól ismered a Java osztályokat, interfészeket és a bájt‑tömbök manipulációját.
• Alapvető szimmetrikus titkosítási koncepciók (az XOR szekcióban lefedve).

Ha minden pontot kipipálsz, készen állsz a GroupDocs hozzáadására a projektedhez.

GroupDocs.Signature for Java beállítása

A könyvtár beillesztése a build rendszerbe egyetlen XML vagy Groovy sor.

Maven

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

Gradle

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

Közvetlen letöltés

Ha a manuális kezelés a kedved, töltsd le a JAR‑t a GroupDocs.Signature for Java releases oldalról, és add hozzá a classpath‑hoz.

Licenc beszerzési lépések

1. Ingyenes próba – töltsd le a próba JAR‑t; a kimeneti fájlok látható vízjelet tartalmaznak.
2. Ideiglenes licenc – kérj 30‑napos értékelő kulcsot a teljes funkcionalitású teszteléshez.
3. Vásárlás – szerezz örökös licencet a termelési telepítésekhez.

Alap inicializálás és beállítás

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

A Signature objektum a belépési pont minden aláírási, ellenőrzési és titkosítási művelethez a GroupDocs.Signature‑ban.

Implementációs útmutató

Egyedi XOR titkosítási funkció

Létrehozunk egy osztályt, amely megvalósítja az IDataEncryption interfészt, majd regisztráljuk a Signature objektummal.

1. lépés: IDataEncryption interfész implementálása

IDataEncryption a GroupDocs.Signature interfésze, amely meghatározza az adat titkosításáért és visszafejtéséért felelős metódusokat.

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

Mi történik: Az osztály két alapvető műveletet ígér – encrypt és decrypt. Az auto_Key mező tárolja az XOR kulcsot, amely minden payload bájtjára alkalmazásra kerül.

2. lépés: Titkosítási és visszafejtési metódusok definiálása

Mivel az XOR szimmetrikus, mindkét metódus ugyanazt a bájt‑szintű transzformációt végzi.

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
}

Magyarázat:

• A védelmi ágak megakadályozzák a nulla kulcsot (ami semmit sem csinál) és a null bemenetet.
• Egy új bájt‑tömb tárolja a transzformált adatot, hogy ne módosítsa az eredeti puffert.
• A ciklus minden bájtot XOR‑ol az auto_Key‑val.
• A visszafejtés egyszerűen újra meghívja az encrypt‑et, mivel ugyanaz az XOR kétszer alkalmazva visszaadja az eredeti bájtokat.

Kulcs konfigurációs lehetőségek

• auto_Key nem nulla érték 1‑255 között kell legyen. 255‑nél nagyobb értékek az alsó 8 bitre lesznek vágva.
• Tárold a kulcsot biztonságosan – környezeti változók, titkosított konfigurációs fájlok vagy dedikált titokkezelő ajánlott.
• Termelésben valószínűleg egy többbájtos kulcsot vagy teljes AES titkosítót fogsz használni, de az interfész változatlan marad.

Kulcs beállításának példája

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

Gyakori implementációs hibák

Biztonsági szempontok

Miért nem elegendő az XOR érzékeny adatokhoz

Az egybájtos XOR szinte semmilyen kriptográfiai erővel nem bír; egy támadó azonnal enumerálhatja a 255 lehetséges kulcsot. A művelet statisztikai mintákat is szivárogtat, így a gyakorisági és ismert‑szöveg támadások triviálisak. Ennek következtében az XOR‑t soha ne használd kizárólagos védelemként személyes, pénzügyi vagy bármilyen bizalmas információ esetén.

Mikor elfogadható az XOR

Az XOR biztonságosan használható, ha az adat már erősebb rétegekkel (TLS, VPN vagy adatbázis‑titkosítás) védett, és a maszk csak a laza ellenőrzés vagy egy régi formátum teljesítése céljából van. Alkalmas ideiglenes azonosítókra, cache‑kulcsokra vagy belső flag‑ekre, amelyek soha nem hagyják el a megbízható környezetet.

Ajánlott erős alternatívák

• AES‑256 – iparági szabvány, natívan támogatott a javax.crypto‑val.
• RSA‑2048 – kis szimmetrikus kulcsok titkosításához hasznos.
• ChaCha20 – magas teljesítmény mobil CPU‑kon.

Mivel az IDataEncryption szerződés algoritmus‑agnosztikus, az AES‑re való áttéréshez csak a encrypt/decrypt testét kell a megfelelő titkosító hívásokkal helyettesíteni.

Gyakorlati alkalmazások

1. Biztonságos dokumentum‑aláírási munkafolyamat

Lehet, hogy a felhasználó metaadatait (azonosító, időbélyeg, részleg) úgy kell tárolni, hogy elriassza a laza ellenőrzést. XOR titkosítónkkal a metaadat bájt‑tömbként kerül a aláírás csomagba, míg a PDF többi része érintetlen marad.

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

2. Könnyű integritás‑ellenőrzés

Titkosíts egy ismert konstansot, és tárold a dokumentummal együtt. Később visszafejtve összehasonlíthatod, hogy a fájl nem sérült-e a szállítás során.

3. Régi rendszer híd

Egy régi mainframe egy 0x7F kulccsal XOR‑olt payload‑ot vár. Azonos kulcs beállításával a CustomXOREncryption‑ban adatcserét végezhetsz anélkül, hogy külön transzformációs szolgáltatást írnál.

Teljesítmény szempontok

Nyers sebesség

Az XOR körülbelül 1 ns per bájt sebességgel fut egy modern x86 magon, így egy 10 MB payload kevesebb, mint 10 ms alatt titkosítható. Ezzel szemben az AES‑256 CBC mód általában 3‑4‑ször lassabb ugyanakkora méret esetén.

Memóriaigény

Az implementációnk egy másolatot készít a bemeneti tömbből, így átmenetileg a memóriahasználat megduplázódik. Egy 50 MB fájl esetén körülbelül 100 MB heap‑re lesz szükség a titkosítás során. Nagyobb fájlok esetén dolgozz 4 KB‑os darabokban:

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

Legjobb gyakorlatok Java memória kezeléshez

1. Töröld a kulcsot használat után: Arrays.fill(keyArray, (byte)0);
2. Használj try‑with‑resources a stream‑ek automatikus lezárásához.
3. Kerüld a titkosított bájtok String‑gé konvertálását; tartsd őket nyers byte[]‑ként.
4. Figyeld a heap‑et VisualVM‑mel, ha sok nagy dokumentumot dolgozol fel egyszerre.

Gyakori problémák hibaelhárítása

Probléma 1 – „A visszafejtett adat szemétnek tűnik”

Közvetlen válasz: Győződj meg róla, hogy ugyanazt az XOR kulcsot használod titkosítás és visszafejtés során, tartsd az adatot byte[]‑ként a teljes csővezetékben, és kerüld a karakter‑kódolási konverziókat, amelyek korrumpálhatják a bájtokat.

Miért fordul elő: Nem egyező kulcs, adat csonkítás vagy véletlen String konverzió torzítja a bájtmintát, így a kimenet olvashatatlan lesz.

Probléma 2 – „NullPointerException titkosítás közben”

Közvetlen válasz: Az encrypt metódus ellenőrzi a null bemenetet; ha mégis hibát kapsz, ellenőrizd, hogy a forrás‑bájt‑tömb helyesen van‑e inicializálva a titkosítóhoz való átadás előtt.

Javítás: Adj védelmi ellenőrzéseket a hívó kódban, vagy biztosítsd, hogy a dokumentum aláírási adatait a signature.getSignatureData()‑val töltöd be titkosítás előtt.

Probléma 3 – „A titkosítás látszólag semmit sem csinál”

Közvetlen válasz: Ez általában azt jelenti, hogy az XOR kulcs 0‑ra van állítva. A nulla kulccsal az XOR nem változtatja meg a bájtot, így a kimenet megegyezik a bemenettel.

Megoldás: Állíts be nem‑null kulcsot a setKey()‑vel, vagy adj meg alapértelmezettet a konstruktorban.

Probléma 4 – „OutOfMemoryError nagy PDF‑eken”

Közvetlen válasz: Egy teljes PDF betöltése a memóriába a titkosítás előtt meghaladhatja a JVM heap‑et. Válts streaming megközelítésre, amely darabokban dolgozza fel a fájlt, ahogy a teljesítmény szekcióban látható.

Tipp: Ideiglenesen növeld a maximális heap‑et (-Xmx2g), de hosszú távon a darabolt feldolgozásra refaktorálj a skálázhatóság érdekében.

Gyakran feltett kérdések

K: Hogyan válasszak megfelelő XOR kulcsot?
V: Bármely nem‑null egész szám 1‑255 között működik, de maga a kulcs nem nyújt biztonságot. Valódi védelemhez cseréld le az XOR‑t AES‑256‑ra, és tartsd a kulcsot biztonságos széfben.

K: Futás közben változtathatom a XOR kulcsot?
V: Igen – hívd meg a setKey()‑t új értékkel. Ne feledd, hogy a régi kulccsal titkosított adatot előbb vissza kell fejteni, mielőtt váltanál, különben elveszíted a hozzáférést.

K: Milyen alternatívák léteznek az XOR titkosításra?
V: Tanulásként kipróbálhatsz Caesar‑cifert vagy Base64‑t (bár a Base64 csak kódolás). Termeléshez használj AES‑256‑ot, RSA‑2048‑at vagy ChaCha20‑at a Java javax.crypto csomagjával.

K: Hogyan kezeli a GroupDocs.Signature a nagy fájlokat titkosítással?
V: A könyvtár PDF‑tartalmat stream‑eli, amikor csak lehetséges, de a saját IDataEncryption implementációd dönti el, hogyan dolgozod fel az adatot. Implementálj darab‑alapú titkosítást a teljes fájl memóriába töltésének elkerüléséhez.

K: Lehet-e ezt a funkciót webalkalmazásba integrálni?
V: Természetesen. Regisztráld a titkosítót Spring Bean‑ként, injektáld a Signature szolgáltatást, és tartsd a kulcsot környezeti változóban vagy titokkezelőben. Biztosítsd, hogy minden kérés külön szálon dolgozza fel az adatot a versengés elkerülése érdekében.

Hogyan működik az XOR titkosítás Java‑ban?

Java‑ban az XOR‑t a ^ operátorral hajtjuk végre bájt értékeken. Betöltöd a tiszta szöveget egy bájt‑tömbbe, végigiterálsz minden elemen, és alkalmazod a byte ^ key műveletet. Mivel az XOR önmagának inverze, ugyanazzal a kulccsal történő újrafuttatás visszaadja az eredeti bájtokat, így a titkosítás és visszafejtés szimmetrikus.

Mik a lépések a saját titkosítás hozzáadásához a GroupDocs‑szal?

Először létrehozol egy osztályt, amely megvalósítja az IDataEncryption interfészt, majd megírod az encrypt és decrypt metódusokat a saját algoritmusoddal. Ezután regisztrálod a példányt a Signature objektummal a setDataEncryption‑en keresztül. Ettől a ponttól a GroupDocs automatikusan meghívja a logikádat, amikor aláírási adatot kell védeni.

Összegzés

Áttekintettük a how to encrypt java kód teljes életciklusát egy egyedi XOR rutin segítségével, integráltuk a GroupDocs.Signature‑ba, és kiemeltük, mikor ad értéket ez a könnyű megközelítés. Ne feledd:

• Az XOR‑t csak obfuszkációra használd, ne személyes vagy pénzügyi adatok védelmére.
• Az IDataEncryption interfész tiszta csere‑pontot biztosít erősebb algoritmusokhoz később.
• A megfelelő kulcskezelés, memória‑kezelés és streaming elengedhetetlen a termelési stabilitáshoz.

Következő lépések:

1. Cseréld le az XOR logikát AES‑256‑ra a valódi biztonság érdekében.
2. Implementálj kulcsrotációt és biztonságos tárolást.
3. Fedezd fel a GroupDocs további funkcióit, például a több‑aláírásos munkafolyamatokat, ellenőrzést és dokumentum‑bélyegzést.

Most már szilárd alapod van a titkosítás testreszabásához bármely Java aláírási megoldásban – alakítsd a saját üzleti igényeidhez!

Utolsó frissítés: 2026-06-26
Tesztelt verzió: GroupDocs.Signature 23.12 for Java
Szerző: GroupDocs

Kapcsolódó források:

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

Kapcsolódó oktatóanyagok

• 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