Allow passphrases to be supplied as char arrays

[justinludwig]

and to be zeroed after use; for #19

• Updated the Subkey class to:

  • Add new passphraseChars property, allowing a subkey's passphrase to be set and cached as a char[] instead of as a String object.
  • Add new unlock() method, allowing the subkey to be unlocked without caching the passphrase at all.
  • Cache the private-key material (in the form of a PGPPrivateKey object) after the subkey has been unlocked.
  • Add new clearSecrets() method, allowing the cached private-key material to be released for garbage collection, and zeroing-out the cached char[] passphrase.

• Updated the Key class to:

  • Add new passphraseChars setter as a convenience for setting subkey char[] passphrases.
  • Add new constructors that accept char[] passphrases; one each corresponding to the old String passphrase constructors.
  • Add new clearSecrets() method as a convenience for clearing subkey secrets.

• Updated the Ring class to:

  • Add new clearSecrets() method as a convenience for clearing subkey secrets.

• Updated the Encryptor class to:

  • Add new symmetricPassphraseChars property, allowing the passphrase for symmetric encryption to be set and cached as a char[] instead of as a String object.
  • Add new clearSecrets() method as a convenience for clearing subkey secrets, and zeroing-out the cached char[] symmetric passphrase.

• Updated the Decryptor class to:

  • Add new symmetricPassphraseChars property, allowing the passphrase for symmetric encryption to be set and cached as a char[] instead of as a String object.
  • Add new clearSecrets() method as a convenience for clearing subkey secrets, and zeroing-out the cached char[] symmetric passphrase.

[dtitov]

Looks good to me! The only question is whether the char[] passphrase should be copied or set as is. As I see, currently it's set as is, which means that upon clearing we will clear the original array as well. That might be a bit unexpected if the user still needs this array for some reason in some other place... On the other hand, it's documented in the JavaDocs, so it should be an expected behavior. I'm a bit unsure what behavior would be better in this case...

[justinludwig]

Thanks for the feedback -- that's a good point about whether to copy the char[] or not -- I can definitely see an argument either way. I'm thinking it's probably better to err on the side of clearing too much rather than too little, though, and make users explicitly create a copy of the char[] themselves if they want to keep the passphrase around for use later.

I'll go ahead and merge this in and build a new release with it (call it 0.5) in a couple of days.