Armory on Tails 1.7 Help! ;)

[Jubbe]

Hey guys!

I'm trying to get Armory to install on Tails 1.7 booted from flashdrive.
I tried using the offline bundle ubuntu 12.04, but it does not seem to be compatible.

Doing some good old google-searching, it seems most people are using offline bundle ubuntu 10.04 for Tails, but those were old posts (usually pre 2013).

So, yeah, my question is, what is the best way to get Armory running on Tails 1.7 booted from a flashdrive?

Thanks alot for any answers

All the best,

Jens

[1714873002]

1714873002

[1714873002]

1714873002

[1714873002]

1714873002

[1714873002]

1714873002

[BitcoinNewsMagazine]

Armory needs Bitcoin Core to run. TAILS 1.7 comes with Electrum wallet which is your only option I believe.

[Jubbe]

Thanks alot for your anwser, most appreciated!

Ah, I see, so Electrum is already included in Tails 1.7?

I have seen some people use offline Armory on Tails, so somehow they get it to work

Actually what I'm after is the watch-only, and the signing transactions offline feutures of Armory so that I can manage my bitcoins whilst maintaining them on cold storage.

This is because I'm concerned about how to trade with and manage my funds from my colds storage wallet in a safe way avoiding internet as much as I can
Do you know if Electrum has similar feutures as mentioned above?
Or else, how should I safely take money off of my coldstorage account?

[goatpig]

The offline packages are for Ubuntu, some of the .deb in there won't install on Tails (which is based on Debian Wheezy).

I'm not sure what you are trying to achieve. If you are using this machine as an offline signer, you will need to build up the list of necessary packages to install Armory. If you start with one of the Ubuntu packages, you will most likely run into dependency issues with python-twisted, python-openssl and libqt4.

You will want to browse to the offline package folder from the terminal and run:

sudo dpkg -i ./*.deb

You will get a bunch of errors, these will be from packages that are either missing or not suited for Debian Wheezy. Go to Debian's repo (https://www.debian.org/distrib/packages) and search for these packages by name. Download the Wheezy i386 version for each package (I'm fairly sure Tails is x86), unless it says all, in which case get that. Copy the downloaded packages into the offline bundle folder, and run that one command again.

On top of my head, the packages you will be missing are:

libqt4-designer
libqt4-help
libqt4-scripttools
libqt4-test
python-crypto
python-openssl
python-twisted-bin
python-twisted-core
python-twisted-names
python-twisted-web

and whatever else I forgot about.

Once you finally get the message that Armory has been installed (kinda hard to miss), you should be able to run it just by typing armory in the terminal.

------------------------

If you are using Tails for online Armory, follow these instructions:

https://bitcoinarmory.com/building-from-source/

You'll have to build Core from source too most likely.

[Jubbe]

The offline packages are for Ubuntu, some of the .deb in there won't install on Tails (which is based on Debian Wheezy).

I'm not sure what you are trying to achieve. If you are using this machine as an offline signer, you will need to build up the list of necessary packages to install Armory. If you start with one of the Ubuntu packages, you will most likely run into dependency issues with python-twisted, python-openssl and libqt4.

You will want to browse to the offline package folder from the terminal and run:

sudo dpkg -i ./*.deb

You will get a bunch of errors, these will be from packages that are either missing or not suited for Debian Wheezy. Go to Debian's repo (https://www.debian.org/distrib/packages) and search for these packages by name. Download the Wheezy i386 version for each package (I'm fairly sure Tails is x86), unless it says all, in which case get that. Copy the downloaded packages into the offline bundle folder, and run that one command again.

On top of my head, the packages you will be missing are:

libqt4-designer
libqt4-help
libqt4-scripttools
libqt4-test
python-crypto
python-openssl
python-twisted-bin
python-twisted-core
python-twisted-names
python-twisted-web

and whatever else I forgot about.

Once you finally get the message that Armory has been installed (kinda hard to miss), you should be able to run it just by typing armory in the terminal.

------------------------

If you are using Tails for online Armory, follow these instructions:

https://bitcoinarmory.com/building-from-source/

You'll have to build Core from source too most likely.

Ah, thank you so very much! Just the information I needed!
I will try it out!

I want to create an offline cold storage but I have only one machine hence I am using Tails to create a safespace to set up my coldstorage. I also want to use it as offline signer as you mentioned.

I just found out that Tails has Electrum already installed on it.
What would be your opinion on using that instead to set up my cold storage and use as offline signer?
I would assume it's not as safe as it is an SPV client and Armory specialices in safety?
Im pretty new to all this stuff, so sorry if my questions are a bit obvious or basic, but I'm learning.

Thanks again so very much for your answer!

[goatpig]

You lose privacy with SPV/lite clients. Armory has a harder and longer than average setup but won't jeopardize your privacy in return. That choice is for you to make.

Regarding security, as long as the wallet software doesn't do anything ridiculous, the security of your coins depends on the security of your stack + backups. In other words, the main factor is you and how well you understand the mechanics of cold storage.

I can't tell you much of anything about Electrum's security, I don't use it. I'm in no position to evaluate that part of the software.

[Jubbe]

You lose privacy with SPV/lite clients. Armory has a harder and longer than average setup but won't jeopardize your privacy in return. That choice is for you to make.

Regarding security, as long as the wallet software doesn't do anything ridiculous, the security of your coins depends on the security of your stack + backups. In other words, the main factor is you and how well you understand the mechanics of cold storage.

I can't tell you much of anything about Electrum's security, I don't use it. I'm in no position to evaluate that part of the software.

Okey, thanks very much again for the answer.

Electrum is included on Tails OS though. Wouldn't Tails compansate sufficiently for the loss of privacy in Electrum?

[goatpig]

Electrum is included on Tails OS though. Wouldn't Tails compansate sufficiently for the loss of privacy in Electrum?

You will still be uploading your wallet's addresses to Electrum to fetch your history. As for the IP, if the Electrum server is a hidden service, you'll be fine. If it's on the clearnet, you'll be using an exit relay which may or may not reveal your IP.

[Rampion]

Electrum is included on Tails OS though. Wouldn't Tails compansate sufficiently for the loss of privacy in Electrum?

You will still be uploading your wallet's addresses to Electrum to fetch your history. As for the IP, if the Electrum server is a hidden service, you'll be fine. If it's on the clearnet, you'll be using an exit relay which may or may not reveal your IP.

Why? The exit relay doesn't know your IP, the only one knowing your IP is the entry guard and the traffic going through the entry guard is encrypted and routed through a second intermediate relay before reaching the exit relay.

[goatpig]

I've read several times that the weakest point in Tor is the exit relay since it is essentially positioned as a MITM. I'm no network security specialist but it seems rather benign for an adversarial exit relay to inject data into a non encrypted clearnet packet to try and reveal meta data about the requesting party, or monitor said packet size.

[Rampion]

I've read several times that the weakest point in Tor is the exit relay since it is essentially positioned as a MITM. I'm no network security specialist but it seems rather benign for an adversarial exit relay to inject data into a non encrypted clearnet packet to try and reveal meta data about the requesting party, or monitor said packet size.

I think you misunderstood that attack. A successful attack vector, now fixed, allowed malicious entry guards (not exit relays) to inject packets in the encrypted traffic, and that allowed the attackers to track the traffic through the whole circuit (entry guard -> relay -> exit node) and in that way they danonymized the users.

What an exit node could do is a MITM, but nevertheless they are not able to deanonymize users just by MITM them. Imagine I cannect to bitcointalk.org through Tor, the exit relay could MITM me to grab my bitcointalk credentials (but still I would get a warning regarding a bad SSL certificate which I should dismiss for the MITM to work), but they wouldn't be able to know my clearnet IP unless they controlled the whole circuit or did some very complicate traffic correlations attacks that only a gov. agency is able to do.

[goatpig]

I actually didn't know about the entry guard attack.

My point is that not all clearnet traffic is encrypted:

to inject data into a non encrypted clearnet packet

Rather simple to setup this broad, undiscriminated attack on the Tor network, the kind de-anonymising parties would resort to I expect.

did some very complicate traffic correlations attacks that only a gov. agency is able to do

If it's a credible attack vector, it should be accounted for, regardless of the resources implied. This is why I consider Tor to clearnet traffic to be unsafe.

Same goes with SSL, for obvious reasons. There are 300+ CAs out there, and it only takes compromising one.

[Rampion]

I actually didn't know about the entry guard attack.

My point is that not all clearnet traffic is encrypted:

to inject data into a non encrypted clearnet packet

Rather simple to setup this broad, undiscriminated attack on the Tor network, the kind de-anonymising parties would resort to I expect.

did some very complicate traffic correlations attacks that only a gov. agency is able to do

If it's a credible attack vector, it should be accounted for, regardless of the resources implied. This is why I consider Tor to clearnet traffic to be unsafe.

Same goes with SSL, for obvious reasons. There are 300+ CAs out there, and it only takes compromising one.

Of course not all clearnet traffic is encrypted but only in the last hop, when it goes from the exit node to the clearnet site (exit node -> clearnet site). During the rest of the circuit (user -> entry guard -> relay -> exit node) the traffic is always encrypted when you use Tor. Therefore, a malicious exit node could sniff the traffic, or even perform a MITM attack to break a SSL connection, but nevertheless such a malicious exit node would just be seeing the traffic, not the clearnet IP of the user.

Summing up, unless in the traffic itself there is some deanonymizing information (for example because you are logging in an email account with emails wrote by or to your "real life" persona, or because you are logging to a social media account linked with your real identity) there is no way for a malicious exit node to deanonymize you just by sniffing the traffic because they cannot know the clearnet IP of the source, they only know the IP address of the destination.

[goatpig]

1) Governments have an easy time side stepping SSL (subpoena the CA)

2)

for example because you are logging in an email account with emails wrote by or to your "real life" persona, or because you are logging to a social media account linked with your real identity

That's a very optimistic perspective. The only thing a government needs is some meta data that links whatever account you are using with the massive aggregated data it already has on you. This stands out in particular with Bitcoin where there is a high chance you have an AML verified account at some exchange (or traded coins with someone that does) and a thread of transaction links part of your addresses together.

3) You have yet to demonstrate that Tor is resilient to MITM injections. Matter of fact, it isn't. Tails implements good practices that go a long way in reducing that attack surface, but it isn't something you can just dismiss like you seem to imply.