Java中的XOR加密:解密后丢失数据 [英] XOR Encryption in Java: losing data after decryption

查看:152
本文介绍了Java中的XOR加密:解密后丢失数据的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在编写一个非常小的Java程序来实现一个一次性的pad,其中pad(或key)本身使用一个SecureRandom对象生成一系列字节,该对象使用一个简单的字符串SHA-512算法。

I'm currently writing a very small Java program to implement a one-time-pad, where the pad (or key) itself is generated as a series of bytes using a SecureRandom object, which is seeded using a simple string with the SHA-512 algorithm.

生成一次性垫没有引起任何问题,如果我每次提供相同的种子字符串,我预期会得到相同的序列,随机数,使解密过程成为可能,只要人员解密有用于加密的种子字符串。

Generating the one-time-pad hasn't caused any problems, and if I supply the same seed string each time, as expected I get the same sequence of psuedo-random numbers, making the decryption process possible as long as the person decrypting has the seed string used to encrypt.

当我尝试加密文件时,程序读入一次数据64个字符(文件结束除外,通常为奇数),并生成64字节(或匹配数量)的伪随机字节。在两个数组的元素之间执行XOR,将包含密码字符的结果 char 数组写入文件,重复此过程,直到文件中的所有文本都已读取。

When I try to encrypt a file, the program reads in the data 64 chars at a time (except for the end of file, which is generally an odd number), and generates 64 bytes (or matching amount) of psuedo random bytes. XOR is performed between the elements of both arrays, the resulting char array containing the cipher characters is written to file, and the process repeats until all text in the file has been read.

现在,由于Java将所有原语视为有符号数字(数据类型字节的范围为-128到127, 0到255)这意味着XOR操作可以(并且确实)导致一些负值(-128到-1)。似乎Java不能将这些值识别为有效的ASCII,只需写一个? (问号)到文件的任何负值。当从文件读取解密密文时,导致的负值?被写入文件丢失,用63替换有效的ASCII码作为问号。

Now, because Java treats all primitives as signed numbers (the data type byte ranges from -128 to 127, not 0 to 255) this means that the XOR operation can (and does) result in some negative values (-128 to -1). It seems that Java does not recognise these values as valid ASCII, and simply writes a ? (question mark) to the file for any negative values. When it comes to reading from the file to decrypt the cipher text, the negative value that resulted in the ? to be written to file is lost, replaced with 63, the valid ASCII code for a question mark.

这意味着异或这个值是无用的,没有原始值没有办法产生明文。顺便提一句,如果我重现加密某些数据的行为,然后在相同的程序运行中立即解密数据,并且打印状态一直没有问题。只有数据写入文件是丢失的信息。

This means that XORing this value is useless, without the original value there is no way to produce the plaintext. Incidentally, if I reproduce the behaviour of encrypting some data and then decrypting the data immediately after, in the same program run, and printing status along the way, there are no problems. Only if the data is written to file is the information lost.

我还应该提到,我尝试添加128到每个加密XOR结果,然后在执行之前减去它解密XOR(将每个值放在有效的ASCII范围内),但是?问题仍然出现,因为有128个ASCII码,从128到159,我无法阅读并显示为?

I should also mention that I did try adding 128 to each encryption XOR result, and then subtracting it before performing the decryption XOR (to put each value in a valid ASCII range), but the ? problem still showed up because there are 31 ASCII codes from 128 to 159 that I'm unable to read and appear as ?

我一直在撞我的头在这一段时间,任何帮助是赞赏。
干杯。

I've been banging my head off the wall on this for a while now, any help is appreciated. Cheers.

推荐答案

这很困惑。如果正在处理一个字符数组,元素是16位宽,它们是无符号的,并不是所有的值都是有效的。所以(a)你不可能有一个符号或字节的问题,和(b)你不应该这样做。您应该将文件读入字节数组,XOR-ing,并将字节数组直接写入输出文件。没有读者或作家,没有字符,没有字符串。

This is very confused. If you are processing a char array, the elements are 16 bits wide, they are unsigned, and not all values are valid. So (a) you cant possibly be having a problem with signs or bytes, and (b) you shouldn't be doing that at all. You should be reading the file into a byte array, XOR-ing, and writing out the byte array directly to the output file. No Readers or Writers, no chars, no Strings.

这篇关于Java中的XOR加密:解密后丢失数据的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆