RSA block by block encryption produces blank output for files larger than 1kb

前端 未结 2 1632
爱一瞬间的悲伤
爱一瞬间的悲伤 2021-01-26 22:48

I\'m not opening this thread for AES or other encryptions because this is what I\'m going to use to encrypt the keys of AES and other encryptions. I\'ve gathered several codes f

相关标签:
2条回答
  • 2021-01-26 23:28

    Although the algorithm RSA is internally expanded to mean "RSA/ECB/PKCS1Padding" by the Sun provider. However, ECB mode is not actually used. It should have been named "RSA/None/PKCS1Padding". So RSA cannot be used for larger data by CipherOutputStream as it doesn't implement any block cipher mode.

    Unfortunately CipherOutputStream has the nasty habit of "eating" exceptions. This is why you get an empty string instead of a clear warning.


    One of the problems with Java are checked exceptions. Although they certainly have their benefits, exceptional circumstances should not be part of a function definition. Checked exceptions are a well-meant but wrong method to produce reliable / error free code.

    This is made perfectly clear by the IOException that may be thrown by streams. Not all streams do actually perform I/O so the exception is wrong. But because IOException is a checked exception it must be part of the write method definition. On the other hand, security exceptions have a checked base class called GeneralSecurityException. These exceptions cannot be thrown by a stream because they are not defined in the method definition.


    Now there are ways around this, for instance creating an additional secureWrite method that does throw the exception. The usual write method could throw a new RuntimeException derived exception carrying the original GeneralSecurityException. These solutions seem to have escaped the designer of the cipher streams though; instead they opted remove the exceptions altogether or possibly throw an IOException where another exception is expected.

    As a result the cipher streams should be used with extreme caution. Replacing them with a proprietary implementation seems best.

    0 讨论(0)
  • 2021-01-26 23:38

    RSA is not ment for bulk encryption as it's quit slow compared to symmetric algorithms like AES (it's more than a factor of 1000 slower). The amount of data that can be encrypted with RSA in one block is dependent on the key size and any data that might be used by padding.

    When you need the two keys of RSA and at the same time need to encrypt more than what can be in one RSA block, you would usually use Hybrid encryption, where you encrypt the data part with a random symmetric key, and then encrypt the encryption key with RSA. This way you get the speed of the symmetric key, and the two keys of the RSA. But if you don't really need to have different keys for encryption and decryption then you properly should not use RSA at all.

    As RSA is not ment for bulk encryption, the standard implementation's can't handle it when you try to encrypt more than what can be in one block - no logic is implemented for chaining of encryption blocks with RSA. This would be handle for symmetric ciphers out of the box.

    0 讨论(0)
提交回复
热议问题