Quote from: traderjoe on July 21, 2012, 02:50:57 PM

Passing an unwanted guest to the offline wallet and back again over the USB key, seems like the one main vulnerability of Armory. I was thinking of re-partitioning an old USB flash drive to be just large enough to store most transactions one might make to/from the offline wallet.

This is definitely a non-perfect situation, but it's pretty damned good given the usability requirements. The process is already complicated for some new users, and they may not yet fully understand what's going on. I'd rather them use offline wallets with a USB key than not use offline wallets at all (which is a significant risk if it's too complicated). In that sense, everyone understands USB keys, so it serves its purpose well, and if you take precautions (like disabling USB autorun services, etc), it's very safe.

If you are ultra-paranoid, one thing you can do, is buy a USB key that has a write-protect switch. Write the transaction to the USB key (which may be many kB), then turn on write-protect and insert it into the offline system. If you sign the transaction and observe the difference between the original and the signed version, it's only ~140 bytes for each input at the bottom of the TxDP: (in bold)

Quote

-----BEGIN-TRANSACTION-FygKQ1EY-------------------------------------------------
_TXDIST_fabfb5da_FygKQ1EY_00a0
01000000023f4c47217647372132666fc1ae28d03508c8688a20273b255fbbf9b115b455e601000 0
0000ffffffff2224b044061b79b7af49c0df6c431dc600259fd5b222b3e25ebeb6001a7bc1d0000 0
...
_TXINPUT_00_19.59950000
_SIG_myiqg9jzUJ3TFi2dXaMBth1dDEcGuWuyRf_00_008c
4930460221007c746bf76bd6f8b3f60f62a8afd2dd653f66e87c90482fb4bea79118109bf1d1022 1
003d5ea4fe5223c7cc060f4f197208b4c8551195a6a1618065ef44cecba9405ec201410440ecb35 a
d63922d4d11314705a47372d63bc8bbc52f38c6abfba9c9fc5b1f230d432b7023687fda21c8a1f5 5
bf6c779cfd691917d4cb00b706b7a0df7d3af360
_TXINPUT_01_21.11110000
_SIG_mxUVS4fhnxD7jm5yjozuwkeMVDYakMueHB_01_008c
4930460221007db2bfb26234265781b7ca224f637a59fd4d1cb3b2f54330a1a075237f5ce09b022 1
00e05ce4dc9e3fcbc167d748da5286d26aabb3c0ad3874e2d4d8792b0e86208147014104f347f5a 0
3fa446972313e1df4e1596410bcfbaddaea90a8dd7cce01ff4f9575f34ed5b0e185fe1b36279e6f a
b0e219a72090de2d703b4df8d35df5af661f4fe5
-------END-TRANSACTION-FygKQ1EY-------------------------------------------------

This is quite a bit of data, but theoretically it could be copied by hand or scanned+OCR on the online computer. If you only do it a couple times a year and holding a ton of money, it might be worth it. I was looking into serial cable solutions, but the hard wire connecting the two computers made me uncomfortable (not to mention that it takes quite a bit of setup to make sure that the serial line is secure).

Quote from: traderjoe on July 21, 2012, 02:50:57 PM

I was wondering if that sounds like a very good idea and, if it does, if the developer had any idea about how much space might be a good compromise between usability (key not usable if too small) and enhanced security (space for unwanted guests if key partition too large). As the wallet is offline, I don't anticipate ever sending to multiple addresses, or having especially long blockchain entries. I have imported private keys for this just in case anything were to go wrong with the armory wallet or if support on Armory were to end abruptly.

Luckily, Armory wallets have been the same since day one, and will continue to support the same deterministic structure even with the new wallet format coming up. As such, any version of Armory since January will be sufficient at producing any number of keys from any Armory wallet you've ever created. Even if support were to disappear, you'll be able to get those back with any version.

As for the small USB key partition: I like the idea a lot better if there was a way to bound the transaction size. Unfortunately, these sizes are highly variable -- since I need to store previous transactoins in the TxDP (what is sent to the offline computer) there could be 100 kB in a single transaction. However, most transactions, for simple users, will only include a couple inputs and will only be a few kB. As such, the gap between smallest and largest is big enough that something sufficiently advanced could hide there Sad