For reference, part of the motivation of the new announcement system was to be able to do stuff like this.  It will check our S3 folder on startup and every 60 minutes, and will only download/save files that are signed with our offline key.  This includes being able to periodically update the bootstrap file between Armory releases.    If someone compromises our AWS/S3 account, the best they can do is DoS these announcements, unless they also get our offline Bitcoin private key.

For that reason, you can always stay up to date on the latest torrent simply by watching the bootstrap.file in the atisignedannounce folder. 

Bummer!  When I updated the torrent and re-signed the installer hashes, I accidentally left the "Testing (Unstable)" on 0.91.2 which is what is shown in the secure downloader.  I'll have to fix that.

On the other hand, it's listed on our website as the latest stable version.  So there's that...

Whoops, forgot to post here after we updated.  I don't have a direct link for you, but if you've run Armory for 5+ seconds since we updated it, your ARMORY_HOME_DIR/atisignedannounce directory will have something like "bootstrap.file".  Rename it to bootstrap.dat.torrent and you have the latest.

One thing I've learned over the course of building Armory is that those time-remaining bars are very difficult to get right.  Especially when it comes to things like downloading data that fluctuates in speed rapidly.   I have an extensive background in signal processing, yet I still can't get it right.

On the other hand ,there is a flaw in my algorithm -- it seems to use CPU-timings instead of wall-timings.  Typically this results in the system reporting that it took 2 sec to move 1% of the bar, instead of 3.2 or whatever.  This leads to very optimistic estimates.  I've been meaning to go in and figure out what is causing that, but I haven't had it on my priority list for a while.

Wow, I missed out on some fun discussions.  Let me clarify how this works, and what Armory has done (and failed to do).

• You can use openSSL to generate your own SSL certificate (offline if you want), and send just the [effective] public key to the CA for signing.  In this way, the private part of your certificate can be protected in exactly the same way as we do GPG.
• The certificate provider/signer will verify your identity before they sign any certificate claiming "Joe's Fish Shop" is the provider of this software.
• A single compromised CA cert could be used to impersonate just about anything.  Your system trusts any number of probably 100 certificate roots, and a signature from any one of them pretty much gives the green light, unless you are manually inspecting the certificate chain and know that certain certs are lower security and/or compromised.  It's the job of the OS and the browsers to track which CAs are still trustworthy and help update your CA lists to make sure that any compromised providers are no longer trusted.
• The MS/authenticode system is not good for verifying specific certificates.  Ideally, for high-security apps, the publisher would publish their public cert and everyone would verify that the signatures from that cert, though it's a bit of work to do this.  Instead, they just check whether there's any valid certificate chain and shows you "Yes/No" that the signature is valid.
• For this reason, I don't care much for Authenticode-signed certs.  They avoid the unsightly "Unknown Publisher" when you go to run the installer, but that can be a false sense of security.
• I stand by the notion that the GPG signatures are the most secure.  Our offline GPG fingerprint is everywhere, and it's simple to check via command-line.  It's also easy to integrate into our release scripts.
  

Here's what Armory has done to this point:

• I have a Class 2 object code signing certificate, signed by StartCom.  Though at this point it might be expired.  However, it is in my name ("Alan Reiner")
• Getting a cert associated with the company requires quite a bit of ID verification work, including supplying tax returns.  We haven't been keen to do this, though I suspect we will at some point.  This would be needed for it to show "Armory Technologies, Inc." on the "Verified Publisher:" line.
• Before version 0.90, Armory used my personally-verified cert.  I generated it on an offline windows machine, and integrated an three extra steps into my release process to make sure the windows installers made it to that machine for authenticode signing before going to the offline Linux box for GPG signing.  This is quite a pain ... you can't sign afterwords or else the GPG hashes/sigs break.
• There is technically a way to do this in linux, but it didn't work with the type of .exe I was signing.  I was left with no choice but to use a dedicated offline Windows box

.

• Before version 0.90, I did go through with all this.  You should be able to run the 0.88 installers and see my name as the verified publisher
• Since version 0.90, we have been using NSIS to package up our installers.  The signing process that I previously used no longer works.  I believe it has to do with the chained installer architecture:  the outer shell of the installer is signed, but it's only purpose is to unpack the real installer and run it... which is not (easily) signed.  This means that if you take the .exe posted on the website (if it were signed this way), you could view its properties in Windows and see the signature is there.  But when you run it, you still see "Unknown Publisher."

With all this in mind, I hope you'll forgive me that I wasn't excited about going through a lot of work, to provide what I felt was less security than the GPG sig, and complicates the heck out of my signing&release process.  Is it useless?  Not exactly.  But I'm comfortable with the idea that the user either checks the GPG sig and knows it's good, or they don't and know it's not verified. 

However, it is possible that the new installer format works with linux authenticode tools, so that it could be easily integrated into the release process.  If anyone wants to try that out for us and provide a recipe for doing it, I will take a shot at it.  But I'm not anxious to put a lot effort into what is already a complex and inconvenient process (low convenience but high security!).

The new backup system is backwards compatible.  It has no problem doing fragmented backups of old wallets, though they will be four-line backups instead of the new two-line backups.  This is because the older versions of Armory (before fragmented backups were implemented) independently generated the root key and chaincode from secure-random data and thus both needed to be backed up.  This was unnecessary since there is already more than enough entropy in the 256-bit key, so we switched to computing it from the root key itself.  Thus, if you have the root key, the chaincode can be computed and doesn't need to be backed up.   

Just make sure you use the backup tester and/or actually remove the wallet and restore it.   It will give you the option to test your backup after you are done creating it.

As far as I know, TrueCrypt doesn't do encrypted swap.  It makes sure that nothing touches your primary (storage) partitions unencrypted, but if you hibernate with key material in RAM, it will still end up on disk unencrypted.   I recommend both disabling swap (and hibernate), and use full-disk encryption.  TrueCrypt works for the disk encryption part, though most recent versions of Ubuntu have had home-partition encryption in the OS-install wizard for a while

Well the most sensitive keys will be kept on an offline computer which presumably runs nothing else except offline Armory.  There's not really a way to run through your RAM there.  Plus, I'd rather run out of swap than have the keys accidentally hit the hard drive unencrypted without warning.  But yes, it is possible to have encrypted swap, though I don't think you can use hibernate if you do that, so you'd be disabling hibernate which is 80% the reason you wanted encrypted swap to begin with.

Yup, you can sign in parallel.   Both regular multi-sig spends and simulfunding. 

If you look at the screenshot I posted a few up, you'll see that the latest version organizes everything into "Organizer" and everyone else.  In all operations, the organizer simply communicates with each other party/device indepdently, and merges the results. 

I wish this were true, but it's a common misperception about mlock().  mlock() actually cannot prevent keys from getting swapped, and it is pretty much guaranteed if you hibernate.  It's one reason we recommend that high-security device disable swap space entirely -- it's not like you're going to need it running offline Armory, anyway, which has a very limited resource footprint.  And hibernate as well, but I'm not sure hibernate works without a swap partition (good question, but go ahead and disable both). 
 

Even worse, mlock() cannot guarantee that key material is not paged even outside of hibernate.  mlock() is simply a very strong suggestion not to swap that key data, but if your really stress your system, it might happen.  This is why Armory guarantees that key material stays in RAM self-destructs after 5 seconds of being unlocked.  This pretty much guarantees that the user can't accidentally end up with key data in swap, unless they hibernate within 5 seconds of signing a transaction.  Luckily, Armory enforces a 5 sec delay before showing you if a transaction succeeded

Thanks! 

Armory is now a company, and we have a few full-time devs.  I still do the "feature innovation" like multi-sig, which I've been anxious to do for months/years and have already implemented six times over in my head.  When my current "vision" for Armory is complete, then I'll let some of the other guys do fun stuff like this    Plus, it's no small task to learn the subtleties of Bitcoin the way that is needed to implement things like this securely/properly. 

So yeah, all the multisig stuff I'm doing myself, with the others helping out, doing code reviews, fixing bugs and generally learning about what I implemented.  But they are covering the other parts of project so I can focus on my vision, such as armoryd, blockchain engine upgrades, better testing frameworks, etc.

Speaking of that, one of the big things for this release is a much more featureful armoryd.  It's not complete yet, so I won't call for testing, but it will be by the time we release 0.92-multisig, and will feature multi-wallet, multi-sig, and have a full suite of unit/functional tests.  PM me if you'd like to discuss how you could contribute.  We'd love to get more testing resources, especially if there's some security background involved!

As for testnet on OSX:  should be no problem.  You'll have to run it from the command line and use "--args" as the first CLI arg, otherwise OSX doesn't pass them along.  I believe it would look something like

Going forward, this kind of thing makes sense for us to do.  In fact, your comments inspired this thread, and I think that will be one of the first things we implement when we start figuring out how to better satisfy small-business type use cases.  I hadn't considered the idea before that you could make sure the key is encrypted with multiple passwords, thus enabling better access control on consumer hardware as long as there is operational security to back it up.

@PRab

Just fixed the repeated-public-key issue.  Will release an update this week that will enable you to sign your transactions back to the faucet

@helgabutters

Thanks so much for the feedback!  Especially for all the useful videos showing the bugs!  It's been extremely helpful. 

I think I fixed most of the issues you identified, except for some of the longstanding sizing issues and quirks running Armory on Linux.  Mostly what I've done is I've imposed a maximum character size on all the free-form entry fields (like prom note labels, etc), or limited the number of characters displayed. 

---

With the new lockbox dashboard and a bunch of these quirks fixed, I'll have a new version for you to test midweek and you can collect more bounties. 

If you use coin control and only select a few addresses with lots of outputs, you are most likely to spend them oldest-first.  I had been meaning to update the coin-control dialog to use a proper table instead of its current design, and along the way I would have it show individual UTXOs, not just addresses.  But that hasn't been a priority.

As for being an expert feature... no matter how you look at it, this is still not something that "regular" users use, care about or even understand.  Should they?  Maybe in a perfect world everyone would study Bitcoin and understand how to optimize their privacy, etc.  But the vast majority don't and the feature would just confuse them.

It's complicated.  There is some randomness involved in Armory's algorithm, but it's usually unnecessary.  I've written a detailed description of it before, and you can traverse the code for it starting here:

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/CoinSelection.py#L582

The gist of it is that we create a pool of coin-selection solutions, and then score each solution based on a variety of factors, such as "output anonymity," tx size, spending zero-conf, and most importantly -- number of input addresses linked.  The coin-selection solution with the highest score from that function is what is used:

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/CoinSelection.py#L358

The pool of coin-selections is created by doing a bunch of different sortings of the UTXOs.  Some by straight priority, some by modified "priority", some even have a few random solutions in them.   Then we pop off the highest sorted UTXOs until we have a candidate that is close to exactly the output amount, and one aiming for 2x (so that both output sizes are approx the same, if there is change).   Those two candidates are added to the pool to be ranked.

The process ends up with about 20 solutions, ranks all of them, and then uses the one with the highest score.   Typically, the solutions use the UTXOs with the highest priority.  Some of the sortings guarantee that coins from the same address are near each other and thus will typically use multiple inputs from a single address.

So the answer to your question is basically that it's not consistent, but there is a strong preference for using older UTXOs before newer ones.  You're also not guaranteed to use coins from the same address, though it is likely to happen due to the ranking system, which will give a higher score to solutions that have less unique input addresses. 

Fees are a sticky subject.  This is a limitation of the network, not Armory.
 
I am short on time at the moment, so I don't have time to look up fee calculation discussion links, but I can tell you if you are trying to send 0.01 BTC, you will need a fee unless that input is 100 days old.  800 confirmations is about 5 days.  So it absolutely will require a fee.  Armory is only applying the same algorithm that the network does, to avoid you using sub-par fees that might cause your tx to be DOA or get stuck.

I think this is the right answer!  Rather, it securely gets me what I want without too much implementation complexity.

@Crowex:  this is cool stuff.  I'm glad I finally know what to search for.   I'm a mathematician, so I am still intrigued by these theoretical solutions, and I'd love to find some math that does this naturally instead of the solution D&T posted above.  Though, if I put these features into Armory it will be D&T's solution for obvious reasons.   But I'm happy to continue discussing the math in this thread.

Ack, you just reminded me that I need to do something with that menu.  It is tough to describe why thy are there -- mainly you use them if you want to simulfund a regular address or lockbox you don't have loaded.  The lockbox manager requires you to select the lockbox to be simulfunded, and if you try to switch the simulfunding to another address or lockbox, you get an error (it seems unnecessary, but implementation was much simpler).   

In other words, if you want to simulfund a lockbox that you have loaded, you use the lockbox manager.  If you want to simulfund anything else (such as matching donations to a regular bitcoin address), you currently have to use those menu options.  I'd like to figure out how to make both available in a coherent way.

Nothing really to do with your bug, simply stating that I meant to figure out how to clean those up or remove those menu items, and actually forgot they were there, so they've been neglected.  You will get your bounty nonetheless. 

Yeah, I should've been more clear in my post.  Rephrasing what you said:

Shamir's Secret Sharing usually starts with a secret, and then you split it into M-of-N shares.   The participants receiving the shares get no say in the data contained in the shares.   You start with the secret and get M-of-N shares.

What I want is that your N participants each produce their own shares indpendently (their passwords), and then some calculation is performed on all of them to produce an encryption key that is only computable with M of them.   You start with the shares, and get an M-of-N secret.  It is okay if this process produces a piece of non-sensitive data that needs to be stored with the encrypted data to complete the computation.

When phrased that way, it's just an inverse of the problem that SSS solves

Today I was thinking about the idea that you could implement a software-based multi-factor encryption key for a wallet.  What comes to mind is Shamir's Secret Sharing, but in reverse.  I'll explain what that means after I explain basic SSS.

Goal
Modify wallet encryption, which normally requires the user to enter a password, and then key stretches it into a symmetric encryption key (such as AES256) and uses that to encrypt the wallet private keys.  What I would like is:  during wallet setup, you can have 3 passwords entered, and any 2 of them would be sufficient for the system to compute the AES256 encryption key.   Of course, it would be nice to implement any M-of-N.

The idea is that 3 employees of an [wing of] an organization would be responsible for managing either a single-sig wallet, or a single key of a multi-sig wallet.  In order to gain access to the offline key to sign transactions, the wallet will need to be decrypted, but the decryption key can't be calculated from any single employee's password.  


Background
Shamir's Secret Sharing is a mechanism by which a secret piece of data is interpretted as the highest order coefficeint of a polynomial, and then points of that polynomial are distributed and stored separately.  For instance, you store the secret as the slope of a line, and then you write down three points of the line on separate pieces of paper.  If you have any two pieces of paper, you have two points on the line and can compute the slope--which recovers the secret.  This would be 2-of-3.  You can do this with any M and N, using N points on an (M-1)th order polynomial.

While this concept is easy to visualize like we did in high school, you can't use floating point numbers because of precision issues.  Instead, you do all operations on finite fields, which are really just modulo-arithmatic, cyclic groups.  You simply define all operations to be on integers between 1 and some large prime N, define division to be   a/b = a * b^N-1, and then you can implement all the algebra identically.  I won't go into the details here, but this is how SSS is implemented in crypto systems.  However, usually the prime N is chosen ahead of time, and known by the device, so it knows which finite field to use to combine the points.  

Rephrased goal:  
Shamir's Secret Sharing is a process for converting a secret into M-of-N shares to be distributed.  What I want is a process for converting N shares (user passwords) into an M-of-N secret.  It's the inverse of the problem being solved by SSS.


Half-way there
If this was 2-of-2,  3-of-3, or M-of-M, stock SSS would work.  Say for 3-of-3:  the system collects all three passwords when the wallet is created, computes the highest-order coeffiicent of the parabola created by the hash of all three passwords (perhaps using the first four bytes of the hash as the X-value, and the remaining as the Y-value), then uses that as the encryption key for the wallet.  When all passwords are entered, the system can compute this value, decrypt the wallet, then destroy it.  This works, though there are simpler ways to combine mulitple passwords.   But how do you do arbitrary M-of-N?  


Discussion
But this doesn't work for M-of-N where M is not equal to N.  For 2-of-3:  you would like to compute a slope that could be computed from any two of the three points, but the three points are not co-linear in a pre-defined finite field.   One way would be to collect all the passwords first, and then figure out a set of finite field parameters for which all three points are colinear (for simple prime-based finite fields, try to find a prime N such that they are colinear).  Store the FF parameters in the wallet, and the wallet will use that data when two passwords are entered.    But this feels like a hack.

Unfortunately, my googling skills are failing me -- as I keep running into a bunch of unrelated things.   I feel like this must be a solved problem, and I just need to find the right documentation of it.


Alternatives
The best alternative is to simply not let users create passwords, but create a secure encryption key, then use SSS and put the shares onto smartcards.  In the institutional security world, this is at least how backups are made when using HSMs (and how Armory does fragmented backups of its wallets).  In this case, we're simply trying to expand on the user-password concept to be executed on consumer PCs.  At the moment, HSMs don't exist in the BTC world, and while they may, it would still be cool to have a solution for this problem here.

Another alternative, for small M and N is to simply store all N-choose-M multi-encrypted forms of the encryption key.  For instance, for 2-of-3, the encryption key will be randomly generated by the system, and then it will be stored 3 times in the wallet, each one encrypted with a different 2 keys.  Decrypting would simply be matter of trying to decrypt all three keys and picking the one that works (if any).  But this is an even bigger hack, and it doesn't scale very well (though modern computers could handle most use-cases pretty easily if there was no additional key stretching).


Caveats
I recognize we're still talking about a single piece of consumer hardware that could be compromised by malware, or someone with DMA could swipe the key from RAM once all passwords are entered, etc.  The goal is to provide a mechanism whereby multiple people are required to access the system, and together they monitor all interactions with the system and verify that no one is tampering/manipulating it.  Is it failproof?  No.  But it still prevents one person who temporarily gains access from pulling the key off the disk, even if they have one password.  If proper access control is exercised, this might provide another tool for implementing segregation of duties, in-place-of or in-addition-to multi-sig transactions.  

In the future, this might be moot, since orgs will move to HSMs which are all tamper-proof, destroy the private keys if you try to open, implement similar M-of-N access control, etc.  But for consumer hardware, I think this could be pretty strong.