Prevent server from cheating (MITM attack) ! about serch HOT 17 OPEN

This is one of the biggest human problems today, and I am happy to have a share in solving it! And also thank you very much for reminding of this problem. You need to know that you are doing a very valuable work in the world.

💛

We have no choice but to remove the server from this story. But there will always be servers in the world that users can not avoid their services!

So it is better to make a public space that everyone can see. Public keys and users ID are stored in it.

The server only has a duty that if Alice requests Bob's public key, the server will provide it.

But Alice checks the validity of the public key and Bob's ID with the visible public space (e.g., blockchain).

Each user, after generating his public key for the first time, must checks the blockchain that the server did not cheat.

from serch.

Now, i find a bad problem now!!!

if server generate anonymous IDs/ public keys and save it in blockchain, Nobody know which IDs created by server.

So, if server lies to alice about bob public key, alice can underestant it. Becouse bob's ID will not valids by that fake public key. But what happens if alice don't sure about bob ID?

How mean if server, lies about ID of bob?
Server lies about id and public key!

Only for famous persons, it will not happened, couse every one know their ID.

from serch.

@DwS5KaMxi2pZ3Lw

no, it not i mean.

if alice havn't bob's id,
she ask it to a random node in blockchain.

if alice have id but havn't pk,
she ask it to server.

than server can't cheat

That's probably a good idea, but it seems like a solution that can be implemented in a P2P topology.

We're running a CS topology. That's why I'm looking for other solutions...

I came across another good idea, while asking my question in different forums, I'll post it a in a separate comment.

from serch.

One Known solution for MItM is SAS : "Short Athentication String"

A short authentication string (SAS) is a sequence of characters, usually six or eight digits long, used to authenticate devices or users in secure communication protocols. SAS is commonly used in end-to-end encrypted messaging applications, such as Signal and WhatsApp, to verify the identity of the user on each end of the conversation. During the encryption key exchange process, both parties compare the SAS displayed on their respective devices to ensure that they have a shared secret that has not been compromised by a third party. This provides an additional layer of security for the communication, as it helps to prevent man-in-the-middle attacks.

Here is an example of Signal messaging app. When two users initiate a new conversation for the first time, Signal uses an asymmetric key exchange protocol to generate encryption keys that will be used to secure their communication. During this process, both users are presented with a SAS code, which is a sequence of five digits.

For example, user A sees the following SAS code: 12345
And user B sees the same SAS code: 12345

Both users can compare the SAS codes displayed on their devices to ensure that they match. This indicates that they are communicating directly with each other and that no one is intercepting or altering their messages. If the SAS codes do not match, it means that there may be a security breach, and the users should not proceed with the communication.

Once the SAS codes are verified, the users can complete the key exchange process, and Signal encrypts all subsequent messages using the shared encryption keys. This ensures that only the intended recipients can read the messages, even if they are intercepted by a third party.

This is also what Telegram does to ensure security for calls using emojis.

I can turn this solution into something cool and workable for SeRCH, but not an eventual solution.
We need something more solid:3

from serch.

Found something cool and more solid:3

Interlock protocol

Read "How to Expose an Eavesdropper" by RONALD L. RIVEST and ADI SHAMIR.
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.159.1673&rep=rep1&type=pdf

From Wikipedia:

In cryptography, the interlock protocol, as described by Ron Rivest and Adi Shamir, is a protocol designed to frustrate eavesdropper attack against two parties that use an anonymous key exchange protocol to secure their conversation. A further paper proposed using it as an authentication protocol, which was subsequently broken.

Most cryptographic protocols rely on the prior establishment of secret or public keys or passwords. However, the Diffie–Hellman key exchange protocol introduced the concept of two parties establishing a secure channel (that is, with at least some desirable security properties) without any such prior agreement. Unauthenticated Diffie–Hellman, as an anonymous key agreement protocol, has long been known to be subject to man in the middle attack. However, the dream of a "zipless" mutually authenticated secure channel remained. The Interlock Protocol was described as a method to expose a middle-man who might try to compromise two parties that use anonymous key agreement to secure their conversation.

How it works:

The Interlock protocol works roughly as follows:

Alice encrypts her message with Bob's key, then sends half her encrypted message to Bob.
Bob encrypts his message with Alice's key and sends half of his encrypted message to Alice.
Alice then sends the other half of her message to Bob, who sends the other half of his.

The strength of the protocol lies in the fact that half of an encrypted message cannot be decrypted. Thus, if Mallory begins her attack and intercepts Bob and Alice's keys, Mallory will be unable to decrypt Alice's half-message (encrypted using her key) and re-encrypt it using Bob's key. She must wait until both halves of the message have been received to read it, and can only succeed in duping one of the parties if she composes a completely new message.

Now, This is brilliant way to expose a MItM, but that can't be used as a totally assured authentication. The MItM obviously knows the drill, and cannot be easily deceived that way, all he needs to do is to prepare a pre-encrypted message divided in two parts, although it may not match the content of original message and it may expose him, but still not a definitive approach.

But I believe it can be inspiration of some solid approach:3

from serch.

@DwS5KaMxi2pZ3Lw

First of all, ThanQ for your contribution.

And it's very kind of you to join the project <3

So it is better to make a public space that everyone can see. Public keys and users ID are stored in it.

The server only has a duty that if Alice requests Bob's public key, the server will provide it.

But Alice checks the validity of the public key and Bob's ID with the visible public space (e.g., blockchain).

Each user, after generating his public key for the first time, must checks the blockchain that the server did not cheat.

To be honest , this was a great idea , and you blew my mind. 👍

The blockchain idea is great 🥇

We can have each block get signed by the owner of keys that this specific block is validating .

We just need to discuss the details of that blockchain....

I know it's gonna solve our problem , I'm sure of that:)

ThanQ again.

So, if server lies to alice about bob public key, alice can underestant it. Becouse bob's ID will not valids by that fake public key. But what happens if alice don't sure about bob ID?

Bloody hell , You're so right!

That is going to be a problem...!

We should think it over...

from serch.

Users never trusts to server about ID.
but they can trusts to blockchain.

Ok,

If Alice have bob's ID, so good but she must not asked server that bob's id befor!

from serch.

Who can save data in blockchain?

• 1server get a sign of user and save it in blockchain. then Users only can see blockchain. And DDOS on blockchain will not happens( 51% attack). But server have a little control! (Savers, only listen to server and check data, answer to everybody's request and...)

• 2 every user can send and save data in blockchain.
  But we need receive a little money of new users for we will sure about security and attacks. This money will be monero or zcash.( if attack happens, savers and server, get rich 😅 also services will free after it 😉)

What we choose? 1 or 2?

from serch.

I find a way but that is not so good.

If alice has bob's id, it's not problem couse blockchain is visible and every [public keys group] has appened to one id.

But if alice has not bob's id, how can alice tell to server who is bob? without (searching name or familly or ...)?

If id be only way to accessing to bob, alice can't find bob.

Ok, alice can't find bob ==> server can't find bob's id ==> server can't tell to aice find bob's id couse that's unfindable!

Ok
Alice will not talk to bob!

only way to access to bob is bob's id and no searching bob's name or ...

Only bob's id

alice will not beilive any id/public key from server.

alice only beilive once : id or public key, couse she can check it

from serch.

@DwS5KaMxi2pZ3Lw

ThanQ for your valuable ideas,...

Let's have a small observation on what you said:

1server get a sign of user and save it in blockchain. then Users only can see blockchain. And DDOS on blockchain will not
happens( 51% attack). But server have a little control! (Savers, only listen to server and check data, answer to everybody's
request and...)

What I know for sure is : 51% attack has nothing to do DDOS.

DDOS stands for Distributed Denial Of Service , which is when a system goes down because of the flood of requests, sent by different points at a certain time.

51% attack is the possibility of cheating of a group of minors controlling more than 50% of the network, and validating false blocks in a chain.

These two are totally different.

DDOS attack is possible in our scenario, since it is possible in all Client-Server architectures.

What we choose? 1 or 2?

I put it this way:
Our system architecture is CS (Client-Server) , so , like it or not there's a server involved!

If we aimed for a system which was running in hands of users , we shall implemented a P2P (Peer-to-Peer) architecture, which is a great idea , and I myself prefer P2P , but it's our next step.

In this specific project, we're obligated to rely on server. that's why we have to choose first option.

On success , after this protocol , we implement that second option alongside with a P2P network.

I find a way but that is not so good.

If alice has bob's id, it's not problem couse blockchain is visible and every [public keys group] has appened to one id.

But if alice has not bob's id, how can alice tell to server who is bob? without (searching name or familly or ...)?

If id be only way to accessing to bob, alice can't find bob.

Ok, alice can't find bob ==> server can't find bob's id ==> server can't tell to aice find bob's id couse that's unfindable!

Ok
Alice will not talk to bob!

only way to access to bob is bob's id and no searching bob's name or ...

Only bob's id

alice will not beilive any id/public key from server.

alice only beilive once : id or public key, couse she can check it

I'm not sure if I understood the gist of your conversation here, can you please explain a little more about that?

from serch.

Thank you very very very very very very much for your reply.

I'm not so good in network, i love learning about cryptography and programming. Than your reply will good for me!

For more explain , i think it will be better than only way to alice find bob's pk, be knowing bob id.

alice don't can find bob by searching server for bob id/pk

Alice must not except bob's pk from server if sha haven't bob's id .

Searching in database will happens by one or any random node in blockchain
And alice get sure about bob's id from blockchain not server

from serch.

@DwS5KaMxi2pZ3Lw

I think I've got the general idea...

You mean a user (Alice) , shouldn't trust on pk , based on what server said...

They shall ask another client (randomly picked) on the network.

They ask:

Hey , can you send me Bob's pk?

Third client asks the server about Bob's pk, and checks with the blockchain and tells the result to Alice..

Is this what you mean?

If so, I tell you it's a fascinating idea! -

but there's still the a possibility of cheating...

Server makes a fake block FOR EACH USER on the blockchain (for example for Bob , makes a certain fake ID and pk and signs it on blockchain ), and tells that to everyone.

The problem is still there...

from serch.

no, it not i mean.

if alice havn't bob's id,
she ask it to a random node in blockchain.

if alice have id but havn't pk,
she ask it to server.

than server can't cheat

from serch.

Hi sweet Behrad

Sometimes the solution for the protocol we wanted to design has come to my mind.

(I was translated by google, and i tried to fix it!😅)

We know that having a very safe exchange key without contact in contact with the person and a key exchange (perhaps through the server) is impossible. But why once?

Ancient Iranian ...

It is quoted that ancient Iranians used a good trick to provide government orders because of the tough communication at the time.

The king wrote two alike letters to his commander, then asked for one of the two candidates who did not know each other, and they sent the letter from two different paths to the commander. The commander compared the letters. If the content was one; He followed the order.

I was inspired by their method and came to my mind in this way:

1. Alice and Bob are connecting twice

2. Alice and Bob use their first communication information in the second commitment without mentioning it directly

3. If the server betrays in one or two steps, the end result will be in trouble that mitm attack not be success!

4. The server cannot detect that the second message is related to the wich other msg at past. Because IPs changed and the server is usually unable to find real alice and bob, that can not teach

from serch.

@DwS5KaMxi2pZ3Lw

1. Alice and Bob are connecting twice

2. Alice and Bob use their first communication information in the second commitment without mentioning it directly

3. If the server betrays in one or two steps, the end result will be in trouble that mitm attack not be success!

4. The server cannot detect that the second message is related to the wich other msg at past. Because IPs changed and the server is usually unable to find real alice and bob, that can not teach

This is actually a great approach, that helps alongside with other approaches, but in something like P2P networks.
We are in a CS architecture, which leaves us with only one connection line.

from serch.

This make me happy ;

Want to invent a new encryption algorhythm like this?

from serch.

@DwS5KaMxi2pZ3Lw

Like I said :

This is brilliant way to expose a MItM, but that can't be used as a totally assured authentication. The MItM obviously knows the drill, and cannot be easily deceived that way, all he needs to do is to prepare a pre-encrypted message divided in two parts, although it may not match the content of original message and it may expose him, but still not a definitive approach. But I believe it can be inspiration of some solid approach.

from serch.