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