Topic: Armory - Discussion Thread - page 172. (Read 521829 times)

No there is not, but fear not, the next major release (with multi-threading) will do away with the splash screen completely!  I'm just finishing butchering the code base to get the multi-threading code implemented.  There will be lots of testing, but hopefully only another week or two before it's done. 

---------

Bugfixes Bugfixes Bugfixes
Version 0.82.4-alpha

Three fixes:  Network fix (already in 0.82.3), URL handling, and some issues with the send & receive buttons on the main window.

Also:  I'm testing signing the installers again with my offline GPG key.  Please test it -- details at the bottom of this post!


http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-alpha_win32_and_win64.msi
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-1_amd64.deb
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.82.4-1_i386.deb

I'm continuing to get reports of strange behaviors in Windows.  Perhaps the Win32 version doesn't actually work as well on Windows 64-bit...?  If you are currently using an old 64-bit version and it does work, then please try this one for me.  I need some empirical evidence to suggest whether this is a good or bad idea!

---

You should be able to verify the following signature with the Armory Signing Key (98832223) (which should also be distributed to the major key servers by now, so you don't have to trust a forum link if you don't want to):

The signed MD5 hashes are below: or download it directly, here

Is there a config option or cmd-line option to "not show splash screen"?

It annoys the hell out of me because it covers my stuff and can neither be moved nor closed (using weird window manager).

I just had to delete my settings after upgrading to the version before this one. Thanks for the update, regardless

Btw, I finally got around to posting a version with windows networking issues fixed:

https://github.com/etotheipi/BitcoinArmory/downloads

It appears to affect a very few number of users.  If you're not having a problem, there's no reason to upgrade to 0.82.3 (though, I might have fixed a bitcoin: URL-handling issue, too... I don't remember if that was fixed in the last version or this one)

Cross posting this here as there may be some interest:

I made a fork/addition to bitaddress.org that allows easy printing of blockchain.info wallet exports.  If this is interesting/useful to you then you can read more here:

https://bitcointalksearch.org/topic/ann-bitaddressorg-printing-of-existing-backups-105066

I'm in total agreement.  I was skeptical of deterministic wallets early on, because I know that they are full of traps waiting to catch the unwary.  But done right, the difference in security is negligible at worst (and with a huge upside 99.9% of the time).  And the negligible security loss is only in the amount of work the attacker has to do after he's already done the impossible.  Seems like a good trade.

However, for my personal deep safe wallet, I still prefer that my keys be unrelated and totally random (well, as random as /dev/random).  Keys generated offline using known code (using something like a live distro that predates bitcoin, heh), encrypted and burned to M*Disc DVDs and printed on archival paper, addresses burned to different DVDs and also printed.  Copies of the encrypted private keys stored in different cities.  Easy to send money to a wallet like that, but very difficult to get money out, which fits my needs very well (but is not practical for most people or most uses).

The sad thing is that for every person that thinks that I went overboard, at least one other person will think that I wasn't careful enough.

The security drawbacks of a deterministic wallet like this are basically insignificant.  A common complaint is that someone could compromise your seed, and then wait for your to make a big deposit and steal it at a later time.  The Satoshi wallet, "unsteals" itself after some time.  I think this argument is bogus:  they still have 100 addresses in your address pool to wait for some juicy coins to come in with your Satoshi wallet, and frequently there's enough there to be worth taking it right away.  There's very few situations where the deterministic wallet compromise is actually non-negligibly worse than a Satoshi-wallet compromise.  You're screwed in both cases.

On the other hand, the security benefits of the deterministic wallets are so dramatic, they far outweight anything else (and hence why the Satoshi client wants to switch to deterministic wallets in a future version).

-- One-time backup -- many more users are going to accidentally delete their wallet or have a failing disk drive, than those who will suffer because the deterministic nature of the wallet enabled a very unique attack on their already-compromised wallet.  Backup your wallet one freakin' time, ever.  Generate milllions of addresses, you're always protected.  This is the biggest fear users have with the Satoshi wallet, and regular, persistent backup solution will fail for the average user... they may keep it up for a whlie, but they swap their backup drive, and forget to set-up their backup system again, or just too lazy.  Nay -- print off your wallet once, put it in a safe-deposit box, and live merrily knowing that you won't lose them.

-- Offline wallets -- you don't need me to tell you the benefits of it.  You already know.  The ability to store the private seed offline and never touch the internet is why the attacker won't get the seed to compromise you. 

Ahh, so it is bytes.  I read your chart wrong.

Hmm, that makes your scheme (very!) slightly less secure against rainbow tables.  Yeah, I know, rainbows for this are totally impractical because you have a good initial a, but a (very!) lucky hit would reveal the rest of the sequence without the bother of having to search for the c that generates the next one.

And just to be clear to people following along at home, the level of "very lucky" that I'm talking about is probably along the lines of an attacker being saved from Death By Meteor when another meteor hits the first one at the last second, knocking it aside.  In practice, it isn't much better than brute force, as long as a is strong.  If some idiot modifies it to accept a weak a from the user, all bets are off.

The first private key and chaincode are each 32 bytes.  Even if the chaincode was smaller, it wouldn't matter much.  The purpose of it is simply to add entropy to the iterative process.  And in Armory, the chaincode is actually calculated from the hash(PubKey) so it changes on every step.  In the end, the chaincode only protect your privacy, not your security... I had recommendations to shorten it considerably for this reason: it doesn't need to be a full 32 bytes to accomplish its purpose.

scrypt seems to be the only safe way to do it, and with terribad parameters so that it takes forever even on a decent box.  Real users won't do it often enough to be put off by it, but attackers have more resources.

Agreed on the brain wallets.

The rainbow attack would be huge, and sneaky.  You are using 32 bits for the chain, so find one collision and 2 billion operations later (on average) you've got the entire rest of the sequence, forever.  I know you care enough to carefully generate high quality a and c values, but a brain wallet using this system starting with a and c derived from user input is a disaster waiting to happen.

ECDSA "multiplication" doesn't exactly resemble the multiple that most folks are familiar with, but it's still associative.  a*G is just "adding" G to itself a times.  Then c*(a*G) is just adding P to itself c times, which was just adding G to itself a times.  So it makes sense (to me) that it's associative, but I've been doing this stuff for a long time...


That's the basis for this thread: https://bitcointalksearch.org/topic/self-descriptive-strengthened-keying-a-standard-for-deriving-keys-from-seeds-102349
The idea is to make the standard clients only accept certain kinds of seeds, thus requiring brainwallet users to add X bits of hard entropy to their [probably crappy] brainwallet seed.  I'm not a fan of brainwallets, but we know that folks insist on it, so we want to try to be responsible about it.




You have a watching-only wallet on your system monitoring your offline coins.  Then through some feat, either through unauthorized access, or exploiting users' ignorance of how Bitcoin works, they import one of their own addresses into your wallet.  You don't know, because you don't pay attention to every address that is in your wallet at all times.  Now they offer to buy something from you for 1000 BTC, send the coins to their own address -- and it shows up in your offline wallet watcher!  Snugly, you believe that the coins have been sent, because there's 3000 confirmations by now.  You send the merchandise, and then they sweep the address.  SCAM!

What I was considering doing was the following:
(1) Create a special kind of watching-only wallet just for this, and it's balance will never be included in your master balance
(2) Allow a user to import a watching-only address if it is signed by one of their offline private keys. 

Part (2) sounds inconvenient, but it actually isn't that bad.  Most people would import their private key to the offline computer, first, anyway.  The program can sign the public key with one of your existing addresses, so that it can be imported to your online computer. 

It's just one of those things where I'm putting security above convenience.  The vast majority of users could do all this responsibly without hand-holding, but while Bitcoin is still immature, it's my integrity on the line when they screw up.  So I want to help them avoid this...

"There's some security issues with being able to import arbitrary public keys for watching-only purposes"

What issues could be presented just by monitoring the balance on a public address in a watch-only wallet?

I also have a brain wallet I'd like to monitor (for which of course I have the ability to recreate the private key) and a coinbase.com wallet (for which I don't have the private key)

I'm having a lot of fun learning about creating transactions and signing messages by using Armory - thank you for all the work!

That's pretty cool.  The EC multiplication routine doesn't look like it should associate and cancel like that.

I guess that means that if Moore's law holds for a bit longer (heh), it will become possible to attempt rainbow tables attacks on schemes like this if they don't start with a good entropy source for a and c.  Brainwallets come to mind.

It's the same process as diffie-hellman key exchange: here's the simplest way to do it:

a:  Private Key (32-byte integer)
P:  Public Key (a point on the secp256k1 curve)
G:  Public "generator" for ECDSA curve (another point on the curver)

A public key is just a "multiple" of the generator of the group:


Note that ECDSA multiplication cannot be reversed.  This is secure.  Let's pick another point, c, which is our chaincode.  I create a new private key:


What is the public key?

So if you have a keypair and a chaincode, you can make the publickey+chaincode the watching-only wallet, and the privatekey+chaincode is the private wallet:


What Armory does has a few more details, but that's it.  Note that this is necessarily secure for the same reason that your private key isn't compromised by your public key:  ECDSA "multiplication" can't be reverse (efficiently)

Heh, I'm no cryptographer either, that's probably my problem.  But I do have an implementation of ECDSA that I'm somewhat familiar with, and it works correctly with bitcoin keys.

I was just going through the code that I use to generate ECDSA keypairs, and the multiplication used to create the public key didn't look like it could possibly be done in that way.  The multiplication depends on every bit in the private key, and you can't back out a step if you want to change one of the private bits.  (My understanding is that if you could do that, it would totally break ECDSA's security.)

Because of that, I had assumed that Armory generated a couple thousand (or whatever) private keys, made public keys for them, and gave you the option to export just the public keys for watching elsewhere.  If it turns out that there is a pair of iterator functions that can create halves of a keypair without the other half present, I've gotta see it.

There is actually a website for merchants (http://acceptbit.com/) that is based on that very idea.
That site is tailored for Electrum, but I think it should be possible in Armory too, as it uses
similar deterministic wallets.

I'm not a cryptographer so perhaps someone else can answer you with more details, but from what I've read around here, the seed is an ECDSA key pair itself. A sort of "master key". So, you use the master private key for the private key series, and the master public key for the public key series. It's a nice feature of ECDSA, apparently.

Question about watching wallets...

Someone is saying that with your deterministic wallet you can create a watching wallet that generates a sequence of public keys that matches the sequence of private keys generated elsewhere.  Is that true?  And if it is, how the heck do you do it?

Generating a list of (pseudo)random numbers to use as private keys is easy enough, and deriving public keys from them is also pretty simple.  But I can't figure out how to write a generator for a sequence of public keys that doesn't involve generating the list of private keys and then deleting them.

Yeah, sorry, I keep forgetting to look at the pull requests.  I thought the last changes I made to the Makefile were good...?  Did I never merge that to the master? 

I can't change the Makefile yet, without risk of breaking my debian package build.  It uses DESTDIR, so I need to do some testing on it before committing the change.  My guess is that it won't work right, but I guess I can always branch the makefile based on detected OS.

It doesn't need to get done right away, anyway.  No major bug fixes to master that aren't already in dev.  So you can stay on dev and everything will be fine...