THIS CHANGE IS UNTESTED. It builds fine, but I have not tested to see if it works. If DIGEST_NONE is, in fact, required by some codepaths, reject this pull request.
Allowing use of raw RSA keys is not safe. Signing chosen plaintexts can reveal the bits of the private key. The PKCS#1 v1.5 padding that you require limits this attack, but only if used with a good digest algorithm (the SHA-256 and SHA-512 algorithms you allow are great; even SHA-1 is technically okay in this context, though deprecated).
If your code always does the digesting prior to signing then DIGEST_NONE makes sense... but it's still risky because you do not get the assurance provided by AndroidKeyStore that the key can never be used without digesting. An attacker who somehow gains unlimited use of the key (e.g. compromises the Kryptonite app) can extract the private key. Of course, without DIGEST_NONE, such an attacker can sign anything he likes but only as long as he retains access to the phone; he can't clone the private key, so removing DIGEST_NONE is an increase in security.
THIS CHANGE IS UNTESTED. It builds fine, but I have not tested to see if it works. If DIGEST_NONE is, in fact, required by some codepaths, reject this pull request.
Allowing use of raw RSA keys is not safe. Signing chosen plaintexts can reveal the bits of the private key. The PKCS#1 v1.5 padding that you require limits this attack, but only if used with a good digest algorithm (the SHA-256 and SHA-512 algorithms you allow are great; even SHA-1 is technically okay in this context, though deprecated).
If your code always does the digesting prior to signing then DIGEST_NONE makes sense... but it's still risky because you do not get the assurance provided by AndroidKeyStore that the key can never be used without digesting. An attacker who somehow gains unlimited use of the key (e.g. compromises the Kryptonite app) can extract the private key. Of course, without DIGEST_NONE, such an attacker can sign anything he likes but only as long as he retains access to the phone; he can't clone the private key, so removing DIGEST_NONE is an increase in security.
Fixes: Issue #44