Donate BTC:
1zEAtvzgh3GXRq4M9DySzLhamUpBEZpHY
Yea thanks !
Sent some
The reason, that I avoided using names or places is due to spelling issues for foreigners.
A single family name in Russian: Epёмeнкo.
can be spelled as:
Yeremenko
Yuromenko
Eremenko
Eromenko
Juromenko
or any combination thereof...
of course it may be possible to use Unicode to write in own language. But for now I wanted to avoid spelling issues.
source of randomness:
Some users keep it stable (I use GMail for 10 years), but other change email every year.
Same for phone numbers.
My friend, Uzi, changed 8 (!!) phone numbers in two years. But other friend, didn't change in a decade.
With this, it may be difficult to remember what you had 20 years ago.
While it is true that a name can be spelled many different ways, one individual will almost certainly always spell their name the same way every time, even after 20 years. It's an extreme corner case where someone changes their name. It's an even more extreme corner case where someone changes their name and forgets their old name. And it's an almost impossibility that someone changes their name, forgets their old name, and has no documentation to show what their old name was whatsoever. At that point, they've probably forgotten the passphrase anyway.
As for web version --
this is something I cannot trust, as my password may leak straight into a hacker's hands. (unless it is a simple HTML, that I can download into an offline PC).
hackers can silently replace the generator HTML with something... so no Web version I won't trust very much. For this reason, I store only trivial amounts of BTC in blockchain.info wallet.
And after Diginotar bankruptcy I don't trust SSL/HTTPS either. (my bank is insured by the government).
In my opinion blockchain-based technology might replace SSL/X.509 certificates in the future.
That's not what I meant - I meant use the hash a a password for a website.
Username: CJYP
Password: H(Passphrase + salt), where H is the algorithm your program uses
Since we're not in the future where we can use blockchain-based technology to log in, we have to deal with the reality that people use weak passwords that then get guessed.
Key salt storage on Blockchain:
Another great idea: is to somehow store key salting hash on blockchain itself. (Ethereum allows to do this easily... but I dunno how-to store anything on the Bitcoin blockchain. Although a few experts were able to embed a few images, there is no how-to for python devs)
Obviously only connected clients can do that, but from desktop.
This will allow to store long, 128-bit salts.
A transaction can have arbitrary data. I like this idea too.
ASICs and SHA algo:
As for hashing change .. well I don't know which one is secure.
Litecoin claimed that their hash is ASIC-proof, yet came KNC miner and built a Scrypt-ASIC.
This field needs more research.
-Technologov
Thus why I suggested using a loop. H(x) = SHA-256(Scrypt(CryptoNite(SHA-256(Scrypt(CryptoNite(x)))))) or similar. (Named hash functions are entirely arbitrary btw - use whatever works best)
Use the salt as seed for next salt for each round.
But as far as using a hash of hash, you can build dictionaries of hashes that meet certain characteristics.
For example, if you take the average digit of a sha256 sum it will typically be between 7 and 9.
So you can exclude all hashes from your dictionary that are not between 7 and 9, etc. greatly reducing the possible size of your dictionary and increasing the odds of finding a collision.
Try them and their hash.
It's still pretty damn slim, a very large set, but smaller than 2^256 - so that's why you don't want to use a hash of a hash as your private key.
hash of a hash likely has less than 2^256 possibilities, how much less I don't know. Hash of high entropy random data is 2^256 (well, slightly less - I believe the EEC curve bitcoin uses doesn't go all the way to 2^256 but very close)
You want your private key to be a hash of high entropy random data, and that means it is not safe to use something that is easy to remember, even if you stretch it.
Pass phrases are fine for an encrypted wallet because the hacker has to get your wallet first (and then your pass phrase should be salted) but for something where a public address will be in the blockchain, the private key really needs to be a hash of high entropy random data.
Don't use brain wallets. Especially since addresses tend to be single use and should not be used against once you spend from it.
It seems to me that this can be solved simply by using a different hash function than bitcoin's. Maybe I'm not fully understanding though.
Placing a random salt on the blockchain seems to be an excellent way of increasing the entropy enough (as long as it's different for each user) - but again, I don't understand the math well enough to know for certain if that's enough.
