.

[ghdp]

.

[1713556891]

1713556891

[1713556891]

1713556891

[1713556891]

1713556891

[1713556891]

1713556891

[goatpig]

Original seed is 256bits. If you know some Python it's rather easy:

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L1914

You can use that call to convert 128bits of entropy to an Armory backup string. Do it twice and you have created you own root key that you can then plug in the restore wallet function to create a wallet file out of it.

[goatpig]

You're on the right track so far.

There isn't a public seed per say. Address N+1 public and private components are derived from address N and a scalar which is created by hashing address N's public key and the chaincode.

The chaincode is an HMAC of the root key:

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L2941

You can read the derivation code here:

https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/EncryptionUtils.cpp#L681
https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/EncryptionUtils.cpp#L757

[etotheipi]

My recommendation is to use a deck of cards.  Shuffle it to your heart's content, then type in the order of the cards into a string, such as "Ah9d3s3h...".  Hash that and use the resulting 32 bytes as your seed.  You can use armoryengine to do the conversions:  hash256() to hash the string, and "makeSixteenBytesEasy()" to convert each half of the string to a line that can be entered into the wallet restore window.

The order of a deck of cards has 225 bits of entropy, which is plenty big enough.  I tried the dice thing before, but it's a lot of dice rolls and it makes a lot of noise.  The deck of cards is much more pleasant

[TimS]

My recommendation is to use a deck of cards.  Shuffle it to your heart's content, then type in the order of the cards into a string, such as "Ah9d3s3h...".  Hash that and use the resulting 32 bytes as your seed.  You can use armoryengine to do the conversions:  hash256() to hash the string, and "makeSixteenBytesEasy()" to convert each half of the string to a line that can be entered into the wallet restore window.

The order of a deck of cards has 225 bits of entropy, which is plenty big enough.  I tried the dice thing before, but it's a lot of dice rolls and it makes a lot of noise.  The deck of cards is much more pleasant

(highly scientific statement here ) Sometimes when I shuffle a deck, the cards are too similar to the original.
Dice sounds like a better method to me if you want a great real-world entropy source (and you have the time to spare), especially if you're not experienced at shuffling cards well.

[etotheipi]

You don't have to be good at shuffling:  just play 52-card pickup with yourself   Or less chaotic, just put all the cards on the floor or table and swirl them around for 60 seconds then put them back together.  The ordering of a deck of cards has 225 bits of entropy which is technically overkill anyway:  128 bits is generally accepted as forever-secure.  You'd have to be trying hard to "cheat" to end up with less.

Alternatively, you can roll a 6-sided die 50 times to get approximately 128 bits of entropy.  I'd recommend doing 160 to be safe, but 128 really is sufficient (technically a 256-bit private key has about 128 bits of entropy, anyway).

[goatpig]

I flip burgers for real life entropy. If the burger falls out of the pan, it counts as a 0, otherwise it's a 1. Each burger can only be flipped once. It maybe long and noisy, but it's delicious!

[TimS]

I made a few tests this morning : with 5 dices it takes less than five minutes to generate a 256 bits key. And not so much noise.
The disturbing thing is that the dices don't "look" random. I can see a lot of "patterns" in them : 23423 23451 ...
I think it's my imagination...

It's (almost definitely) your imagination. Humans are great at seeing patterns in random data, even when it's just that: random. Compare your data to a true-randomness-generated list at http://www.random.org/dice/?num=50 (this site has high quality true random numbers, not pseudo-random, but it's not a secure thing, so don't try to use it for your crypto/private key)

Is there any test to make on the root key before using it ?
Are some of them bad/weak ?

To the best of my knowledge, the only weak keys are ones whose addresses happen to correspond to ones with easily-guessed private keys. (e.g. because the private key is 0x000...0002, or comes from a brainwallet passphrase "duck", or from a poor PRNG) The probability of you hitting one of these accidentally is so small it's not practical to worry about it.

[fallinglantern]

The disturbing thing is that the dices don't "look" random. I can see a lot of "patterns" in them : 23423 23451 ...

True random numbers often look off. Additionally, cheap dice typically aren't evenly distributed because the actual dimples cut out will create a weight imbalance which biases higher numbers. You can measure this by doing a few hundred rolls and drawing a histogram.

Since we're on the topic of using dice for generating encryption keys, you may find this interesting reading: http://world.std.com/~reinhold/diceware.html

[CoinRocka]

What percentage of Armory users use dice/cards versus trusting the developer?

[etotheipi]

The question is not to trust or not trust the developers.
The question is how to remove the need for trust, not only in the developers, but also on the hardware.

A bad PRNG may come from :
- bad hardware, or badly used hardware (a fully offline computer gathers little entropy)
- mistakes in implementations

The first step was to generate a wallet without relying on any PRNG by using real dices. I consider this step done.
I am still relying on the official armory code to convert the "paper backup format" into a functional wallet (full wallet + watch only wallet).

The next step should be to generate the watch only wallet using only easily auditable code.

Armory has a backup tester specifically for this.  Technically, it does exactly what Armory would do when restoring a wallet from backup, but some people won't trust it unless they actually restore the wallet.  So either use the backup tester, or create the wallet you plan to use, create your single/fragmented backup and then wipe everything and restore it on a fresh version of Armory.  For the watch-only wallet, you can generate the first X addresses on the offline/full wallet, and then import the watch-only wallet to the online computer and verify it generates the same X addresses.  Technically, you only need 2 addresses since the equation is the same for generating subsequent addresses, but again people won't trust it unless they see it work a dozen times.  Compare 1,000 addresses if you have the patience to do so.

[etotheipi]

Armory has a backup tester specifically for this.  Technically, it does exactly what Armory would do when restoring a wallet from backup, but some people won't trust it unless they actually restore the wallet.  So either use the backup tester, or create the wallet you plan to use, create your single/fragmented backup and then wipe everything and restore it on a fresh version of Armory.  For the watch-only wallet, you can generate the first X addresses on the offline/full wallet, and then import the watch-only wallet to the online computer and verify it generates the same X addresses.  Technically, you only need 2 addresses since the equation is the same for generating subsequent addresses, but again people won't trust it unless they see it work a dozen times.  Compare 1,000 addresses if you have the patience to do so.

I do "trust" that Armory works. And I did that (comparing addresses generated on the online vs offline computer).

What I don't know (and I don't want to fully "trust" you on this) is :
- how are the public keys calculated,
- what exactly is stored inside the watch only wallet file.

I admit I do not currently fully understand the part of the source code you pointed above. So I must do my homework and when I will be able to generate the watch only wallet myself I will be fully happy.

The logic is in EncryptionUtils::ComputeChainedPrivateKey and EncryptionUtils::ComputeChainedPublicKey.

Simply put, publicKey(i+1) is computed from publicKey(i) using:

Code:

multiplier(i) = hash256(PubKey(i)) XOR chaincode
PubKey(i+1) = PubKey(i) * multiplier(i)

[etotheipi]

I admit I do not currently fully understand the part of the source code you pointed above. So I must do my homework and when I will be able to generate the watch only wallet myself I will be fully happy.

The logic is in EncryptionUtils::ComputeChainedPrivateKey and EncryptionUtils::ComputeChainedPublicKey.

Simply put, publicKey(i+1) is computed from publicKey(i) using:

Code:

multiplier(i) = hash256(PubKey(i)) XOR chaincode
PubKey(i+1) = PubKey(i) * multiplier(i)

Yep, that's what I do not (yet) fully understand :
- how from a "Root Key" (the one on the paper backup) I get PrivKey(0) and Pubkey(0) (with what knowledge of PrivKey(0) ?)
- what information is stored in the watch only wallet
- and why it is secure to calculate the pubkey chain this way

You're walking down the math-heavy path of elliptic curve calculations.   It is described dozens of times elsewhere throughout the forum.  Look up "Type 2 deterministic wallets" originally conceived by gmaxwell. The watch-only wallet is an exact copy of the regular wallet without any private key data.  If you are uncomfortable, you can manually inspect the binary file and confirm that the private key fields are all 0x00 bytes.  

I forgot to mention above that the private keys are computed the same way.  I should've had.

Code:

multiplier(i) = hash256(PubKey(i)) XOR chaincode
PubKey(i+1) = PubKey(i) * multiplier(i)
PrivKey(i+1) = PrivKey(i) * multiplier(i)

Yes, you can derive the same chain of public keys using only the root public key, as the private keys derived the same way from the root private key.  This is the basic math behind "Type 2 deterministic" wallets and the basis for HD Wallets/BIP32 which is in-process of being adopted by all major wallets.  Armory and Electrum both demonstrated the power of type2 det wallets and have used them for years.  Now everyone else will be, too (however, Armory's deterministic wallets use a different type2 algorithm that I created before BIP32 existed, but it still has all the same security and privacy properties)

[Nyterax]

Has it been considered to use a bunch of human mouse movements as seed, like TrueCrypt did?

[etotheipi]

Has it been considered to use a bunch of human mouse movements as seed, like TrueCrypt did?

Armory already collects real world entropy, including mouse movements, clicks, key presses, and hashes of system files, when creating the wallet.  It bundles in that extra entropy with the Crypto++ RNG.  That extra entropy alone should be well in excess of 256 bits.

[Nyterax]

Has it been considered to use a bunch of human mouse movements as seed, like TrueCrypt did?

Armory already collects real world entropy, including mouse movements, clicks, key presses, and hashes of system files, when creating the wallet.  It bundles in that extra entropy with the Crypto++ RNG.  That extra entropy alone should be well in excess of 256 bits.

Oh, my bad. And then I fail to see how could that not be enough in any conceivable case.

[Perlover]

Code:

multiplier(i) = hash256(PubKey(i)) XOR chaincode
PubKey(i+1) = PubKey(i) * multiplier(i)

As i understand if anybody knows my "i+1" public address and "i" address he can easy calculate chaincode?
Yes?
And same chaincode used in for generation of next private key?
So if anybody will define (i don't how it's gypotetical question) private key i+100, and he knows "i+1" and "i" public keys (for example i am shop and one customer bought 2 orders: one order -> two order and after he knows my chaincode?) he will know next private key and so on?
May be here is some vulnarabilities?

[Perlover]

Sorry, my mistake may be
I see now that multiplier is EC function.
I don't know how it works but now i think if anybody knows publicAddress(i+1) and publicAddress(i) he cannot find chaincode?

[Perlover]

Has it been considered to use a bunch of human mouse movements as seed, like TrueCrypt did?

Armory already collects real world entropy, including mouse movements, clicks, key presses, and hashes of system files, when creating the wallet.  It bundles in that extra entropy with the Crypto++ RNG.  That extra entropy alone should be well in excess of 256 bits.

One question please: data are collected in moment only when i press button "Create" or before?
I don't see any messages like "To move mouse, to press some keys" and don't understand where start and end time for real world  entropy?

[etotheipi]

Has it been considered to use a bunch of human mouse movements as seed, like TrueCrypt did?

Armory already collects real world entropy, including mouse movements, clicks, key presses, and hashes of system files, when creating the wallet.  It bundles in that extra entropy with the Crypto++ RNG.  That extra entropy alone should be well in excess of 256 bits.

One question please: data are collected in moment only when i press button "Create" or before?
I don't see any messages like "To move mouse, to press some keys" and don't understand where start and end time for real world  entropy?

It's collected in the background as you go through the create-wallet process.  Only 32-bytes of entropy is needed, and the whole process collects far more than that, so there's no need to explicitly request the user do stuff.  Though, from a marketing perspective, it's probably better to make the user aware that it's happening.