Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.
steps of generating & renewing PGP keys
A few staff left the company & there's no handover/documentation.
I was told by one colleague that placing it in the incorrect folder for the apps to read is one of the
main challenges :
we have a few sites with our outsource providers ie it may differ in folder locations for different
apps.
Can someone provide step by step instruction on how to generate new keys (it's required yearly
by Audit) & send over to remote end & how to check where to place them in right place for decrypting
(& if there's steps to decrypt it, let me know).
It's all on Win 7 and Win 2008 R2
I was told by one colleague that placing it in the incorrect folder for the apps to read is one of the
main challenges :
we have a few sites with our outsource providers ie it may differ in folder locations for different
apps.
Can someone provide step by step instruction on how to generate new keys (it's required yearly
by Audit) & send over to remote end & how to check where to place them in right place for decrypting
(& if there's steps to decrypt it, let me know).
It's all on Win 7 and Win 2008 R2
Who is Participating?
pgp used for what? Commonly each person has their own pair and the combination avails for secure communication.
Commonly, the public keys are exchanged.
The user can create a new pgp key, and resend it ..
If you have a pgp key exchange, a user can revoke/expire an old public key on this registration server while registering a new public key.
The user will maintain all prior private keys to avail access to prior ....
Getting detail on a setup whether the issue at hand is an encryption of a disk, admin OS level, then each user gets their own ......
Commonly, the public keys are exchanged.
The user can create a new pgp key, and resend it ..
If you have a pgp key exchange, a user can revoke/expire an old public key on this registration server while registering a new public key.
The user will maintain all prior private keys to avail access to prior ....
Getting detail on a setup whether the issue at hand is an encryption of a disk, admin OS level, then each user gets their own ......
It's public keys exchange that we need instructions on.
We encrypt sensitive files that we send over to our outsource provider who will use the key (presume it's public key) to decrypt at their application end (ie end to end encryption using PGP).
We encrypt sensitive files that we send over to our outsource provider who will use the key (presume it's public key) to decrypt at their application end (ie end to end encryption using PGP).
Sunhux,
He public key is exchanged, the remote side uses the private key to decrypt.
Understanding your setup is what is important. Do you have an internal key manager?
The short process, a new pgp key needs to be generated on the remote provider side, the new public key needs to be registered, usually, that meant it has to be uploaded into the ....
At the same time, the prior public key is revoked such that future emails will use the new public key in the repository.
The mailings encrypted with the prior public keys would still be accessible/decryptable on the remote side since they still have the private keys to access the data.
If there is no key repository, the remote provider needs to kr rate a new key pair. Send you the new public key. Your side would add the new public key to use for these mailings replacing the old one. While invalidating/untrusting the prior.
And that is commonly all it takes.
People leaving your side can not compromise the remote PGP key. I.e. Even if they took all the encrypted files which require that they have access to the private key of the remote recipient.
Have not had a chance to look at the links bean kindly provided, but the public key is named public as it has no security implication in the method of exchange.
Before merely signing an unencrypted message was sufficient to exchange public keys that a recipient would add to their public keyring as a trusted recipient's ...
In the newer proces, you actuall have to output the public key .asc file and email it to the remote recipient who will import it .........
It is on the user to "expire" the prior pgp public key from their public keyring
Commonly, the public and privates on their respective key rings
Are tied to the email for which they were generated.
I.e. User@somedomain.com in 2015 sent you their public key there is an identifier.
Then in 2016 has its own unique identifier/finger print.
The same is true for the 2017 and the newest 2018.
If you do not invalidate/untrust the prior keys, when generating an email you wish to encrypt for the recipient, a secondary parameter would be required to identify which of the existing public keys for this recipient should be used.
He public key is exchanged, the remote side uses the private key to decrypt.
Understanding your setup is what is important. Do you have an internal key manager?
The short process, a new pgp key needs to be generated on the remote provider side, the new public key needs to be registered, usually, that meant it has to be uploaded into the ....
At the same time, the prior public key is revoked such that future emails will use the new public key in the repository.
The mailings encrypted with the prior public keys would still be accessible/decryptable on the remote side since they still have the private keys to access the data.
If there is no key repository, the remote provider needs to kr rate a new key pair. Send you the new public key. Your side would add the new public key to use for these mailings replacing the old one. While invalidating/untrusting the prior.
And that is commonly all it takes.
People leaving your side can not compromise the remote PGP key. I.e. Even if they took all the encrypted files which require that they have access to the private key of the remote recipient.
Have not had a chance to look at the links bean kindly provided, but the public key is named public as it has no security implication in the method of exchange.
Before merely signing an unencrypted message was sufficient to exchange public keys that a recipient would add to their public keyring as a trusted recipient's ...
In the newer proces, you actuall have to output the public key .asc file and email it to the remote recipient who will import it .........
It is on the user to "expire" the prior pgp public key from their public keyring
Commonly, the public and privates on their respective key rings
Are tied to the email for which they were generated.
I.e. User@somedomain.com in 2015 sent you their public key there is an identifier.
Then in 2016 has its own unique identifier/finger print.
The same is true for the 2017 and the newest 2018.
If you do not invalidate/untrust the prior keys, when generating an email you wish to encrypt for the recipient, a secondary parameter would be required to identify which of the existing public keys for this recipient should be used.
attached is our best effort documentation (must say it's vague & may be incomplete) captured just prior to the staff leaving.
The pages on the 2nd half onwards (ie post generation of the keys) are the doubtful part of what we need to do, especially at the remote outsource provider's end.
The pages on the 2nd half onwards (ie post generation of the keys) are the doubtful part of what we need to do, especially at the remote outsource provider's end.
I gather generation is an indicator which should be used, i.e.
generation 1 have long expired if the one they sent you is generation 21.
how are the files transferred.
you have oureternalprovider@somesit
each time they send you a public key, you record the generation and the finger print of the public key that you then go ahead and add to the public keyring.
looking at the book, and listing the known public keys on the public keyring for this recipient that are active need to be listed and the preceding keys need to be marked inactive.
https://support.symantec.com/en_US/article.TECH148895.html
it is too complex to cover all the steps .......
familiarity with your environment is .....
point being so long as the public keyring used by whatever process is used to transfer the data after encrypting it .......
this is the ring to which the new public key needs to be added, while the prior inactivated.
Search For PGP key server
pgp.mit.edu/
pgp.key-server.io
keyserver.pgp.com/vkd/GetW
https://en.wikipedia.org/wiki/Key_server_(cryptographic)
generation 1 have long expired if the one they sent you is generation 21.
how are the files transferred.
you have oureternalprovider@somesit
each time they send you a public key, you record the generation and the finger print of the public key that you then go ahead and add to the public keyring.
looking at the book, and listing the known public keys on the public keyring for this recipient that are active need to be listed and the preceding keys need to be marked inactive.
https://support.symantec.com/en_US/article.TECH148895.html
it is too complex to cover all the steps .......
familiarity with your environment is .....
point being so long as the public keyring used by whatever process is used to transfer the data after encrypting it .......
this is the ring to which the new public key needs to be added, while the prior inactivated.
Search For PGP key server
pgp.mit.edu/
pgp.key-server.io
keyserver.pgp.com/vkd/GetW
https://en.wikipedia.org/wiki/Key_server_(cryptographic)
Fortunately, MIT PGP, includes info on key revocations.
https://pgp.mit.edu/faq.html
I had long ago registered a key...
the local user public keyring will remove the public key when the remote side sends you the revokation ...
https://pgp.mit.edu/faq.html
I had long ago registered a key...
the local user public keyring will remove the public key when the remote side sends you the revokation ...
Attached this time the work instructions: outsource provider told me they only need the private key for their applications to read (which confuses me further)
Generate_New_PGP_KeysampleSteps2.docx
Generate_New_PGP_KeysampleSteps2.docx
not very clear in the document. But it seems like once the pgp key pair is generated, that keypair is supposed to give to the outsourced vendor and future correspondence will be based on that public key to encrypt for the outsourced vendor to decrypt using the private key. The private key is protected using a password. So there must be a mean to get this across to the vendor so that they can use the private key for decryption. The EmbossAdmin seems to means to exchange this password with the vendor, those csenv.ini and getpass.ini are just the encrypted password. Eventually the auto retrieve bat file is another unknown where by the PAN details are downloaded and may be used to encrypt and shared with vendor .
.. It is actually the business logic and hard to determine based on the flow only.. ultimately the principle of key generation, key sharing out of band and having preshared secret and data encrypt/decrypt seems to be in the regime again so not much can be comments knowing the flow - better to draw up the chart
.. It is actually the business logic and hard to determine based on the flow only.. ultimately the principle of key generation, key sharing out of band and having preshared secret and data encrypt/decrypt seems to be in the regime again so not much can be comments knowing the flow - better to draw up the chart
Similar to btan, the fact that the PGP of the receiver is generated on the sending side means lack of security.
Why doesn't the receiver generate their own and provide the public to the sender. This way, the sender does not have the private to decrypt..
It would be similar to every year the locks on an external storage location have to be changed, but instead of having those at the remote, the people whose records/information should be stored would go to the external storage change locks, and provide the keys ......
think of it this way, you are shipping a container.
One option, is the remote side sends you a lock to which they have a key, or you go and buy a lock and mail them the key separately.
Make sure to create a revocation of the existing, but that would require that you have access to the old/current private key.
Why doesn't the receiver generate their own and provide the public to the sender. This way, the sender does not have the private to decrypt..
It would be similar to every year the locks on an external storage location have to be changed, but instead of having those at the remote, the people whose records/information should be stored would go to the external storage change locks, and provide the keys ......
think of it this way, you are shipping a container.
One option, is the remote side sends you a lock to which they have a key, or you go and buy a lock and mail them the key separately.
Make sure to create a revocation of the existing, but that would require that you have access to the old/current private key.
The last time (about 2-3 years ago) the receiver (ie sftp server end) or the outsource vendor sent us the public keys, somehow
the team ran into error (which they did not document down the error).
Now, I was told we send private keys to the outsource vendor instead.
the team ran into error (which they did not document down the error).
Now, I was told we send private keys to the outsource vendor instead.
Make sure to generate a revocation of the current key which you need to import to invalidate the current outsourced public key.
Since you are transitioning, why not take the time to test the scenario by having the outsourcing entity generate their own key, and provide you with the asc encoded public key the opposite your own guide on how the private key has to be handled before transmission.
Sounds as though this step was missed and the pubsec.skr
This way you may also review the steps potentially creating a process, that the outsourcing side could and would be responsible for maintaing compliance as it seems that now they rely on your firm to provide them new keys to transition.
Since you are transitioning, why not take the time to test the scenario by having the outsourcing entity generate their own key, and provide you with the asc encoded public key the opposite your own guide on how the private key has to be handled before transmission.
Sounds as though this step was missed and the pubsec.skr
This way you may also review the steps potentially creating a process, that the outsourcing side could and would be responsible for maintaing compliance as it seems that now they rely on your firm to provide them new keys to transition.
Agree with expert. Ownership need to be clear especially the source is on the vendor and you on receiving end mostly. There would be a trusted CA but you are using pgp and also not using any key server, so management of key is really adhoc and as and when informed of key status. Have them to owner the keys and contractually have this clarity.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
https://riseup.net/en/security/message-security/openpgp/best-practices
https://riseup.net/en/security/message-security/openpgp/gpg-keys#install-gpg4win
Note - You must not be sharing your private keys or transmitting them off the machine once install besides mainly for backup and recovery.
For Windows, you can consider Gpg4win. Choose a strong passphrase.
Example of a Step by step https://privacyforjournalists.org.au/guides/generating-pgp-keys-windows
During the installation, you can install the Gpg4win compendium too.
https://gpg4win.de/doc/en/gpg4win-compendium.html