Bitcoin Forum
June 25, 2016, 05:19:43 AM *
News: Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 102 »
501  Bitcoin / Armory / Re: Simple entropy questions on: July 29, 2015, 01:04:07 AM
The mouse data in this particular code is a pair of integers (x, y) that define the position of the mouse relative to top left corner of the dialog the position is retrieved from. For a dialog of size (X, Y), the top left corner is (0, 0), the bottom right corner is (X, Y).

In this particular case, the dialog is created with a default size so it depends on the desktop resolution and the default system font size, which influences the size of the elements within that dialog (and thus how large Qt is going to create it). Assuming a desktop resolution of 800*600, I believe the dialog could get as small as 300 pixels wide and 150 high. This gives us x E [0, 150] and y E [0, 300], so an average of 16 bits for the pair in some pretty bad conditions.


Timestamps are in the plain old UNIX format, i.e. the amount of time that has passed since Jan 1st 1970. I believe the timestamp is in milliseconds in this case (I would have to double check). The more significant bits of the timestamp won't change at all during this operation, so only the bottom few really matter for consecutive throws. If you take [3-8] seconds per throw and key press that's about 12 bits of entropy per, but assuming I messed up and the timestamps are in seconds, then you are closer to 6~8 bits on the span of 100 throws.
502  Bitcoin / Armory / Re: Armory on Windows 10 on: July 28, 2015, 11:36:00 PM
Quote
Why don't you recommend

It's bad practice. If you can fix the issue by only changing credentials on a folder, that should be the solution you go for. Giving system wide privileges to the process instead is not an acceptable work around, rather a way to verify this is a permission issue.
503  Bitcoin / Armory / Re: armory is offline help please on: July 28, 2015, 09:46:39 PM
Chances are you have to explicitly tell Armory where your new block folder is.

Start Armory with --satoshi-datadir="mynewpath".
504  Bitcoin / Armory / Re: Armory on Windows 10 on: July 28, 2015, 09:43:29 PM
I'm switching the machine controlling my Offline wallets... But it simply doesn't get out of offline mode

Just nitpicking

Quote
CalledProcessError: Command '[u'icacls', u'D:\\Bitcoin\\bitcoin.conf', u'/inheritance:r', u'/grant:r', u'*******:F']' returned non-zero exit status 5

It failed to change privileges on bitcoin.conf, most likely because you user doesn't have the proper credentials to change access rights on that drive.

There are a few solutions available:

1) Start Armory with admin rights (I don't recommend this)
2) Turn off auto bitcoind management and run BitcoinQt yourself.
3) Start Armory with --disable-conf-permis (https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L120). I don't exactly recommend this either
4) Give your user the proper permission. Right click on the D drive, go to the security tab, pick your user and give it full control over the drive.
5) Move your bitcoin folder into a path your user has full rights over (most likely C:\Users\*yourusername*)
505  Bitcoin / Armory / Re: Simple entropy questions on: July 28, 2015, 09:32:34 PM
You're also forgetting about things like how a die may not have even weighting on all sides, thereby biasing every throw you make. So, to "guarantee" X amount of entropy for die throws isn't quite as simple as it looks at first glance.

Which is why the deck of cards is preferable.

Quote
The question is simply: Will this guarantee a 256-bit additional entropy from the die or not? And if not, how many extra die throws would be required?

I guess this is sort of a maths question. I don't know how to calculate it, because I don't know precisely how the cursor points map into raw entropy bytes, etc.

There's about 16 bits of entropy in each mouse pos considering the average size of the dialog and that the position is relative to the dialog's top left corner and cannot exceed the bottom right corner. With the added timestamp, I'd say you get another 8 bits so that's ~24 bits per keystroke.
506  Bitcoin / Armory / Re: Simple entropy questions on: July 28, 2015, 01:31:46 PM
You are complicating things for no apparent reason. If you don't trust the software RNG, use a hardware one or dice/cards. Mixing them defeats the premise. You either trust the RNG or you don't. If you believe the software RNG is unsafe, why mix it with a safe source? Just use the safe source.

Nevertheless, you are also using the weirdest way possible to mix the entropy sources. Add a command line argument in armoryengine.py, something like --extranentropy. Pass in your external entropy as a hex string, load that into a SecureBinaryData object so that it is mlock'd then feed that through the extra entropy channel at wallet creation.

If that's too complicated, start some offline live instance of Linux, copy over Armory and the necessary packages (into the live ramdisk). Make sure no storage device (internal or external) are plugged for the good measure. Hardcode your extra entropy straight into the .py. Start Armory, create your wallet, write down the backup string, test it a couple times and shut down the machine. Voila.

Lastly, as picobit stated, it's easy to shoot yourself in the foot manipulating entropy on your own. Make sure you follow the dice roll/card deck instructions properly, and that you know what you are doing with the code. It's pretty easy to pass in an empty string for your entropy source.
507  Bitcoin / Armory / Re: Different hashes when creating encrypted backup twice (Bump. Nobody?) on: July 25, 2015, 03:00:09 PM
You unlocked the wallet so it used this opportunity to compute missing private keys. Armory wallets derive the public key chain without the need to compute the relevant private keys beforehand. This is how watching only wallets function. Specific to our format, when you unlock a wallet (i.e. make the private keys temporarily "visible" to Armory), the missing private keys are computed and saved to disk along the relevant public keys.

As I said a wealth of different operations can modify a wallet file, but that does NOT explain your issue. Your issue is that your wallet went from hash1 to hash2 (nothing out of the ordinary), yet it went back to hash1 later on. Certain operations in Armory could result in that but the steps you describe does not include any of these.

Quote
What could explain this? Some Armory developer must have some ideas.

etotheipi developed the wallet format and I did the recovery tool. We are the only 2 at Armory with lots of experience on this wallet format, and I don't expect he has a different angle on this. You should start looking at the state of your environment as well.
508  Bitcoin / Armory / Re: Different hashes when creating encrypted backup twice (Bump. Nobody?) on: July 24, 2015, 09:04:45 PM
The data in the wallet can change for a lot of different reasons, but I don't expect anything short of user action can modify data then roll it back. Maybe your log file could yield some information of what happened, but at this point I'm not so sure Armory is the culprit anymore. Did you change permissions on the file maybe? You should try to reproduce the faulty hash again.
509  Bitcoin / Armory / Re: Different hashes when creating encrypted backup twice (Bump. Nobody?) on: July 24, 2015, 02:27:34 PM
Used a different password the second time around?
510  Bitcoin / Armory / Re: Different hashes when creating encrypted backup twice (Bump. Nobody?) on: July 24, 2015, 11:18:15 AM
Did you hash the wallet, the backup, or both?
511  Bitcoin / Armory / Re: Not able to get armory online again on: July 24, 2015, 11:15:54 AM
You should turn off auto managed bitcoind until your system is stable.

You can force your block data path using the --satoshi-datadir command line argument.
512  Bitcoin / Armory / Re: Not able to get armory online again on: July 23, 2015, 10:09:49 PM
This is a symptom of an unsync'd Armory.

Again, you want to start Core manually (look for BitcoinQt.exe). Let that sync all the way, then report here.
513  Bitcoin / Armory / Re: Different hashes when creating encrypted backup twice (Bump. Nobody?) on: July 23, 2015, 07:30:24 PM
Tons of different operations will change the binary content of a wallet. From adding/modifying/removing comments, to generating new addresses, to spending coins, and so on.

A wallet should not change in between runs: if you turn off Armory, hash your wallet, don't run Armory for a couple days and hash the wallet again, you should expect the same hash. If you ran Armory in between, all bets are off.
514  Bitcoin / Armory / Re: Not able to get armory online again on: July 21, 2015, 06:08:19 PM
Turn off auto bitcoind management and run Core manually.

Quote
PS: I have a paper backup (made at installation) but I am not sure if it will get my incoming addresses created after that backup if I restore with paper backup

Of course it will
515  Bitcoin / Armory / Re: ADWARE/Adware.Gen7 Armory on: July 20, 2015, 07:43:25 PM
guardian.exe is a very simple piece of code, meant to kill bitcoind if Armory came to crash before gracefully closing the instance of Core it is managing. It is only used when auto bitcoind management is turned on, so if you don't trust the exe, turn off that setting and delete the binary entirely.

It is also very easy to build. Download any version of Microsoft Visual Studio 201x Express (that's the free version), load the guardian project and build it. Nothing more needed.
516  Bitcoin / Armory / Re: Armory Offline Bundle (0.93.2) seems to work on Ubuntu 15.04. Can I trust it? on: July 19, 2015, 12:00:00 PM
An offline package targeted to a specific OS means the binary has been built and tested on a fresh install. Same for the package list, it was put together to get Armory running on a freshly installed OS.

A binary for 12.04 will definitely run fine on 15.xx. However there is no guarantee the package list will be entirely compatible with a later OS, although it apparently is with 15.xx. If you are concerned about security, keep in mind that the offline signer derives its security from the air gap. You should be more concerned about how you are passing transaction data to and from the offline device rather than package compatibility.
517  Bitcoin / Armory / Re: Is SecurePrint secure enough to make the paper wallet publicly available? on: July 19, 2015, 11:51:31 AM
I didn't implement SecurePrint, this code predates Armory having any employees. You would have to rest your case directly with etotheipi to have this feature customized. As you can see all the parameters for SecurePrint passphrase derivation are hardcoded, I'm guessing to make things simple while maintaining an acceptable level of security.

I believe your request is receivable but I cannot modify this feature without getting approval, and I don't expect I will get it simply because we have a large list of high priority items to go through currently. The best I can do for you atm is to point etotheipi to this thread, leaving you to defend your position.

This would be a good candidate for a plugin though, and if you are willing to develop one we will most likely sign it. Otherwise I would suggest you modify the hardcoded values for passphrase derivation (it's pretty simple) and write down your custom parameters on your paper backups, maybe with some instructions on how to reproduce them.

This way you can use any parameters you want now while waiting for a plugin to be developed.
518  Bitcoin / Armory / Re: Is SecurePrint secure enough to make the paper wallet publicly available? on: July 18, 2015, 10:11:43 PM
Brute forcing a SecurePrint key is pretty expensive.

The key is elongated through a scrypt precursor (ROMix): high RAM cost so it's expensive to parallelize a brute force attack. Just decrypting the encrypted root key with a candidate passphrase isn't enough to verify it, you still need at least 2 ECDSA public key exponentiation to get the first public key with potential balance.

Let's ignore the other operations, let's just look at the KDF. The key derivation function defaults to 16MB RAM. Assuming a recent high end computer can compute 2000 candidates per second, with 10000 machines attacking your SecurePrint passphrase simultaneously, you are looking at 2^24 attempt/s on a 7 bytes passphrase so you are left with 2^32 seconds worth of work to crack the passphrase, or about 130 years (unless I messed up somewhere).

Obviously this isn't as strong as the 128bits of actual security a 256bits EC offers, but I find it acceptable considering the economics of such attack.

If you are unsatisfied with this level of security, you can always use fragmented backups. In this case you can choose to mix and match unencrypted, SecurePrint encrypted and digital fragments to implement a stricter security model. An attacker would need a quorum of fragments to even attempt anything.
519  Bitcoin / Armory / Re: Does Armory ever expose unencrypted private keys to memory or hard drive? on: July 18, 2015, 09:25:06 PM
All crypto sensitive material goes through SecureBinaryData objects, which is C++ code, with it's memory explicitly mlock'd. That code is made available to Python through SWIG, but the actual memory is managed by code in the C++ shared library.
520  Bitcoin / Armory / Re: Is SecurePrint secure enough to make the paper wallet publicly available? on: July 18, 2015, 08:13:57 PM
https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L3455

def hardcodeCreateSecurePrintPassphrase(secret) -> this method derives the SecurePrint password from your root key
def hardcodeMask(secret, passphrase=None, ekey=None) -> encrypts your root key with the passphrase using AES256 CBC

The code is pretty straight forward, speaks for itself.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 102 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!