You can export all the private keys from the offline computer, and import them in another wallet.  Then you have access to your bitcoins again.

In spite of OP's tone being unacceptable in a public forum, I still think we should not give that bad advice.  blockchain.info is a disaster waiting to happen - no, it is a disaster happening right now in slow motion.  The number of security issues is incredible.

OP:  Armory is a power-user application, but it is a nasty ressource hog.  The Bitcoin block chain has grown faster than their software has improved.  A very good compromise between convenience and security is Electrum, see electrum.com.  It securely stores your private keys on your computer (or even on an offline computer like Armory does), but uses online servers for the blockchain data.

Python is extremely popular in the scientific computing community because it seems to be really good for writing clear, easily maintainable code.  Also, most sysadmin tools in Linux appear to be built using Python these days.  It is a language that has acquired a large use base, and been tested a lot - also the amount of open-source libraries available is pretty impressive.  I cannot speak for the Armory devs, but Python seems like a natural choice (of course there are many others).

Maybe I'm not.  But perhaps I am being inconsistently paranoid, since I am willing to run a precompiled Armory - anything could be sneaked into it, in principle. 
The point is, I can't.  How can I know that the firmware on the device is the same as on github. 

I am aware of the code signing.  But if somebody at Satoshilabs sneaks in such a line, it is pretty impossible to detect.

I agree that this may be unduely paranoid, and presumably, they have QA procedures that makes it impossible to do in practise.
And I am seriously considering buying a Trezor.  It is, in my opinion, a very good idea to offload the signing to specialized hardware. The really paranoid can probably make it part of a 2-of-2 multisig wallet. 

Indeed.  But how do I know for sure that nobody modified the firmware on the trezor.  For example somthing like this:
that will be exceedingly difficult to detect, but the culprit could harvest all Trezor wallets a year later.

Yes, I know, the same could be done in the precompiled binary of a wallet.  At least in Armory, I could generate the keys by shuffling a deck of cards.

But I am probably being unduly paranoid.

Not yet, but I will definitely do so before deciding what to do!  It is, after all, not urgent.

I share your feeling. I suspect that we are wrong, but I feel the same way
Electrum.  It even has offline storage like Armory, but is badly missing n-of-m backups, and probably several other Armory features.

What I would do would be to make a secondary wallet somewhere, e.g. an SPV wallet, an Electrum wallet or something like that.  Bring that wallet with you on your trip (or encrypt it and drop it in dropbox - that is not good security, but odds are that you will never use the wallet).  Make and sign a transaction moving money from Armory to the new wallet, but do not broadcast it.  You can even sign multiple transactions of different sizes, although you may not be able to use more than one of them if they use the same inputs.  Encrypt the transactions, leave them on dropbox.   Write down the first address of the Electrum wallet, and an empty address of your Armory wallet. 

If you need to access your BTC on your trip, download the Electrum wallet.  Check that the bitcoin address is as expected.  Decrypt the selected armory transaction and broadcast it using blockchain.info or another such online tool.  When your money appears in the Electrum wallet, spend the part that needs spending, and return the rest to the Armory address you brought along.

Important:  Before leaving, try this out at least once.  Mistakes can potentially be expensive

Thank you, nerioseole, for another enlightning reply.  You even answered my next question in your edit - I am considering putting a full node in the cloud, and then use that as my own electrum server.   I was under the impression that Electrum could also fall back to SPV mode if there are no servers, but maybe I am mistaken.

I will definitely consider using a Trezor.  I have been a bit reluctant since I am not sure what happens if it breaks and they go out of business, but I presume the private keys can be recovered from the seed without a Trezor.  I also have to convince myself that somebody getting hold of both my laptop (with the watch-only wallet) and the Trezor cannot spend the funds.

Otherwise, I will probably do the SSSS trick with the electrum seed on an offline raspberry pi, and use that as the offline wallet.  I am aware of the theoretical risk of transferring malware between my laptop and the R-Pi over the USB stick (this nasty hardware exploit people are talking about), but that almost seems to require somebody targetting my setup specifically, and I do not believe I have near enough BTC for that to be worth the effort

SSSS in electrum would be nice.  Alan Reiner from Armory always says that one's heirs should be able to recover the funds - that will be a lot easier if all they have to do is to copy the three parts of the key into Electrum

It would be nice to see this version appear on the Armory home page, since it is a very important compatibility fix.

Thanks for your reply, ThomasV. 

I did not know that I could use multisig in that way.  I realise that I am probably talking to one of the main developers, so maybe you can tell me if I understand this correctly:

If I create a 2-of-3 multisig wallet on the offline machine, then I have three chains of private keys that I can back up separately on paper.  The watch-only (online) wallet will then have three chains of public keys.  If I lose the offline machine, I can use two of the paper backups to create an offline wallet that now only contains two of the chains, but that is enough to sign any transaction made by the watch-only wallet.

But if I lose both computers (burglary, house burns, or something like that) then two paper wallets will no longer be enough, since I then only have two of the three chains of public keys, and I need all three public keys to derive the bitcoin address, and thus to be able to generate the transaction that can be signed with only two private keys.  Or do I miss something?

In that case, multisig is not quite as safe to backup a single wallet as Shamir secret sharing.

I guess I should start experimenting with Electrum. 

Thanks!  But that is slightly different, I will end up with needing to sign each transaction on multiple computers.  That is highly useful, but not for me, I just need a single offline wallet on a raspberry pi.  It is only the backup I need to split, with Shamir secret sharing scheme, or something like that.

Yes, that is really a good thing!   

Hi,

Seriously considering migrating from Armory to Electrum, mainly as maintaining two copies of the entire blockchain on my laptop is no longer viable (and because Armory dropped Mac support).  Electrum has a cold storage facility just like Armory.  But does it have an equally secure way of making paper backups?

Armory can make, say, a 3-of-5 backup where I can store the five sheets of paper in five secure locations, and as long as I can get to three of them, I can restore my wallet.  And if Dr. Evil gets two copies, he can do nothing.  Does electrum has a reasonably easy way of doing the same?

Otherwise, I was considering using Armory for the backup: Creating an Armory wallet on the offline machine, make a 3-of-5 backup, use the first private key of the wallet as a seed for Electrum.  Is that doable?  Is it a bad idea for some reason I have overlooked?

I am trying to do just that.  Copied Bitcoin Core's stuff onto a virtual Linux machine on my Mac, and started bitcoin-qt on the virtual machine yesterday evening.  It does not redownload the blockchain, but it does reverify it.  Has been running for 11 hours so far, judging from the rate it crunches blocks according to the log file, it will finish within 12-24 hours

I am not going to move Armory's stuff over to the VM, instead I plan on letting it rescan the blockchain.  It would probably to that anyway, and it did not use to be too slow.  I will report back tomorrow.

It is disappointing that Mac support has been dropped, but considering how badly Qt is supported on Mac, it is not surprising.  Pulling 0.94 is far worse, since that was going to only store one copy of the blockchain (Bitcoin Core's).  Having two blockchain on my laptop is no longer viable, within a few month I need to find an alternative.  Getting rid of one of them would have postponed that for a year or so.

Edit: spelling.

For me, the first two points are a must.  In addition n-of-m PAPER backups (shamir secret sharing or similar) is important.

Bring my own entropy is nice to have, but any system that allows paper backups can be tricked to accept your own entropy.

Even though I regard myself as a power user, and have done this myself, I must say:  It is needlessly complicated.  This setting should be available in the settings panel, where people expect it to be.  Since it is not there, many will think it is not possible.

Of course it becomes more complicated due to the fact that it is another program's data we want to move around.  This may be one of the reasons that it is not on the settings panel

The truly paranoid will tell you what a horrible idea this is.  Personally, I do it that way for my medium-term wallet.  The long-term wallet is on a Raspberry Pi that I rarely turn on.  My short-term wallet on my phone

It is theoretically possible to write a virus that grabs your password from your keyboard, and then use that to decrypt the lvm and steal your wallet (and your wallet password).  But the encrypted lvm is a significant obstacle, the attacker would almost have to attack you personally instead of just spreading a wallet-stealing virus on the net.  I would not worry, unless we are talking about a really large amount of BTC.

Just roll the dice a few more times :-)

An honest die provides log2(6) bits of entropy, that is 2.58 bits.

A pretty biased one, where the odds of getting 6 is twice that of any other number (2/7 versus 1/7 for the five other possibilities) gives you
S = - SUM_i p_i log2 p_i = - ( (2/7) log2(2/7) + (5/7) log2(1/7) = 2.26 bits

Not much less, and that is a pretty biased die.  If you roll your die 100 times, you get 226 bits of entropy; more than enough since the work of breaking the discrete logarithm problem with a 256 bit key is only 128 bits.  But you could just roll it 113 times instead.

TL;DR: Even a biased die is an excellent source of randomness.