Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So the situation is thus. We're working with another company and as part of some file distribution processing we have to encrypt some files before they are sent.

The company in question sent us their public key which we have been using to encrypt files using GPG.

Recently they've got back to us complaining that they need to enter a passphrase each time they attempt to decrypt their files. So they changed their settings on their side to remove the passphrase requirement and sent us another public key

The thing is this "new" public key seem exactly the same as the old one. These are my tests: -

  • Both .asc files -> the same
  • MD5 hashsums of .asc files -> the same
  • Installed key into a test keystore -> GPG refuses to install it as it's the same as the one already there (i.e. "Unchanged: 1")
  • Deleted key from keystore, installed "new" key, made note of fingerprint/other details, deleted key again
  • Added "old" key to keystore, made note of fingerprint/other details
  • Compared the two notes -> the same

Surely we don't need to install this "new" public key if it's exactly the same as the old one? The reason why I ask is it's a bit of a pain to call our ops team to get them to install the key in the PROD keystore if we don't need to.

Any advice would be appreciated.

share|improve this question

2 Answers 2

up vote 6 down vote accepted

Public keys don't change just because someone removed (or changed) the passphrase on the private key. I see no reason why you would have to install this "new" public key.

I'd be concerned as to the competence of the other party if they're complaining that they have to always enter their passphrase (and that they thought it was a winning idea to remove the passphrase).

share|improve this answer
    
Normally I'd agree. But without any information about the sensitivity of the data or the overall security of either endpoint, the passphrase removal is moot, imho. –  Sirex Aug 5 '11 at 10:31
    
If security really wasn't important, they could just stop encrypting (or use weak encryption, like ZIP passwords or something). Anyone who doesn't know how to cache passphrases for repetitive use probably isn't competent to do proper security in a lot of other ways, either. –  womble Aug 5 '11 at 11:07
    
Thanks I suspected as much. I was starting to question my own judgement before posting this, so thanks for keeping me sane! As for the security issue - this isn't of our concern, our remit is to just encrypt the files and send them over, we have no visibility of work being done on their side. –  djhworld Aug 5 '11 at 11:46

+1 for womble; writing this as an answer to avoid chaaracter limit.

The public key does not have to change when the secret key is decrypted. "Removing the passphrase" for the secret key just means it is left in a decrypted state permanently and written to disk, whereas generally the secret key is itself symmetrically encrypted with a given passphrase to ensure that an assailant who gains access to the key file cannot access the key without also knowing the passphrase.

There was, however, no reason for them to reveal this incompetence to you (though you should be grateful to have this information, so you know not to trust the other party with security). You should advise your collaborators to merely save out cleartext versions of the desired encrypted files rather than leave the secret key unprotected. If the secret key falls into the wrong hands, the keypair is invalidated forever and all content encrypted for that public key will be accessible by anyone who has the secret key. This is obviously very dangerous if anything important has ever been encrypted for that keypair. Please tell your partners to reapply a passphrase and save out the files as cleartext rather than exposing the secret key directly.

share|improve this answer
    
Thanks for the reply, yep, the security concerns are certainly worrying but this issue is not of our concern, as far as we're concerned we just encrypt the files and transmit them. Their implementation and processes have no bearing on us. –  djhworld Aug 5 '11 at 11:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.