RSA 加密算法的问题

[cosin0001]

采用的是 128 bit 的算法，发现加密中文字有些奇怪的问题

C 和 Java 的版本都出现这个问题

字符串 < 16 bytes 时，加解密没有问题。
字符串 = 16 bytes 时，如果开头的字符是个中文字，就加解密失败，如果开头的不是中文字，则没有任何问题。

去网上看了 RSA 的大概原理，发现如下的一个条件
0 < a < n ，发现可能是因为 中文字 的ASCII 是 0xA? ，比 n （008?...）的数值要大，所以 a mod n 会发生错误，因此 找了个 00FF... 开头的 n ，但是仍然加解密失败。

请教高手，RSA 的 128 bit 加密对于 长度 = 16 bytes 的字符串，中文开头的话，是什么原因导致不能加解密？

算法应该没有问题。

[DiabloWalkOnTheEarth]

RSA加密时,明文要比 N 小那么一点点,不然就OVER,你找个00FF开头的N岂不是N只有15bytes,当然更不行了.

[NowCan]

16字节的字符串，如果有中文，其最高位就是1，也就是128bits了。而RSA128bits的N，最高位确不一定是1，就是说可能存在127bits的情况，两个64bits的数乘很容易出现127bits的结果。
所以，解决方法是将分段改成8字节，这样会浪费一些空间，但是绝对可靠。
顺便说一下，128bits的RSA根本没有用，分解太容易了，至少1024bits才安全。

[cosin0001]

回复人： DiabloWalkOnTheEarth(毁灭小符 (Annihilus)(99)(3502))

我用的 Java 包里

RSA_N = "00FF..." ...里包含 30 个字符,总长是 34 个,前面2个零去掉,还有32位呢 = 16 bytes

RSA_N 这里面的都是 00 开头的

[cosin0001]

回复人： NowCan(((((( ★ ))))))

我找了个 "00FF..." 开头的 n （n = 16bytes，...里有30个字符的，总共 n 是16 bytes）,还是失败了,不可能有中文字比 0xFF 还大吧

目前切分的方法确实有用到，后面使用到的新字段已经考虑了，但是 系统数据库 中以前的一些字段已经被定义了，很多程序都是按这个定义写的（我介入系统的时候已经是后期了），因此目前要改变存储方法是不太可行的（系统再过没多少天就要正式运行了）

所以想问问 这个是 128 bit 的 RSA 的缺陷么？
如果不是缺陷，怎么才能 做到 16 bytes 长度中文开头，加解密正确？

[mathe]

是你的代码的问题吧？还有可能中文最高字节是1，你的算法可能把它当成负数了。
一般来说（实际上，被加密的数据量会比较大），我们不使用RSA直接加密数据，而是用一种对称算法（比如DES)来加密数据，而用RSA来加密对称算法的密码。