Cách Mã Hoá Java: Mã XOR Tùy Chỉnh với GroupDocs

Giới thiệu

Nếu bạn từng cần cách mã hoá java cho một quy trình công việc cụ thể, bạn sẽ hiểu sự bực bội khi các tùy chọn tích hợp sẵn không phù hợp với giao thức kế thừa hoặc mục tiêu hiệu năng của bạn. Hãy tưởng tượng bạn đang tích hợp một mô-đun ký mới vào một hệ thống ERP cũ hơn, hệ thống này yêu cầu một payload được XOR‑mask đơn giản. Bạn có thể viết lại toàn bộ ERP, nhưng cách nhanh hơn là thêm một lớp mã hoá tùy chỉnh nhẹ ngay trong ứng dụng Java của bạn.

Trong hướng dẫn này, chúng ta sẽ đi qua cách tạo cơ chế mã hoá XOR tùy chỉnh, tích hợp nó vào GroupDocs.Signature for Java, và thảo luận khi nào cách tiếp cận này hợp lý so với việc sử dụng các thuật toán tiêu chuẩn của ngành. Khi kết thúc, bạn sẽ có thể bảo vệ siêu dữ liệu chữ ký, đáp ứng các hợp đồng tích hợp kỳ quặc, và hiểu các đánh đổi khi sử dụng XOR trong mã sản xuất.

Bạn sẽ học được:

• Tại sao mã hoá tùy chỉnh quan trọng đối với các kịch bản kế thừa và hiệu năng
• Cách XOR hoạt động (giải thích bằng tiếng Anh đơn giản + ví dụ Java)
• Tích hợp từng bước với GroupDocs.Signature for Java
• Các trường hợp sử dụng thực tế, cân nhắc bảo mật, và những bẫy thường gặp
• Cách thay thế triển khai XOR bằng thuật toán mạnh hơn sau này

Câu trả lời nhanh

• XOR là gì? Một phép toán đối xứng đảo bit bằng một khóa; mã hoá hai lần bằng cùng một khóa sẽ khôi phục dữ liệu gốc.
• Khi nào nên dùng mã hoá tùy chỉnh? Khi cần tương thích hệ thống kế thừa, tối ưu hiệu năng, hoặc mục đích học tập—không phải để bảo vệ dữ liệu nhạy cảm.
• Thư viện nào được dùng trong tutorial này? GroupDocs.Signature for Java (v23.12 trở lên).
• Có cần giấy phép không? Bản dùng thử miễn phí đủ cho việc thử nghiệm; giấy phép đầy đủ cần cho môi trường sản xuất.
• Có thể thay thế XOR bằng AES sau này không? Có—chỉ cần thay thế logic encrypt/decrypt trong khi giữ lại giao diện IDataEncryption.

Mã hoá tùy chỉnh trong Java là gì?

IDataEncryption là một giao diện của GroupDocs.Signature định nghĩa các phương thức để mã hoá và giải mã dữ liệu. Mã hoá tùy chỉnh cho phép bạn xác định chính xác cách dữ liệu được biến đổi trước khi lưu trữ hoặc truyền đi. Với GroupDocs.Signature, bạn cung cấp một triển khai của giao diện IDataEncryption, và thư viện sẽ tự động gọi mã của bạn mỗi khi cần bảo vệ dữ liệu chữ ký. Mô hình plug‑in này cho phép bạn bắt đầu với một routine XOR đơn giản cho proof‑of‑concept và sau này thay thế bằng AES‑256 mà không cần thay đổi phần còn lại của quy trình ký.

Tại sao Mã hoá Tùy chỉnh Quan trọng

Mã hoá tùy chỉnh có giá trị khi các thuật toán hiện có không đáp ứng được các ràng buộc cụ thể như định dạng giao thức kế thừa, ngân sách hiệu năng chặt chẽ, hoặc yêu cầu hợp đồng độc quyền. Bằng cách tự triển khai routine của mình, bạn giữ toàn quyền kiểm soát việc biến đổi dữ liệu, giảm overhead, và đảm bảo tính tương thích mà không phải viết lại hệ thống bên ngoài, đồng thời vẫn tận dụng khả năng mở rộng của GroupDocs.

Tích hợp Hệ thống Kế thừa

Các hệ thống cũ đôi khi yêu cầu một phép biến đổi byte‑wise rất cụ thể—thường là XOR với một khóa byte đơn. Việc tái cấu trúc những hệ thống này tốn kém, vì vậy việc khớp kỳ vọng của chúng bằng một encryptor tùy chỉnh là con đường thực tế.

Tối ưu Hiệu năng

Các thuật toán chuẩn như AES‑256 mạnh về mặt mật mã nhưng có thể tiêu tốn đáng kể chu kỳ CPU, đặc biệt trên các thiết bị năng lượng thấp hoặc khi xử lý hàng triệu payload nhỏ. XOR chỉ cần một lệnh CPU cho mỗi byte, mang lại overhead gần như bằng 0 cho dữ liệu không nhạy cảm.

Yêu cầu Sở hữu

Một số hợp đồng hoặc tiêu chuẩn ngành quy định thuật toán tùy chỉnh (ví dụ, “XOR‑mask” do chính phủ chỉ định). Việc tự triển khai logic yêu cầu giúp bạn tuân thủ trong khi vẫn giữ phần còn lại của stack hiện đại.

Học hỏi và Linh hoạt

Xây dựng một encryptor tùy chỉnh buộc bạn phải hiểu các thao tác ở mức byte, quản lý khóa, và thiết kế dựa trên hợp đồng của giao diện IDataEncryption. Kiến thức này sẽ hữu ích khi bạn chuyển sang các giải pháp mật mã phức tạp hơn.

Mẹo chuyên nghiệp: Chỉ dùng mã hoá tùy chỉnh cho dữ liệu đã được bảo vệ bởi các lớp khác (TLS, VPN, hoặc mã hoá cơ sở dữ liệu). Không bao giờ dựa vào XOR làm lớp bảo vệ duy nhất cho thông tin cá nhân hoặc tài chính.

Hiểu về XOR: Những Điều Cơ Bản

XOR (exclusive OR) so sánh hai bit và trả về 1 nếu chúng khác nhau, 0 nếu chúng giống nhau:

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

Vì phép toán là tự nghịch đảo, áp dụng cùng một khóa lần thứ hai sẽ khôi phục giá trị gốc. Trong Java bạn có thể XOR hai byte bằng toán tử ^:

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

Khi bạn XOR toàn bộ mảng byte với một khóa byte đơn, bạn nhận được một biến đổi nhanh, có thể đảo ngược. Hãy nhớ, một khóa byte đơn chỉ tạo ra 255 biến thể có thể, vì vậy bất kỳ ai có một lượng ciphertext vừa đủ đều có thể brute‑force khóa ngay lập tức. Chỉ dùng cho mục đích obfuscation, không dùng để bảo vệ dữ liệu bí mật.

Các Điều Kiện Tiên quyết

Trước khi triển khai mã hoá tùy chỉnh với GroupDocs.Signature for Java, hãy chắc chắn bạn đã có:

Thư viện và Phụ thuộc Cần thiết

• GroupDocs.Signature for Java – phiên bản 23.12 trở lên (API sẽ được dùng xuyên suốt).
• Java Development Kit – JDK 8 hoặc mới hơn; JDK 11 được khuyến nghị cho hỗ trợ lâu dài.

Yêu cầu Thiết lập Môi trường

• Một IDE như IntelliJ IDEA, Eclipse, hoặc VS Code với các extension Java.
• Maven hoặc Gradle để quản lý phụ thuộc (cả hai đều được hỗ trợ).

Kiến thức Cần có

• Thành thạo các lớp, giao diện Java, và thao tác mảng byte.
• Hiểu biết cơ bản về các khái niệm mã hoá đối xứng (đã được trình bày trong phần XOR).

Nếu bạn đã đáp ứng tất cả các mục trên, bạn đã sẵn sàng thêm GroupDocs vào dự án.

Cài đặt GroupDocs.Signature for Java

Đưa thư viện vào hệ thống build chỉ cần một dòng XML hoặc Groovy.

Maven

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

Gradle

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

Tải trực tiếp

Nếu bạn muốn quản lý thủ công, tải JAR từ GroupDocs.Signature for Java releases và thêm vào classpath.

Các Bước Nhận Giấy phép

1. Dùng Thử Miễn Phí – tải JAR trial; các file output sẽ có watermark hiển thị.
2. Giấy phép Tạm Thời – yêu cầu key đánh giá 30 ngày để thử đầy đủ tính năng.
3. Mua Bản Quyền – nhận giấy phép vĩnh viễn cho triển khai sản xuất.

Khởi tạo và Cấu hình Cơ bản

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

Đối tượng Signature là điểm vào cho tất cả các thao tác ký, xác thực và mã hoá trong GroupDocs.Signature.

Hướng dẫn Triển khai

Tính năng Mã hoá XOR Tùy chỉnh

Chúng ta sẽ tạo một lớp triển khai giao diện IDataEncryption, sau đó đăng ký nó với đối tượng Signature.

Bước 1: Triển khai Giao diện IDataEncryption

IDataEncryption là giao diện của GroupDocs.Signature định nghĩa các phương thức để mã hoá và giải mã dữ liệu.

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

Giải thích: Lớp này cam kết hai hoạt động cốt lõi—encrypt và decrypt. Trường auto_Key lưu khóa XOR sẽ được áp dụng cho mỗi byte của payload.

Bước 2: Định nghĩa Phương thức Mã hoá và Giải mã

Vì XOR là đối xứng, cả hai phương thức thực hiện cùng một biến đổi byte‑wise.

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
}

Giải thích:

• Các guard clause bảo vệ khỏi khóa bằng 0 (sẽ không làm gì) và đầu vào null.
• Một mảng byte mới chứa dữ liệu đã biến đổi để tránh thay đổi buffer gốc.
• Vòng lặp XOR mỗi byte với auto_Key.
• Giải mã chỉ gọi lại encrypt, vì áp dụng XOR giống nhau hai lần sẽ khôi phục byte gốc.

Các Tùy chọn Cấu hình Khóa

• auto_Key phải là giá trị khác 0 trong khoảng 1 đến 255. Giá trị trên 255 sẽ bị cắt xuống 8 bit thấp.
• Lưu khóa một cách an toàn—biến môi trường, file cấu hình đã mã hoá, hoặc một secrets manager được khuyến nghị.
• Trong môi trường production, bạn có thể thay thế byte đơn này bằng khóa đa byte hoặc một cipher AES đầy đủ, nhưng giao diện vẫn không thay đổi.

Ví dụ Đặt Khóa

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

Những Sai lầm Thường gặp Khi Triển khai

Cân nhắc Bảo mật

Tại sao XOR không đủ cho Dữ liệu Nhạy cảm

XOR với một khóa byte đơn hầu như không có độ mạnh mật mã; kẻ tấn công có thể liệt kê ngay 255 khóa có thể. Phép toán còn rò rỉ các mẫu thống kê, làm cho các cuộc tấn công tần suất và known‑plaintext trở nên dễ dàng. Do đó, XOR không bao giờ nên là lớp bảo vệ duy nhất cho thông tin cá nhân, tài chính, hoặc bất kỳ dữ liệu bí mật nào.

Khi nào XOR được chấp nhận

XOR có thể được dùng an toàn khi dữ liệu đã được bảo vệ bởi các lớp mạnh hơn như TLS, VPN, hoặc mã hoá cơ sở dữ liệu, và mask chỉ nhằm ngăn chặn việc xem nhanh hoặc đáp ứng định dạng kế thừa. Nó phù hợp cho các identifier tạm thời, khóa cache, hoặc flag nội bộ không bao giờ rời môi trường tin cậy.

Các Giải pháp Mạnh hơn Được Đề xuất

• AES‑256 – tiêu chuẩn ngành, hỗ trợ sẵn qua javax.crypto.
• RSA‑2048 – hữu ích để mã hoá các khóa đối xứng nhỏ.
• ChaCha20 – hiệu năng cao trên CPU di động.

Vì hợp đồng IDataEncryption không phụ thuộc vào thuật toán, việc chuyển sang AES chỉ cần bạn thay thế thân của encrypt/decrypt bằng các lời gọi cipher thích hợp.

Ứng dụng Thực tiễn

1. Quy trình Ký Tài liệu An toàn

Bạn có thể cần lưu siêu dữ liệu người ký (ID, timestamp, department) sao cho không dễ bị xem xét. Khi dùng encryptor XOR của chúng ta, siêu dữ liệu được lưu dưới dạng mảng byte trong gói chữ ký, trong khi phần còn lại của PDF không bị thay đổi.

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

2. Kiểm tra Tính toàn vẹn Nhẹ

Mã hoá một hằng số đã biết và lưu cùng tài liệu. Sau này, giải mã và so sánh để xác nhận file không bị hỏng trong quá trình truyền.

3. Cầu nối Hệ thống Kế thừa

Một mainframe cũ yêu cầu payload mỗi byte được XOR‑mask với 0x7F. Bằng cách cấu hình cùng một khóa trong CustomXOREncryption, bạn có thể trao đổi dữ liệu mà không cần viết một dịch vụ chuyển đổi riêng.

Cân nhắc Hiệu năng

Tốc độ Thô

XOR chạy khoảng 1 ns mỗi byte trên một lõi x86 hiện đại, nghĩa là payload 10 MB được mã hoá trong chưa tới 10 ms. Ngược lại, AES‑256 ở chế độ CBC thường mất 3‑4 × thời gian đó cho cùng kích thước.

Dấu chân Bộ nhớ

Triển khai của chúng ta tạo một bản sao của mảng đầu vào, tạm thời tăng gấp đôi lượng bộ nhớ. Đối với file 50 MB, bạn sẽ cần khoảng 100 MB heap trong quá trình mã hoá. Nếu cần xử lý file lớn hơn, hãy xử lý luồng theo khối 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);
}

Thực hành Tốt cho Quản lý Bộ nhớ Java

1. Xóa khóa sau khi dùng: Arrays.fill(keyArray, (byte)0);
2. Sử dụng try‑with‑resources để đảm bảo luồng được đóng.
3. Tránh chuyển đổi byte đã mã hoá sang String; giữ chúng dưới dạng byte[] thô.
4. Giám sát heap bằng các công cụ như VisualVM khi xử lý nhiều tài liệu lớn đồng thời.

Khắc phục Các Vấn đề Thường gặp

Vấn đề 1 – “Dữ liệu giải mã trông như rác”

Câu trả lời ngắn: Đảm bảo cùng một khóa XOR được dùng cho cả mã hoá và giải mã, giữ dữ liệu ở dạng mảng byte suốt pipeline, và tránh bất kỳ chuyển đổi mã hoá ký tự nào có thể làm hỏng byte.

Nguyên nhân: Khóa không khớp, dữ liệu bị cắt ngắn, hoặc chuyển đổi ngẫu nhiên sang String sẽ làm thay đổi mẫu byte, khiến đầu ra không đọc được.

Vấn đề 2 – “NullPointerException khi mã hoá”

Câu trả lời ngắn: Phương thức encrypt đã kiểm tra null; nếu vẫn gặp ngoại lệ, hãy xác minh mảng byte nguồn được khởi tạo đúng trước khi truyền vào encryptor.

Cách sửa: Thêm các kiểm tra phòng thủ trong mã gọi hoặc chắc chắn dữ liệu chữ ký được tải bằng signature.getSignatureData() trước khi mã hoá.

Vấn đề 3 – “Mã hoá dường như không làm gì”

Câu trả lời ngắn: Thông thường khóa XOR được đặt thành 0. XOR với 0 giữ nguyên byte gốc, vì vậy đầu ra trùng với đầu vào.

Giải pháp: Đặt một khóa khác 0 bằng setKey() hoặc cung cấp một giá trị mặc định trong constructor.

Vấn đề 4 – “OutOfMemoryError trên PDF lớn”

Câu trả lời ngắn: Tải toàn bộ PDF vào bộ nhớ trước khi mã hoá có thể vượt quá heap JVM. Chuyển sang cách xử lý luồng theo khối như đã mô tả trong phần hiệu năng.

Mẹo: Tăng heap tối đa (-Xmx2g) chỉ là giải pháp tạm thời; hãy refactor sang xử lý theo khối để mở rộng.

Câu hỏi Thường gặp

Hỏi: Làm sao chọn khóa XOR phù hợp?
Đáp: Bất kỳ số nguyên khác 0 nào trong khoảng 1 đến 255 đều được, nhưng khóa tự nó không cung cấp bảo mật. Đối với bảo vệ thực sự, thay thế XOR bằng AES‑256 và lưu khóa trong vault an toàn.

Hỏi: Có thể thay đổi khóa XOR lúc chạy không?
Đáp: Có—gọi setKey() với giá trị mới. Nhớ rằng dữ liệu đã mã hoá bằng khóa cũ phải được giải mã trước khi chuyển, nếu không sẽ mất dữ liệu.

Hỏi: Có những lựa chọn nào thay thế mã hoá XOR?
Đáp: Đối với học tập, thử Caesar cipher hoặc Base64 (mặc dù Base64 chỉ là mã hoá). Đối với production, dùng AES‑256, RSA‑2048, hoặc ChaCha20 qua package javax.crypto của Java.

Hỏi: GroupDocs.Signature xử lý file lớn như thế nào với mã hoá?
Đáp: Thư viện sẽ stream nội dung PDF khi có thể, nhưng việc xử lý dữ liệu trong IDataEncryption do bạn quyết định. Triển khai mã hoá theo khối để tránh tải toàn bộ file vào bộ nhớ.

Hỏi: Có thể tích hợp tính năng này vào ứng dụng web không?
Đáp: Chắc chắn. Đăng ký encryptor như một Spring Bean, tiêm dịch vụ Signature, và lưu khóa trong biến môi trường hoặc secrets manager. Đảm bảo mỗi request xử lý dữ liệu trong một thread riêng để tránh tranh chấp.

XOR Hoạt Động Như Thế Nào trong Java?

Trong Java, XOR được thực hiện bằng toán tử ^ trên các giá trị byte. Bạn tải plaintext vào một mảng byte, lặp qua từng phần tử và áp dụng byte ^ key. Vì XOR là tự nghịch đảo, chạy cùng một routine với cùng một khóa sẽ khôi phục lại các byte gốc, làm cho quá trình mã hoá và giải mã trở nên đối xứng.

Các Bước Để Triển khai Mã hoá Tùy chỉnh với GroupDocs?

Để thêm mã hoá tùy chỉnh, đầu tiên tạo một lớp triển khai giao diện IDataEncryption, sau đó viết các phương thức encrypt và decrypt bằng thuật toán của bạn. Tiếp theo, đăng ký instance này với đối tượng Signature qua setDataEncryption. Từ lúc đó, GroupDocs sẽ gọi logic của bạn mỗi khi cần bảo vệ dữ liệu chữ ký.

Kết luận

Chúng ta đã đi qua toàn bộ vòng đời của cách mã hoá java bằng routine XOR tùy chỉnh, tích hợp nó với GroupDocs.Signature, và nêu bật các tình huống mà cách tiếp cận nhẹ này mang lại giá trị. Hãy nhớ:

• Chỉ dùng XOR cho obfuscation, không bảo vệ dữ liệu cá nhân hoặc tài chính.
• Giao diện IDataEncryption cung cấp điểm thay thế sạch cho các thuật toán mạnh hơn trong tương lai.
• Quản lý khóa, xử lý bộ nhớ, và streaming là yếu tố then chốt cho độ ổn định trong môi trường production.

Bước tiếp theo:

1. Thay thế logic XOR bằng AES‑256 để có bảo mật thực sự.
2. Thực hiện quay vòng khóa và lưu trữ an toàn.
3. Khám phá các tính năng khác của GroupDocs như quy trình ký đa chữ ký, xác thực, và đóng dấu tài liệu.

Bây giờ bạn đã có nền tảng vững chắc để tùy chỉnh mã hoá trong bất kỳ giải pháp ký Java nào—hãy triển khai và điều chỉnh nó cho nhu cầu kinh doanh của bạn!

Cập nhật lần cuối: 2026-06-26
Kiểm thử với: GroupDocs.Signature 23.12 for Java
Tác giả: GroupDocs

Tài nguyên liên quan:

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

Các Hướng dẫn Liên quan

• 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