|
Please divert some mining power to namecoins. If people lend their miners there for just a few days, merged mining will be in effect. This means that both bitcoin and namecoin will be stronger. Afterwards, everyone will be able to earn both BTC and NMC with their miners and no additional work.
Save distributed DNS!
|
|
|
|
|
There is no legitimate reason for threatening namecoin. Even children understand that just because you can do something, that doesn't mean you should.
An attack like this shows nothing that we don't already know. Why not try to learn something that we don't know? For instance, let's see if merged mining really works on production chains. Why not put the hashing power towards something constructive? Show everyone that you're not a vandal - that you're bigger than that; mine namecoins and and get it up to the merging mark.
Make an internet with distributed currency and free DNS a reality.
|
|
|
|
I'm not the one claiming to have written a superior technique here. The burden of proof rests with the person making claims about his superior his method is compared to established methods. Also, the functions are already written in basically every language that matters. Look at how easy this is: $hash = bcrypt_hash({
key_nul => 1,
cost => 8,
salt => $salt,
}, $password);
Done. That particular problem is now solved, and you can go on to other issues. No need for algorithms of dubious efficacy written by anonymous authors. Also, don't take my word for it: https://bitcointalk.org/index.php?topic=17004.msg228724#msg228724Bcrypt effectively eliminates offline attacks. Iterative hashing does not. Again, I'm not the one who proved that. This has been well understood for many years. Time to use the right tools. Also worth noting explicitly, as this has come up: the question of obtaining the database is of course important, but it is a separate issue. |
|
|
|
Can you please stop talking "I'm smarter than you and I know better" bullshit and show me the difference between bcrypt() and my algo ?
Because sorry - there isn't any according to PHP manual.
Try harder. Maybe read primary references. EDIT2:
Investingating the matter further, actually it seems that my function far better than crypt(), as it uses different salt for each layer of hashing, where crypt() only uses single salt for all layers.
Cool. Now go write a paper and submit it, because you have just discovered something that dozens of security specialists over several decades couldn't. Or... maybe you missed something rather important and are letting your ego get the better of you. Sorry, but you're no Niels Provos. EDIT:
OK, i have had enough of this.
Only a fool uses the argument of power instead of power of arguments.
So you either show me the logical evidence that you are correct, or I will officially view you as a fool. I dare you.
Try reading and understanding what bcrypt actually does instead of assuming that you have trivially solved one of the most well-studied problems in computer security. |
|
|
|
This is what hashes were designed to do.
No. They are designed to quickly compute a mostly unique digest for a preimage. |
|
|
|
<whole lotta' bullshit>
Totally wrong. Basically, all of your "advice" is garbage. Some real programmers, please chime in. I am a programmer from 14 years, and FYI, i have written some stron cryptography myself from scratch. So stop talking bullshit. <whole lotta' bullshit>
Totally wrong. Basically, all of your "advice" is garbage. Some real programmers, please chime in. You should be using bcrypt(). Not whatever many rounds of hashing. Hashing is meant for huge amounts of data (such as files) and is meant to run fast - which means it can be bruteforced fast. By using bcrypt with a high work factor, logins take one second to process - and bruteforcing takes one second per hash as opposed to 10 billion hashes per second. Wait, just let me get something straight before i continue this discussion. If i generate a password hash using bcrypt with X rounds, and then i increase it to Y rounds, will both functions generate the same hash ? I mean is bcrypt(pwd, rounds = 10, salt) equal to bcrypt(pwd, rounds = 20, salt) ? Am I understanding this correctly ? id assume no, or else it would be pointless to increase round time. If no is the answer, then there is completely no advantage of using bcrypt versus multi hashes with multi salt as I have already written a recurrent function which does exactly the same as bcrypt(). You simply use the_hash_function($data, salt1, salt2, salt3, rounds) and basically what it does is it recurrently repeats hash_algo1(salt1 + hash_algo2(salt2 + hash_algo3(salt3 + data)))
, each time salting everything again. Once the hardware becomes more powerful, i can simply increase the number of rounds to Y. Glorious. Way to miss the point of this fundamental concept. |
|
|
|
<whole lotta' bullshit>
Totally wrong. Basically, all of your "advice" is garbage. Some real programmers, please chime in. I am a programmer from 14 years, and FYI, i have written from scratch strong cryptography algorithms myself. So please stop talking bullshit and let's have a real discussion other than " BCRYPT FTW, IF YOU DON'T THINK SO, STFU".
Scary... but doubtful. <whole lotta' bullshit>
Totally wrong. Basically, all of your "advice" is garbage. Some real programmers, please chime in. You should be using bcrypt(). Not whatever many rounds of hashing. Hashing is meant for huge amounts of data (such as files) and is meant to run fast - which means it can be bruteforced fast. By using bcrypt with a high work factor, logins take one second to process - and bruteforcing takes one second per hash as opposed to 10 billion hashes per second. Wait, just let me get something straight before i continue this discussion. If i generate a password hash using bcrypt with X rounds, and then i increase it to Y rounds, will both functions generate the same hash ? I mean is bcrypt(pwd, rounds = 10, salt) equal to bcrypt(pwd, rounds = 20, salt) ? Am I understanding this correctly ? No. Try reading the links. Also, bcrypt doesn't use "rounds" as a means to be slow. It has a slow key schedule. |
|
|
|
heres an idea that might sound crazy, but what if we all used secure passwords? sure hashing as some weaknesses, but it allows for you to log in fast, and if you use a good password and a salt you should be good, as i dont think any huge company handling huge volumes of traffic would use that algorithm, simply because they do not have the required amount of processing power to keep the passwords secure and a reasonable login time.
Wrong threat model. Read this link: http://codahale.com/how-to-safely-store-a-password/ |
|
|
|
Some real programmers, please chime in.
That must mean you are not a real programmer also and are nothing more than a parrot that can only repeat stuff without even understand what he's saying, right? I won't presume to call myself and expert in web programming, but I have experience in certain fields going back more than 10 years. At the very least, I do know how to protect a local password database. For those who refuse to read linked texts (lazy TL;DR crowd), let me quote a portion of it: To cut a long story short, hashing a hash N times doesn't make your passwords more secure and can actually make it less secure as a hacker can quite easily reverse the process by generating hash collisions.
[...]
It has already been mentioned before but the solution is to use an algorithm called "BCrypt". BCrypt is a hashing algorithm based on Blowfish with a small twist: it keeps up with Moore's law. The idea of BCrypt is quite simple, don't just use regular characters (and thus increasing the entropy) and make sure password X always takes the same amount of time regardless of how powerful the hardware is that's used to generate X. I'm not going to cover all the technical details but basically BCrypt requires you to specify a cost/workfactor in order to generate a password. This workfactor not only makes the entire process slower but is also used to generate the end hash. This means that if somebody were to change the workfactor the hash would also be different. In other words, hackers, you're fucked. In order for a hacker to gain the original password he must use the same workfactor and thus has to wait N times longer than when not using a workfactor.
It might be useful to avoid problems which have long ago been solved. Simple things like using proper functions and understanding programming interfaces makes life much easier and keeps us from embarassing situations like MTGOX and others repeatedly keep finding themselves in. |
|
|
|
<whole lotta' bullshit>
Totally wrong. Basically, all of your "advice" is garbage. Some real programmers, please chime in. |
|
|
|
http://falkvinge.net/2011/09/05/cable-reveals-extent-of-lapdoggery-from-swedish-govt-on-copyright-monopoly/I'm not particularly surprised by the cable, although some of you may find it informative. What I find interesting are the implications of the loss of control of finance and IP to centralized power. Bitcoin/Namecoin present major obstacles to corporate interests who would prefer to control all conduits of creating, distributing and profiting from all different types of IP. "Finance" is the only real remaining power center in the US, and it relies on IP (media/propaganda) on a fundamental level. This probably explains why the state department is being used to bully countries like Sweden with "super 301." To an unprecedented degree, bitcoin/namecoin unlock the corporate deathgrip on information. I am sure that "finance" has recognized distributed currencies as lethal threats to its existence. The attacks will be fast and furious. In particular, beware the threat of infiltration and its potentially paralyzing effect on organization and progress. Don't trust; only build infrastructure that doesn't require trust.
|
|
|
|
|
One thing that would help is using a well written, peer reviewed codebase. The only one that I know of is bitcoin-central. Of course, this has to run on top of a secure and well monitored infrastructure. No amount of transaction numbers, transaction cards or authorization codes will help if those requirements aren't met first.
|
|
|
|
|
Exchanges are crucial. If this exchange is shit (smells like it), it damages bitcoin.
So yes, it is time to get vicious.
|
|
|
|
This is the dumbest bullshit ever.
Of course it is, because you said so. How can we ever doubt you, you are such a SMART-ASS ! Everybody please ignore this "advice."
Yes, and become easy prey to hackers of all sorts. The way to secure a wallet isn't by your laughable Rube Goldberg machine. Generate a wallet on a dedicated airgapped machine, write down some of its addresses, encrypt the wallet and back up the encrypted file. Then send BTC to the addresses.See how that works? Now you have a bank from which you can make withdrawals to smaller wallets. Use your brain to figure out how. Christ. How hard can this be? It's amateur hour at forum.bitcoin.org... |
|
|
|
|
Obvious manipulation is obvious. We need more exchanges. Why don't people use bitcoin-central.net? It is the only exchange for which we have the source, so that we can see that it isn't a pile of shit, like bitcoin7 or whatever it is called.
More liquidity!
|
|
|
|
So what you're saying though is to encrypt the entire linux HD with trucrypt? right? not just create a truecrypt image on the VM's HD.
I am saying about a following scheme: 1. Create encrypted TrueCrypt hard drive. 2. Put a VirtualBox disk with VirtualBox Linux machine on it. 3. Install TrueCrypt within the Virtual Machine 4. Create encrypted TrueCrypt hard drive within the VM. ================== (LAYER 2) ================== 5. Create a VirtualBox disk with VirtualBox Linux machine on the VM. 6. Install TrueCrypt within the Virtual Machine in Virtual Machine 7. Create encrypted TrueCrypt hard drive within the VM in VM. ================== (LAYER 3) ================== (...) ================== (LAYER 4) ================== (...) And so on... This is the dumbest bullshit ever. Everybody please ignore this "advice." Also, VMs cannot protect data. |
|
|
|
|
Air gapped (not networked) computer with bitcoin transferred over via clean USB drive.
Open bitcoin and write down automatically generated address (address x).
From networked computer, open bitcoin and send funds to address x.
Encrypt wallet.dat and shred the original on the air gapped machine. Save encrypted wallet all over the place -- hardcopy too.
The unencrypted wallet never touches a networked computer.
|
|
|
|
At the risk of putting too fine a point on it, perhaps my "opacity" comes from your lack of reading comprehension.
Gene, I think the problem with GPG can be found right about here: How to use GPG? gpg --compress-algo BZIP2 --bzip2-compress-level 9 --encrypt -a -o text_crypt_wallet.txt wallet.dat
Say what now? Of course, I anticipate that your response will be a sarcastic version of how stupid I am not to understand your code world, and I don't--so I must be stupid. But bitcoin's adoption is very, very threatened by this wallet problem and the advice they will encounter for it. I know you are addressing a software audience with your gpg advice, but there are a lot of newbies coming in here seriously wanting to understand how to protect their investment, and the advice they encounter here is dreadful so far. We have to use the best available tools, despite their limitations. Sometimes the command line does the job, and I gave cut-and-paste examples. Those options are not too cryptic, but that may be just because I have seen far more horrible examples for other programs. You didn't paste it, but I explained what these options do. Not sure what your beef is. |
|
|
|
To be fair, these same issues exist with other disk-encryption schemes, like filevault. If someone has a keylogger on your computer, you're sunk no matter what.
I'm more concerned about the in-memory password storage and getting my computer stolen/seized when the power is on than having keyloggers/malware installed. Does GPG suffer from that too? Not in the same way. You can put in your ~/.gnupg/gpg.conf to... well... require secure memory (not to be swapped). No matter, once it finished {en|de}crypting, gpg immediately forgets your passphrase, by default. It also uses some techniques that make bruteforcing take much longer. Yes, I meant the local shred command. It depends of which UNIX or Linux you are using. Check your man pages to see which options apply.
How many shred iterations would you consider "astronomically safe"? I just use the defaults. With such a small file, you can just go crazy and it still won't take too long. |
|
|
|
|
Show Posts
