Author

Topic: Armory - Discussion Thread - page 225. (Read 521693 times)

legendary
Activity: 1764
Merit: 1002
January 17, 2012, 04:28:20 PM


i use an Ironkey that has a malware scanner built in on top of the encrypted internal chip.  this combined with desktop antivirus/malware should be pretty effective in preventing malware from infecting the Ironkey would it not?

I've heard good things about the Ironkey.  For the offline wallet interface, the biggest threat is hidden USB-key viruses, so something with built-in-AV probably helps.  But without some kind of updating mechanism, it's built-in A/V could quickly become outdated and useless against evolving threats.  I think more importantly, having A/V on the online system and disabling any kind of autorun-on-mount capability on the offline system are the most proactive way to avoid these problems. 

But even without that, the offline wallet system is probably the absolute safest way to manage large sums of BTC, despite being fairly complicated.  Yet, I believe Armory has actually made it usable by ordinary users (now I just need to get the system req'ts down to "normal"), and hope others will help me test that part and let me know what they think.  It was one of my prime motivators for starting Armory.





i really appreciate this product.  i too look forward to offline tx capability in a simpler way.  thanks.

fyi, Ironkey updates the malware scanner online each time i open it and scans the contents of the Ironkey.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 17, 2012, 04:01:45 PM

I fully believe in the goal of OP_EVAL and BIP_0016, and I believe it is a hard problem to solve safely.  As found with OP_EVAL, enabling a sub-scripting system with recursion in a system that was intentionally not Turing-complete, opens up a can of dragons.  Unfortunately, I've been so focused on Armory development, that I haven't gotten too deep into the discussions on it, so I can't form a valid opinion on any specific proposal.   But I do believe that the goal of these proposals is extremely beneficial to BTC in the long run.  (although, it would be nice to get my client out with the old rules before having to support new ones right away).


i use an Ironkey that has a malware scanner built in on top of the encrypted internal chip.  this combined with desktop antivirus/malware should be pretty effective in preventing malware from infecting the Ironkey would it not?

I've heard good things about the Ironkey.  For the offline wallet interface, the biggest threat is hidden USB-key viruses, so something with built-in-AV probably helps.  But without some kind of updating mechanism, it's built-in A/V could quickly become outdated and useless against evolving threats.  I think more importantly, having A/V on the online system and disabling any kind of autorun-on-mount capability on the offline system are the most proactive way to avoid these problems. 

But even without that, the offline wallet system is probably the absolute safest way to manage large sums of BTC, despite being fairly complicated.  Yet, I believe Armory has actually made it usable by ordinary users (now I just need to get the system req'ts down to "normal"), and hope others will help me test that part and let me know what they think.  It was one of my prime motivators for starting Armory.



legendary
Activity: 1764
Merit: 1002
January 17, 2012, 02:44:03 PM
will this client ever get arm support? i ask because i want to buy a raspberry pi, and that runs arm.

Ctoon,

It'll be a while before Armory will be lite-enough to work on such light-weight hardware.  However, the beauty of the offline transactions technique (based on BIP 0010) would make it feasible to use very inexpensive hardware solely for signing offline transactions (because you don't need the blockchain, you only need to be able to run ECDSA code).  But I don't think I'll be doing that... I just don't have the experience with alternative architectures.

But again, my stuff is open source, BIP 0010 is public, and my wallet files are well-documented.   I bet someone more-suited for the job could make it happen and I'd be happy to help them.  I am excited about the possibility of the offline tx technique to enable super-light-weight, inexpensive, signing devices that could be used for two-factor-authentication-like scheme.  But full Armory might be a stretch.



i use an Ironkey that has a malware scanner built in on top of the encrypted internal chip.  this combined with desktop antivirus/malware should be pretty effective in preventing malware from infecting the Ironkey would it not?
legendary
Activity: 1470
Merit: 1005
Bringing Legendary Har® to you since 1952
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 17, 2012, 01:03:39 AM
will this client ever get arm support? i ask because i want to buy a raspberry pi, and that runs arm.

Ctoon,

It'll be a while before Armory will be lite-enough to work on such light-weight hardware.  However, the beauty of the offline transactions technique (based on BIP 0010) would make it feasible to use very inexpensive hardware solely for signing offline transactions (because you don't need the blockchain, you only need to be able to run ECDSA code).  But I don't think I'll be doing that... I just don't have the experience with alternative architectures.

But again, my stuff is open source, BIP 0010 is public, and my wallet files are well-documented.   I bet someone more-suited for the job could make it happen and I'd be happy to help them.  I am excited about the possibility of the offline tx technique to enable super-light-weight, inexpensive, signing devices that could be used for two-factor-authentication-like scheme.  But full Armory might be a stretch.

sr. member
Activity: 350
Merit: 251
January 16, 2012, 11:50:42 PM
will this client ever get arm support? i ask because i want to buy a raspberry pi, and that runs arm.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 14, 2012, 08:34:03 PM
good work. I am willing to participate in alpha testing

Great!  Build instructions are posted here.

If you're in Windows, you'll need some patience.  Let me know if the build instructions aren't clear enough, or need any corrections!

-Eto
newbie
Activity: 7
Merit: 0
January 14, 2012, 08:19:17 PM
good work. I am willing to participate in alpha testing
legendary
Activity: 1470
Merit: 1005
Bringing Legendary Har® to you since 1952
January 13, 2012, 08:05:52 PM
Quote from: etotheipi
Armory does all of its communication to the Bitcoin network through the Satoshi client
Will that be changed in future releases?
Code:
# proxychains ./armory_executable
That could leak some info that doesn`t respect for some reason proxychains, such as DNS requests.

Untrue.

Proxychains actually proxies DNS through its chains ! It also works well with TOR (also tested myself).

This fancy thing even works with advanced apps (GUI apps).
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 13, 2012, 07:36:23 PM
Quote from: etotheipi
Armory does all of its communication to the Bitcoin network through the Satoshi client
Will that be changed in future releases?
Code:
# proxychains ./armory_executable
That could leak some info that doesn`t respect for some reason proxychains, such as DNS requests. Also, proxychains is outdated and unmaintained since 2006. I suggest using torsocks instead if you want Tor support without building proxy chains. Anyway, native proxy support is better than third-party soft, and, finally, as you mentioned, that will not work in Win and Mac.

The two major upgrades between now and beta will be
(1) Reverting to file-based blockchain operations (to bring memory req'ts from 1.5 GB to 100 MB)
(2) Make Armory networking-independent

For the first release, I decided to go through the Satoshi client, so that it will handle all the complicated networking protocols and full-validation of incoming transactions.  By running Armory through Satoshi, I get all that for free!

I will add proxies to my list of features to support in the future!
sr. member
Activity: 427
Merit: 250
January 13, 2012, 07:24:17 PM
Quote from: etotheipi
Armory does all of its communication to the Bitcoin network through the Satoshi client
Will that be changed in future releases?
Code:
# proxychains ./armory_executable
That could leak some info that doesn`t respect for some reason proxychains, such as DNS requests. Also, proxychains is outdated and unmaintained since 2006. I suggest using torsocks instead if you want Tor support without building proxy chains. Anyway, native proxy support is better than third-party soft, and, finally, as you mentioned, that will not work in Win and Mac.
legendary
Activity: 1470
Merit: 1005
Bringing Legendary Har® to you since 1952
January 13, 2012, 07:04:25 PM
Looks just great. Do you plan to add proxy/socks feature? Or maybe I missed something and can`t find where to set this up.

That's a very good question.  I'm not familiar with that aspect of networking (in general) to know how much effort that would take.  Perhaps someone else on the forums can reply to the following naive answer:

Right now, Armory does all of its communication to the Bitcoin network through the Satoshi client.  Perhaps, if you set up the Satoshi client to go through a proxy, then you will get the benefit of having done that in Armory.  This assumes that you can still execute a localhost connection to the Satoshi client while it is using the proxy.

Code:
# proxychains ./armory_executable
will probably work well on most Linux/BSD/UNIX-like systems.

http://proxychains.sf.net/

If it even works with SSH (checked myself), it should work with most of apps.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 13, 2012, 05:20:01 PM
Looks just great. Do you plan to add proxy/socks feature? Or maybe I missed something and can`t find where to set this up.

That's a very good question.  I'm not familiar with that aspect of networking (in general) to know how much effort that would take.  Perhaps someone else on the forums can reply to the following naive answer:

Right now, Armory does all of its communication to the Bitcoin network through the Satoshi client.  Perhaps, if you set up the Satoshi client to go through a proxy, then you will get the benefit of having done that in Armory.  This assumes that you can still execute a localhost connection to the Satoshi client while it is using the proxy.
sr. member
Activity: 427
Merit: 250
January 13, 2012, 05:15:16 PM
Looks just great. Do you plan to add proxy/socks feature? Or maybe I missed something and can`t find where to set this up.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 13, 2012, 04:56:16 PM
I have updated the bitcoinarmory.com webpage with the build instructions and a short tutorial on offline transactions (but, no screenshots, yet).

http://bitcoinarmory.com/index.php/building-armory-from-source
http://bitcoinarmory.com/index.php/using-offline-wallets-in-armory

As I continue filling out the webpage, I will be moving more and more Armory-related communications to it.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 13, 2012, 12:18:29 PM
However, I'm not clear what your deterministic algorithm is...?  Do you use the DHSS method that allows you to compute the deterministic addresses without the private keys?  I have been looking at the Electrum website, but didn't see how it is done.   So far I haven't seen anyone else implement the determinism this way, and thus I would have no choice but to use my own method.  Armory is critically dependent on the ability of watching-only wallets to be able to generate the public key chain without needing private keys.

I use the method described by gmaxwell, that he called "type 2 wallet".
This method allows to generate the public key sequence without the private keys, so I guess it the same as what you describe.
Note that the same method is used in BCCAPI as well.

I use two separate sequences: one for receiving addresses, one for change addresses.
The wallet recovery procedure stops when it finds a sequence of N consecutive unused addresses (default is N=5)

By default, the software generates seeds that have 128 bits of entropy. However, this is not strictly enforced; users may use longer seeds.
The master private key is derived from the seed using hash based key stretching.
I do not use the password as salt because I want users to be able to modify their password.


Okay, we're doing the same thing, then, just with different algorithms.  The only real difference is that, in Armory, the master key is randomly generated, and then the passphrase is passed through a scrypt-like KDF to get the encryption key.  If the user changes their passphrase, then everything is unencrypted and reencrypted with the new KDF-derived encryption key.

In Armory, I don't keep a separate chain for change addresses.  I simply "get next unused address" for change.  And while I had to battle the question of how far out to extend the chain beyond that last seen address, I believe 5 is way too small.  I use 100 which may be too large, but I'd much rather err on the high end than vice versa.  You only need the user to generate a couple addresses that end up not being used, before your wallet will get stuck.  But you do have it as an adjustable parameter, so it's easy enough for you to change if you determine it's a problem.

You can either post here, or send me a PM, the specifics of your deterministic algorithm.  I will consider switching the wallet to that format, as long as there is enough "standardization" around the algorithm -- it sounds like there is, if electrum and BCCAPI are both using it.  Any other clients with deterministic wallets?  I haven't been following other clients too much, because I've been completely consumed getting mine into a releasable state...
legendary
Activity: 1896
Merit: 1353
January 13, 2012, 12:09:48 PM
However, I'm not clear what your deterministic algorithm is...?  Do you use the DHSS method that allows you to compute the deterministic addresses without the private keys?  I have been looking at the Electrum website, but didn't see how it is done.   So far I haven't seen anyone else implement the determinism this way, and thus I would have no choice but to use my own method.  Armory is critically dependent on the ability of watching-only wallets to be able to generate the public key chain without needing private keys.

I use the method described by gmaxwell, that he called "type 2 wallet".
This method allows to generate the public key sequence without the private keys, so I guess it the same as what you describe.
Note that the same method is used in BCCAPI as well.

I use two separate sequences: one for receiving addresses, one for change addresses.
The wallet recovery procedure stops when it finds a sequence of N consecutive unused addresses (default is N=5); during normal operations, the software never allows the user to create gaps larger than N.

By default, the software generates seeds that have 128 bits of entropy. However, this is not strictly enforced; users may use longer seeds.
The master private key is derived from the seed using hash based key stretching.
I do not use the password as salt because I want users to be able to modify their password.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 13, 2012, 11:41:46 AM
SORRY if anyone tried to checkout and compile on Windows.  I updated the MSVS 2005 projects, but forgot to commit-and-push the changes.  D'oh!  I just pushed them to the qtdev branch, so it should go a lot smoother now.  Sorry about that!
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 13, 2012, 11:26:50 AM
Someone suggested that deterministic wallets shoud try to use a standard key generation algorithm.

https://bitcointalksearch.org/topic/m.688099

Since you have not released the initial version, may I suggest to use the same key generation algorithm
that is already used in Electrum? This would allow users to use the same seed in both clients.

see http://ecdsa.org/electrum

It is much more difficult to change this after you have released your software.


Luckily, I have made sure I have a separate version number just for wallets, so I can do exactly what you suggest.  Obviously, if I upgraded, old wallets would not be convertable but would still work.  Only new wallets would be transferable, which is fine... (users can upgrade if they want it).

However, I'm not clear what your deterministic algorithm is...?  Do you use the DHSS method that allows you to compute the deterministic addresses without the private keys?  I have been looking at the Electrum website, but didn't see how it is done.   So far I haven't seen anyone else implement the determinism this way, and thus I would have no choice but to use my own method.  Armory is critically dependent on the ability of watching-only wallets to be able to generate the public key chain without needing private keys.

For reference, the algorithm I use is not terribly complicated.  The 32-byte "chaincode" is kept with the wallet (and actually stored with each key in the wallet).  You chain addresses via:

Code:
a = hash256(PubKey65(i)) XOR chaincode  
PrivKey(i+1) = a*PrivKey(i)

The magic is in the ECC math, so you can continue the chain with public keys only:
Code:
a = hash256(PubKey65(i)) XOR chaincode  
PubKey(i+1) = EC_Multiply(a, PubKey(i))

The chaincode is simply extra entropy added to the determinism (i.e. salt), but not entirely necessary.  I might revert, in the future, to making the chiancode deterministically generated from the root private key, so that you only need 256 bits (root private key) to recover the wallet, not 512 bits.

Btw, I really like your technique for converting entropy into dictionary words.  That's pretty slick!  I never considered the possibility that a user would try to memorize their keys, or even write it down by hand, but that certainly makes it possible!  (because I will never generate a wallet with less than 256 bits of entropy, that's a lot of write/memorize). 


legendary
Activity: 1896
Merit: 1353
January 13, 2012, 02:43:31 AM
Someone suggested that deterministic wallets shoud try to use a standard key generation algorithm.

https://bitcointalksearch.org/topic/m.688099

Since you have not released the initial version, may I suggest to use the same key generation algorithm
that is already used in Electrum? This would allow users to use the same seed in both clients.

see http://ecdsa.org/electrum

It is much more difficult to change this after you have released your software.
Jump to: