Topic: [GUIDE] How to Safely Download and Verify Electrum [Guide] - page 7. (Read 52687 times)

Fantastic post and find!!!!!  Works perfectly for me after 6 test runs with different stuff.  Also, the asc file name is not important at all because kleopatra will match the signing key to the actual file you are trying to verify as noted a post or two above this one.

I simply name the signature file as sig.asc on my Desktop.  I like keeping things simple.  This is so easy I may stop using command lines in a terminal for this process.

GREAT find and post worth merits!!!!!!

And just to clarify, because it may not be immediately obvious... after you double click the .asc file and get the dialog shown, You click the folder icon labelled #1 and select the .exe that you're trying to verify (that is the "signed data"). Then you click "Decrypt/Verify".


ps. that get's my vote for post of the year!

Actually, there is.

Here's how to enable it:

• Open Kleopatra's configuration - "Settings->Configure Kleopatra..."
• Go to "Crypto Operations" and uncheck "Automatically start operation based on input detection for decrypt/verify"; then Apply/OK.
• With that, every time you open an ".asc" file, you'll be prompted to select the file to verify using that signature file.

Image (after opening the signature):

I had encountered this, too. It seems that Kleopatra has to somehow find the executable by the name of the .asc file. Anyway, it doesn't matter with the verification and yes, you did it properly. The names of those files aren't related at all. There must be a setting where you choose both the signature and the executable and not just the signature.

It has quite confusing UI if I remember correctly.

I know this is a very dumb question but this is the first time I encountered this issue where I always need to rename the signature file similar to the name of the corresponding windows installer.

I've downloaded the signature file with a file name of:

Then I renamed the file to make the verification of the signature become possible using Kleopatra.

Am i doing this correctly? Because if I did not changed it there is an error that keeps popping out.

He should just post his key here and sticky it, have a few others quote it, then lock the thread. It's not perfect, as bitcointalk accounts can get hacked, but it will work as an additional source.

Or just upload all the public keys on a public PGP server. There are several of them on the internet that sync with each other, and finding one having a working page that lets you upload keys isn't too hard. These keys can't get "hacked" in the traditional sense because most clients that download these keys have a list of mirrors to try.

I don't think it's a big deal that they're all in the same Git repository.  The odds of both the Electrum site and the Git repository getting hacked at the same time are extremely remote.  If one or the other gets hacked the binary signatures wouldn't verify. 

I do think it adds security to have a couple of sources from which one could download the keys, just in case one of those sources is hacked.  In the OP I included redundant sources for ThomasV's key.  If you're in the habit of storing other people's public keys yourself, this really only helps when you download someone's key for the first time.  It would allow you to confirm that the multiple sources provide the same key, which helps confirm the key's authenticity.  Once the key has been downloaded and a signature confirmed, you should store the key locally.  Again, this is based on the theory that it's unlikely for multiple sites to get hacked simultaneously.

Wouldn't it be wiser to publish those keys on separate places? For example, they could also upload them onto Google Drive, Gitlab etc. It doesn't offer a greater security if in the same place Thomas' public key is, you put the others' too, because the compromiser could just generate seven keys more.

There might be a reason behind this I can't think of at the moment. Anyway, thanks for doing it.

Since the Electrum releases are now being signed by multiple builders I thought it was a good time to update the OP to mention that fact, and also add the following link:

Electrum Builders' Signing Keys: https://github.com/spesmilo/electrum/tree/master/pubkeys

People getting lazy for any reason on verifying signatures, that's on them. If a hash is provided, verify hash for integrity. (some people still use dial up modems today or are on choppy intermittent satellite connections). If a GPG signature is provided, verify it too.

As to why?, aside from all the other reasons stated, why not? How else do you know if a particular public key is trusted if no one else signs it? Very few people actually trust my own public key (or more accurately, few signed it and uploaded the signed key to the keyserver) but I've tried to put it in more than one place.

They whole point of using PGP keys to sign stuff for others to verify them is to utilize the Web of Trust which is the correct way of using PGP too. That warning is mandatory (it is not bogus, and should not be hidden) since it is telling you that you have forgotten a very important step in verifying digital signatures which is to first import a trusted public key the correct way not just copy it from the internet without putting much thought into it.

By adding the public key of the signer and adding it to your trusted keys (you should have your own key here) you are confirming that you DO actually trust this public key.
Otherwise a malicious attacker can create a fake software, a fake public key and a valid signature with that fake public key. An unaware user downloading all 3 from the same place would see a valid signature but has a fake/malicious software.

You don't need a private key or to certify anything to verify stuff, the certify process is only to remove the bogus "This key is not trusted" warnings. Some suites may not even display it at all (GPGtools does insist on making a keypair though, I wonder if you can skip that part).

That would be pointless because it is like saying each transaction should both contain the signature and the hash it signed. We already know how to serialize the transaction and hash it to verify that signature in that transaction, similarly we already know how to read the file binary and hash it to then sign.

On top of that providing the hash is increasing the risk of newbies getting scammed because it encourages lazy people to only verify the hash instead of the signature (even if the signature is also provided). Down the line we could see someone downloading a fake Electrum and only verifying its hash the scammer provided!

File hashes should ONLY be used for integrity validation NOT authenticity. Integrity validation is also not needed because it is leftover concept from the dial up model days when the  downloaded file could get corrupted.

There aren't many things to be mentioned about the complexity of the tutorial. As I said, you guided the reader step-by-step of how to verify the signature of the binaries, but what I find missing from this tutorial and generally from almost every tutorial on the internet is the lack of explanation. Don't get me wrong! Not the explanation that will make you succeed on verifying the signature. I'm talking about the answer to "why?".

Why would I need a private key to certify the public keys of others?

Why would I need to certify someone just to ensure that my electrum binaries aren't malicious? Why will I have to deal with an email address and how is it resulted from a file of non-sense characters?

Why would you recommend me to create a private key? Note that this can be very confusing for a newbie. Do I need a private key for the certification of Thomas' identity or is it just recommended after all?

Thank you for saying that, this is actually the type of feedback I want.  Would you be willing to take some time and tell me what you found to be complicated?  I would really like this tutorial to be simple enough for folks who aren't what we would call "computer savvy," and those who are new to cryptography.

It can be hard for us who enjoy these types of technical projects to put things into the perspective of the masses who don't.  But, we need to keep in mind that we all started someplace.  No one is born with knowledge of cryptography, we all started with a lot less knowledge than we have today.  I've been playing and working with computers since 1985 and considered myself among the more advanced users in my circle of acquaintances and collogues.  But, when I showed up here I felt like a complete dunce.  It had been nearly 20 years since I had used a Unix style OS, and found myself struggling with simple shell commands.  I still get lost reading the technical boards, and realize I've only scratched the surface of how much knowledge exists here.

And, I don't think you and I are alone.  Look at how many newbie accounts pop up asking pertinent, pointed technical questions.  I have a feeling many of these "newbies" are actually long time members who are embarrassed to ask questions from their main account.



Lol.  Don't stop.

Minor correction: I did not ask the dev team, but I made a thread about it here and those were the answers I got (it's a good throwback read).

Internally, GPG signatures already use a hash or checksum, most likely either SHA1 or SHA256, so it's not any more likely than the signature itself to have a collision. The signature could be SHA512 (that's what I set mine to) so the "unlikelyness" of a collision is effectively and for all practical purposes, zero, unless something is broken.

With a GPG signature, the file is first hashed, then that hash is then signed. It does not "sign" the whole file.

I think the files should be both signed and also include a hash (and the hashes are also signed). More work maybe, but what's another page to sign? If not, just accept what is available. GPG signatures alone are more than enough. Hashes just make it convenient and easy to verify download integrity.

I meant faster for the newbies who want to verify their executables. I don't know about the others but when I firstly verified electrum using this tutorial, I wasn't completely sure of what I was doing. I was feeling secure with the replies and with the greatly described steps, but I considered the method kinda complex. To be honest, I wasn't into anything related with Bitcoin a year ago, as you can see in the first page of this thread, so this is maybe why. 

Or I may simply have this weirdly paranoid symptom in which you want to understand every-single-thing you're doing, on a disgustingly detailed way, such as understanding the maths behind RSA/ECC. Anyway. Signed checksums might had a shorter tutorial than this one. Although, you're explaining everything perfectly.

While, they may prefer not to do this with the checksum-way, I personally find it ridiculous for them to justify it with the collisions. Despite the fact that it's never going to happen you're essentially failing the function your entire project relies on. It's ironic...

I might be misunderstanding your question/comment, so I'll try to get a handle on it:

You're suggesting that (like the bitcoin core dev team) the Electrum dev team should post a PGP signed list of checksums, correct?  Although there's nothing wrong with that, I fail to see how that's faster.  GPG can verify the 28 megabyte windows installer file in just a few second (if that,) it takes me longer to type out the command.  

If the dev team only published a signed list of checksums, I would still verify the PGP signed list, and then I would have to verify the checksums of the binary file.  I would have to verify two files, which takes longer.

And, like NotATether already mentioned; the question was posed to the Electrum dev team.  They don't like that approach due to slight risk of checksum collisions.  Obviously checksum collisions are HIGLY unlikely, but if you have the tools to mitigate a potential issue why not employ them?