Jan (OP)
Legendary
Offline
Activity: 1043
Merit: 1002
|
|
March 03, 2014, 03:55:41 PM |
|
Security question here: I store my backup online, but the 15 character password locally. If someone were to get ahold of my encrypted backup, how quickly could they bruteforce it? With 26 characters to choose from, there is 26^15 possibilities, but how long does it take to test each one?
About 1 million years if they use 1 million of today's desktop computers to brute force it. More info here: http://www.mycelium.com/wallet/FAQ.html#q020http://www.mycelium.com/wallet/FAQ.html#q021
|
Mycelium let's you hold your private keys private.
|
|
|
apetersson
|
|
March 03, 2014, 04:17:18 PM |
|
Security question here: I store my backup online, but the 15 character password locally. If someone were to get ahold of my encrypted backup, how quickly could they bruteforce it? With 26 characters to choose from, there is 26^15 possibilities, but how long does it take to test each one?
I just measured it using this program: @Test @Ignore public void testSpeed() throws InterruptedException { long start = System.currentTimeMillis(); int tries = 1000; for (int i = 0; i < tries; i++) { KdfParameters params = new KdfParameters("123" + i, TEST_SALT_1, MrdExport.V1.DEFAULT_SCRYPT_N, MrdExport.V1.DEFAULT_SCRYPT_R, MrdExport.V1.DEFAULT_SCRYPT_P); EncryptionParameters.generate(params); }
double duration = (System.currentTimeMillis() - start)/1000.0; System.out.println("duration:" + duration+" s"); double speed = (double) tries / duration; double secondperTry = 1/speed;
System.out.println("secondperTry "+ secondperTry+" / s "); } output: duration:104.771 s secondperTry 0.10477099999999999 / s i ran it with -server VM in sun JDK so it does about 10 tries/second under near-optimal conditions on a fast CPU. (i7 4770K) in single-thread mode, with JIT compiler. this means a single core takes 390 times the age of the universe to crack a single backup. when you speed that up to graphics cards, asics if becomes shorter but still outside human lifespans.
|
|
|
|
RGBKey
|
|
March 03, 2014, 04:26:05 PM |
|
That's good, I never considered how much security 15 Alphabetic characters could give. Thanks for testing that.
|
|
|
|
Jan (OP)
Legendary
Offline
Activity: 1043
Merit: 1002
|
|
March 03, 2014, 04:30:35 PM |
|
That's good, I never considered how much security 15 Alphabetic characters could give. Thanks for testing that.
Nore that this is not a generic result that can be applied anywhere. It requires that the password is random (read not human generated) and scrypt (or something similar) is applied.
|
Mycelium let's you hold your private keys private.
|
|
|
RGBKey
|
|
March 03, 2014, 05:13:55 PM |
|
That's good, I never considered how much security 15 Alphabetic characters could give. Thanks for testing that.
Nore that this is not a generic result that can be applied anywhere. It requires that the password is random (read not human generated) and scrypt (or something similar) is applied. Of course, that's pretty obvious. Have some faith in me
|
|
|
|
(A)social
|
|
March 03, 2014, 05:50:17 PM |
|
That's good, I never considered how much security 15 Alphabetic characters could give. Thanks for testing that.
Nore that this is not a generic result that can be applied anywhere. It requires that the password is random (read not human generated) and scrypt (or something similar) is applied. What about cat generated passwords? I'd trust my little fellow* more than any human *no, it isn't that in the pic
|
|
|
|
RGBKey
|
|
March 03, 2014, 06:16:57 PM |
|
That's good, I never considered how much security 15 Alphabetic characters could give. Thanks for testing that.
Nore that this is not a generic result that can be applied anywhere. It requires that the password is random (read not human generated) and scrypt (or something similar) is applied. What about cat generated passwords? I'd trust my little fellow* more than any human *no, it isn't that in the pic Imagine a die like a magic 8 ball, except the die is a cube, and on each side there is a seperate container for a magic 8 ball type liquid filled chamber with another die inside of it, making a 36 sided die.
|
|
|
|
IamNotSure
|
|
March 03, 2014, 07:26:31 PM |
|
Would it be considered "unsafe" to test a cold wallet address (properly generated, live USB, BIP 38, dumb printer etc.) with the Mycelium cold storage spending function. All this on a dumb smartphone (factory reset, not connected to GSM network, just connected to wpa2 secure wifi to D/L mycelium to make the test spend)
Or should I be more paranoid and this address should be considered not "cold" anymore by having touched breifly the network? And using Armory is the only solution ?
|
|
|
|
apetersson
|
|
March 04, 2014, 10:29:03 AM |
|
Would it be considered "unsafe" to test a cold wallet address (properly generated, live USB, BIP 38, dumb printer etc.) with the Mycelium cold storage spending function. All this on a dumb smartphone (factory reset, not connected to GSM network, just connected to wpa2 secure wifi to D/L mycelium to make the test spend)
Or should I be more paranoid and this address should be considered not "cold" anymore by having touched breifly the network? And using Armory is the only solution ?
that depends on your paranoia level. i'd say it is cold enough. since i don't know anything about root exploits of that dumb smartphone, be sure to ONLY install mycelium.
|
|
|
|
soullyG
|
|
March 06, 2014, 10:59:37 AM |
|
I see the latest version dropped the "Avg." pricing info. Would it be a big thing to bring it back?
I'd also like to see this feature brought back, and if possible, add the ability to customize which of the exchanges count towards this average. Also, are there any plans to add multi-send to the wallet? Thanks for all your hard work, Mycelium makes it a pleasure to use Bitcoin - you guys are on the forefront of wallet software development - never stop innovating!
|
|
|
|
Jan (OP)
Legendary
Offline
Activity: 1043
Merit: 1002
|
|
March 07, 2014, 07:54:07 AM |
|
I see the latest version dropped the "Avg." pricing info. Would it be a big thing to bring it back?
I'd also like to see this feature brought back, and if possible, add the ability to customize which of the exchanges count towards this average. Also, are there any plans to add multi-send to the wallet? Thanks for all your hard work, Mycelium makes it a pleasure to use Bitcoin - you guys are on the forefront of wallet software development - never stop innovating! Thanks. We have started adding rates from sources that are not actual exchanges such as Coinbase and BitPay. Many users have requested this as it allows them to see what their coins are worth when buying at for instance Coinbase or spending at a BitPay enabled merchant. Since these sources do not have a volume associated we cannot really calculate a weighted average. In the testnet version (released 2 days ago) we have added BitcoinAverage. They make a business out of monitoring and selecting relevant exchange sources, and we believe that they track the markets closer than the Mycelium developers. The default choice is right now Bitstamp, and it is up to the user to select a source that he/she finds valuable and trustworthy.
|
Mycelium let's you hold your private keys private.
|
|
|
bitcoincodes
Newbie
Offline
Activity: 35
Merit: 0
|
|
March 08, 2014, 03:43:14 PM |
|
It would be really nice if the user could set the tx fee to 0 or lower than 0.0001. For most Transactions 0.00001 or 0.000001 BTC fee would be enough. So it would be nice to set the fee at the users own wishes.
BTW: I really like the App.. especially the function to spend btc directly from a cold / paper wallet.. good job guys.
|
|
|
|
Rassah
Moderator
Legendary
Offline
Activity: 1680
Merit: 1035
|
|
March 08, 2014, 04:13:32 PM |
|
It would be really nice if the user could set the tx fee to 0 or lower than 0.0001. For most Transactions 0.00001 or 0.000001 BTC fee would be enough. So it would be nice to set the fee at the users own wishes.
BTW: I really like the App.. especially the function to spend btc directly from a cold / paper wallet.. good job guys.
Right now the fee in default Bitcoin-QT nodes is hardcoded to 0.0001BTC, so setting it lower runs the risk of your transaction not being broadcast. We will lower the fee once 0.9 comes out, which will drop the fee further.
|
|
|
|
ffe
|
|
March 08, 2014, 09:08:16 PM |
|
I've run into a situation where Mycelium was monitoring two public keys - one the compressed version of the other. It showed a positive balance for the the compressed public key and a zero balance for the normal public key.
I loaded the private key to see if it was required for Mycelium to recognize that the two public keys are for the same private key, but it simply attached it to the compressed public key. The uncompressed one remained observer only (no private key associated) and still with a zero balance.
Questions: - Is it mathematically possible to calculate the compressed public key from the uncompressed one (and visa-versa) in the absence of the private key? (I assume if you have the private key they can theoretically be associated since you can calculate each from the private key.)
- Is it possible to make one of the two forms the canonical form internally so that loading either into Mycelium causes the correct private key's balance to be tracked?
Background: I ended up with a compressed version of the public key when I loaded a BIP38 protected key into the app on a dedicated device separate from my phone. I then transferred some coin to it. I had been monitoring the full public key on my regular phone and it failed to show the new balance. I then loaded the compressed key to my phone and ended up with the situation described.
|
|
|
|
witwit
Newbie
Offline
Activity: 1
Merit: 0
|
|
March 09, 2014, 09:28:18 AM |
|
Right now the fee in default Bitcoin-QT nodes is hardcoded to 0.0001BTC, so setting it lower runs the risk of your transaction not being broadcast. We will lower the fee once 0.9 comes out, which will drop the fee further.
I would personally love the ability to set your own fee, since this can be done safely if you know what you are doing (txn priority and so forth). I would definitely hide it behind an "expert" mode, though.
|
|
|
|
cetus
Newbie
Offline
Activity: 22
Merit: 0
|
|
March 09, 2014, 02:58:49 PM Last edit: March 09, 2014, 07:03:28 PM by cetus |
|
I've run into a situation where Mycelium was monitoring two public keys - one the compressed version of the other. It showed a positive balance for the the compressed public key and a zero balance for the normal public key.
Compressed and uncompressed form of the same public key correspond to different Bitcoin addresses. They have individual balances and behave like independent addresses. They just happen to have the same private key which can be used to spend coins from each of them. I loaded the private key to see if it was required for Mycelium to recognize that the two public keys are for the same private key, but it simply attached it to the compressed public key. The uncompressed one remained observer only (no private key associated) and still with a zero balance.
Private key representations usually include a flag to indicate whether the key is meant to be used with a compressed public key or uncompressed one. I believe if you set that flag to 'uncompressed', Mycelium will attach it to the other address. Questions: - Is it mathematically possible to calculate the compressed public key from the uncompressed one (and visa-versa) in the absence of the private key? (I assume if you have the private key they can theoretically be associated since you can calculate each from the private key.)
Yes. - Is it possible to make one of the two forms the canonical form internally so that loading either into Mycelium causes the correct private key's balance to be tracked?
I don't think there is such a thing as a "private key's balance". If you want to use both compressed and uncompressed public keys, I think you can load your private key twice with different flags and Mycelium should do the right thing then. Mathematically these private keys are identical, but logically they are different. Background: I ended up with a compressed version of the public key when I loaded a BIP38 protected key into the app on a dedicated device separate from my phone. I then transferred some coin to it. I had been monitoring the full public key on my regular phone and it failed to show the new balance. I then loaded the compressed key to my phone and ended up with the situation described.
I don't know BIP38, unfortunately. The SIPA format for private keys includes the compression flag. It was either the loss of information (flag) during private key transfer to the dedicated device, or a failure of the app on that device to interpret that flag correctly, that created such situation.
|
|
|
|
ffe
|
|
March 09, 2014, 04:17:49 PM |
|
Thanks for the clarification. Much appreciated!
|
|
|
|
Bees Brothers
|
|
March 10, 2014, 04:27:28 PM |
|
Thank you Rassah for taking the time at the Texas Conference to sit down with us and answer several questions about using Mycelium.
We will be doing some small workshops in our town for small businesses about using bitcoin and the time spent with you was very helpful.
|
|
|
|
roslinpl
Legendary
Offline
Activity: 2212
Merit: 1199
|
|
March 10, 2014, 09:23:02 PM |
|
Thank you Rassah for taking the time at the Texas Conference to sit down with us and answer several questions about using Mycelium.
We will be doing some small workshops in our town for small businesses about using bitcoin and the time spent with you was very helpful.
Did you record him on a camera? It would be nice to see what he was telling to you. regards!
|
|
|
|
RGBKey
|
|
March 13, 2014, 03:06:20 AM |
|
Is Mycelium ready for the changes coming with 0.90? I expect we should have support for lower fees cery soon after official release and support for payment requests later on?
|
|
|
|
|