CAPCHA-T
CAPCHA-T (pronounced as Capchat) is an idea which can be used to make messaging hard to eavesdrop. It is intended for sending and receiving private data which you do not want and 3rd person to be able to read or to eavesdrop. Also you do not want the chat / messaging history to be saved anywhere.
In order to achieve anything like that it seems the safest option is to have thick client to thick client chat where each client will itself be client and server on its own.
Like the name suggest, the idea comes from the way image capchas work on various websites which basically prevents BOTs or scripts from accessing services unless it is an actual human being. The capcha image is requested once and it is expired when it is already used once or it expires certain amount of time. The images are generated variously depending on how hard you want to make it for it to be read automatically.
I would now define a protocol by which we will achieve this idea.
CAPCHA-T Protocol
The following image illustrates how this can work,
As we can see from above, the way it works is, user 1 sending the message when they commits a message,
Now when the client at user 2 receives the message in form of the key, the client makes a request using the key to be rendered at their end. The user sees the message on their screen in form of an image rendered much like capchas or whatever the rendering function would do to render the text as image.
The protocol should also extend to point that their should be basically 3 functions implemented 1) Text to image renderer 2) Key generator and 3) Algorithms to send and receive these files in order to make it more secured if possible in the future.
The following are the good and bad sides of this approach
Pros
How it might look when implemented
I am planning to come up with a PHP, HTML, JS based implementation soon.
Note : The above idea is intended only for 'exploring ideas' purpose. And we should keep in mind that with great powers should come great responsibilities :).
CAPCHA-T (pronounced as Capchat) is an idea which can be used to make messaging hard to eavesdrop. It is intended for sending and receiving private data which you do not want and 3rd person to be able to read or to eavesdrop. Also you do not want the chat / messaging history to be saved anywhere.
In order to achieve anything like that it seems the safest option is to have thick client to thick client chat where each client will itself be client and server on its own.
Like the name suggest, the idea comes from the way image capchas work on various websites which basically prevents BOTs or scripts from accessing services unless it is an actual human being. The capcha image is requested once and it is expired when it is already used once or it expires certain amount of time. The images are generated variously depending on how hard you want to make it for it to be read automatically.
I would now define a protocol by which we will achieve this idea.
CAPCHA-T Protocol
The following image illustrates how this can work,
As we can see from above, the way it works is, user 1 sending the message when they commits a message,
- The message is first rendered at clients end as an image.
- A key is assigned to the message at clients end which can be a hash tag or a randomly generated key with timestamp and the key is attached to the image, i.e. the image can be requested using the key. We also set flags for when the key expires etc.
- The key is sent to the other end, user 2, instead of the message.
Now when the client at user 2 receives the message in form of the key, the client makes a request using the key to be rendered at their end. The user sees the message on their screen in form of an image rendered much like capchas or whatever the rendering function would do to render the text as image.
The protocol should also extend to point that their should be basically 3 functions implemented 1) Text to image renderer 2) Key generator and 3) Algorithms to send and receive these files in order to make it more secured if possible in the future.
The following are the good and bad sides of this approach
Pros
- Hard to eavesdrop / tap, making it more secured.
- Hard to find, as messages expires after one request, cannot be re-requested, if stored then only at the main senders end.
- Heavy weight messages.
- Thus slow.
- un-searchable (search could be achieved by adding tags etc if used as emails, just thinking).
How it might look when implemented
I am planning to come up with a PHP, HTML, JS based implementation soon.
Note : The above idea is intended only for 'exploring ideas' purpose. And we should keep in mind that with great powers should come great responsibilities :).
