I think that's what I did with CCL. Check it out, I'm uploading the file later.
It looks symmetric to me? As far as I see the checksum generation algorithm only takes the data as an input and is used by both sender (generator) and recipient (client). It is randomized with some constant seed but that would be required inside the recipient map so is public knowledge.
I once implemented RSA check in galaxy, I'll look for it. It was terribly slow though (not to mention generating prime numbers) - I borrowed big num from starcode guys (they do it on strings <lol>). I need to rewrite it on arrays with some large base numbers (sc2 can handle up to 10^9, so 10^4 would be max), and we'll see.
The idea is kinda nice but I really don't think it has any advantage over just using a small mod file. Instant distribution, fast, and doesn't require you to play a match of your map.
It seems like it'd work better as a tool to allow community members of a given map to make their own broadcasts to spread the message faster. Say, "tournament tonight (dec 29th) 7pm GMT", which would actually be a pretty amazing tool since I don't think many players really bother with the game-specific chat channels.
I think that it's good way to spread mod privileges (votekicks, etc.).
I tweaked it a b it and it is ok now imo.
Everything depends on message and exponent size. I managed to process 1024 bit key with 17 bit exponent in around 30 seconds (game says that trigger completed in 2s, that's weird) . With low exponents (3/5/7) and short messages (for example 30 characters) can be processed in less than 1 second. Because of this small key sizes are suggested. Considering fact that they cracked 700 bit key in 2007-2009 using 2000 processor cores going with something like 500 bit key and bigger e will be ok.
One missing puzzle element - conversion from string to decimal (RSA padding).
I tweaked it a b it and it is ok now imo. Everything depends on message and exponent size. I managed to process 1024 bit key with 17 bit exponent in around 30 seconds (game says that trigger completed in 2s, that's weird)
Probably the debugger overhead. Do not think all those metrics are free...
I am 90-100% sure the time could be greatly reduced by using a proper array bignum rather than a string. String stuff probably has huge overhead due to all the memory allocation and garbage collection involved where as an array approach has no such memory allocation overhead.
@ImperialGood: Go
Even without metrics trigger returns much faster. I think that game stops counting time when it's in trigger for too long (so it can't render itself). Probably time is measured in fixed timestep, and because there is no next frame mission time is not increased. Sticking wait 0 seconds all over the code will fix it.
Ofc bignum on arrays would be faster, go on make it ;) After I discovered that there are no uints I gave up.
@ImperialGood: Go Even without metrics trigger returns much faster. I think that game stops counting time when it's in trigger for too long (so it can't render itself). Probably time is measured in fixed timestep, and because there is no next frame mission time is not increased. Sticking wait 0 seconds all over the code will fix it.
Execution time should be measured with some form of system timer which always increments as part of the processor operation. Being a hardware timer it will continue to work even if your system becomes completely unresponsive due to all cores getting into a infinite loop at kernel level. Time is not measured in game frame timesteps (every 0.0625 seconds) because triggers always execute as part of a deterministic tick so unless suspended using Wait they will appear to execute immediately with no game time passing. A 0 wait will not help since it will suspend the thread for 1 deterministic frame (0.0625 seconds).
What could be happening is integer overflow. Performance counters are usually obtained in nano seconds or micro seconds. If they use a 32bit integer to compute them then long execution times could result in the timer overflowing. The physical timer in hardware uses at least 64bits to avoid this for a long time.
Quote:
Ofc bignum on arrays would be faster, go on make it ;) After I discovered that there are no uints I gave up.
The lack of uints is seldom a problem as bit manipulation and most arithmetic operations work the same regardless. That said you could always treat an int as an unsigned short, using only the first 16 bits (which results in always a positive number). It should still execute faster than any string based method since you can manipulate it in units of 65536 instead of just 10.
Ugh, are you kidding me? The moment I find this thread is when I'm half way done implementing a "Very Large Integer" system using strings. (For my RSA implementation)
I'll check it out though, thanks for sharing!
Rollback Post to RevisionRollBack
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
Here's it in a library form for the record. Right now caps out at 1000000000 for the binary to decimal conversion so i hope you don't have any bigger number than that needed for this.
Edit: anyone else notice that the native pow2 and power functions don't seem to work for any powers over 19 really. If not I feel like my sc2 is broken then.
Vicboy:
Go move back from there, doing bignum on strings is pointless :) To implement RSA padding you need to perform bitwise operations on big numbers (hashing) and without it RSA is easy to crack. I'll convert decimal string into binary string, because I already coded it.
Looks like I am "forward", so I think that I'll just finish my function and posit it here ;)
willuwontu:
You don't need encryption in your map, because you want to encrypt data outside (for instance with python script) and just paste encrypted message in game - otherwise all players will be able to see your private key, uh?
Also using stuff that I posted as library is pointless, because naked rsa is not cryptosytem! RSA with all stuff (padding, etc.) is cryptosystem. Remember that!
@ShadowDancer93: Go
IK it's useless without private/public keys, just had a brain fart when I asked for a decryption function (just needed to replace e with d, exact same function otherwise). The library is meant for a base starting point (they supply the keys and it does the work for them). Although I could use an explanation on how the decimal math works (I know that you convert it to a decimal in order to work with bigger numbers), and why you would use binary input as opposed to decimal input.
On a side note i hate the size limitations for it, I can't do a 8 digit n (which would be used for dates mmddyyyy)
Also the library is what you made earlier except for a decimal to binary conversion, the source combined into one custom script, and all the functions renamed so that it doesn't clash with starcode.
@willuwontu: Go
e is binary for fast powering algorithm in modulo ring. Other numbers are strings in decimal format. Galaxy code uses 32 bit signed integers ("int"), that can represent values in −2 147 483 648 — +2 147 483 647, therefore you can't convert from my string using StringToInt built in function, becasue I use primes with hundreds of digits. I use decimal string to speed up computation time compared to binary, and keep implementation easy (compared to higher bases).
You can't use n for anything, it's part of public key!
yes n can't be used for anything, however n is the maximum size for any data that you encrypt and want to be able to restore (eg. can't store 20150101 with an n of 3233)
Your test only tried to encode it. I find that when I try to decode any thing over 7 digits it returns wrong. No idea why either, i made it correctly and it works on my computer calculator.
Do keep in mind the idea is for you to first generate a cryptographic hash of the message (eg SHA-1) and then apply RSA to that. As such I would recommend multiplies of 256 bits for the length (where more is more secure but slower and more space wasting). A good compromise might be 512 bits (86 characters) as it probably is not unbreakable however the chances of someone with the skills and resources breaking it is negligible. You could also make things harder by changing the public and private key from time to time.
Do keep in mind that these signatures need to be pretty big to be secure. Recommended RSA keys now are 2048 to 4096 bits long.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
It looks symmetric to me? As far as I see the checksum generation algorithm only takes the data as an input and is used by both sender (generator) and recipient (client). It is randomized with some constant seed but that would be required inside the recipient map so is public knowledge.
@ImperialGood: Go
Yeah, I understand it now. Trying to make sense of it so I can do something like that.
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
Gentelmen,
I once implemented RSA check in galaxy, I'll look for it. It was terribly slow though (not to mention generating prime numbers) - I borrowed big num from starcode guys (they do it on strings <lol>). I need to rewrite it on arrays with some large base numbers (sc2 can handle up to 10^9, so 10^4 would be max), and we'll see.
The idea is kinda nice but I really don't think it has any advantage over just using a small mod file. Instant distribution, fast, and doesn't require you to play a match of your map.
It seems like it'd work better as a tool to allow community members of a given map to make their own broadcasts to spread the message faster. Say, "tournament tonight (dec 29th) 7pm GMT", which would actually be a pretty amazing tool since I don't think many players really bother with the game-specific chat channels.
I think that it's good way to spread mod privileges (votekicks, etc.).
I tweaked it a b it and it is ok now imo. Everything depends on message and exponent size. I managed to process 1024 bit key with 17 bit exponent in around 30 seconds (game says that trigger completed in 2s, that's weird) . With low exponents (3/5/7) and short messages (for example 30 characters) can be processed in less than 1 second. Because of this small key sizes are suggested. Considering fact that they cracked 700 bit key in 2007-2009 using 2000 processor cores going with something like 500 bit key and bigger e will be ok. One missing puzzle element - conversion from string to decimal (RSA padding).
Attached test map - example input:
Edit: This is map with lots of debug stuff, only for test purposes.
Edit #2: Vicboy - sorry for invading your topic, but I think that this solves (or it's on good way to solve) your problem ;)
Probably the debugger overhead. Do not think all those metrics are free...
I am 90-100% sure the time could be greatly reduced by using a proper array bignum rather than a string. String stuff probably has huge overhead due to all the memory allocation and garbage collection involved where as an array approach has no such memory allocation overhead.
@ImperialGood: Go Even without metrics trigger returns much faster. I think that game stops counting time when it's in trigger for too long (so it can't render itself). Probably time is measured in fixed timestep, and because there is no next frame mission time is not increased. Sticking wait 0 seconds all over the code will fix it.
Ofc bignum on arrays would be faster, go on make it ;) After I discovered that there are no uints I gave up.
Execution time should be measured with some form of system timer which always increments as part of the processor operation. Being a hardware timer it will continue to work even if your system becomes completely unresponsive due to all cores getting into a infinite loop at kernel level. Time is not measured in game frame timesteps (every 0.0625 seconds) because triggers always execute as part of a deterministic tick so unless suspended using Wait they will appear to execute immediately with no game time passing. A 0 wait will not help since it will suspend the thread for 1 deterministic frame (0.0625 seconds).
What could be happening is integer overflow. Performance counters are usually obtained in nano seconds or micro seconds. If they use a 32bit integer to compute them then long execution times could result in the timer overflowing. The physical timer in hardware uses at least 64bits to avoid this for a long time.
The lack of uints is seldom a problem as bit manipulation and most arithmetic operations work the same regardless. That said you could always treat an int as an unsigned short, using only the first 16 bits (which results in always a positive number). It should still execute faster than any string based method since you can manipulate it in units of 65536 instead of just 10.
@ShadowDancer93: Go
Mind tossing a decryption function in there?
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
@ShadowDancer93: Go
Ugh, are you kidding me? The moment I find this thread is when I'm half way done implementing a "Very Large Integer" system using strings. (For my RSA implementation)
I'll check it out though, thanks for sharing!
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
Oh wow, you did a Big Number shit? I feel like I wasted time. Oh well, I should continue with mine just for the knowledge of it.
Member since 2010. Made the -The Thing- [Revival] game. Nostalgic of the WC3 days.
@Vicboy: Go
Here's it in a library form for the record. Right now caps out at 1000000000 for the binary to decimal conversion so i hope you don't have any bigger number than that needed for this.
Edit: anyone else notice that the native pow2 and power functions don't seem to work for any powers over 19 really. If not I feel like my sc2 is broken then.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
Vicboy: Go move back from there, doing bignum on strings is pointless :) To implement RSA padding you need to perform bitwise operations on big numbers (hashing) and without it RSA is easy to crack. I'll convert decimal string into binary string, because I already coded it.
Looks like I am "forward", so I think that I'll just finish my function and posit it here ;)
willuwontu: You don't need encryption in your map, because you want to encrypt data outside (for instance with python script) and just paste encrypted message in game - otherwise all players will be able to see your private key, uh?
Also using stuff that I posted as library is pointless, because naked rsa is not cryptosytem! RSA with all stuff (padding, etc.) is cryptosystem. Remember that!
@ShadowDancer93: Go IK it's useless without private/public keys, just had a brain fart when I asked for a decryption function (just needed to replace e with d, exact same function otherwise). The library is meant for a base starting point (they supply the keys and it does the work for them). Although I could use an explanation on how the decimal math works (I know that you convert it to a decimal in order to work with bigger numbers), and why you would use binary input as opposed to decimal input.
On a side note i hate the size limitations for it, I can't do a 8 digit n (which would be used for dates mmddyyyy)
Also the library is what you made earlier except for a decimal to binary conversion, the source combined into one custom script, and all the functions renamed so that it doesn't clash with starcode.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
@willuwontu: Go e is binary for fast powering algorithm in modulo ring. Other numbers are strings in decimal format. Galaxy code uses 32 bit signed integers ("int"), that can represent values in −2 147 483 648 — +2 147 483 647, therefore you can't convert from my string using StringToInt built in function, becasue I use primes with hundreds of digits. I use decimal string to speed up computation time compared to binary, and keep implementation easy (compared to higher bases).
You can't use n for anything, it's part of public key!
Why are people still fumbling around with strings?
@ShadowDancer93: Go
yes n can't be used for anything, however n is the maximum size for any data that you encrypt and want to be able to restore (eg. can't store 20150101 with an n of 3233)
@ImperialGood: Go
How else would you do it?
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
Still waiting for somebody who will write bignum on arrays :) Go on!
@willuwontu: Go
In my example data n has 309 digits - date should fit in there :)
@ShadowDancer93: Go
Your test only tried to encode it. I find that when I try to decode any thing over 7 digits it returns wrong. No idea why either, i made it correctly and it works on my computer calculator.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
Do keep in mind the idea is for you to first generate a cryptographic hash of the message (eg SHA-1) and then apply RSA to that. As such I would recommend multiplies of 256 bits for the length (where more is more secure but slower and more space wasting). A good compromise might be 512 bits (86 characters) as it probably is not unbreakable however the chances of someone with the skills and resources breaking it is negligible. You could also make things harder by changing the public and private key from time to time.
Do keep in mind that these signatures need to be pretty big to be secure. Recommended RSA keys now are 2048 to 4096 bits long.