SHA-2 Support in Feature Requests

Page: 1 2
ID:105814
 
Dec 16 2010, 10:19 pm
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
BYOND should include support for SHA-2. The MD5 algorithm is broken and while BYOND applications may not require the most hardened hashing, there's little sense in not including a better algorithm when a free implementation is available.

http://www.aarongifford.com/computers/sha2-1.0.zip

Aaron Gifford provides a BSD licensed SHA-2 implementation. This license allows the code to be implemented within BYOND as the BSD license is not copyleft.
#1 Dec 17 2010, 12:43 pm
+
#2 Dec 17 2010, 8:14 pm
Anything you can encrypt with BYOND, you can decrypt with it, so what's the point?
#3 Dec 18 2010, 6:26 am
Falacy wrote:
Anything you can encrypt with BYOND, you can decrypt with it, so what's the point?

How do you decrypt SHA hashes with BYOND?
Just curious.
#4 Dec 18 2010, 6:42 am
Falacy: Please don't speak to things you don't know about. SHA-2 (and SHA-1 and md5) are hashing algorithms, not encryption. There's a huge difference and they stand for different purposes. There is no such thing as "decrypting" SHA hashes because they are not encrypted in the first place. If you read the article I linked to, you would know md5 is not broken because it can be reversed, it is broken because collisions can be feasibly generated.

While it's true you can generate rainbow tables for reverse lookups, I don't think anyone would dream of doing that in BYOND since it would be so slow. Additionally they would be effectively futile with a proper salting mechanism, but that's up to the developer, not BYOND.
#5 Dec 18 2010, 2:55 pm
Murrawhip wrote:
How do you decrypt SHA hashes with BYOND?

I would assume the same way you can do it now with md5. Though as Airjoe said, I don't really know what I'm talking about.
Really though, if you need to encrypt something in your BYOND project in the first place, you're probably doing something wrong.
#6 Dec 18 2010, 3:22 pm
Falacy wrote:
Murrawhip wrote:
How do you decrypt SHA hashes with BYOND?
I would assume the same way you can do it now with md5. Though as Airjoe said, I don't really know what I'm talking about.
Really though, if you need to encrypt something in your BYOND project in the first place, you're probably doing something wrong.

I was asking if you knew how, because I would be amused to discover that you were the only person in the world.

Hashing is valuable and has uses within BYOND projects, including its most common use, client-side saving.

In my own projects I use it for interacting with an external server - I'd prefer to send a hash to verify a command rather than a password that can be nabbed by a user with too much time on their hands.
#7 Dec 18 2010, 3:28 pm
Murrawhip wrote:
I was asking if you knew how
Yes, I do.

because I would be amused to discover that you were the only person in the world.
Not sure what that's supposed to mean

Hashing is valuable and has uses within BYOND projects, including its most common use, client-side saving.
Client sided saving is a bad idea all around, so I stick to my previous statement about you doing something wrong.

In my own projects I use it for interacting with an external server - I'd prefer to send a hash to verify a command rather than a password that can be nabbed by a user with too much time on their hands.
This is at least a slightly more legit use of it, but if they can get your password, and put it to use through a Topic, I'd be surprised if they couldn't do the same with a simple md5 hash.
#8 Dec 18 2010, 3:32 pm
Falacy wrote:
Long stuffz.

It appears you don't know - seeming as it's not currently doable.

It means that SHA-2 functions have not been declared 'broken', so I didn't think you would manage it yourself.

I don't see why client-sided saving is such a bad idea. It exists because there are positives to it.

Sure they can get the hash I send through a topic - but will it be useful without knowing how it's salted? No.
#9 Dec 18 2010, 3:39 pm
Murrawhip wrote:
I don't see why client-sided saving is such a bad idea. It exists because there are positives to it.

You can't save people when they log out, which is when they should be saved. Which means you either have to resort to auto saves, or saving whenever something changes, to make sure no data is lost. You have to upload and download files to the player every time you want to save or load them, which can suck for people with bad connections - or even worse, servers with bad connections. The file is saved on the players computer, which is bad in pretty much every way. They can modify it, they can delete it, they can change computers and lose it. The only real advantage is that they can use their save on multiple servers, which is much better handled with a save server, database, or some other global method.
#10 Dec 18 2010, 3:43 pm
Falacy wrote:
Murrawhip wrote:
I don't see why client-sided saving is such a bad idea. It exists because there are positives to it.
You can't save people when they log out, which is when they should be saved. Which means you either have to resort to auto saves, or saving whenever something changes, to make sure no data is lost. You have to upload and download files to the player every time you want to save or load them, which can suck for people with bad connections - or even worse, servers with bad connections. The file is saved on the players computer, which is bad in pretty much every way. They can modify it, they can delete it, they can change computers and lose it. The only real advantage is that they can use their save on multiple servers, which is much better handled with a save server, database, or some other global method.

A player has nothing to gain from modifying their save file. That's the point of the hashing.
The whole changing computer and losing it dealio is a disadvantage; with a database you'd need to remember your key password. That's a disadvantage for using a database. Everything has disadvantages.

EDIT: Lul@my fail. Removed.
#11 Dec 18 2010, 3:47 pm
Just to clarify, you never "decrypt" a one-way hash function like MD5 of the SHA series. You brute-force them to get likely reverse mappings, one of which will be your desired data.

The list of these mappings are very long, as you can just as gladly hash "hello world" as you can the entire contents of a ripped DVD, both of which produce a hash of the same size.

Two things make MD5 broken, the first of which is covered by the OP's provided link, in that you can fairly easily collide data, such that you don't need to know the intended input data (password or what have you) to get a program to validate you, you just need a collision.

The second issue is that MD5 is cryptographically poor and the search space is small. Hence open databases of mappings exist that allow you to plug in an unsalted hash and get a set of likely matches back, any of which could do the job easily enough for auth and one of which may (if mapped) be the intended input.

The SHA series as a whole has addressed problem one as best we know, and problem two is addressed by having differing round sizes, hence SHA1, SHA2, SHA-256, SHA-512 or other non-standard round sizes. The search spaces in those round sizes are progressively larger and thus more difficult to brute force or map publicly as was done with MD5.

As a series goes, SHA will go the route of MD5 one day, but not for the next few years at least.
#12 Dec 18 2010, 3:50 pm
Murrawhip wrote:
A player has nothing to gain from modifying their save file.
Infinite everything?

That's the point of the hashing.
Yes, it is. But its unnecessary, and for anyone who actually knows how to use it, it won't prevent them from cheating.

with a database you'd need to remember your key password. That's a disadvantage for using a database.
Why would you need to remember a password? Everything should be handled through the code without the player knowing. And I would recommend a BYOND built save server over a database anyway, which could even be a database of sorts itself.

EDIT: Lul@my fail. Removed.
Once they log out, their client is gone, and you can't send a file to it.
#13 Dec 18 2010, 3:55 pm
Falacy wrote:
Fallacies

The entire point of using md5 in client-side saving is to prevent cheating, and it does it very well. They cannot get 'infinite everything', because the client save file is no longer valid as soon as the user attempts to change it.
#14 Dec 18 2010, 3:57 pm
Murrawhip wrote:
The entire point of using md5 in client-side saving is to prevent cheating, and it does it very well. They cannot get 'infinite everything', because the client save file is no longer valid as soon as the user attempts to change it.

You can't just store md5 values. You have to log the actual values also. Anyone who understands this concept can easily find the matches (using BYOND) fill in whatever they want, create the matching md5 hash (again using BYOND), and magically they have a "legit" save.
#15 Dec 18 2010, 3:57 pm
Stephen001 wrote:
Two things make MD5 broken, the first of which is covered by the OP's provided link, in that you can fairly easily collide data, such that you don't need to know the intended input data (password or what have you) to get a program to validate you, you just need a collision.

And truly, I'm not sure if generating collisions is really a problem, because in the case of a client-side save, for example, the problem isn't authentication, it's validation. Let's say a savefile stores a player's level and an md5 hash- if you change your level alone, the game can tell you edited the file. So you want to change the hash to validate the change to your level... but if you don't know how the hash is generated, being able to compute a collision is useless because you don't know what the resulting hash should even be!

Generating a collision works well when you know what the hash should be and you're trying to provide the data, like a password, to yield that hash.



Anyway, the request stands- md5 is broken, sha-2 is not and is also freely available. The only reason not to implement it is Lummox JR's lack of time... if only BYOND had more people working on the software itself...
#16 Dec 18 2010, 3:59 pm
Falacy wrote:
Murrawhip wrote:
The entire point of using md5 in client-side saving is to prevent cheating, and it does it very well. They cannot get 'infinite everything', because the client save file is no longer valid as soon as the user attempts to change it.
You can't just store md5 values. You have to log the actual values also. Anyone who understands this concept can easily find the matches (using BYOND) fill in whatever they want, create the matching md5 hash (again using BYOND), and magically they have a "legit" save.

You hash the entire file, along with a salt. That hash goes inside the save file.
When loading the savefile, you hash the entire file again, with the salt, and if it matches, the file has not been modified.
#17 Dec 18 2010, 4:26 pm
Falacy wrote:
Murrawhip wrote:
The entire point of using md5 in client-side saving is to prevent cheating, and it does it very well. They cannot get 'infinite everything', because the client save file is no longer valid as soon as the user attempts to change it.
You can't just store md5 values. You have to log the actual values also. Anyone who understands this concept can easily find the matches (using BYOND) fill in whatever they want, create the matching md5 hash (again using BYOND), and magically they have a "legit" save.

No no, you just store the hash in the savefile, after running your saved data through it. Now if salted properly with a salt the program knows but you don't, it becomes very difficult to update that hash with a valid value after you've edited. Unless like me you casually read these things out of the DMB. But if your player is doing that, they are past the point it's reasonable worth your while to stop.
#18 Dec 18 2010, 5:15 pm
Falacy wrote:
A lot of stuff in this whole forum post.

So you are the one who broke md5?

#19 Dec 20 2010, 1:33 pm
Sounds like you should be able to call a DLL that implements whatever hashing algorithm you want.
Page: 1 2