Cryptography Implementation Discussion

[Ipquarx]

how is the key transmitted or synchronously generated securely?

The same way we discussed earlier, the host does something that allows us to generate entropy out of it, and then we generate random numbers out of that entropy.

Most CSPRNGs DO use block ciphers like AES as a basis for the actual generation of the numbers, so in the end AES is still a necessity, but less so.

[Ad Bot]

[Lugnut]

how do we send it to the client???
am I missing a big point here? i'm ill, so that's a possibility, but I'm not sure how we prevent a MITM attack on the secret key

it isn't safe to rely on client side interpretation of the entropy gathering we mentioned earlier, either.

[Ipquarx]

We send it to the client completely unencrypted as we don't need to, any man in the middle attack that would intercept that would just invalidate the data. (And the server can code the secret key to change based on the client so only that specific client can use the data.)

Generating entropy will be a one-time deal for a server. If you manage to pull off a man in the middle attack to generate the entropy for the host, then you have effectively broken blockland as a whole. This is NOT our concern, since we cannot change how blockland works and we can't prevent an attacker from going to the host's house and holding them hostage while he generates entropy.

[Lugnut]

alright now i'm positive i'm missing something
i'll use sha1 cause it's on hand for my example, as I understand you're using it

ideal situation:
SERVER: hello world - 4535ac92c9ef45c5a208ba008168b 4335567ea89 - [SECRETKEYLOL]
CLIENT: (verifies that "hello world[SECRETKEYLOL]" corresponds to the given hash)
CLIENT: HELLO SERVER - 9bed34acf0f92253c75b328464eb8 487a4d89ac0 - [SECRETKEYLOL]
yay!

actual situation:
SERVER: hello world - 4535ac92c9ef45c5a208ba008168b 4335567ea89 - [SECRETKEYLOL]
EVE: (mmm nevermind, won't send that message)
EVE: hello client - c3e3f6de645a38e2037e36ee76573 b682b977e75 - [SECRETKEYLOL]
CLIENT: (verifies message eve sent, it checks out - wow, a personal introduction!)
CLIENT: HELLO SERVER - 9bed34acf0f92253c75b328464eb8 487a4d89ac0 - [SECRETKEYLOL]

what am I missing? the only way around this is to securely transmit the random seed and have them generate the secret key client and server side, never actually sending the secret key.
alternatively, send the secret key itself via secure methods

if we could securely transmit the hash, then yes, this would work - if the attacker has no way to modify the hash then the best they could do is DoS. however, I don't think that's what you're suggesting

[Ipquarx]

I'm not sure you're getting how HMAC works...

Here's what would would happen.

Message: "1111"
Secret key: "T0Ps3cReT"

Server calculates HMAC(Message, Secret Key) [ 0ad96cc2de36916da025bc60226b8 2c396ffa50f ]
Server appends HMAC to message [ 1111 0ad96cc2de36916da025bc60226b8 2c396ffa50f ]
Server sends message to client

Client receives message
Client tries to edit message to gain an unfair advantage: Message = "9999"
Client sends message to server [ 9999 0ad96cc2de36916da025bc60226b8 2c396ffa50f ]

Server receives message [ 9999 0ad96cc2de36916da025bc60226b8 2c396ffa50f ]
Server calculates HMAC(message, secret key) [ aaecb9288b5ad5530958bf57dfc43 cf2d0396c22 ]
Server checks if new HMAC == received HMAC [ False! ]

Server concludes that the message was edited and is therefore invalid. The HMAC reveals nothing about the key, and you can't edit the signature or message without both becoming invalid.

http://www.freeformatter.com/hmac-generator.html

[Lugnut]

while I did not perfectly understand how the hmac works, I dont think you have a perfect understanding of a good use case. hmac uses symmetric keys. the client and the server must both know the key for it to work. if the client does not know the key, they cannot verify the message.
the purpose of an hmac is to prevent a man in the middle from altering the message.
this: yes
Server calculates HMAC(Message, Secret Key) [ 0ad96cc2de36916da025bc60226b8 2c396ffa50f ]
Server appends HMAC to message [ 1111 0ad96cc2de36916da025bc60226b8 2c396ffa50f ]
Server sends message to client

Client receives message
Client verifies message by using their secret key. HMAC(Message, Secret Key) [ 0ad96cc2de36916da025bc60226b8 2c396ffa50f ]
DONE. there is no editing of the message - that's the trusting the client thing except not, because cryptography. just don't listen to them at all.

the point of the hmac is to make sure that someone with the secret key sent that specific message.

http://security.stackexchange.com/questions/20129/how-when-do-i-use-hmac

the first guy explains it pretty well

[Ipquarx]

The client does not need to verify the information because the client does not USE the information.

If the client absolutely NEEDS to verify the information then you need to use public-key crypto.

[Lugnut]

then why the forget are we implementing this if the client doesn't do it

wtf?!?!??

aside from general purpose crypto (maybe some kind of password system with verification) implementations, I don't see the point!?

[Ipquarx]

Because how damn long it takes to do public-key crypto. If we don't need to use it then we don't, and there are a multitude of reasons one would not need to use it. (Storing a message on the client side for use by the server later + disallowing tampering is the example I gave)

TL;DR we only use public-key crypto when absolutely necessary, in cases like my example there isn't a need for it as the client cannot know the key, in order to prevent tampering. this is not a purely public-key crypto support library

TO CLARIFY: we WILL be implementing authenticated messages that the client can authenticate as well

[Lugnut]

okay... you're the one doing it....
could we focus on getting the following three things working though please
a: asymmetric key encryption (ecc, apparently)
b: symmetric key encryption (aes, apparently)
c: hashing/authentication (can't we get away with sha1, i guess not, hmac then)
before we go onto anything else??

aes and hmac are used in tandem you know

[Ipquarx]

If you have alternatives to ECC, AES, and sha1 that are faster/better then please, let me know.

[Lugnut]

no, sorry, that last post was misleading

to the best of my knowledge those are the fastest effective ones out there

[Ipquarx]

I might've figured out a way to speed up multiplication by 4-6x. Holy crap. This could seriously reduce the time to do ECC from just over 20 seconds to just over FOUR.

Assuming my calculations are right..

[Lugnut]

Are these optimizations cryptographically sound?

[Ipquarx]

Are these optimizations cryptographically sound?

What do you mean?