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.