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

torus,

That looks great.  You make it seem like it was so easy!  I think I'll be getting my hands on a Snow Leopard machine 10.6.7, so I will try these instructions when I get it, and I will update the webpage with this information, too.

Are you familiar with py2app?  I would like to create Mac binaries, if possible, and that seems like a good option for it, especially for Mac where compiling has been so difficult.  Are such binaries likely to work on all Mac systems?  Only 10.6.X systems?  


runeks,

I have quite a bit of experience with cryptography, but not specifically secure programming.  The python/C++ mix probably "hurts" security a bit due to not respecting the memory-management rules I designed into the C++ code (i.e. the SecureBinaryData container).  But I believe there are very few attacks that would be able to take advantage of sloppy python garbage collection that wouldn't also be able to take advantage of a solid, pure C++ solution -- if they have access to your local process-memory or DMA, you're pretty much screwed no matter what solution you have implemented.  There's a slightly higher risk that keying data could be left in memory and then written to swap space, but again, they would need low-level access to your HDD to get it, which again usually implies the whole system has been compromised.  In nearly all cases, if they can leverage one of those attacks, they already have enough access to the system to install a keylogger on the system, and then get your encryption passphrase and wallet next time you unlock.

The other major point of failure would be what you mentioned: actual wallet-encryption.  Here is the post about it, which I updated recently for-the-record:
    

• https://bitcointalksearch.org/topic/wallet-encryption-issue-51474

This was the inspiration for Armory's wallet files, which were designed to be straightforward for other developers to implement, while at the same time guaranteeing in-place overwriting of key data, or blanking of deleted data.  I was frustrated with the difficulty of accessing wallet information, as well as the general uncertainty about how BSDDB was handling the data.  I figured, a manual binary solution, with error-correction and manual ACID-like operation was not terribly difficult.  Mainly because the access patterns for a wallet are much simpler than an arbitrary application:  usually only appending key data and comments, or overwriting data with equal-sized strings.

Some might say that your OS/filesystem might not actually delete stuff, and instead rewrite the whole wallet to a new location and leaving the old one (much like the BSDDB bug described in the other post).  The Bitcoin devs themselves acknowledge such concerns are outside the scope of the application.  They/I could spend months coming up with something 1% more robust against specific kinds of attacks, for a specific filesystem types, but in the end, the user error/laziness will dominate the security concerns.  

My attitude was that you should do everything you can to protect online wallets, but you'll never fully succed.  Enter offline wallets.  If the keys never touch the online computer, the available attack vectors are two orders-of-magnitude harder, and require much more specialized viruses.  Those might even be avoided by using pure visual communication (QR code exchange via dual webcams, or IR tx/rx of binary transaction information).  But in the end, I think that's tremendously more complexity than necessary to keep yourself secure (it would confuse people more than it would add security).

Finally, python development is about 3x faster than C++.   And it already took me 3-4 months, as-is, to produce the existing python codebase (the rest of the time was spent on the underlying C++ code).  I'm not sure if Armory would even exist if I hadn't done most of it in python.  I'm a patient person, but I'm not *that* patient (which means you should give a lot of credit to Satoshi, for having been able to do it by himself, and took him 2 years).

Updated installation instructions are on Pastebin.
Building Bitcoin Armory on Mac OS X 10.6.x using Homebrew

I managed to make Armory running using homebrew to compile the dependencies on Mac OS X 10.6.8

The brew packages I installed

To get twisted for python2.7 install it using easy_install

I had to set the following for the environment

I also had to create a symbolic link to point to the homebrew python 2.7 directory
and then compile swig

I have a few questions regarding the security of Armory.

First of all, what kind of experience do you have in secure programming? I remember you said you were the one who found the "plain text key leak from encrypted Satoshi wallet"-bug. That's very impressive! Thanks for discovering this. Do you have a link that explains in detail what caused this bug? I've tried searching for an explanation of how this bug came to be, but I haven't been able to find anything.

I'm beginning to take an interest in computer security myself, so I'd like to know more about the design choices of Armory. Regarding the Python/C++ combination, is that related to the security of the final application, or is it just because it's easier/saves time?

I had some trouble building python libraries in the past with homebrew.  I think I had to manually set ARCH.  I think I put something like this in my .bashrc and then didn't have to worry about it anymore.


When I get to my laptop, I'll check.

Just FYI:  I already applied those patches to the codebase and verified that they don't affect Armory running in Windows or Linux.  The only thing that might need to be modified, still, is the Makefile (but I'm pretty sure that was patched, too). 

After Joric posted, I patched, tested and committed it, then modified the directions slightly and posted them on the Building Armory from Source.  Probably doesn't fix your problem, but it's worth mentioning since I don't think I responded to Joric's post directly.

Thanks for the instructions.
I tried to use homebrew to install the dependencies.
I applied your patches and changed the python path int he Makefile (homebrew uses python 2.7.

I now want to compile BlockUtils using make swig in cppForSwig.
But it does not succeed with the following error:

Any ideas?

btc_artist,

That is exactly right.  There's actually a warning box when you decide to print a paper wallet that warns you that imported keys are not part of that backup.  However, that's why there's also a wallet option labeled "Backup Individual Keys."  Clicking that gives you a list of private keys that you can manually copy/save/print (and a checkbox for imported-keys-only).  The goal was to allow you to be able to get your individual keys if you want to import them into another program, or just create a imported-key-backup to supplement your deterministic backup.

One question I do have is how do imported addresses and the deterministic wallet work?  You can rebuild the deterministic wallet based on the seed value, and I assume imported addresses are just held completely separate.

Good decision.

I'm excited for this.

Joric succeeded at reading encrypted wallets, and I do want to eventually allow the move, but I want to make sure it's possible to run Armory without running bitcoin-qt/bitcoind at the same time.  Sharing some addresses between the two wallets while also having some independent addresses can lead to you having absolutely no idea how much money you have (and usually over-estimating).

At the very least, I want to allow people to switch to Armory, but I can't reliably create a perfectly synchronous dual-wallet system.  I designed the Armory wallet specifically to be simple and straightfoward, and easy to maintain among multiple clients.  The Satoshi client wallet uses a database engine, which not only requires a separate library, but I also think it comes with extra risks (like the encrypted-wallets-not-actually-encrypted bug 0.4.0).   I will not add any support for Satoshi wallets beyond pulling keys out of them.  

In the future I will not only implement a bulk-import feature, but also leverage pywallet code to do a direct import of the Satoshi wallet, but with a warning to stop using the Satoshi wallet (perhaps a print-backup-then-delete option).  Until then, just create a new wallet and send it some money.

The single-address-import function was aimed more for vanity-gen addresses and Casascius physical bitcoins.

That *is* a valid point.  In many cases, it would be better to send the BTC to the Armory wallet via a transaction.  Of course, the exception is vanity addresses.

and then you have a deterministic wallet that is a few bytes big  + hundreds of isolated keys including the backup keys. very useful.

Import functionality would not mean changing the Armory format.  You would simply read the old wallet.dat file and then import all the private keys into the Armory wallet.

the existing format sucks and armory has a completely different and imho way superior approach. its better to make a clean cut early than to carry on with a bad solution because of backward compatibility.
its not like there a millions of people out there depending on their old addresses.

znort,

I have actually, explicitly, decided not to allow people to import their wallet.dat.  It's because stupid things happen when you have two clients open using the same keys, and users shoot themselves in the foot.  Not to mention, I don't want everyone blindly converting their entire wallet to a piece of alpha software.  Armory is good, but it needs to survive in the wild a bit longer before I start allowing people to import their entire wallets.  This way, users know to approach cautiously.

I should've explained, that the point was for you to make a new wallet, and transfer some of your money to the new wallet.  If you're comfortable transferring all of it, I won't stop you.  If you have some popular addresses you want to move over, you can use pywallet to get them and import them to Armory. 

Once I get some other features implemented, I will be making a bulk-import dialog.

Man I suck at quality control.  I had tested the pseudo-binary solution in Windows, except I used a machine with python already on the path which wasn't part of the install instructions.  I updated install_zope.py and tested it on a fresh Windows7-32bit VM.  Works perfectly now.

Also, it gave me the opportunity to test the XP-32bit binary on Windows7-32bit, which did work.  So I renamed them simply to "Armory_32bit.zip" and "Armory_64bit.zip".  Only the rare few with WinXP-64bit may have an issue.  And I don't have a sample system like this, so I can't test it.  If you do have such a system, let me know how it goes.

I'm still working on the full-binaries, but the issue I'm having is inconsistent, so I don't have a good way to know for sure.  I just have to do some more exhaustive testing.  Thanks for your patience!

Matoking, thanks.  I have seen that a couple times on systems with screens smaller than my own.  But it doesn't appear to happen on any other tables, so it should be easy to isolate why that's happening.  At least, ugly is better than dysfunctional!  I will look into it this weekend!

Given the previous discussion in this thread about mmap, I might be able to fix the RAM issue sooner than later!  It's not as difficult to implement as I expected (and the madvise() function is exactly what I need to optimize the operation for blockchain scanning).  Linux will get the upgrade first, but hopefully Windows won't be far behind!

-Alan

I don't have enough RAM to hold the whole main network blockchain, that's why.

The GUI issues are nothing severe, it just looks a bit ugly with overlapped text and buttons :
http://i.imgur.com/BOQ6d.png