Author Topic: Cryptography Implementation Discussion  (Read 16025 times)

I can't suggest any examples seeing as I don't actually know any multiplication algorithms, but aside from flat out breaking the thing using torque, are these optimizations and multiplication algorithms suitable for cryptographical use?
I can't see how they wouldn't be, but maybe you could do a quick google check or something for "[algorithm name] crypto" or "[algorithm name] crypto problems"

I don't see how it wouldn't be as well. I mean if you multiply 100 by 10000000 it's going to be somewhat faster than 949 by 15025823, but it's pretty non-dependant on the data except for statistically very rare inputs.

In other words, it might be faster by maybe a tenth of a ms for every one in 10,000,000 inputs.

On top of that I've yet to actually test it! I HOPE it's that much faster but anything could happen.

Dammit, my math was wrong. It's slower. Ugh.
« Last Edit: February 07, 2014, 06:26:50 PM by Ipquarx »

That's... not... secure... do you even understand how cryptography WORKS?

If you take a message 1111 and then send it in plaintext with a signature, that is NOT SECURE. That is VERIFIED, NOT SECURE.

Anyone between the two endpoints who's listening in can still hear that the payload is 1111. They can't CHANGE it, but they can still HEAR it.


And that's not even getting into the fact that you haven't actually shown how the secret key is spontaneously generated the same on both the client and the server - anyone who intercepted the no-longer-secure secret key could change the message any way they want. So now it's not verified OR secure.

To authenticate with websites and the like, wouldn't we need to use public key cryptography?

That's... not... secure... do you even understand how cryptography WORKS?

If you take a message 1111 and then send it in plaintext with a signature, that is NOT SECURE. That is VERIFIED, NOT SECURE.

Anyone between the two endpoints who's listening in can still hear that the payload is 1111. They can't CHANGE it, but they can still HEAR it.


And that's not even getting into the fact that you haven't actually shown how the secret key is spontaneously generated the same on both the client and the server - anyone who intercepted the no-longer-secure secret key could change the message any way they want. So now it's not verified OR secure.
What are you talking about? If you mean my example on a use for HMAC, that was an example of a scenario where it would only be necessary to use just HMAC.

Are player stats sensitive information? No.
Does the player need to verify the information? They can if they want to, by comparing their stats against the message, which could also be automated in the client addon.
But they can't know the signing key otherwise they can change the data without it becoming invalid. Which is bad, if you read the scenario.

I literally specifically chose that example to not use public key crypto whatsoever.

-wat-

Username: Xalos    Password: password1    Hash: 73e560390f1d9daf423ff39919811 39384f9f6a2


Gee, that sure will help keep my password secure, won't it!

they can change the data without it becoming invalid.
why are we even using user input at all

this isn't even a problem that needs fixing - just flat out ignore user input that doesn't need input

why are we even using user input at all

this isn't even a problem that needs fixing - just flat out ignore user input that doesn't need input
Bleh I don't think either of you understand the example I wrote, so here it is again:

You have a server, running a server mod that involves players having different stats, some examples could be money, titles, achievements, etc.

This server mod also comes with a client mod that people can download and use on the server.

The server doesn't want players to loose their stats in the event of a crash or other game-ending and possibly data-loss inducing event, so it wants to store the players stats on the clients harddrive as well as their own, so they can use it combined with a server command of some sort to restore their stats from the file.

Now you may say, "This is a horrible idea! They can edit it!" and you'd be right, but we can prevent that!

How? Using HMAC! Simply sign the data with a secret key that's only known on the server, and send it to the client. Then the client can't change the data without invalidating it.

If you still can't understand that then that's legitimately not my problem anymore.

i get it now, but i feel like that's a major fringe case

Bump from the dead :cookie:

Just changed up the way multiplication works entirely, now instead of using strings it will use an array of global variables each containing 16 bits of the number.

I have some modifications to do, but once it's done multiplication will be an impressive 3.44 times faster than it was before, which will reduce the time needed in total from around 40 seconds without lag to around 15 seconds without lag, or 7 seconds with it.

I have successfully calculated 1000! (1000 factorial) in 3.5 seconds.
1000! is ~102567.

100! takes less than a tenth of a second, and is ~10158.

I'd say this is pretty good!

Do 2147483647 factorial. :P

xalos pls
here have a wolframalpha approximation