^ I just caught the Star Wars quote  That's a really good one! Yeah, sorry if it seemed too harsh, I really should have added a smiley... I hope you don't find my lack of smileys disturbing. |
|
|
|
|
Well, I've got some feedback if you'd care for any...
1. It's not obvious that "encryption" automatically deletes the just-encrypted file.
2. The deletion of the original file is not a secure delete. Because there's no way to inhibit the deletion, the just-encrypted data is guaranteed to still be present on the hard drive.
3. The deletion of the original file fails on Windows (because you don't close the file first).
4. If the "out" file already exists, "encryption" mode is assumed, and file.x and file.y are silently overwritten if they exist.
5. The "key", which additionally "encrypts" the file, is naively implemented and does not add any additional protection. Your statement that the two files can be "stored in separate secure locations--which is unnecessary" is inaccurate; the key feature leads to a false sense of security and should be removed entirely or re-implemented.
Finally, I'm not entirely clear what advantage this scheme has over creating two files using well-established cryptography, one with the ciphertext and one with a passphrase, and storing them apart from each other.
I'm sorry for being harsh, it's not my intention to be mean or discouraging. The fact that you're releasing this open source indicates a willingness for peer review, and that mentality should be applauded. However, it's almost always a bad idea to try to implement cryptography yourself unless you're a cryptographer (I'm not one, and I'd certainly hesitate to do so myself). Even just using existing well-written crypto libraries can be very hard to get right....
Best of luck!
|
|
|
|
No arguments here when it comes to being able to mine in a pool without having to sell your vote, that's definitely a topic that doesn't get the attention it deserves. |
|
|
|
BTW I don't think Bitcoin is undefeatable, you can always destroy it by 51% attack. And that's why I think it is amazing: you can choose.
There are solutions for the 51% attack situation. When the fix needs to be implimented it will be. Gavin and others have had the solution ready for awhile now. The whole 51% thing just makes good press, it's all about selling fear, thats why you never hear that a 51% attack would be noticed immediately and the fix would shut the attack down almost immediately making all the attackers blocks invalid. To the normal citizen Bitcoin user it would be a small "hiccup" and banks have big "hiccups" all the time and no one really complains. Banks even close on the weekends and are getting hacked/fraud/ID thefts daily. I don't know where you get your delusions, laser brain. That refers to a specific stop-all-or-nearly-all-the-transactions attack, however a stop-some-but-not-all-transactions attack, or enough double-spend attacks would probably work just as well in crashing the market if it went on for long enough. Edited to add: He also mentioned in that same blog post that someone willing to spend enough money could continue to pull off a stop-all-or-nearly-all-the-transactions attack even with the countermeasure in place. |
|
|
|
BTW I don't think Bitcoin is undefeatable, you can always destroy it by 51% attack. And that's why I think it is amazing: you can choose.
There are solutions for the 51% attack situation. When the fix needs to be implimented it will be. Gavin and others have had the solution ready for awhile now. The whole 51% thing just makes good press, it's all about selling fear, thats why you never hear that a 51% attack would be noticed immediately and the fix would shut the attack down almost immediately making all the attackers blocks invalid. To the normal citizen Bitcoin user it would be a small "hiccup" and banks have big "hiccups" all the time and no one really complains. Banks even close on the weekends and are getting hacked/fraud/ID thefts daily. I don't know where you get your delusions, laser brain. |
|
|
|
...
What I can't understand is the need for all of the extra operations (initial shuffle, cutting the deck, factoradics, etc.) over what I think is a much simpler scheme:
- Server computes server_seed and shares hash(server_seed) with the client
- Client computes client_seed and shares it with the server
- Server uses (server_seed + client_seed) as the seed for a PRNG
- Server generates N random variables required for the result of the game (cards, numbers, slot positions, etc.) with the PRNG. For games that require unique values (card games), we keep generating until they are all unique.
- Share the game results (random variables) and server_seed with the client, who can run the same deterministic PRNG with (server_seed + client_seed) to obtain the same N random variables and ensure the game is indeed fair.
I simply might have misunderstood some fundamental need behind all of the extra complication. The only downside I can think of with this approach is the situation where we need unique random variables (like card games). The idea here is not to compute the full deck, since that is never needed (maximum number of cards that can occur in a game of single-deck blackjack, for example, is <25). Yes, a few collisions might happen while generating uniques, but PRNGs are very efficient and deterministic (so they don't use up the precious entropy), so that shouldn't be a problem.
...
The fair shuffling article you mentioned actually explains why, but you may have missed it. PRNGs are typically seeded with either 32 or 64 bit numbers. Let's say we choose a PRNG that has a 64-bit seed (the article went with one using a 32-bit seed). That means it has about 1.8 × 10^19 different starting points, so at most that many different combinations of hands can be dealt. Single-player blackjack, assuming an 8-deck shoe (very common) and a 4-hand split limit (also common), can consume at least 68 cards (that's the best I could figure, anyways). Producing 68 choices from an 8-deck shoe yields 1.5 × 10^79 different combinations (around 15% the count of atoms in the visible universe Wolfram|Alpha tells me) edited because that's all wrong, it's closer to, but larger than 2.7 × 10^114 different permutations (20ish million billion billion billion times the count of atoms in the visible universe). This analysis isn't entirely fair, because many of those combinations would never be chosen when hands bust early, but suffice it to say that if you start with only a 64-bit seed, you are immediately eliminating the the ability to generate the vast majority of possible combinations. Their solution was: (1) server shuffles first, using a long-running CSPRNG that does not have this limitation, and then (2) we both identically shuffle the result, using a simpler PRNG with a smallish seed. Edited to add: if you're using a 32-bit seed, as they were in the article, it's also more likely than it should be that you deal the exact same hand multiple times. Regarding your random card selection algorithm, I'd suggest that read up on the Fisher-Yates shuffling algorithm instead. It's actually a bit faster than your proposed algorithm (because it never has "collisions"), and like yours it does not need to shuffle the entire deck if it's not required (although it's much faster to do so if desired). I suspect that a gambling site would prefer to go ahead and shuffle the entire deck anyways just because it would appear more transparent to the average user even if it's not really necessary. Does this answer some of your questions? Also, to Tetraplay Casino: congratulations on being the very first user I've ever added to my ignore list. Your obnoxious off-topic 100% spam response fully qualifies you for this honor, thanks. I happily see that the mods have nuked said spam, thanks! |
|
|
|
Surprisingly not a bad article, thanks. In briefly describing the history of girls (or rather of "no girls") on the Internet, it almost exactly parallels what we see today on Bitcointalk (and it's a good read for you young folk who've never heard of MUDs, MOOs, etc.) Unfortunately it looks like Bitcointalk has only reached the 4chan phase, a.k.a. the "TITS or GTFO" phase. Hopefully, as (and if) Bitcoin gains popularity, this forum will be able to drag itself into the new millennium (easier said than done, since scammers will always be here with us...) |
|
|
|
|
One thing not yet mentioned in this thread is the difference between per-transaction 2FA and logon-only 2FA.
Logon-only 2FA (such as supported by Blockchain.info) helps protect against password brute-forcing attacks. Unfortunately, it does practically nothing to help protect against malware.
Per-transaction 2FA (such as supported by GreenAddress.it and BitGo.com) means that each transaction that sends bitcoin out of your wallet must use a new 2FA code. This type of 2FA offers very effective protection against malware (although it's not necessarily perfect).
You should keep all this in mind when weighing your wallet options.
|
|
|
|
Any step-by-step guide how to double spend bitcoin?
I know I can't do this with my little hashpower but I'm just interested in understanding the theory behind this.
Thanks.
You don't really need any hashing power to attempt double spending. You just need to create two different transactions that both spend a particular tx output, and you broadcast both the two transactions to the network. Eventually one will get confirmed, and one will never get confirmed. But if you are talking about reverting a confirmed transaction and replacing it with another one, it will be a different story. There exist tools (such as the one here, although it's not intended for newbies: https://github.com/petertodd/replace-by-fee-tools) that will create double-spend transactions which may work some of the time. By "work", I only mean that it can "fool" recipients who choose not to wait for confirmations. (FYI many people don't consider the term "double-spend" to ever apply to 0-conf transactions...) |
|
|
|
|
I hadn't replied yet because I don't know an answer to your problem, and was hoping that someone else did.
I think that this should be very unlikely to ever happen. I think it means that a 48-byte encrypted private key was decrypted and had the correct 16 bytes of padding, but then the derived public key didn't match the public key stored in the wallet. This all seems very unlikely to happen unless the public key alone in the wallet file was corrupted. But if that were the case, I wouldn't expect your wallet balance to be correct, so I must be missing something here...
How many addresses are in your wallet?
Are you certain that all of the addresses displayed are correct?
Are any of the addresses in your wallet completely unused?
|
|
|
|
That's a great article, thanks. Of course, anything you can find on google (using quotation marks around the search term), you don't need to bother putting it in that tool. Contrary to other "password check" tools, zxcvbn at least makes mention of that by showing "pattern: dictionary".
Good points. I hope you're not suggesting that you should type your brainwallet into google to check its password strength....  |
|
|
|
Just a thought, but another possibility might be that the Linux out-of-memory killer was tripped. Many VPS providers don't create a swap file by default, which might be a cause of this (but be careful, creating a swap file might cost you $ depending on the provider and on where the swap file is created). |
|
|
|
Hypothetically speaking (I am absolutely not suggesting that anyone is doing this now) if I was a hacker it seems like a good way to steal bitcoins would be to write a little program, probably like the javascript above, but something faster, that for each pass phrase in those lists, generate an Armory wallet, check the first 20 or so addresses for any bitcoins.
People already do it for other brain wallets, so I don't see why it would be any different for Armory brain wallets. I use a shuffled deck of cards myself. Peel off the first 40 cards to generate my root key. Then 3 of 6 fragmented backup, test them out a few times on my offline device, and store them in separate places. Then I use my brain wallet pass phrase to protect my offline armory wallet. Good to go.
That sounds pretty good to me. Since it's no longer a brain wallet, there's no reason to call it a "brain wallet pass phrase", right? |
|
|
|
I do believe that in suggesting that (or any) entropy estimation tool, you just contradicted yourself... Entropy estimation tools such as the one mentioned can provide, at best, an upper bounds estimate, and therefore provide a false sense of security. They assume password crackers only use particular predetermined techniques when generating password guesses, however crackers are forever improving their techniques (furthermore these techniques are not necessarily public knowledge). The (nice, thanks for that) article you pointed to exactly demonstrates this. I took the first "difficult" password mentioned in the article (which has been successfully cracked using the described techniques), and plugged it into the estimation tool, and got this: password: Am i ever gonna see your face again?
entropy: 100.857
crack time (seconds): 1.1482519836189682e+26
crack time (display): centuries
score from 0 to 4: 4
calculation time (ms): 7
It seems awfully unlikely that the article's authors were able to crack a password with 101 bits of entropy, hence the estimate is a bad one. So, just to reiterate: estimating entropy is really hard... |
|
|
|
does this work on altcoins to?
Which "this" did you mean? Most of the methods in this thread will work on most altcoins which were originally based on Bitcoin software (and that's most, but not all, altcoins). So in short: probably, but it depends on the details... i've got a pandacoin (PND) wallet, i changed my password a few months ago. i mixed up one or two letters. i always write my passwords on paper and ceep them in a secret location  but this one i fucked up, at the time i didn't care to much as it was wirth only a few hundred usd. but atm its worth a lot nore then that.. im not a geek so im green when it comes to this kind of shit. i did a search for pandacoind put didn't find anything, so any help would be great tommy I'm not familiar with pandacoin, but here's the best advice I can give you. Basically, you'll need to create a test wallet with a known password, and test one of the password recovery techniques in this thread to make sure it succeeds, and then try your real wallet: - First and foremost, close the wallet software and then make a backup (or two!) of your wallet file.
- Rename your wallet file, and restart the wallet software.
- I'm presuming that a new wallet file is created during startup (which is common). If not, create a new wallet.
- Add a password to the new wallet.
- Find and install some software from this thread that can attempt to recover passwords from bitcoin wallets.
- Configure the software to check your known password against the newly created wallet from above, and see if it succeeds.
- Assuming it does, use this software against your backed-up wallet.
I realize it's a pain, so you might rather enlist the (paid) services of someone in the Services Discussion section. Maybe someone with pandacoin experience will reply, but until then, this is the best I can offer... |
|
|
|
Who is that?? Is that Conchita when she was a girl?  Let's just say that she has more to hide than it might first appear.... (google reverse image search is your friend ) |
|
|
|
Well, I should have read better! Since english is not my native language and there was a lot of text I did not read everything (yet) Also due to the fact I could not wait to begin testing Wait, you're not a native English speaker?? Your English is much better than many (most?) native speakers I've seen on this board... I'm trying to use a wordlist with JtR but I can't really get it to work. My hash file looks good, I extracted the hash from a blockchain.info wallet with the tool called blockchain2john. The password is something like house1tree2 I made a wordlist.txt ... Sorry, I actually don't know that much about JtR... but I think that the --wordlist option just takes the input file and uses each line as a single password, so nothing at all like btcrecover's token file. JtR can make all sorts of alterations to each line, but I don't know much about making JtR construct whole passwords the way btcrecover does. You can however use both programs together: you can run btcrecover with the --listpass option (and with no --wallet), and it will generate and output whole passwords to test, one per line, and then you can use JtR (with it's better cracking speed) to actually try the passwords. I imagine there's a way for JtR to accept passwords directly from it's stdin, so you could pipe the output of btcrecover directly to JtR, e.g. btcrecover.py --token tokens.txt --listpass | john --options... By the way, there is a small error in the code you gave earlier.
...
Oops, my mistake, thanks. |
|
|
|
, I mean if you know that the password contains "house" and "tree" and 2 or 5 other characters/numbers. Is it still possible to bruteforce through all these options?
Like
housetree11111
housetree11112
housetree11113
Sure, here's a token file: That third token becomes all combinations of numeric digits, between 2 and 5 digits long, and can appear in the beginning, end, or between the other two tokens. It's described here in the tutorial: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#expanding-wildcardsIf you'd like to restrict that wildcard token to the end, you'd use this: That "$" forces it to be at the end (if present at all, it doesn't make the token required in every try). That feature is described here: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#anchors |
|
|
|
So I got this up and running and was able to crack a zip file which I encrypted with a simple password.
I was amazed to see how quick the password was cracked.
First I had to extract the password hash from the encrypted zip file and then I had to do "./john zip.hash"
But how do I extract the password hash from the "wallet.aes.json"?
edit: now downloading bleeding version, I saw something about blockchain2john, might be it.
Yup, that's the one. I don't know if you've finished compiling the bleeding version yet, but it might be worth getting an OpenCL or Cuda version compiled and working, it runs around 8ish times faster than the CPU-only version (and FYI CPU-only JtR runs about 6 times faster than btcrecover with Python 2.7.8+). I also managed to have this tool up and running. I made myself a new blockchain wallet with a password like "house23tree1"
It took 30 seconds to crack the wallet. I made a token file with about 7 words and numbers.
Very nice tool if you know all contents of a password, but not exactly what came first and last.
As far as I can see I was not able to bruteforce any unknown characters. You really should put everything into the token file
What do you mean by "bruteforce any unknown characters"? |
|
|
|
And since "Two beer, or bottle of wine? That is the question of my silly brain." is (almost) grammatically correct and uses sensible punctuation, it has much lower entropy than one would expect. I *think* it is barely out of reach of a brute force search, but honestly I have no clue.
I agree it seems like a nice long passphrase, but this is exactly the problem. We humans (myself included of course) are really bad at estimating how much entropy something has by just looking at it, and we're just as bad creating things with lots of entropy using only our brains. If it turns out the passphrase was in fact good enough, you'll know in 10 or 20 years because your key was never stolen. If, on the other hand, you were wrong, your bitcoin could disappear at any time between now and then. If you're that worried about losing your paper backups, you can be nearly as paranoid as you want, e.g. print a 2-of-6 backup, and store them all in safety deposit boxes at different banks. (or how about just a standard/1-of-1 backup that you tattoo to a, uh, private area of your body? that should be hard to lose and, depending on your profession, hard to get stolen too ) |
|
|
|
|
Show Posts
