The problem with a local wallet is: No matter how well you protect it, be it 2FA or a DNA sample of the owner: Once you do a transaction, you have to unlock it, and that's exactly the moment the malware steals your coins.Well, we could go on and have individual 2FA keys for every address. Then you can only lose that address you just unlocked. Technically, this would be possible. But then, instead of having a second device for the 2FA, why not have a watching only wallet on your computer and the whole wallet on your second device, to begin with?

Hmm fair enough, right now I have it enabled on top of my keepass database. If anything it provides some protection against key loggers as if my password is logged the hacker then only logs the OTP password I use on my database to open it which would do him no good.

No matter how you look at it, Armory (and the decentralized Bitcoin concept) is that your computer holds the private keys. No matter what kind of toppings you put on it, at some point your system decrypts the private key and uses it to sign a transaction. Therefore, you can require as many devices as you want, in any complicated scheme you want, but unless there's a server somewhere holding they key, etc, it's not going to help. Your computer still holds all the data needed to decrypt the single key needed to move the funds. (this is also why removable-media DRM keeps failing -- at some point, your computer or DVD drive has to decrypt the data and send the unencrypted results to the TV/monitor -- that process cannot only be intercepted, but also run in a VM and analyzed to excrutiating detail to reverse engineer the algorithms)

However, when I finally implement multi-sig, you will have actual 2FA -- the network acts as the "server" which requires two signatures from two different keys to move the coins. And those keys can be be created completely separately, no located on the same device, thus requiring multiple devices to be compromised to get the signatures needed.

Until then, there really are no multi-factor solutions for a decentralized, run-locally app like Armory.

Ente, that's why we invented this thing called a trusted platform module which lets us do crypto operations in a boxed, temper resistant environment.

Oh wow, here comes the next, even more polarizing topic! :-)Nah, I'm no friend of TPMs in their current state. Or, maybe, I lost track of the actual current state. Did "roll your own CA into your TPM" ever materialize?In fact, by now with the latest revelations I trust software much more than hardware. Be it a TPM or a PRNG. And even with software I am careful, I only use stuff Schneier was involved with for years now.

I'm running Armory 0.89.99-5-beta (7cd98b1a282438fc060ecc84305e20f5b0970142 on the "testing" branch) and the "Spendable/Maximum Funds" number doesn't include the coins in my offline wallet. It only counts the coins in my online "pocket change" wallet. If I double click the offline/watching-only wallet, I can see the correct amount for "Spendable/Maximum Funds", but they are not included in the main window.

is it safe now to use that stick for other stuff, plug into internet connected machines, because it is encrypted right?

This is not some pseudoeconomic post-modern Libertarian cult, it's an un-led, crowd-sourced mega startup organized around mutual self-interest where problems, whether of the theoretical or purely practical variety, are treated as temporary and, ultimately, solvable.Censorship of e-gold was easy. Censorship of Bitcoin will be… entertaining.

is it safe now to use that stick for other stuff, plug into internet connected machines, because it is encrypted right?

I wouldn't, it's not worth the risk. Just spend a few bucks and get a dedicated USB key for your wallet. There's no point in making a wallet on an offline machine and then sticking it into your online machine.

ok, but it is encrypted right? as long as I never enter my password on a possibly keylogged box nobody can use it

This is not some pseudoeconomic post-modern Libertarian cult, it's an un-led, crowd-sourced mega startup organized around mutual self-interest where problems, whether of the theoretical or purely practical variety, are treated as temporary and, ultimately, solvable.Censorship of e-gold was easy. Censorship of Bitcoin will be… entertaining.

ok, but it is encrypted right? as long as I never enter my password on a possibly keylogged box nobody can use it

That's like putting on your new bullet-proof vest then walking upright into an open field in a warzone. You risk getting shot, and if you do you might survive, but if your vest (password) isn't high quality or the person happens to be using something like an anti-tank weapon (a lot of computing power to break your password), you might get screwed despite your nifty vest. Why even risk it?

This is not some pseudoeconomic post-modern Libertarian cult, it's an un-led, crowd-sourced mega startup organized around mutual self-interest where problems, whether of the theoretical or purely practical variety, are treated as temporary and, ultimately, solvable.Censorship of e-gold was easy. Censorship of Bitcoin will be… entertaining.

Nah, I don't know, guys.. The point of an offline wallet is that the privkeys nor the wallet password is never present on the online computer.Sure, you can encrypt the wallet once again with truecrypt, ssl or rar. But then, would you send someone to the battlefield with two bullet-proof vests?Should he use two different passwords? So he has a greater risk of mixing them up or forgetting one? Or shall he use the same password twice, so the "outer" encryption is the only one needed to break?

So, the internal wallet-encryption is either secure enough, or it is not. And with the encryption set to need lots of ram (against GPU-bruteforcing), and knowing Alans level of quality-of-work, I lean out of the window to say that shall be enough.BUT, don't forget you add other risks by having a plain (encrypted) wallet visible: People see it's a wallet (filename and contents), and they even see the public keys. This might, in a worst case scenario, lead to attacks (computational or physical) which wouldn't happen if the wallet was encrypted in "diary.rar".

If you're going to go through all the trouble of setting up an offline computer it's just silly to put your wallet into an online computer.

Exactly. For the money you use often you should already have an encrypted "hot" wallet in an online computer - the question is: how much are you willing to risk online? Is like having an X amount of cash in your pockets while you take a walk at night - how dangerous or safe is that walk (or how dangerous or safe is your neighborhood) depends on how security conscious you are with your computer, but the risk by being online, bigger or smaller, ALWAYS exists.

The only purpose of an offline wallet is precisely to reduce to the minimum the risk of having your cash in your pocket while you take a walk, if you bring that wallet online you are just defeating its primary purpose.

Nah, I don't know, guys.. The point of an offline wallet is that the privkeys nor the wallet password is never present on the online computer.Sure, you can encrypt the wallet once again with truecrypt, ssl or rar. But then, would you send someone to the battlefield with two bullet-proof vests?Should he use two different passwords? So he has a greater risk of mixing them up or forgetting one? Or shall he use the same password twice, so the "outer" encryption is the only one needed to break?

So, the internal wallet-encryption is either secure enough, or it is not. And with the encryption set to need lots of ram (against GPU-bruteforcing), and knowing Alans level of quality-of-work, I lean out of the window to say that shall be enough.BUT, don't forget you add other risks by having a plain (encrypted) wallet visible: People see it's a wallet (filename and contents), and they even see the public keys. This might, in a worst case scenario, lead to attacks (computational or physical) which wouldn't happen if the wallet was encrypted in "diary.rar".

I have a general wallet question, which is partly about BIP32, and partly how Armory will implement it.

1) As I understand it, a seed creates a tree, where each branch itself may form a new branch or whole tree, so to speak. With that, will Armory allow to create multiple "wallets" from one single seed?Right now I use several wallets, for bookkeeping and not mixing up inputs/outputs of different categories. So it would be important that change addresses and inputs only mix within one "wallet" or "wallettree" or whatever it would be called.

With security in mind:2) From knowing the "public key seed" (or similar) and one single private key, all private keys may be reconstructed. I guess from the "public key seed" and one public address all public addresses may be reconstructed as well then.Is there anything I have to take care of in reality? As long as I only use regular Armory functions (sending and receiving) and don't export stuff and don't share my wallet file, nothing evil should happen? Is there anything to extract from the wallet file without knowing the encryption password?3) I.e., is the "public key seed" encrypted too?

And, finally:4) In case I can haz several "wallets" in one file, from one seed: Can I have several, different passwords for each "wallet"?

To make sense of all this:Imagine I now have three wallets. One is my unencrypted playmoney, one is my regular funds, one is my long-term savings (with watch-only wallet), one is funds I manage for mom and grandpa. I don't want to lose all of those in case a keylogger steals my one password. I don't want my long-term savings on my online computer altogether.Will I be able to have all this from one seed, with the new wallet format?

This would be a huge selling point for me, and differentiate Armory even more as a pro wallet, focusing on security and advanced features.

Ente

Ente

Not to be a d$%k but you said "So, the internal wallet-encryption is either secure enough, or it is not." That really does not make sense to me. A lot of people like to say your data is "secure" but really it's only secure because no one has found a way around it YET. Then one day we hear on the news that all our credit card numbers are stolen. At that point it went from "secure enough" to "not." And it changed in a flash.I would not want to be the mark of someone far smarter and depraved than me when they obsolete the word secure for my thumb drive.

Not to be a d$%k but you said "So, the internal wallet-encryption is either secure enough, or it is not." That really does not make sense to me. A lot of people like to say your data is "secure" but really it's only secure because no one has found a way around it YET. Then one day we hear on the news that all our credit card numbers are stolen. At that point it went from "secure enough" to "not." And it changed in a flash.I would not want to be the mark of someone far smarter and depraved than me when they obsolete the word secure for my thumb drive.

Well, that's two different kinds of "security":

1) is "low level, algorithm security". Like, if the keys in the wallet file are encrypted via AES, ECDSA or similar, with xy bits and z rounds, I consider it secure.

2) is, totally independent, "high level, operation security". No matter how good 1) is, once I use "asdf" as password, or my supersecure password is stolen via keylogger or rubberhose attack, my funds are gone.

You are talking about 2). In the case you mention, most often servers are hacked (which is an entirely different attack vector than the walletstuff) and the data is stolen right out of the ram, or unencrypted active partition, or similar. 1) isn't even active in that case.I talk about 1). I want (and am sure) the parameters and algorithms which encrypt the sensitive parts of the wallet to be sound, and to be resistant against brute-force attacks of a large scale attacker for many years. That's all 1) has to do. And it's most definitely not the solution against other, higher-level attacks.

And, as a note: I have long passphrase(s) or real random passwords for my wallets, have the long-term wallet rar-password-encrypted, and finally all wallets or the rar file in a password manager, encrypted with a long masterpassword. With that, I feel reasonably secure in the means of 1) to spread that file for backup. Against 2), I use different passwords, for example. So when one password and its wallet are cleared out, I wouldn't lose all of my wallets.

..and then let's get 3) in the mix: Backup all of that mess securely, but redeemable in case something happens to me :-)

"the bitcoin software appears to be installed now but needs to be closed for armory to work, close it now?

click ok, click try again

"the bitcoin software does not seem to be installed, change your settings..."

wtaf? you just shut it down...good grief

I go to settings and point it to the bitcoin directory on my D drive, same message

This is not some pseudoeconomic post-modern Libertarian cult, it's an un-led, crowd-sourced mega startup organized around mutual self-interest where problems, whether of the theoretical or purely practical variety, are treated as temporary and, ultimately, solvable.Censorship of e-gold was easy. Censorship of Bitcoin will be… entertaining.

"the bitcoin software appears to be installed now but needs to be closed for armory to work, close it now?

click ok, click try again

"the bitcoin software does not seem to be installed, change your settings..."

wtaf? you just shut it down...good grief

I go to settings and point it to the bitcoin directory on my D drive, same message

It's complicated. And ironic wording... sorry about that.

It's easiest if you just run it yourself, if you don't mind running it yourself. If you do, then go to "File"->"Settings" and uncheck the first checkbox about letting Armory run it for you. Then close Armory, start Bitcoin-Qt/bitcoind, let it synchronize, then start Armory. It should behave a bit better. Apparently detection of Bitcoin-Qt installation is still not as good as it could be...

Is it installed? Did you simply download a zip file and unzip it somewhere? Did you install to a non-standard directory?