Re: [Tails-dev] Set coin selection to "privacy" by default in Electrum
I just spent an hour reading: * https://medium.com/@lopp/the-challenges-of-optimizing-unspent-output-selection-a3e5d05d13ef#.63vst18ff * https://github.com/spesmilo/electrum/issues/1203 First, let me say that I absolutely do not want this feature documented for end-users. I'm not sure how this could be explained in less a way so a user could make an informed decision without using thousands of words (with a thousand possibilities to misunderstand). So, yeah, either we enable this by default in Tails, or we completely ignore it. Second, now I understand this feature better, and I feel quite convinced that it makes sense for Tails: we can take a selfish stance were we don't care about the potential negative effects this can have on the network and blockchain bloat; then only other drawback is potential increase of transaction fees, but that seems like a negligible effect to me. So, I say: let's do it! If you want to speed things up, please create a ticket about this, and assign it to me. Mega bonus points if it contains a patch against config/chroot_local-includes/etc/skel/.electrum/config. :) Cheers! That's great news! I created issue #12177 and I uploaded the replacement config file. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Set coin selection to "privacy" by default in Electrum
Anonym, Of course, mine too (and intrigeri's, I'm sure :)). Sorry for frustrating you like this about something that is obvious for you, but it indeed gets hard for us when we need to consider things we have little or no clue about. And I'm sure you understand we cannot just blindly trust and implement any suggestion we get. Yes, I understand. I think that it is unlikely that other Tails users will give their opinion, so could we at least put this setting in the documentation? Otherwise, I guess that we will have to abandon it. Cheers, Michael English ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Set coin selection to "privacy" by default in Electrum
Anonym,
Please Cc me with any replies. For some reason, I am unable to subscribe
to the list.
Anonym:
> Note that I haven't chimed in with my opinion yet. :) I think intrigeri
> is just careful: privacy features are routinely exaggerated in their
> efficacy and can easily have many unexpected effects; for instance,
> playing with such parameters often introduces fingerprintability
> ("this user seems to have enabled the non-default feature X, which
> Tails enables, so +1 indication that this is a Tails user"). It's
> hard to weigh weigh such advantages and disadvantages against each
> other, especially when the domain (blockchain) is not well-known,
> which at least is the case for me (intrigeri has read up in the past
> weeks for other reasons, so he's definitely in a better position to
> evaluate).
Increased fingerprintability is not at all relevant here. Consider
adding uBlock Origin to the Tor Browser as an example of increasing the
fingerprint left by Tails users. Websites could check whether a client
using Tor is blocking ads to narrow down that the user is a Tails user.
The coin selection that I recommend changing happens entirely offline.
No remote servers are involved in the creation of a new transaction.
Once the transaction is broadcast to the Bitcoin network, the
fingerprintability actually goes down as the transaction looks more
generic. Remember that all transactions will have inputs and outputs
that appear the same to the network. The change here is selecting inputs
that reveal less about the user’s total bitcoin balance.
> So, if the decision comes down to me, I'd delegate to our community.
> That's also hard. Now we have two voices in favour, none against,
> and some probably good arguments for those that know how the
> blockchain works. If we can get some argument why enabling this
> feature won't have nasty consequences (e.g. increased
> fingerprintability) and get some more people to join in support for
> this change, I'd do it. I am afraid this is the best I can do.
Is anyone else in favor or against this change? My attempt is to make
privacy a default option in Tails.
Cheers,
Michael English
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Set coin selection to "privacy" by default in Electrum
Intrigeri, Hi, s7r: intrigeri wrote: The text was copied from Electrum man page. Thank you! UTXO's are basically the coins you can spend. The spendable coins are in UTXO's, not in addresses. Addresses are just a smart crypto way to let the world know in advance who has the right to spend a given UTXO. Existing unspent outputs cannot be reused, they are burned and re-crated entirely every time. So you cannot spend part of a UTXO, you spend it all (practice does not recommend re-using addresses - it's true nothing keeps you from receiving the change in the same initial address that you spent from, but you'll have a different UTXO). Yes, I had to learn all that last week already, but thanks anyway :) Still, this doesn't answer my question of why the setting called 'privacy' "helps to reduce blockchain UTXO". I would love to understand, if someone is kind enough to explain it to me. I will try to explain to you what I think Electrum meant by reducing UTXO bloat. I am not a good teacher, but I hope that this helps. Honestly, reducing UTXO bloat depends on the circumstance. I will explain a few circumstances below. The UTXO set is most likely to be reduced by the "privacy" setting in a circumstance where one address has received three or more inputs. There are three cases for transaction inputs and outputs: 1. Find exact change 1. This case is very unlikely unless transaction creation is hand optimized. For example, let's say that I want to donate 0.01 BTC to Tails ;) and I find that I have a UTXO of 0.012 BTC. I could decide to spend the extra 0.002 BTC to protect my privacy and save a small amount on transaction fees. In this case, the UTXO set is not changed since there is one input and one output. 2. Use Electrum's "priority" coin selection that uses older and larger value UTXO first 1. This case is likely to use a single large value UTXO and produce two outputs since one output has to be the change. The extra output created by this transaction could be considered "bloat." 3. Use Electrum's "privacy" coin selection that prioritizes the number of UTXO in an address (and also optimizes change which we are trying to avoid) 1. This case takes several medium to small value UTXO and combines them into two outputs. If the number of inputs are three or more, then this could be considered reducing UTXO bloat. Routing transaction relay through Tor is only part of the solution. The blockchain is a public ledger that can be analyzed anytime after the initial transaction broadcast. Private coin selection impedes correlation of transaction inputs and outputs that could link back to an identity. Sure. I hope our doc clearly states that it's very hard to use Bitcoin in a privacy-preserving way, for some various value of "privacy". Agreed, but the setting indicated by Michael could be shipped as a default imho. It makes sense in a context like Tails/Tor threat model. Sorry if I was unclear: I'm not arguing this point. I didn't look into it in details, so I am really not in a position to have opinion about it yet. It's clear to me that there's no way to optimize coin selection for all possible desired outcomes (e.g. optimizing the blockchain itself, optimizing usage of unspent outputs i.e. not wasting money via fees on the long term, optimizing some kind of privacy on the short term), but it's not obvious to me which way Tails should lean towards: at this point I have no idea if the (limited) privacy benefits brought by this feature outweigh the drawbacks it brings in other areas. I think that the privacy benefits are more substantial than you think and transaction fees should be about the same. Consider the fact that the current method spends across multiple addresses in a single transaction confirming in that transaction and future transactions that a single identity owns all of those addresses. Anyway: I personally don't feel responsible for maintaining the Electrum integration in Tails, would rather not to become more involved into it, and will therefore let its maintainer (i.e. anonym) make the call. But I'm genuinely curious about the unspent outputs optimization claim; I bet my intuition is wrong, and I'll learn something along the way :) Cheers, Anonym, I did not expect this to be a controversial change. If you also think that it is controversial, then maybe we should keep it disabled and let the user decide. Cheers, Michael English ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Set coin selection to "privacy" by default in Electrum
S7r, Hello intrigeri, Michael, intrigeri wrote: Hi Michael, Michael English: It also helps to reduce blockchain UTXO (unspent transaction outputs) bloat, This makes me curious. How does this help with that property, exactly? My intuition tells me that by restricting the set of coins that can be spent to one single address, on the contrary, the software has fewer possibilities to optimize towards 1. reusing existing unspent outputs; and thus 2. avoiding to create more. Also: where was this text quoted from? The text was copied from Electrum man page. The privacy coin chooser will not offer 100% anonymity, because that's technically not possible in a system using a public blockchain, but it will obfuscate information about sender's total BTC holdings so it's a plus. Yes, I was relating this to routing the SPV validation through Tor which also obscures the addresses that a particular person owns. Without Tor, the bloom filters that SPV wallets like Electrum use are not very private at all. UTXO's are basically the coins you can spend. The spendable coins are in UTXO's, not in addresses. Addresses are just a smart crypto way to let the world know in advance who has the right to spend a given UTXO. Good explanation. Existing unspent outputs cannot be reused, they are burned and re-crated entirely every time. So you cannot spend part of a UTXO, you spend it all (practice does not recommend re-using addresses - it's true nothing keeps you from receiving the change in the same initial address that you spent from, but you'll have a different UTXO). Yes, when a transaction is created, all of the inputs must be spent in their entirety. Whatever coins do not need to be sent to another person are sent back to a "change address" which is a new address under the control of the spender. If there are still coins left after the destination address(es) and the change address(es), then it is interpreted as a transaction fee for the miners to collect. Routing transaction relay through Tor is only part of the solution. The blockchain is a public ledger that can be analyzed anytime after the initial transaction broadcast. Private coin selection impedes correlation of transaction inputs and outputs that could link back to an identity. Sure. I hope our doc clearly states that it's very hard to use Bitcoin in a privacy-preserving way, for some various value of "privacy". Agreed, but the setting indicated by Michael could be shipped as a default imho. It makes sense in a context like Tails/Tor threat model. Yes, that is exactly my rational. Private coin selection is perfectly suited to the context of Tails. I like to think of it as similar to browser fingerprints in the Tor Browser. Onion routing and private coin selection reduces the "bitcoin fingerprint" left by Tails users. Cheers, Michael English ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Set coin selection to "privacy" by default in Electrum
Hi,
I recommend the following change in the file ~/.electrum/config
{
"coin_chooser": "Privacy",
"proxy": "socks5:localhost:9050"
}
"Attempts to better preserve user privacy. First, if any coin is spent
from a user address, all coins are. Compared to spending from other
addresses to make up an amount, this reduces information leakage about
sender holdings. It also helps to reduce blockchain UTXO (unspent
transaction outputs) bloat, and reduce future privacy loss that would
come from reusing that address' remaining UTXOs. Second, it penalizes
change that is quite different to the sent amount. Third, it penalizes
change that is too big."
Routing transaction relay through Tor is only part of the solution. The
blockchain is a public ledger that can be analyzed anytime after the
initial transaction broadcast. Private coin selection impedes
correlation of transaction inputs and outputs that could link back to an
identity. Tails should set the coin selection to privacy in Electrum by
default to protect Tails users.
Please Cc me with any replies. I am not subscribed to the list.
Cheers,
Michael English
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
[Tails-dev] Browser Bookmarks Persistence Bug
When saving bookmarks to the “Unsorted bookmarks” category, occasionally a bookmark moves from “Unsorted bookmarks” to “Bookmarks menu” when I reboot. I think that this has been a bug in Tails for a long time and I can reproduce the problem on a consistent basis. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails Hardware
Sorry, I just noticed that the link to installing Libreboot on the X200 is incorrect. Here is the correct link: https://libreboot.org/docs/install/x200_external.html . Michael English: > Intrigeri, > > First, we should identify the problem. Tails does not replace all of the > software on one's computer. There is additional storage on the SPI flash > chip which carries the BIOS and ME, and there is the USB stick which has > its own firmware. As shown by LegbaCore, this software outside of Tails > can be easily infected. “Since almost no organizations in the world > provide BIOS patch management, it is almost guaranteed that any given > system has at least one exploitable BIOS vulnerability that has > previously been publicly disclosed. Also, the high amount of code reuse > across UEFI BIOSes means that BIOS infection is automatable and > reliable.” Once the firmware is infected, the malware is more privileged > than all applications and operating systems. Basically, Tails is > completely useless on insecure hardware. > > Your question about the audience is a bit of a leading question. All > Tails users should be the audience. Currently, Tails only has > documentation about warnings of firmware vulnerabilities. However, > readers have no course of action to take against this serious problem. > Anyone who cares about their privacy/security/freedom enough to run > Tails should purchase or configure secure hardware. > > One solution to the vulnerable SPI flash chip that we can document is > Libreboot. Unlike Coreboot, Libreboot is completely open-source without > the Intel FSP and provides easy to understand documentation. There are > two options to get a Libreboot X200. First, one can buy a refurbished > Lenovo ThinkPad X200 from a electronics store like Newegg in the United > States. (I assume that there is a European equivalent.) Then, he or she > can follow the relatively easy-to-understand instructions on the > Libreboot website for installing the BIOS > https://libreboot.org/docs/hcl/x200.html and removing the ME > https://libreboot.org/docs/hcl/gm45_remove_me.html . Second, one can buy > a laptop with Libreboot pre-installed. The Free Software Foundation has > a list of hardware that respects your freedom and currently includes two > companies that sell Libreboot laptops: > https://www.fsf.org/resources/hw/endorsement/respects-your-freedom . I > personally recommend Minifree which is run by the same person who > founded Libreboot. When buying a laptop with Libreboot pre-installed, > one does not have to worry about making a mistake in the installation > process, financially supports Libreboot, and gets a longer warranty in > the case of Minifree which offers a whole two year warranty. I do not > recommend that we specifically promote one company on the Tails website, > but we should link to the Respects Your Freedom page as an option > instead of the manual install. > > Another small note about the X200 is that it has a wireless kill switch > to prevent the leaking of sensitive information over the network without > the user noticing. > > I am unsure what to do about the vulnerable firmware on the USB stick > that runs Tails. As far as I know, there is no open-source USB > drives/firmware. Though, USB drive malware could be almost as damaging > as the BIOS/ME because it can perform MITM attacks between the OS and > flash memory. Here are a couple videos which explain USB stick/SD card > firmware vulnerabilities: https://www.youtube.com/watch?v=nuruzFqMgIw > https://www.youtube.com/watch?v=CPEzLNh5YIo . Please let me know if > there is a solution to vulnerable USB stick firmware and if some USB > sticks more secure than others. > > Cheers, > Michael English > ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails Hardware
Intrigeri, First, we should identify the problem. Tails does not replace all of the software on one's computer. There is additional storage on the SPI flash chip which carries the BIOS and ME, and there is the USB stick which has its own firmware. As shown by LegbaCore, this software outside of Tails can be easily infected. “Since almost no organizations in the world provide BIOS patch management, it is almost guaranteed that any given system has at least one exploitable BIOS vulnerability that has previously been publicly disclosed. Also, the high amount of code reuse across UEFI BIOSes means that BIOS infection is automatable and reliable.” Once the firmware is infected, the malware is more privileged than all applications and operating systems. Basically, Tails is completely useless on insecure hardware. Your question about the audience is a bit of a leading question. All Tails users should be the audience. Currently, Tails only has documentation about warnings of firmware vulnerabilities. However, readers have no course of action to take against this serious problem. Anyone who cares about their privacy/security/freedom enough to run Tails should purchase or configure secure hardware. One solution to the vulnerable SPI flash chip that we can document is Libreboot. Unlike Coreboot, Libreboot is completely open-source without the Intel FSP and provides easy to understand documentation. There are two options to get a Libreboot X200. First, one can buy a refurbished Lenovo ThinkPad X200 from a electronics store like Newegg in the United States. (I assume that there is a European equivalent.) Then, he or she can follow the relatively easy-to-understand instructions on the Libreboot website for installing the BIOS https://libreboot.org/docs/hcl/x200.html and removing the ME https://libreboot.org/docs/hcl/gm45_remove_me.html . Second, one can buy a laptop with Libreboot pre-installed. The Free Software Foundation has a list of hardware that respects your freedom and currently includes two companies that sell Libreboot laptops: https://www.fsf.org/resources/hw/endorsement/respects-your-freedom . I personally recommend Minifree which is run by the same person who founded Libreboot. When buying a laptop with Libreboot pre-installed, one does not have to worry about making a mistake in the installation process, financially supports Libreboot, and gets a longer warranty in the case of Minifree which offers a whole two year warranty. I do not recommend that we specifically promote one company on the Tails website, but we should link to the Respects Your Freedom page as an option instead of the manual install. Another small note about the X200 is that it has a wireless kill switch to prevent the leaking of sensitive information over the network without the user noticing. I am unsure what to do about the vulnerable firmware on the USB stick that runs Tails. As far as I know, there is no open-source USB drives/firmware. Though, USB drive malware could be almost as damaging as the BIOS/ME because it can perform MITM attacks between the OS and flash memory. Here are a couple videos which explain USB stick/SD card firmware vulnerabilities: https://www.youtube.com/watch?v=nuruzFqMgIw https://www.youtube.com/watch?v=CPEzLNh5YIo . Please let me know if there is a solution to vulnerable USB stick firmware and if some USB sticks more secure than others. Cheers, Michael English ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails on compromised hardware
We should add a warning about using different operating systems alongside Tails. Rootkits can be embedded in the SPI flash by a malicious operating system and persist across boots. Tails users should have a dedicated Tails computer possibly with the hard drive removed to limit persistent storage. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Limiting the Amount of Software in Tails
Hello, There are a few software packages installed in Tails from contrib and non-free that concern me. gobi-loader (contrib) Firmware loader for Qualcomm Gobi USB chipsets firmware-libertas (non-free) Binary firmware for Marvell Libertas 8xxx wireless cards firmware-linux-nonfree (non-free) firmware-misc-nonfree (non-free) Binary firmware for various drivers in the Linux kernel Especially the last packages introduce a lot of closed-source software that could compromise Tails. Could someone explain the reasoning for including these software packages? Maybe Tails could add a boot option to disable non-free software? Cheers, Michael English ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails Hardware
intrigeri, Could you explain the backdoors in Intel ME? Would you be interested in me drafting a page for Tails hardware? I have been using Tails and Debian for a while and I could give some recommendations for new users. Cheers, Michael English Michael English: > Tails should have a page on the website dedicated to recommended > computer hardware. For example, Tails should link users to the Computer > vendors that pre-install Debian webpage > https://www.debian.org/distrib/pre-installed for guaranteed > compatibility with Tails. Also, major computer manufacturers are known > to have BIOS level backdoors which renders Tails security useless. > Smaller computer manufacturers on the above list would be less likely to > violate users' security and privacy on a hardware level. > > Cheers, > Michael English > ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] KeePassX Security Update
KeePassX has been updated to version 0.4.4 although it has not been included in Debian yet. https://www.keepassx.org/news/2015/12/551 CVE-2015-8378: Canceling XML export function creates export as “.xml” file When canceling the “Export to > KeePassX XML file” function the cleartext passwords were still exported. In this case the password database was exported as the file “.xml” in the current working directory (often $HOME or the directory of the database). Originally reported as Debian bug #791858 https://bugs.debian.org/791858 Someone should get it included in the Debian repositories so that it can be installed in the next version of Tails. Cheers, Michael English ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] KeePassX Security Update
I just noticed that I made a mistake. KeePassX has been fixed in Debian testing except it has not been fixed in Debian stable. The fix for CVE-2015-8378 is also available as a patch: https://www.keepassx.org/releases/0.4.4/CVE-2015-8378.patch Michael English: > KeePassX has been updated to version 0.4.4 although it has not been > included in Debian yet. https://www.keepassx.org/news/2015/12/551 > > CVE-2015-8378: Canceling XML export function creates export as “.xml” file > > When canceling the “Export to > KeePassX XML file” function the > cleartext passwords were still exported. > > In this case the password database was exported as the file “.xml” in > the current working directory (often $HOME or the directory of the > database). > > Originally reported as Debian bug #791858 > https://bugs.debian.org/791858 > > Someone should get it included in the Debian repositories so that it can > be installed in the next version of Tails. > > Cheers, > Michael English > ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Yes, waiting for block confirmations is an easier way to protect against an out-of-date bitcoin balance than manually connecting to a trusted onion server. I still hold my opinion that the Electrum networking settings are the best way to protect against DoS, but it unnecessarily complicated for little risk. I actually recommended that we document block confirmations in March of this year when we first installed Electrum in Tails: “For my documentation, I already explained the concept of a double-spending attack to you. In the case of the Electrum DoS attack, the double-spend would be a 0 confirmation transaction. The solution is to wait for block confirmations to make sure that you actually have the money. Remember: 'An SPV node cannot be persuaded that a transaction exists in a block when the transaction does not in fact exist. The SPV node establishes the existence of a transaction in a block by requesting a merkle path proof and by validating the proof of work in the chain of blocks.'” If we make the documentation too long, users might not actually read it. Also, Tails purpose is to provide a secure operating system and not to provide a complete security guide. I completely agree with focusing on documentation that is specific to Tails and then linking elsewhere for more information. Otherwise, we would have imbalanced priorities. Cheers, Michael English sajolida: > I worked on an update to the current documentation in branch > doc/9713-electrum-2.5. I tried to combined everybody's input while > sticking to the minimum as per our guidelines. > > I'm sorry I won't reply inline to the different topics raised in this > thread, but here is a summary: > > 1. Give more emphasis on external backup of the seed in addition to > using persistence, as suggested by s7r. > 2. Apply the grammar fixes and phrasings suggested by Michael. > 3. Make the warning about SPV less scary and more useful by focusing on > transaction confirmation. I was quite convinced by the details provided > by s7r but tell me if I misinterpreted something. > 4. Add a tip about mBTC. > > I didn't include s7r's suggestion to explain better what an Electrum > server is, what it can do and what it cannot do. I think this is out of > the scope in the Tails doc, while it clearly fits better in the upstream > doc. I understand that some of your points were specific to Tails, but > still, I think we found a configuration in Tails that doesn't make the > security discussion radically different than outside of Tails (which was > the goal). If we think this discussion about the Tails context is worth > been written somewhere it should be done in our design documentation. > But honestly, I feel very lazy to do this and I'm not sure it's worth it. > > Tell me what you think or if I missed anything. And thanks for your > patience and for doing the research and discussion without me. > ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Electrum is Offline in Tails 1.8 with Persistence Enabled
I found a simple workaround to the problem. I replaced the all of the files in .electrum except for the wallets folder with the files from a Tails session without persistence enabled. You could make this process easier for other users if someone could narrow down exactly what file caused the problem. Cheers, Michael English Michael English: > I tested Electrum in Tails 1.8 without persistence enabled and it > successfully synchronizes with the network. However, when I enable > persistence that I setup with the previous version of Electrum, the > client never synchronizes with the network. I checked the Tor bandwidth > graph and there is no significant network traffic. Can anyone else > replicate this issue? I think that it is a problem with Tails and not > with my own configuration. > > Cheers, > Michael English > ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Electrum is Offline in Tails 1.8 with Persistence Enabled
I tested Electrum in Tails 1.8 without persistence enabled and it successfully synchronizes with the network. However, when I enable persistence that I setup with the previous version of Electrum, the client never synchronizes with the network. I checked the Tor bandwidth graph and there is no significant network traffic. Can anyone else replicate this issue? I think that it is a problem with Tails and not with my own configuration. Cheers, Michael English ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Sajolida, s7r thinks that the SPV documentation that I wrote earlier should not be changed. You had stated at one point that you did not want to document the change of default base unit. Could you state your current opinions based on the conversation so far? Perhaps you could add the small non-controversial changes that I listed at the bottom of my previous email until we can come to a consensus about the other proposals. Cheers, Michael English Michael English: > My main goal with the documentation is informing users of the > vulnerabilities of Electrum in Tails to promote secure practices. > > I don't think that Bitcoin should be installed in Tails in the first > place for the following reasons: > Bitcoin is unstable software/protocol > Tails runs off of memory > We have to trust a remote server > Tor traffic can be manipulated > > Would you log in to your bank over Tor even if it was encrypted with > SSL? Money can't be stolen with Electrum, but the SPV verification can > cause servers to withhold information from their clients leading to an > incorrect balance. > > Until we can get the prefnet=tor option, I would like to recommend that > the user manually selects a trusted onion server in place of the SPV > documentation to protect against an out-of-date bitcoin balance. Then, > the user would have a strongly encrypted connection exchanging accurate > information about the bitcoin network. > > Also, we should include the change of default base unit and link to > https://en.bitcoin.it/wiki/Units . > > I have a few small grammar edits and clarifications to the first few > lines of the existing documentation: > Remove comma after passphrase, put a comma after seed, and change so to > lowercase. > Also, change the period after blockchain to a comma and change the so to > lowercase again. > Add “for extra security” after “offline working session.” > > If you disagree, please tell me what specific information should be > written instead. > > Cheers, > Michael English > ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
s7r, Please see my replies that follow. >> The main debate is over the DoS documentation. This is a good >> summary by anonym of a worst case scenario: “Thanks to SPV, the >> server can spoof the wallet balance. Hence the server operator can >> scam Tails users, e.g. s/he can buy stuff from a Tails user, and >> then bump their balance with that exact amount so it looks like >> they've received payment.” >> > > I don't exactly understand what you mean when you say DoS and not sure > what would you like to include in the documentation. Obviously an user > shouldn't trust an unconfirmed transaction, but this recommendation > usually goes for full wallets as well not only SPV. This is already > written everywhere and that's why Electrum shows the unconfirmed > balance separately. Full wallets do not suffer from the same vulnerabilities of SPV. I am used to using Bitcoin in the most decentralized way, so, when I see an SPV client using centralized servers run by strangers, I become nervous especially when it is over Tor. That is a bad combination shown in the example of “Bitcoin over Tor is not a good idea.” Security is not black and white. There is a probability of risk that is assessed based on the environment that the software is in. Perhaps I am too paranoid and you are too confident. I hope that we can find a middle ground. > >> I strongly disagree. DoS should be mentioned as it has a >> possibility (although unlikely) to have a devastating effect on >> Tails users. > > How exactly? Can you explain me detailed where you think the DoS risk > is? Again, the linked research paper has nothing to do with Electrum. > The fact that an electrum server runs on top of bitcoin core which is > mentioned in that research paper cannot be taken into consideration > (how do we even know if the bitcoin core running on the electrum > server we are connected to uses Tor for its peer to peer connections > with other nodes). > > The problem here is that I don't know how you define DoS in this > context. From my point of view an Electrum Server lying about an > unconfirmed balance until first block is mined cannot be called DoS. > (Also, in this case, the server has to OWN the coins apparently spent > and target a certain user which is behind Tor (so anonymous) which is > highly unlikely.). The first mined block could never reach the client essentially putting the user offline. Yes, it is unlikely, but this is Tails where we take security seriously. >>> - An Electrum server could not broadcast an outgoing transaction >>> (payment) sent by you; >> I'm not sure what you mean by this. > > When you send a transaction from Electrum, it's sent do the Electrum > server to which you are connected. The server automatically feeds it > to bitcoin core via cli command which broadcasts it to the peers (and > into the network). The Electrum server could skip this step and drop > your transaction, never send it to the network. Wouldn't this be proof of DoS? ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
My main goal with the documentation is informing users of the vulnerabilities of Electrum in Tails to promote secure practices. I don't think that Bitcoin should be installed in Tails in the first place for the following reasons: Bitcoin is unstable software/protocol Tails runs off of memory We have to trust a remote server Tor traffic can be manipulated Would you log in to your bank over Tor even if it was encrypted with SSL? Money can't be stolen with Electrum, but the SPV verification can cause servers to withhold information from their clients leading to an incorrect balance. Until we can get the prefnet=tor option, I would like to recommend that the user manually selects a trusted onion server in place of the SPV documentation to protect against an out-of-date bitcoin balance. Then, the user would have a strongly encrypted connection exchanging accurate information about the bitcoin network. Also, we should include the change of default base unit and link to https://en.bitcoin.it/wiki/Units . I have a few small grammar edits and clarifications to the first few lines of the existing documentation: Remove comma after passphrase, put a comma after seed, and change so to lowercase. Also, change the period after blockchain to a comma and change the so to lowercase again. Add “for extra security” after “offline working session.” If you disagree, please tell me what specific information should be written instead. Cheers, Michael English ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
You have thoroughly criticized my documentation to help users secure Electrum in Tails. I ask you again what would you change in the current documentation where it warns about SPV. Would you remove it entirely, replace it, or add something on to the end? What specific wording would you use? s7r: > > On 12/5/2015 6:30 PM, Michael English wrote: >> My main goal with the documentation is informing users of the >> vulnerabilities of Electrum in Tails to promote secure practices. > >> I don't think that Bitcoin should be installed in Tails in the >> first place for the following reasons: Bitcoin is unstable >> software/protocol Tails runs off of memory We have to trust a >> remote server Tor traffic can be manipulated > >> Would you log in to your bank over Tor even if it was encrypted >> with SSL? Money can't be stolen with Electrum, but the SPV >> verification can cause servers to withhold information from their >> clients leading to an incorrect balance. > > Yes, I would log in to my bank over Tor if it's encrypted with SSL. I > login into my email accounts and service provider accounts using SSL > and sometimes where possible two factor authentication. > > If you don't want to include Bitcoin in Tails, that's ok, I am not > qualified to decide this, but your arguments are not convincing at all. > > 1. Bitcoin is not unstable, in fact it is quite solid. Every change / > improvement was applied with the highest ethical and security > standards and was carried out with no unwanted events. From my point > of view it is only as unstable as any "under constant development and > improvement" software/protocol. Somethings get fixed, somethings get > improved, etc. Just like Tor - that's not unstable, right? It's the > core of Tails and most important part in it. > > 2. You do not have to trust _a_ remote server. More the proof of work > in the bitcoin network, which is how bitcoin works anyway. So far it > has done a fine job securing about 4 billion USD of market > capitalization (estimated). > > 3. Tor traffic can be manipulated - this requires more context as I am > not sure what you mean, but it sounds like it affects Tails entirely, > not just Bitcoin. The "Bitcoin over Tor is not a good idea" document > is proven not to be 100% accurate and also it's related to the p2p > design and the peer-banning mechanism used by full nodes running > Bitcoin Core. Unrelated to Electrum. There's no sense going through > the arguments again. > > The second part is correct, a server can in theory withhold > information from the client/user, it is just a limitation of the SPV > protocol. But Electrum checks the headers with other servers also, > users doesn't just blindly trust the server he is connected to. > > So for such an attack to work, the attacker would have to: > > a) make sure the user (victim) connects to his malicious server; > b) isolate the user from all the other non-malicious electrum servers. > This is kind of hard to do, because Electrum will not proceed in this > case. Servers are p2p advertised, and some trusted ones (run by wallet > developers) are hardcoded, which means one cannot Sybil, an user will > always get at least 1 honest server to connect to and verify the block > headers. It will detect this and disconnect from that server, or not > proceed at all if it cannot verify this for itself with other servers. > > So the attacker is left with: > c) make sure the user (victim) connects to his malicious server and > make sure the other servers randomly selected by that user for header > verification are also his and lie along with the master malicious server. > > I do take security _very_ seriously, but you have to admit that the > scenario above is *very* hard to pull off and *very* expensive. > >> Until we can get the prefnet=tor option, I would like to recommend >> that the user manually selects a trusted onion server in place of >> the SPV documentation to protect against an out-of-date bitcoin >> balance. Then, the user would have a strongly encrypted connection >> exchanging accurate information about the bitcoin network. > > prefnet=tor will take some time, a lot of things need to be changed > for that. We have to leave it aside for the time being. > > How would an user get a trusted onion server? He will select based on > what criteria? Who decides which servers are trusted or not? There's > no better mechanism here rather than connecting to other servers as > well and verifying yourself - this is already done by Electrum with no > user action required. > > Why do you think a .onion server is better than a clearnet server? Why > doesn't the user select a truste
[Tails-dev] Prioritize onion servers in Electrum
s7r, Since we will probably have to wait for at least one more release of Electrum to include the synchronization fix, do you think that you could also include the option prefnet=tor to prioritize onion servers over normal servers? Using the native protocol for Tor would help make Electrum in Tails more resistant against attack. I am waiting on writing documentation until we make progress on these two problems with the Electrum client. Then, I will reply to your recent email with my proposal for the Electrum Tails documentation. Cheers, Michael English ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Sajolida: “If I understand correctly, the main issue here is about the *change* (and not about the behavior itself), then this should be mentioned most of all in the release notes. If you think that the behavior itself might be confusing, then I guess that this should be solved upstream (in their documentation or the software directly).” S7r and I disagree. Simply noting the change of default base unit could have a big impact in avoiding confusion. “If they have to perform a specific action, then this should be documented. If they don't have to perform a specific action, then maybe we need to adapt the current warning about 'Do not blindly trust the bitcoin balance'.” Yes, they do have to perform a specific action to select the onion Electrum server at the moment. s7r: The mistake that you are making is being too specific with your documentation proposal. Please see the Tails documentation contributors page: https://tails.boum.org/contribute/how/documentation/ . I also proposed specific documentation like yours here: https://mailman.boum.org/pipermail/tails-dev/2015-March/008302.html and found out that it belonged in the Electrum wiki instead of Tails. The main debate is over the DoS documentation. This is a good summary by anonym of a worst case scenario: “Thanks to SPV, the server can spoof the wallet balance. Hence the server operator can scam Tails users, e.g. s/he can buy stuff from a Tails user, and then bump their balance with that exact amount so it looks like they've received payment.” The DoS problem is difficult to solve. The best solution would be for Tails to sponsor its own onion Electrum server. Please see my inline replies that follow. > Hello Sajolida, Michael, > > See inline. > > On 11/22/2015 2:00 PM, sajolida wrote: >> Michael English: >>> Sajolida, please forward this message to s7r. > >> Done. > > > Thanks! > >>> s7r, >>> >>> If you do not have any specific ideas for updating the Electrum >>> documentation, I volunteer to take the lead. Otherwise, you can >>> draft an updated version of the documentation and I can update >>> where necessary. The goal is to document Electrum specifically >>> for Tails and not duplicate the existing Electrum wiki. > >> Thanks for the offer. > >>> Most of the updates like wallet format happen automatically in >>> the background, so they do not need to be documented. I only >>> recommend making two additions. >>> >>> The most obvious change to the user when updating Electrum >>> versions is that the default base unit changes which can be >>> confusing. No, I do not think that we should manually change the >>> default base unit with a config file. That decision should be >>> made upstream. However, users should be aware that the appearance >>> of their Bitcoin balances changes especially when sending >>> Bitcoins. > > > Right, the current page is pretty good: > https://tails.boum.org/doc/anonymous_internet/electrum/index.en.html > > I will include few more additions, especially to highlight how > important the seed is and that is also important to have it backed up > even in case you use a persistent Tails install (since that particular > install can break or etc.). You should link to existing documentation if it is general knowledge that is not specific to the Tails configuration. > > mBTC as default unit should of course be explained. I also want to > include some answered questions about what an Electrum server is, what > it can do and what it cannot do. Documenting what an Electrum server is is completely off topic for the Tails documentation. > >>> DoS refers to the SPV vulnerability of servers withholding >>> information from their clients leading to an incorrect balance. >>> Connecting to a trusted .onion server protects against DoS. Yes, >>> it is not a bug, but it is a well-known limitation of SPV that is >>> specifically relevant for Tor users. Pleas read “Bitcoin over Tor >>> is not a good idea” http://arxiv.org/pdf/1410.6079.pdf . > > > This is unrelated to electrum. It applies to Bitcoin Core (the > software implementing bitcoin protocol - full nodes). Bitcoin core has > a peer-ban-score, where the ban score of a peer (remote server that > you are connected to) increases if that peers feeds you trash data or > tries to DoS you. > > The attack described in that paper takes advantage of the scarce exit > power in the Tor network (~1000 IP addresses) and speaks from the > point of view where an attacker runs few Tor exit nodes that allow > bitcoin exit traffic, and then uses the other exits to feed enormous > amount of trash data to the bitcoin network, hoping the maj
[Tails-dev] Option to disable mouse clicks with touchpad in Tails Greeter
My biggest complaint with Tails right now is that mouse clicks with touchpad are enabled by default and there is no easy way to turn it off before starting the OS. In Debian, mouse clicks with touchpad are disabled by default which I think is the better option to avoid accidental mouse clicks. Especially for a secure environment, accidentally clicking on something can have severe consequences. For example, my touchpad on my laptop is very sensitive and I have accidentally clicked into the wrong field when entering a password. Tails Greeter should at least have an option to disable mouse clicks with touchpad before logging in. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Sajolida, please forward this message to s7r. s7r, If you do not have any specific ideas for updating the Electrum documentation, I volunteer to take the lead. Otherwise, you can draft an updated version of the documentation and I can update where necessary. The goal is to document Electrum specifically for Tails and not duplicate the existing Electrum wiki. Most of the updates like wallet format happen automatically in the background, so they do not need to be documented. I only recommend making two additions. The most obvious change to the user when updating Electrum versions is that the default base unit changes which can be confusing. No, I do not think that we should manually change the default base unit with a config file. That decision should be made upstream. However, users should be aware that the appearance of their Bitcoin balances changes especially when sending Bitcoins. DoS refers to the SPV vulnerability of servers withholding information from their clients leading to an incorrect balance. Connecting to a trusted .onion server protects against DoS. Yes, it is not a bug, but it is a well-known limitation of SPV that is specifically relevant for Tor users. Pleas read “Bitcoin over Tor is not a good idea” http://arxiv.org/pdf/1410.6079.pdf . Cheers, Michael English sajolida: > Michael English: >> Please see https://labs.riseup.net/code/issues/9713 for context. >> >> Recommend users to manually select a trusted .onion server to protect >> against DoS after note about SPV vulnerability. >> >> Make a note that Electrum uses mBTC as the default base unit. 1 mBTC = >> 0.001 BTC. It can be changed in preferences. > > Thanks for the input. I'd like to see whoever is working on the update > to 2.5.4 propose patches to the current documentation [1]. Then I don't > mind editing and polishing it but I won't have time to do the > investigation part myself. So thanks for starting it. > > - How would people "manually select a trusted .onion server"? > - Where can people find "a trusted .onion server"? > - How should our current warning about SPV be adapted? > > [1]: > https://git-tails.immerda.ch/tails/tree/wiki/src/doc/anonymous_internet/electrum.mdwn > ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Upgrade Tails Bitcoin donation address
Electrum version 2.0 and higher supports the creation of multi-signature wallet types. I recommend that Tails upgrade their Bitcoin donation address to a multi-signature address for increased security and redundancy. A multi-signature address requires m of n signatures from separate wallets in order to spend the corresponding Bitcoins. A partially signed transaction is created and sent to one of the cosigners for completion. You can setup a 2 of 3 multi-signature wallet to protect against one of the cosigners' wallets being lost or destroyed. In order to set it up, you need the master public keys of the cosigners' wallets. The cosigners are usually other leaders of the project or it can be an offline wallet. The resulting multi-signature addresses begin with a 3 instead of a 1. Please read the Electrum documentation on multisig at http://docs.electrum.org/en/latest/multisig.html . If you have any further questions, email me. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Update Electrum documentation for Tails 1.8 upgrade to version 2.5.4
Please see https://labs.riseup.net/code/issues/9713 for context. Recommend users to manually select a trusted .onion server to protect against DoS after note about SPV vulnerability. Make a note that Electrum uses mBTC as the default base unit. 1 mBTC = 0.001 BTC. It can be changed in preferences. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
