Dude, awesome  so this accounts for 3% out of your 6.4% improvement, where are the other 3.4% coming from? I don't have 250 btc, in fact I only have ~2 that have been donated to me so far. (Please note - if you decide to share this, post it,don't pm me ) I think I deserve the right to keep this remaining ~3% a secret of mine. I have contributed a lot to this community. AFAIK I was the... * first to show how to down-plug x16 cards in x1 slots by cutting PCIe slots and/or shorting pins A1-B17 http://blog.zorinaq.com/?e=42* first to use BFI_INT, and document how to patch a kernel with it: http://blog.zorinaq.com/?e=43* first to document the PCIe 12V rail redirection hack http://blog.zorinaq.com/?e=44* first to present a cheap solution to cool 4 double width cards http://blog.zorinaq.com/?e=47Now all the miners are using BFI_INT; shops are selling pre-modified PCIe extenders; etc. Enjoy :-) |
|
|
|
I was wondering when the community would discover this optimization... nice one bitless :-) For the record, hdminer has implemented this maj() optimization since day 1: # ibit_extract patched to BFI_INT at runtime
$code .=
" ixor $tmp0, $a, $b\n".
" ibit_extract $tmp0, $a, $c, $tmp0\n";
Phoenix is probably very close to hdminer's performance now, on HD 69xx. |
|
|
|
|
"how ridiculous is that statement"
"Yes, salt, if unknown or per-user, will prevent Rainbow Tables"
Way to contradict yourself! This discussion is now over.
|
|
|
|
No. My point is: use industry standards like PHP's builtin crypt() CRYPT_SHA512 mode. They are an excellent compromise between CPU time & strength.
You have no reason to refuse to follow industry standards.
So was MD5 10 years ago... You've a GOOD reason to NOT follow industry standards actually; it's called "Rainbow Tables" and alike. MD5 was never broken, NTLM was never broken, all of those 1-way hashing mechanisms were never broken, what happened is that they're "industry standards", so it become easy to create dbs with their possible contents. If you had any education whatsoever in the area of password hashing, you would know that CRYPT_SHA512 is immune to rainbow tables thanks to its unique salt per hash. This is why you should use it instead of plain MD5/SHA1/SHA512 etc. |
|
|
|
Btw, who's that "Adam" that signs the post in the redirect blog?! Did they already manage to sell MtGox again?!
He is Adam Barr, an MtGox employee. |
|
|
|
|
No. My point is: use industry standards like PHP's builtin crypt() CRYPT_SHA512 mode. They are an excellent compromise between CPU time & strength.
You have no reason to refuse to follow industry standards.
|
|
|
|
fighting overheating issues in DC3, some capacity went down temporarily.... I suppose I am not the only one with such issues... 28-30 C outside...
Summer is a good stress-test for PUE=1.03 datacenters ;-) |
|
|
|
|
Netrin, with your technique the salt is known: it is effectively the username (plus a fancy hashing algo that you want to keep secret). It is trivial to reverse engineer the hashing algo of a closed source app. People have done this for Oracle, Windows NTLM auth, etc. All closed source and all have been reversed engineered and documented.
|
|
|
|
|
@netrin: stretching means iterating the hash function multiple times, eg. 1000 times for Unix MD5()-based crypt.
@an0therlr3: it would lower security to derive a salt from the username only. If an app was doing that and came with a default account (say "admin"), then every user of this app choosing the same admin pw would result in the same hash being generated everywhere.
|
|
|
|
"Stored per user" doesn't mean "Stored next to password, per user".
It could have been stored on a separate system, in a separate database. Which would have made the leaked passwords worthless without the other "half" of the password file.
This is pointless. This is the same as saying "store the hash on a separate system and make sure it does not get stolen". Hashes (and salts) both get stolen and must be designed to withstand bruteforcing as best as possible. The point of a salt is not to be secret but to be unique. It can be stored alongside the hash. It is an industry-standard practice (think all Linux/Unix systems). |
|
|
|
It's not 25 rounds. It's 25 * login length + 25 * password length + 1 iterations. So it's basically few hundrets. Did you measure this code or just 25 rounds of SHA-512?
I stand corrected on the random salt though - it shouldn't derive from username alone.
gmaxwell's point still stands though. A few hundred rounds of SHA512 is not sufficient. This is barely a bit more computationally intensive than MD5-based crypt(), which is not good enough and which is why MtGox and modern Linux distributions are phasing it out. (Also an undesirable property of your hash function is that the pw/user pair "a:b:c/d" will hash to the same as "a:b/c:d" or "a/b:c:d".) Use PHP's builtin crypt() CRYPT_SHA512 people! Don't re-invent your own crypto. PS: I write password bruteforcers. |
|
|
|
|
The "Adam" you guys said was on the OnlyOneTV show was not an MtGox employee, he was Adam Stradling, a TradeHill co-founder.
|
|
|
|
|
Thanks, I did add the info.
I got confirmation from MagicalTux that the 432k BTC transfer was MtGox moving coins to a safer location.
|
|
|
|
FYI, on The Bitcoin Show tonight, one of the Mt. Gox guys said that the ~400k transfer was them taking security measures by moving their BTC to a different wallet.
Someone else said it was a certain "Adam" on the show who said the 432k BTC txfer was MtGox transferring as a security precaution. "Adam" is not related to MtGox. (Sorry I forget where I heard about this Adam. I'll try to get clarification about this transfer.) But regardless, it worries that it was made (a minute) before MagicalTux appeard on IRC, where he was clearly just discovering the selloff, and hadn't started his investigation yet. Also it doesn't make sense that a "single account" was compromised and had hundreds of thousands of BTC in it. No one in his right mind keeps this amount of coins on MtGox (other than MagicalTux himself?), ask knightmb how he secures his 370k BTC |
|
|
|
Many of these hashes, even those that appear to be strong passwords, show up on various websites about password brute-forcing. Notably, 2 days ago, a user named georgeclooney posted requests to crack some of these hashes on the InsidePro password recovery forums. He is almost certainly the same person who attacked MtGox.
Emphasis yours. Can you elaborate on why you think georgeclooney is the attacker? Is that based solely on the fact that he posted some of the hashes before they were publicly leaked? Yes, it is based on this fact. |
|
|
|
http://blog.zorinaq.com/?e=55There is a massive amount of information on IRC and the forum threads. Hopefully I have done an okay job at summarizing the attack..
|
|
|
|
Not a really good comparison since you'd have to have the hash of the password, and we could compile a rainbow table for almost anything. One way to defeat Rainbow tables is salting the password hashes (you are salting your passwords MtGox aren't you?)  Now, we know that 1765 of the MtGox password hashes leaked today were not salted. :-( |
|
|
|
Spending $1M on a mining cluster would have almost no effect on the Bitcoin network and economy. Assuming the money is spent on AMD GPUs, where $1 buys 1Mhash/s, it would only increase the global network hashrate by about 1 Thash/s. However it would take at the very least 2+ months for this hypothetical tycoon to go online. The network is currently at 8 Thash/s, and is more than doubling in size every month. So 2 months from now the network will be at 30-40 Thash/s. This tycoon would end up owning ~3% of the global hashrate. A drop in the bucket. This would have no significant impact on the difficulty factor. This should not entice anybody to stop mining. Nonetheless this would be a fun learning exercise for whoever sets up such a farm. In terms of DP FLOPS performance, this theoretical AMD GPU mining cluster would be at roughly position #10 on the TOP500 list. On the other hand, if this hypothetical tycoon buys coins it would be different. I don't have access to the complete depth of market data from MtGox, but we know that $430k would raise the price up to $21.13 at this moment ( http://bitcoincharts.com/markets/mtgoxUSD_depth.html). So buying $1M worth of coins would probably push the exchange rate up to $25-30, enticing more users to scale up their mining efforts, and probably contributing to another +50% future difficulty increase. |
|
|
|
Mechanical failure of a PSU fan blade, on a Corsair AX1200, after barely 700h of operation. Aah, the joy of running a mining cluster large enough to make improbable failures actually occur once in a while... After the blade broke, the imbalanced fan was making the whole computer chassis vibrate quite hard.
That's when you just break one off on the other side and call it good.  Impossible. There is an odd number of blades. |
|
|
|
Mechanical failure of a PSU fan blade, on a Corsair AX1200, after barely 700h of operation. Aah, the joy of running a mining cluster large enough to make improbable failures actually occur once in a while... After the blade broke, the imbalanced fan was making the whole computer chassis vibrate quite hard.  |
|
|
|
|
Show Posts
