1697 replies to this topic

[Creator]

Anavrins, on 23 February 2016 - 07:22 PM, said:

ry00000, on 23 February 2016 - 01:09 PM, said:

I COULD unhash an address... If I knew the SHA256 and the key... Yeah, thanks, krist.ceriat.net for not providing the SHA's and the keys.

Let's say the account with password "a", has an address "kxxk8invlf" and a privatekey "9c61cce6bae9ac864b60238532ac8ce1a73006d943b44e060259e50363f4aebd-000" which is 68 characters long.
The hash stored in the database is sha256("address..privatekey"), you know the address, but you still need to figure out the privatekey.
Is it me or you are claiming to be able to crack a 68 characters long password?

Spoiler

If BitCoin uses sha for mining, does it mean it has detected a ton of collisions, since there are possibly millions of users producing billions of hashes per second?

[Anavrins]

Creator, on 23 February 2016 - 09:35 PM, said:

If BitCoin uses sha for mining, does it mean it has detected a ton of collisions, since there are possibly millions of users producing billions of hashes per second?

I highly doubt it, 2^256 is still a very gigantic amount.

Edited by Anavrins, 23 February 2016 - 09:45 PM.

[Creator]

There must have been some collisions that were discovered. And how else are rainbow tables created?

[Lemmmy]

Creator, on 23 February 2016 - 10:06 PM, said:

There must have been some collisions that were discovered. And how else are rainbow tables created?

no as soon as a collision is detected in a hash algo it's ditched. that's what happened to md5 and sha-1

rainbow tables are basically just a huge list of precomputed hashes. they are built from password lists, word dictionaries, all strings from a to z, etc. they take a huge amount of time to generate though

using a salt pretty much completely voids the application of a rainbow table since the hash is different to your input string, and thus you pretty much just have to go for brute force

thus if anyone ever gets access to the krist database, they'll have to manually crack each one still

[Anavrins]

It's not necessary as soon as there's a collision.
Having a collision that produce the same hash with different input is just incredibly lucky, but that doesn't necessary mean any weakness.
Finding a flaw in the collision resistance of an algo though is a big deal, example MD5 which attacks can find a collision with 2^18 time rather than 2^64, which runs in less than a seconds on modern hardware, MD4 which can have collision in less than 2 steps (collisions being as cheap as verifying it).
These attacks aren't a way of reversing a hash back to its original input, meaning that collisions doesn't really matter for password storage, you can generate a different password with the same hash, but you won't recover the real password as easily.
Collisions are much more a big deal for file integrity, or by example, certificate signature, by which you can make your own malicious certificate, and make it have the same hash signature as a legitimate signed certificate.

tl;dr, collision isn't a big deal for password storage or mining, since your resulted input might not even be the original password, or in a valid format for mining.

Edited by Anavrins, 24 February 2016 - 03:40 AM.

[3d6]

Creator, on 23 February 2016 - 09:35 PM, said:

Anavrins, on 23 February 2016 - 07:22 PM, said:

ry00000, on 23 February 2016 - 01:09 PM, said:

I COULD unhash an address... If I knew the SHA256 and the key... Yeah, thanks, krist.ceriat.net for not providing the SHA's and the keys.

Let's say the account with password "a", has an address "kxxk8invlf" and a privatekey "9c61cce6bae9ac864b60238532ac8ce1a73006d943b44e060259e50363f4aebd-000" which is 68 characters long.
The hash stored in the database is sha256("address..privatekey"), you know the address, but you still need to figure out the privatekey.
Is it me or you are claiming to be able to crack a 68 characters long password?

Spoiler

If BitCoin uses sha for mining, does it mean it has detected a ton of collisions, since there are possibly millions of users producing billions of hashes per second?

Right now, the bitcoin network is mining at about 1.2 exahashes per second. There's two SHA hashes in a bitcoin mining hash, so we're lookingat 2,400,000,000,000,000,000 hashes every second. The number of possible SHA hashes is 2^256 - 115,792,089,237,316,195,423,570,985,008,6i'm gonna stop there, it's a really big number. Even with a computers mankind will ever create, and all the energy of the sun - the sun would die out before there is a SHA-256 collision, and it will remain secure until either computers are made of something other than matter or occupy something other than space.

[Creator]

That means that we would need 2^195 seconds (because log(2,2400000000000000000) = 61,... and 256-61 = 195), which is 5*10⁵⁸ seconds. This is 1.59 * 10⁵¹ years. This is 1.13 * 10⁴¹ times the age of the universe, which is about 14*10⁹ years old. A lot!

In comparison, there are 10⁸² atoms in the universe, while there are 2²⁵⁶ = 10⁷⁸ possible SHA 256 outputs. (Square that to get the SHA 512 outputs.) This means that if every atom mined at the speed of 1/10⁴ hashes per second, we would exhaust all the possibilities in one second. However that is never going to happen, so rest in peace weak password users.

[Justy]

Mayushii, on 20 February 2016 - 08:52 PM, said:

On a side note, I found a lovely site just now. So, Hello 1337.

Hey! Thats my website!

[ry00000]

Lemmmy, on 23 February 2016 - 05:57 PM, said:

Lignum, on 23 February 2016 - 05:42 PM, said:

But either way, it's unlikely that the Krist database will be downloadable, since we're no longer using SQLite, which means we would need to dump the db periodically.

To follow this up, I am planning on writing a DB dumper that will make a data.db containing all non-sensitive info at 0:00 GMT daily.
Edit: I'm doing this now.

ry00000, on 23 February 2016 - 01:09 PM, said:

I COULD unhash an address... If I knew the SHA256 and the key... Yeah, thanks, krist.ceriat.net for not providing the SHA's and the keys.

You can unhash an address? Yeah, right. You could rainbow table it for sure, but we store them salted so good luck using a rainbow table too.

Go ahead and unhash these privatekeys:

4aaa3e2da7fcab5c599dab7a5a86341addebf25b19f6696b2e4b3e6d130e5035
8f07ac7acb02b34d043266cae6c4532f639ff56cdd32d1f0f1dcc308eb8d1ff6
0b862738b6f904d55ba4f436f569d732537a8d05e688d4709908ef54bdcccd60
105d5d126a88a910840e137a514f3ddc038f25ccda41ea10bcc6c878b5e1a0e5
0b34dcd8a9d5f5fcbb7791ad0aa25979a2c194bdaffd7951e05404c57cc9d45c

And one for luck:

9627ec943025d95252ea3151cd75f292b26cdb950d77489919b4a2d69f24ee03e4769cb50ea724742b014c4d30cd76c4896426ce6d659187771b220d74485f81

Edit 2: I had a second look at your message, and it's absolutely hilarious how BS it is. First of all, why do you need the SHA-256 AND the key? The SHA-256 is pretty much just sha256(address + privatekey), so the key is just enough. Address generation has nothing to do with the stored SHA-256, it is purely an extra measure against collisions.

Addresses are generated based on the privatekey, and will collide. This means that you can mine addresses. This is most likely what you think you can do. Addresses are generated using SHA-256 and a little bit of fairy dust (and 3d6 quality code). It should be noted that SHA-256 is a cryptographic hash function, and it is one-way. This means you cannot unhash. You can however mine for the target string and hope that you eventually get it. Rainbow tables make this easy as they come with pre-prepared input and outputs, but are invalidated when salts are thrown into the mix. If you have enough computational power, you can easily mine for any address you wish. However, as Lignum stated, you will need to mine for the exact privatekey used now.

ry00000, on 23 February 2016 - 01:09 PM, said:

Yeah, thanks, krist.ceriat.net for not providing the SHA's and the keys.

What the hell? Were you dropped on the head as a child? Did you seriously think that any of us would be stupid enough to literally give you the privatekeys and/or hashes? Please take a good look in a mirror and reconsider your life. Thank you.

I didn't know it was so secure. It's Minecraft, stop being secure!

[Creator]

Even if krist has a minecraft interface, it is still a (kinda) real currency. Not much computational power is needed to add this security, so why not?

[Sxw]

Someone's started mining as "kristisgay." That makes me wonder what happens in the event of an address collision with two different private keys. Is it treated as the same address? Are "private keys" even stored?

[3d6]

Sxw, on 26 February 2016 - 02:51 AM, said:

Someone's started mining as "kristisgay." That makes me wonder what happens in the event of an address collision with two different private keys. Is it treated as the same address? Are "private keys" even stored?

Since very recently, hashes of private keys are stored so that collisions aren't a problem. Before that, private keys did not touch the database at all, hashed or not.

Also, it is quite unlikely that anyone actually has the private key to that address.

[ry00000]

wait, does all of this mean there's an update to KristWallet?
If then, let me build TurboKrist.
If not, then I'M OUTTA HERE.

[sci4me]

ry00000, on 26 February 2016 - 09:11 AM, said:

wait, does all of this mean there's an update to KristWallet?
If then, let me build TurboKrist.
If not, then I'M OUTTA HERE.

No, this is a server-side change...

It happened in a silent update days ago...

Edited by sci4me, 26 February 2016 - 11:37 AM.

[3d6]

ry00000, on 26 February 2016 - 09:11 AM, said:

wait, does all of this mean there's an update to KristWallet?
If then, let me build TurboKrist.
If not, then I'M OUTTA HERE.

You're free to build turbokrist. See its thread in the general board

[ry00000]

I already built it. Shame it doesn't detect my Intel integrated gfx chip. (Will test on a proper card once I get home)

And the JDK was finicky sometimes. I had to reinstall the latest JDK1.8 build just to get Gradle to compile. Then, the tests failed. Oh, the hilarity.

[ry00000]

I'm mining! I compiled turbokrist and now I can watch the krist roll in at a painfully slow rate of 0.25 Blocks a second.

(Ey! Stop mining my blocks! I'm about to solve one and somebody mines it before me!)

YASS! I broke 1 block!

I mined my second block as I type, so yeah, i'm looking at a bright future!

I officially broke 20 KST!

[ry00000]

This is GOING to take a while.

I'm in the range of KILO hashes a second. I was faster with my CPU.

[apemanzilla]

ry00000, on 26 February 2016 - 06:57 PM, said:

This is GOING to take a while.

I'm in the range of KILO hashes a second. I was faster with my CPU.

You didn't follow the mining instructions then. They tell you how to get better speeds. Even integrated graphics will easily beat most CPU-only miners if set up properly.

[Lemmmy]

Sxw, on 26 February 2016 - 02:51 AM, said:

Someone's started mining as "kristisgay." That makes me wonder what happens in the event of an address collision with two different private keys. Is it treated as the same address? Are "private keys" even stored?

I explained this a few posts back. Recently we updated the security model, so even if somebody finds two privatekeys that belong to the same address, the database will only allow the first discovered one to be used. For example, with the address kfe3c3qz4w there are two found KristWallet privatekeys:

• KSTcollision-n=6085997
  
• KSTcollision-n=7770485

If we convert these to pure Krist privatekeys, we get these:

• 66e8d0a8afb8193503ca21b5833ac1ab8cc606d6190f4338cdce6e490af0acd6-000
  
• 245ab5eab0b6a3f6d30773cbf640530804e3b45338077ed4d95a4488fb23bfd6-000

When an API call is made that has anything to do with the address's privatekey (/login, transaction creation, name registration etc), the privatekey is bound to that address. From then on, only that privatekey will work with it. For example, if someone makes a transaction from kfe3c3qz4w using the privatekey 66e8d0a..., it will bind said privatekey to the address. Then, if someone tries to make a transaction from kfe3c3qz4w using the privatekey 245ab5ea..., they will get an "access denied" error.

While this does not prevent address collisions, it prevents wallet collisions. To view the full implementation of the storage, you can view the source code. The relevant file is src/addresses.js, lines 39 to 77.

https://github.com/L...rc/addresses.js

Spoiler

Addresses.verify = function(kristAddress, privatekey) {
	return new Promise(function(resolve, reject) {
		Addresses.getAddress(kristAddress).then(function(address) {
			if (!address) {
				schemas.address.create({
					address: kristAddress,
					firstseen: new Date(),
					balance: 0,
					totalin: 0,
					totalout: 0,
					privatekey: utils.sha256(kristAddress + privatekey)
				}).then(function(addr) {
					resolve({
						authed: true,
						address: addr
					});
				}).catch(reject);

				return;
			}

			if (address.privatekey) {
				resolve({
					authed: address.privatekey === utils.sha256(kristAddress + privatekey),
					address: address
				});
			} else {
				address.update({
					privatekey: utils.sha256(kristAddress + privatekey)
				}).then(function(addr) {
					resolve({
						authed: true,
						address: addr
					});
				}).catch(reject);
			}
		});
	});
};

If you have any doubts, feel free to contact me via forum PM or email.

Edited by Lemmmy, 26 February 2016 - 11:59 PM.