You are welcome! I try to follow the development closely, because lacking OP_CHECKLOCKTIMEVERIFY MercuryExchange doesn't work at the moment and all other decentralized exchange approaches are very complex, using proxy assets to trade etc.
And I agree that BCE is very promising.
BCE's design is just so simple - a broker for multi signature transactions in foreign blockchains!
If you try to read the thread from the start keep in mind that the initial funding was planned in a different way, by making BCE a 100% subsidiary company of Nu. That didn't work, was changed and finally lead to a successful funding.
The design document is not up-to-date as well.
The most important change is the total amount of created BKS (less than 200,000 compared to the initially planned hundreds of millions) along with an adjusted minimum amount of BKS for minting (down from 10,000 to 1).
Thanks for summarizing the whole story of BCE. It's a shame I arrived too late for the party (crowdfunding)... But it's just the beginning of this incredible "decentralized autonomous interexchange". |
|
|
|
Congratulations for this bounty challenge initiative! It's an important tool for future security improvements and a good way to get more code auditing. I'd suggest that you put half the prize in the brainwallet and expect contact from the winner. After that you can show and publish the cracker's brute-force technique and then the other half should be sent to him privately. *edited BTW here goes an interesting experiment: https://1209k.com/brainv2/ |
|
|
|
|
UPDATE #2 of year 2015.
The ranking calculation has been simplified.
Brainwallets are now compared only with Brainwallets and the same goes for Paper wallets.
P.s. Although the main feature will be considered (Paper wallet OR Brainwallet) in order to fill the list, warnings may apply when there are security issues found in multigenerators (Paper wallet + Brainwallet).
Multisignature projects have been removed until I find a good way to compare them.
"Client-side" and "Offline Use" criterions were incorporated to "Security".
Added "Inclusive Web Design" (IWD).
Added "Number of cryptocurrencies supported" (CCY).
Weight (for average purpose) is now 6 for security matters.
List updated and scores upgraded as well.
* Edited:
New "Miscellaneous and related projects" added --> Bitgen; brainflayer; Coinb.in & Multi-signature P2SH
New Paper wallet generators added --> WalletGenerator.net; Liteaddress.org & ethaddress.org
|
|
|
|
|
I'd like to suggest the creation of an .onion url for bitcointalk.org as an additional layer and a security measure against ddos attacks and (maybe) gov attacks (why not?).
I think that would be an interesting idea so the regular forum could suggest that all TOR users should use the onion address the same way blockchain.info does today.
The .onion link will also serve as an backup site.
P.s. I don't know the costs related to that possible implementation.
|
|
|
|
OUCH! Augur already exists and it's called groupgnosis.com. Now we learn you lose the stuff you bought if you don't use it! OMG. Augur could go down as the dumbest thing ever to have purchased. http://groupgnosis.com/ WTF, I've never heard about that GNOSIS project. Who is behind that project? I couldn't even find a Github repository about that. |
|
|
|
|
UPDATE #1 of year 2015.
The ranking calculation has been changed.
Brainwallets that don't support Salt have been penalized.
Brainwallets that support KDF get different points according to the type implemented.
Multigenerators (Brainwallets, paper wallets and multisig: all-in-one) get weighted so we can compare every generator easily and fairly.
Github numbers are now "square rooted".
List updated and scores upgraded as well.
New changes may apply soon...
Keep up the good work all developers and programmers!
|
|
|
|
Wait, you take a dictionary, even an English one (even better if you are a foreigner so you use a foreign dictionary, but lets assume you use and English one) and you choose 12 random words of 6+ letters (even 5 letter words are OK but just to make sure) and you will have a random password with 128 bit+ entropy which is very safe. Of course, you write it down on a piece of paper.
The problem is that average people don't know that's done like this correctly and they use famous phrases and other crap instead.
As shown by this thread, people aren't very good with random-ness. You should let the computer do this for you. People are terrible in choosing passwords for themselves, I know that. But I kind of got from this thread that all brainwallets are doomed since they can be cracked with this software which is just not true if you have a strong and random password. Concept of brainwallets works for NXT pretty well, OK they did have some hacks in the beginning, just because the users used famous phrases which you can look for with these kind of softwares very quickly and successfully. Now, when the users know what the strong password is and when they have option for client to choose it for them, brainwallets work well. I almost forgot that NXT is a brainwallet per se. I did some research some time ago but couldn't find how NXT hashes the passphrase which locks/unlocks the account. Does anyone here know about it? Is it just sha256(passphrase)? It can't be that easy... |
|
|
|
Tools like brainwallet.io and warpwallet are like giving clean needles to heroin addicts. Harm reduction. Heroin (brainwallet-like tools with user-generated passwords/passphrases) is bad, but we can at least make it slightly less bad...
Heorin, eh? That's pretty extreme. I'd say it's more like riding a motorcycle. Most people take caution and pay attention to their surroundings. But there's always those idiots who speed through traffic without wearing a helmet. Very extreme indeed. I see brainwallets with weak passwords/passphrases like a newcomer pilot that only had piloted tiny cessnas in his life and is gonna fly an airbus 380 for the first time without prior specific training. i.e. he doesn't know nothing about all the complexity surrounding that machine's operation. |
|
|
|
The same could be said about brainwallet.org. It would be wise for anyone who is using a brainwallet to download a copy of the website that they can run on an offline computer, and to store the files in case the site goes down. All of my source code can be found on GitHub, so even if brainwallet.io goes down, you can still access your funds. Additionally, there is nothing I am doing that you couldn't do on your own. Scrypt is a widely used key derivation function. I am taking the output of the scrypt function and feeding it into the "classic" brainwallet algorithm. If you'd like to see for yourself, use this online scrypt generator: http://kclnn.github.io/js-scrypt-async/test_scrypt_browser.htmlAnd type in a passphrase and salt (where the salt is your name, email, phone, and DoB combined with no spaces), with parameters N=262144, r=8, p=1, and # of bytes = 32. Then copy and paste the output into the brainwallet generator at https://bitaddress.org. You will arrive at the same private key. @unchi Is that "test_scrypt_browser" (js_scrypt_async) your project? That's an interesting (in-browser) implementation! |
|
|
|
Regarding KDFs, I would score them on a logarithmic scale based on spot instance cracking cost, and severely penalize anything that doesn't include a salt. I would be very surprised if someone made ASICs to try to crack Bitcoin keys generated via brainwallet or otherwise due to very large (well over a million dollars) one time costs. GPUs are likely, FPGAs may be difficult due to memory requirements.
Helpfulness of KDFs is also a little unusual because the public key computations themselves take a bit of work. For example, PBKDF2 with 64 rounds would only double the cracking cost vs a classic brainwallet.
I guess we'll adopt your approach in some way: "score them (KDFs) on a logarithmic scale based on spot instance cracking cost, and severely penalize anything that doesn't include a salt". I'll just need some time to think about a fair way in order to compare different types of KDFs (scrypt, bcrypt, PBKDF2) and their respective "spot instance cracking cost" or some estimation of those values. Any further suggestions? |
|
|
|
|
Unfortunately that brainwallet.org project seemed too malicious by leaving that "correct horse battery staple" phrase as standard without leaving any previous (and visible) warning.
|
|
|
|
For those of you complaining to people linking to my slides/blog posts about brainwallets - I'm currently testing support for brainwallet.io in brainflayer. My limited benchmarking gives an estimate of about 75k passphrases guessed per dollar on Amazon EC2 spot instances.
Congratulations for also researching and testing this tool. That's a positive effort and all community should benefit from it. |
|
|
|
With regard to the generators purses question. Where is the guarantee of key generation, the developer does not receive access to the private key?
In fact there's no guarantee at all. They're all free of warranty as you'll notice at their websites. As a pratical measure, the guarantee is the open-source code that is accessible to you to review it so that you can be assured that the app runs client-side only and is expected that you will be a smart guy that will run it offline in an air-gapped machine and will come up with VERY GOOD security measurements. Doing that way (respecting all security procedures), developer won't have access to your (offline) generated private keys. |
|
|
|
coinb.in is using the dangerously weak "classic" brainwallet algorithm. It also includes third party javascript which can do whatever it wants. Why is it rated so highly on security?
I PMed the author of coinb.in some days ago and I'm still waiting for some answers about that project. I also think that rating based on the number of KDFs combined does not make sense. You need to take the work factors into account.
Yes, in fact I thought it was awkward adding pts by combining KDFs types by the time I first generated the Table's 1st version (I was so asleep at that time lol). 1st idea: For brainwallets I guess I'll add some pts for using different types of KDF according to their resistance to ASIC and GPU attacks. Maybe something like: PBKDF2 = 20pts bcrypt = 30pts scrypt = 50pts 2nd idea: And maybe we could add some additional pts for some additonal KDF algo iteration and/or extra rounds (over those recommended by standards). P.s. for this one, I'll need some deeper research and estimate what are the standard numbers (of rounds/iterations of scrypt, bcrypt and PBKDF2) used to protect from brute-force attacks today and I'll estimate safer (higher) numbers considering the increase in brute-force attack strenght (GPU + ASIC) in the next (at least) 5 to 10 years. (BTW Do you have any numbers - for scrypt, bcrypt and PBKDF2 - in mind?) The list is gonna change soon to reflect those changes... Thanks for your comments, I really appreciate it. |
|
|
|
|
@masterOfDisarter
Thanks for the reply.
It looks promising.
|
|
|
|
Yes, both use KDF as an additional layer of security against brute-force attacks. For more alternatives read my list (at my foot signature). |
|
|
|
|
Nice project. Gonna follow this thread.
BTW Are there any milestones or estimated time of launching some concrete alpha/beta implementation of B&C Exchange?
|
|
|
|
When will this coin list on exchange, is there any plan?
REP is not really a coin. But I guess it's gonna be listed in coinmarkecap in the future as some kind of "asset". I don't even know if it's gonna work in a (centralized) exchange. Reason: if you don't use it (report bets) you lose it (to other active users who do). But sure it could possibly be traded in a decentralized exchange on top of ethereum in the future. Source: http://www.augur.net/blog/what-is-reputation |
|
|
|
@unchi
Suggestion: show the generated private key also in compressed format.
You can get the code from bitaddress.org
This would be easy to implement, but I'm not sure if there would be enough demand for it. I prefer to keep the website as simple as possible to avoid confusion. What's the general consensus on this? I guess it would be more like an add-on to your project. Not an issue at all... Some discussions about that: https://bitcointalk.org/index.php?topic=129652.0 |
|
|
|
⚠️ WARNING ⚠️ YOU MUST READ THIS BEFORE MESSING WITH BRAINWALLETS! ⚠️ About passwords: DO NOT use obsolete methods (weak passwords) for wallet protection. Spend some time educating yourself about Password/Passphrase strength, Entropy as a measure of password strength and the importance of randomness when generating passphrases. Due to brute-force attack unstopable and increasing power & Moore's law, simple password protection is getting obsolete. Remember: you're your own bank, apply some pro-security mesures to protect your coins. Info: http://blog.codinghorror.com/passwords-vs-pass-phrases/ & https://www.random.org/⚠️ About random passphrases: DO NOT create passphrases thinking that you (a human) can be naturally very random and generate good bits of entropy by your own will. Humans tend to be predictable in their behavior and in their actions (and reactions). Idioms and languages - which words are used most of the time as passphrases - are structured in a logical and sequential way. i.e. no randomness in any way. What I'm trying to explain here is that: "it's really a bad idea for people to come up with passphrases themselves". Suggestion: use Diceware. Use (at least) a group of twelve words. ⚠️ About brainwallets: DO NOT use brainwallets which run fast hash functions (MD5, SHA family etc.) in order to hash your passphrase and for key pair creation. Avoid them! They are widely recognized as insecure and vulnerable to GPU brute-force attacks! You'd better choose those versions that use more secure methods such as Salt + Key Derivation Function e.g. scrypt, bcrypt, PBKDF2 and Argon2. And if you're a newbie, don't use brainwallets at all! Just remain safe with your paper wallets. Further info: http://blog.codinghorror.com/speed-hashing/ & https://rya.nc/cracking_cryptocurrency_brainwallets.pdf⚠️ About change addresses: DO make sure you fully understand how change addresses work when dealing with brainwallets and paper wallets while spending your coins. When used correctly, change addresses help increasing privacy of cryptocurrencies. But also with this capability comes the potential for loss and theft when its use isn't completely understood. "To avoid potentially costly mistakes, familiarize yourself with change addresses and how your wallet software implements them". Beware while importing your single address' private key on different wallet softwares: "wallet developers can implement this feature in a number of ways". "Learn how to prevent and Recover from Change Address Disasters" reading this excellent article: http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses⚠️ About use of applications: DO NOT generate wallets neither addresses when conected to the Internet. Download the app, review the code, check the file's hashsum in order to verify it's the original file, only work with it in an air-gapped machine (use a Live Operating System) and never touch the net while doing it. Before sending funds to an address, it is recommended that you first check for compatibility of addresses generated by those apps by importing some of their private keys into the official (and most popular unofficial too) client. This can be done most of the time through the debug console using the "importprivkey" command. If you are able to successfully import keys, the tested generator/app is compatible. ⚠️ About security paranoia: DO NOT consider yourself an InfoSec expert. If you think your coins are safe because you have an "ultimate unbreakable encryption scheme", you'd better think twice: https://xkcd.com/538/ |
|
|
|
|
Show Posts
