Hi,
user@ubuntu:~$ gpg --import id_public_key.asc gpg: key 79A9F115: "Immunity Debugger (Immunity Debugger Sign Key) immunitydebugger@immunityinc.com" not changed gpg: key 54BF70F2: "Immunity Debugger (Immunity Inc.) immunitydebugger@immunityinc.com" not changed gpg: Total number processed: 2 gpg: unchanged: 2
user@ubuntu:~$ gpg --verify ImmunityDebugger_1_80_setup.exe.sig ImmunityDebugger_1_80_setup.exe gpg: Signature made Tuesday 07 December 2010 03:07:31 AM IST using DSA key ID 54BF70F2 gpg: Good signature from "Immunity Debugger (Immunity Inc.) immunitydebugger@immunityinc.com" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 6E32 9351 3A61 5274 6FBF 8273 ABCA 792D 54BF 70F2
user@ubuntu:~$
Is this the proper way of checking the integrity of application with .sig and public key files?
Sorry if it sounds a silly question, but this is the first time I'm dealing with .sig file instead of md5/sha1 hashes.
2010/12/16 Sagar Belure sagar.belure@gmail.com:
user@ubuntu:~$ gpg --import id_public_key.asc user@ubuntu:~$ gpg --verify ImmunityDebugger_1_80_setup.exe.sig gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 6E32 9351 3A61 5274 6FBF 8273 ABCA 792D 54BF 70F2
Is this the proper way of checking the integrity of application with .sig and public key files?
You have got the process right to the extend of verifying that ImmunityDebugger_1_80_setup.exe wasn't modified since the time it was signed by id_public_key.asc, but the next question is whether you trust id_public_key.asc to be actually the key of the person/organization it claims to be. In the WoT scenario, you either know the person personally and hence will ask him whether they key really belongs to him, or alternatively, you'll get someone whom you trust to vouch for the key. If you feel that the key indeed belongs to Immunity, then you can "trust" it yourself - by setting it as a trusted key. Further, you'll sign the key yourself so that someone who trusts you can use your signature to base his decision on the same question.
Sorry if it sounds a silly question, but this is the first time I'm dealing with .sig file instead of md5/sha1 hashes.
The .sig file is pretty much a SHA1 hash that is supposed to be tamper-proof. Without the signature, someone can possibly alter the data being hashed and the hash itself.
Binand
On Thu, Dec 16, 2010 at 6:28 PM, Binand Sethumadhavan binand@gmail.com wrote:
2010/12/16 Sagar Belure sagar.belure@gmail.com:
user@ubuntu:~$ gpg --import id_public_key.asc user@ubuntu:~$ gpg --verify ImmunityDebugger_1_80_setup.exe.sig gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 6E32 9351 3A61 5274 6FBF 8273 ABCA 792D 54BF 70F2
Is this the proper way of checking the integrity of application with .sig and public key files?
You have got the process right to the extend of verifying that ImmunityDebugger_1_80_setup.exe wasn't modified since the time it was signed by id_public_key.asc, but the next question is whether you trust id_public_key.asc to be actually the key of the person/organization it claims to be. In the WoT scenario, you either know the person personally and hence will ask him whether they key really belongs to him, or alternatively, you'll get someone whom you trust to vouch for the key. If you feel that the key indeed belongs to Immunity, then you can "trust" it yourself - by setting it as a trusted key. Further, you'll sign the key yourself so that someone who trusts you can use your signature to base his decision on the same question.
Thanks for the explanation. That was very neat.
Sorry if it sounds a silly question, but this is the first time I'm dealing with .sig file instead of md5/sha1 hashes.
The .sig file is pretty much a SHA1 hash that is supposed to be tamper-proof. Without the signature, someone can possibly alter the data being hashed and the hash itself.
Binand
-
Binand Sethumadhavan -
Sagar Belure