New answers tagged


The expiration date of subkeys is stored in a special kind of signature issued by the primary master key on the subkey. With other words, if you change the expiration date, no private keys are changed at all. If you can restore the public key later (for example, fetching it from the key server network), you're fine.


It depends. It comes down to risk management. By placing the payload into the public domain, you're betting against flaws being discovered in the cipher (and/or implementation), along with technology advancing sufficiently to brute-force the encrypted data. If your data loses value over time, the above risks may be acceptable compared to the convenience ...


Assuming the cryptography is implemented correctly, if any the member's keys are exposed or hacked then your data is vulnerable. The more people you have in this distribution, the greater the risk of information disclosure. Also check out this link, Encryption and the "security time decay" of prior encrypted data


I think one of the biggest risks is that somebody is accidentally going to replace an encrypted file with its unencrypted version. Keeping the files in a private place protects against that. It's part of the concept of multilayered security that others have mentioned: when one layer is bypassed, whether maliciously or accidentally, you still have some ...


If you have confidence in the encryption (which you should), depending on your implementation, you might be leaking some kind of metadata, for example: "user A is using the service", or "user B configuration has not been updated since ...", or "a new user C was recently created", or "80% of users recently moved away from the service".


There is always a risk that any given cipher will be broken at some point and data like this will become truly public. So yes there are some risks but it doesn't mean you aren't making a reasonable security trade-off. A few things you may want to consider: What's your worse case scenario with the data going public and are there implications to this data ...


No it's a pretty accepted practice to do this. Once encrypted, there really isn't any harm in having the encrypted file publicly accessible, assuming you've taken all the standard precautions: Don't store the private keys in the same location Routinely audit who has access and remove accordingly


I'm asking this because I've read somewhere the expiration date in OpenPGP is more of a notification mechanism and can be changed even after a key has expired. OpenPGP's expiry date is generally fine, but is no security feature (considering the primary key). I discussed the expiry date in depth in Does OpenPGP key expiration add to security?. Are ...


You can set every key to ultimate trust through opening the key edit command line gpg --edit-key [key-id] and running the trust command. You will now be prompted to select the trust level: Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I ...


Consider newbie pgp-user, a person who just heard about PGP. If that person receives a signed by whatsoever PGP - he will consider the message as fully trusted and signed and so on. This would create a false sense of security.


Yes, someone with access to your key can logon anywhere the corresponding public key is deployed, gaining access to your data and with the potential to do further mischief ("stealing my identity" is a bit vague). Carrying the key on a USB stick should mean the key is less exposed than sending it over the internet. If you don't have a passphrase on the key, ...

Top 50 recent answers are included