No Chat Reports

No Chat Reports

43M Downloads

Diffie-Hellman key exchange

zerochill-1 opened this issue ยท 6 comments

commented

Idea

Use of Diffie-Hellman key exchange via minecraft /msg to obtain a shared secret that can be used as the decryption key or phrase for encrypted chat between two NCR users.

Reasoning

To share an encryption key or passphrase in a secure way with another NCR user if you don't have any other form of contact with the other player.

Other Information

No response

commented

the server can still change the key before it reaches the other player (mitm), it doesnt matter if you use some rsa public key to encrypt data or a key for use in dh exchange.
if public keys are sent with minecraft chat, you still need to verify with a secure channel between the 2 users that the right key is received

commented

with DH key exchange, no observer can know the complete key. It would be quite hard to find valid data to spoof a key during negotiation and would be impractical (at that point you could likely just as well bruteforce the actual key and decrypt messages that way)

You could do it out-of-band as well (like over some external server)

commented

with DH key exchange, no observer can know the complete key

the server is not only an observer, it can change content on the way to the receiver

It would be quite hard to find valid data to spoof a key during negotiation and would be impractical (at that point you could likely just as well bruteforce the actual key and decrypt messages that way)

no.
imagine player A and B, and a server
keypairs are generated
player A has a keypair (a, A) (a is the private key, A the public key) A, B has (b, B), and the server generates two keypairs (s1, S1) and (s2, S2).
normal procedure:
player A sends A in the chat, player B sends B in the chat, player A sees it and calculates aB, player B sees player A's message and calculates bA. aB == bA so you have a shared secret.
now the server is evil:
player A sends A in the chat, the server records this and sends out S1 (as if player A sent this), player B sends B and the server again intercepts this and sends S2. player A has aS2, a shared secret between the server and player A and B has bS1, a shared secret between the server and player B. the server has As1 and Bs2. when player A encrypts a message using aS1, the server decrypts it using As2 and encrypts it with Bs1, so player B can decrypt it with bS1, player A and B think their communication is private, but the server can read and change the messages.
A and B at least have to verify using a secure channel that their shared secrets are the same (or hashed to not have to send a secret but instead a fingerprint)

commented

You can sign the sent key with the player's chat signing key and then verify that on the other player's client, retrying/refusing the key exchange if said signature is invalid

commented

You can sign the sent key with the player's chat reporting key and then verify that on the other player's client, retrying/refusing the key exchange if said signature is invalid

this would work, but this introduces a trusted third party (microsoft), why not use the chat keys in the first place then? that key exchange is already done when connecting to servers

commented

@kcinnaJlol by the way, this would not be safe on realms, as microsoft owns the chat signing keys