Exactly I would like to add that a good way to make sure that you are signing the correct thing, in case you have malware versions of electrum on both computers is to decode the raw transaction before sending it, if possible on a pc or mobile offline

thanks to all participants in the thread

Not necessarily. If there is a vulnerability in the process used to generate the initial entropy, such that Electrum bases the whole key derivation process on pre-determined or deterministic entropy, then the seed phrase it produces will generate the same keys on other machines, while at the same time being known to the attacker. This is why I suggested that best way to mitigate would be to generate you own entropy by flipping a coin.

Generating weak keys. In theory, the OS could compromise Electrum and create a deterministic seed which would allow the attacker to compromise your funds without any connection to the internet. I don't find this much of a concern (if at all), I've never seen anything like this and Electrum might have implemented sanity checks (or the OS) to thwart such attempts anyways.

It doesn't hurt to validate the .iso file anyways.

(Is more of a reply to ranochigo's post, but system entropy is also used to derive private keys)

The kernel has its own entropy source, an ISO that fails the checksum check could have a backdoor implanted in the kernel random number generator /dev/random to discard entropy from hardware and return its own predictable entropy. This can even affect a verified version of Electrum, along with all other wallets like Core, even if a lot of programs might have already been read from /dev/random, as long as the sequence of bits generated since boot can be calculated. Just know how many bits Electrum uses for each secret and iterate through the entropy brute-forcing I..I+N bits with I beginning from 0 up to the total number of bits generated.

The problem here is that there is no system call to give the kernel RNG your own random bits to use. Even if there was, you wouldn't be able to provide it securely (It would have to go through the terminal, and then bash).

Follow up question then: Do you have persistent storage which is saving your wallet file, or are you restoring it from seed every time you want to use it?

As far as the QR core transportation is concerned, vulnerabilities cannot be stuffed into a QR code itself because it just encodes a query string (something like "address=bc1qabcdefg&amount=0.01&label=My address"), there is nothing an attacker can put in there to implant malware in Electrum, although they can of course change the address which'll generate a different QR code causing you to get scammed.

You did verify the checksum of the live ISO you downloaded, right? There have been cases of Linux distribution websites getting hacked and having malicious ISOs places instead. Somebody could place a package in the operating system specifically for snooping on Electrum private keys.

I would start by using the most up to date version of Electrum. Is there any particular reason you are still using 3.3.8? Even Tails has updated to Electrum 4.0.2.

I would be most concerned about physical access to your set up. Are you using full disk encryption on your airgapped device? I would suggest LUKS.

Side channels through the analysis of time delays and CPU spikes when signing could present an issue if someone with plenty of resources is really really interested in your coins.

TL;DR there are only two ways a GPG encrypted file can get compromised: By guessing the password or by using a backdoored GPG with a crippled AES cipher (or a vulnerable version of GPG that leaks AES keys). If you construct your diceware password without a computer and use a recent official GPG build with the default settings you should be safe. And also, you only need 10 diceware words to get 128 bits of entropy, each word is about 12.92 bits of entropy so 12 words will actually give you more, about 155 bits of entropy.

---

First let's assume the attacker does not know you used diceware.

For guessing the password, an attacker who knows nothing about it's composition will just run a brute force attack with every combination of graphical ASCII characters, and you can figure out that this takes too long to succeed.

There are 128-32-1=95 printable ASCII characters people usually make passwords from. So they make 95^1 + 95^2 + ... + 95^(N, the max length of password they're willing to crack) guesses to get the password. It's an astronomical number of guesses they have to make so we can rule out the possibility of someone successfully doing that for not small N. Even if they only tried cracking N length passwords they still have to do 95^N guesses.

Now let's assume they do know you used diceware and that your entropy came from things like coin flips and dice rolls so that the entropy is truly random. Even if they knew that and also how many words are in your diceware phrase, they still have to make 7776^(number of words) guesses to exhaust the entire random space. A diceware list has 7776 words in it.

So if you use 12 words in your diceware, and each of the words are on average 6 characters long, then they have to make 7776^12 = about 2^155 diceware guesses, or without using any diceware knowledge, a 95^(6*10+ 5 spaces) = 2^427 65-character brute force guesses (or an uncountable number of layman's 1,2,..,65-character brute force guesses). So the size of the random space to search dramatically drops with diceware but that isn't sometime to worry about because it's still too high to be exhausted by modern machines in the foreseeable future.

---

The AES cipher implementations used in GPG should be secure, given that there aren't any reported CVEs about it on https://www.cvedetails.com/vulnerability-list/vendor_id-4711/Gnupg.html. In fact, there are only 27 vulnerabilities reported on the entire program.

If you want maximum security you should download the GPG binaries or compile their source from their website, and verify the signature of what you download to make sure it's official. There have been cases of linux distributions getting compromised and delivering malicious packages so someone can theoretically replace the bundled official GPG with their own flawed GPG release. However, that particular case hasn't happened yet so if you only have a bundled GPG it should be safe to use that too (until such a case does play out, then I personally would migrate away from the impacted distribution).

In any case, if someone steals the encrypted file from Google drive, they have to go through all of the above labor to crack open the file.


AES-256 can still withstand quantum computers because Grover's algorithm used in quantum computers would break it in 2^128 rounds. I don't think there's an optimization to half the AES-192 search space yet, at least according to stack exchange.

GPG is not an algorithm.
So, it really depends on the cipher used.

Usually, for backups, you want to use symmetric ciphers (e.g. AES or CAST5, both were/are standards used by gpg under linux).

Encrypting a file (or data, generally) asymmetrically is rarely needed. What you usually do is to encrypt the data/file with a symmetric cipher and encrypt that symmetric key (which is way shorter than an asymmetric one) with an asymmetric cipher.
Symmetric crypto is way faster than asymmetric one.

To at least partially answer your question, the security of keys compared (by the NIST):

(source)

Bitcoin is using 256 bit EC keys. So, using AES with 128 bit keys is roughly as secure as EC with 256 bit keys.
And both are considered secure by the NIST (and the rest of the world). (Source: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf)


Now, to finally answer your question: It depends on the algorithm. 128 bit AES is secure. 128 bit RSA is not.
You want to have a bit strength of at least 128 bit and you are fine.


However, the encryption is not everything you need to worry about. A few additional things would be:

• Where is the decryption key stored?
• Is your PC definitely not compromised upon encryption?
• How do you generate the key (TRNG, dice)?
• How has your seed been generated (TRNG)?

P.s. Even quantum computers won't break AES 128 bit. Fully functional quantum computers will reduce the search space from 2¹²⁸ to 2⁶⁴ which is still far away from being broken / insecure.