** bump **
I followed this tutorial about encrypting and decrypting a message: https://www.deepdotweb.com/2015/02/21/pgp-tutorial-for-windows-kleopatra-gpg4win/
As I am correct, you need a public key of your recipient to be able to generate the signed message to be send.
But what if I would like to post a signed message, but not to a specific recipient? Like the mentioned example, I encrypt the ICO address?
Is that possible with PGP.
Thanks
Topic: PGP in combination with KYC (Read 173 times)
Hi guys, I'm doing research about PGP keys.
I was reading documentation (*) about PGP and its weaknesses, and to me, the biggest weakness seems to be the validation of the PGP key.
I read about public servers storing (aka staking on BTT) PGP public keys (with only their email attached). However, this doesn't guarantee that you still own a PGP key and you can have multiple PGP keys as you can make as many emails as you want.
This introduction leads to my question, why is there no PGP key server who stores KYC data (like passport, drivers license, picture of you holding the PGP pub key with date written on paper) in combination with the PGP public key? If there is such a server, can you please provide me a link?
Second question, this is a good practice for ICOs or token sales to validate messages like an announcement containing the deposit address? This will be an encrypted message where the public key is provided so every user has to decrypt the message to see the ICO/token sale deposit address. There is only one risk that remains, e.g Coindash there website got hacked and the attackers replaced the deposit address with a wrong one. It is possible to replace the full encrypted message with public key with a false one. So it is important to remember investors to first validate the user behind the provided public key to be sure it is one of the team members and the correct email address. Because, a hacker can stake a PGP public key with a similar address to the one provided by the ICO/token sale, which makes it more tricky. E.g. [email protected] and malicious one: [email protected]. As you can see, it is important that an ICO/token sale buys sufficient domain names that can be abused by malicious persons.
(*) http://www.cymru.com/gillsr/documents/pgp-key-verification.htm
https://tools.ietf.org/html/rfc4880#page-5
I was reading documentation (*) about PGP and its weaknesses, and to me, the biggest weakness seems to be the validation of the PGP key.
I read about public servers storing (aka staking on BTT) PGP public keys (with only their email attached). However, this doesn't guarantee that you still own a PGP key and you can have multiple PGP keys as you can make as many emails as you want.
This introduction leads to my question, why is there no PGP key server who stores KYC data (like passport, drivers license, picture of you holding the PGP pub key with date written on paper) in combination with the PGP public key? If there is such a server, can you please provide me a link?
Second question, this is a good practice for ICOs or token sales to validate messages like an announcement containing the deposit address? This will be an encrypted message where the public key is provided so every user has to decrypt the message to see the ICO/token sale deposit address. There is only one risk that remains, e.g Coindash there website got hacked and the attackers replaced the deposit address with a wrong one. It is possible to replace the full encrypted message with public key with a false one. So it is important to remember investors to first validate the user behind the provided public key to be sure it is one of the team members and the correct email address. Because, a hacker can stake a PGP public key with a similar address to the one provided by the ICO/token sale, which makes it more tricky. E.g. [email protected] and malicious one: [email protected]. As you can see, it is important that an ICO/token sale buys sufficient domain names that can be abused by malicious persons.
(*) http://www.cymru.com/gillsr/documents/pgp-key-verification.htm
https://tools.ietf.org/html/rfc4880#page-5
Jump to: