You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 13, 2022. It is now read-only.
Raknet uses Diffie-Hellman key agreement protocol to do key exchange with a precondition that the long-term server public key is given to clients in some secured way(possibly hard-coded in executive).
PS. the public key i refer to has nothing to do with RSA. Some possible bugs in connect() function makes it very vulnerable to the MITM attacks, the explanations are shown below:
Client keeps secret of its private key c but send its public key C to server in challenge
Server answers the challenge
the client side public key and private key is generated based on the server side public key
in function KeyAgreementInitiator::GenerateChallenge()
// A = client public key,a = client private key
GenerateKey(math, csprng, a);
However math is initialised based on server side public key in function KeyAgreementInitiator::Initialize()
// Unpack the responder's public key
if (!math->LoadVerifyAffineXY(responder_public_key, responder_public_key + KeyBytes, B))
return false;
So, as we see, in the whole sage, the most important variable is server side public key that is pre-given to client. However, Raknet send it to client in the id_connection_request_replay_1 message in clear text !
Someone has done research on this part and we can talk about it. This problem really has been bothering me a long time.
The text was updated successfully, but these errors were encountered:
Do you have any ideas on how to address this? I haven't yet absorbed the issue properly so I don't have anything of value to add. I'd like to find some time to remedy this, so ideas would be great.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Raknet uses Diffie-Hellman key agreement protocol to do key exchange with a precondition that the long-term server public key is given to clients in some secured way(possibly hard-coded in executive).
PS. the public key i refer to has nothing to do with RSA. Some possible bugs in connect() function makes it very vulnerable to the MITM attacks, the explanations are shown below:
in function KeyAgreementInitiator::GenerateChallenge()
// A = client public key,a = client private key
GenerateKey(math, csprng, a);
However math is initialised based on server side public key in function KeyAgreementInitiator::Initialize()
// Unpack the responder's public key
if (!math->LoadVerifyAffineXY(responder_public_key, responder_public_key + KeyBytes, B))
return false;
So, as we see, in the whole sage, the most important variable is server side public key that is pre-given to client. However, Raknet send it to client in the id_connection_request_replay_1 message in clear text !
Someone has done research on this part and we can talk about it. This problem really has been bothering me a long time.
The text was updated successfully, but these errors were encountered: