## Title MYTalken: Private communication between human parties in untrusted environments ## Abstract We draw an all-purpose pragmatic procedure to enable verified trusted private communications between human parties initiated from an untrusted environment, such as the Internet, a social network, a forum or a chat application. MYTalken is built on the core principles of simpleness, practicality, anonymity, security and efficiency. This subject is truthfully relevant nowadays, when the majority of Internet clients are represented by bots and AI agents, often operated by companies or governments to gather data or merely to ameliorate their platforms. ## Section Computer Security and Cryptography ## Keywords key exchange, human recognition, untrusted environment, secure communication, captcha, anonymity, privacy, security, private communications, AI detection, Turing test ## Formulation of Research Subject We define two Internet users -- Alice and Bob -- who want to build a safe communication channel in an efficient way without being intercepted or annoyed by automatized AI bots. This subject is truthfully relevant nowadays, when the majority of Internet clients comprise bots and AI agents, often operated by companies or governments to gather data or merely to ameliorate their platforms. We model this research subject into two well-studied sub-subjects: ### Key Exchange Key exchange [1] is a classical, well studied subject in cryptography and security research. It comprises a protocol to produce a secret shared key for posterior encrypted communications. ### Human Recognition Recognition of human behavior [2] on the Internet is an other classical research subject, since the first appearance of the Turing test [3] to single out human and computer behavior. ## Previous Research ### Key Exchange The task of key exchange is normally handled by one of these systems: 1. Public key schemes Public key schemes, also called asymmetric cryptographic systems, are algorithms to produce a public key -- that can be distributed -- used to encrypt messages and a private key -- that must be retained secret -- used to decrypt them on the side of the receiver. 2. Different protocols There are also different protocols or mathematical procedures to produce a shared secret key. One of the most famous ones is the Diffie-Helmann (DH) key exchange [4], frequently used in network communications. For an inclusive survey about traditional public key and exchange schemes, the reader can consult [1]. ### Human Recognition Human recognition is normally performed by CAPTCHA systems and AI algorithms. Nonetheless, this research is solely restricted to preserving anonymity and security for clients. #### CAPTCHAs CAPTCHAs are used in web sites to stop harmful interactions. They normally require clients to perform complex tasks like image recognition and reasoning. They sometimes use hash functions as an additive layer of complexness. For an inclusive survey about CAPTCHA systems, the reader can consult [2]. ## Research Answer The proposed process incorporates an operational semi automatized protocol to perform a key exchange, along with a CAPTCHA check. The process is straightforward and is delineated below. The premise is that Alice and Bob can share messages on the same untrusted platform. 1. Alice shortly announces that she wishes to initiate the protocol. She proposes a key exchange protocol, a human recognition system and a nonmandatory substitute platform believed to be more trustworthy and less risky. + To exemplify, she may simply write: "MYTalken, DH, English audio-to-text recognition. DH Parameters=0x.......". As the protocol is still little-known at present, she may also include a reference link to this research work. 2. Bob reads the message, joins the substitute platform, if nominated, and performs the key exchange. 3. After the key exchange, Alice and Bob confirm and use the CAPTCHA system to recognize that they are humans. 4. Alice and Bob can communicate via the encrypted channel. To increase efficiency, we propose short names to replace common options below. -------------------------------------------------------------------------------------------------- | Short Name | Key Exchange Scheme, Human Recognition System, Substitute Platform | -------------------------------------------------------------------------------------------------- | MYTalkenV1.1 | DH, written talk, email address | | MYTalkenV1.2 | DH, written talk, own web page | | MYTalkenV1.3 | DH, written talk, own web page, including public key | | MYTalkenV1.4 | DH, written talk, modifiable external web page | | MYTalkenV1.5 | DH, image CAPTCHA, email address | | MYTalkenV1.6 | DH, image CAPTCHA, own web page | | MYTalkenV1.7 | DH, image CAPTCHA, own web page, including public key | | MYTalkenV1.8 | DH, image CAPTCHA, modifiable external web page | | MYTalkenV1.9 | DH, audio CAPTCHA, email address | | MYTalkenV1.10 | DH, audio CAPTCHA, own web page | | MYTalkenV1.11 | DH, audio CAPTCHA, own web page, including public key | | MYTalkenV1.12 | DH, audio CAPTCHA, modifiable external web page | | MYTalkenV1.13 | direct key exchange, written talk, own web page | | MYTalkenV1.14 | direct key exchange, image CAPTCHA, own web page | | MYTalkenV1.15 | direct key exchange, audio CAPTCHA, own web page | | MYTalkenV1.16 | direct key exchange, written talk, modifiable external web page (NA) | | MYTalkenV1.17 | direct key exchange, image CAPTCHA, modifiable external web page (NA) | | MYTalkenV1.18 | direct key exchange, audio CAPTCHA, modifiable external web page (NA) | | MYTalkenV1.19 | PGP, written talk, email address (NA) | | MYTalkenV1.20 | PGP, image CAPTCHA, email address (NA) | | MYTalkenV1.21 | PGP, audio CAPTCHA, email address (NA) | | MYTalkenV1.22 | PGP, written talk, own web page including public key | | MYTalkenV1.23 | PGP, image CAPTCHA, own web page including public key | | MYTalkenV1.24 | PGP, audio CAPTCHA, own web page including public key | -------------------------------------------------------------------------------------------------- + NA=Not Advised for security + NAA=Not Advised for Any application An other better way to nominate an abbreviation is to use the form MYTalkenV1 A,B,C, where A,B,C are taken from the below tables. --------------------------------------------------------------------------------- | Number | Key Exchange Name (A) | --------------------------------------------------------------------------------- | 0 | direct key exchange (NA) | | 1 | Diffie-Helman (DH) | | 2 | PGP | | 3 | OpenSSL public key system | | 4 | no key exchange (NAA) | | 5 | other | --------------------------------------------------------------------------------- --------------------------------------------------------------------------------- | Number | Human Recognition System (B) | --------------------------------------------------------------------------------- | 0 | written talk | | 1 | to be nominated later | | 2 | text CAPTCHA | | 3 | image CAPTCHA | | 4 | audio CAPTCHA | | 5 | other | --------------------------------------------------------------------------------- --------------------------------------------------------------------------------- | Number | Substitute Platform (C) | --------------------------------------------------------------------------------- | 0 | empty (NA) | | 1 | to be nominated later (NA) | | 2 | own web page | | 3 | own web page including public key | | 4 | modifiable external web page | | 5 | external chat | | 6 | external social or forum with private messaging | | 7 | email address | | 8 | other | --------------------------------------------------------------------------------- It's essential to observe that nominating protocols beforehand ameliorates efficiency by preventing both clients to start a protocol with unsupported operations. To exemplify, OpenSSL might not be supported on a specific platform, thence it's better to nominate it beforehand. In place of lines like "MYTalkenV11.24 = PGP, written talk, own web page including public key", it is more efficient and painless to write "MYTalkenV11 2,0,3". Recall as well that the key exchange behaves as a first roadblock for bots, thence Alice may simply designate "written talk" as human recognition system and perchance propose to Bob an other check at the upcoming talk. ## Limitations + The subject can be generalized to permit more than two people, but the core of this research is restricted to two parties. + The protocol fully entrusts the security of its underling components, a key exchange protocol and a human detection mechanism. Nonetheless, present protocols ceaselessly renewed by progression in research, show many limits yet, including the hypothesis of posterior subversion by emerging machines [1]. + Attackers operating the untrusted environment can manipulate the first channel between Alice and Bob or completely obstruct their communications. Nonetheless, in all probability, this can be detected by them or outside observers. Extra studies about this harsh subject will be aim of upcoming work. + It's essential to observe that the procedure doesn't handle the subject of trust. After key exchange there's no confidence in the other party. It's wholly feasible that Alice will end up communicating with an informer of a repressive autarchy with harmful intentions, such as illegitimate espionage [5]. Extra studies about this harsh subject will be aim of upcoming work. ## References + [1] Jonathan Katz, Yehuda Lindell. Introduction to Modern Cryptography: Principles and Protocols. Chapman & all, 2007. + [2] A survey of CAPTCHA technologies to distinguish between human and computer. Neurocomputing 408: 292-307 (2020). + [3] Ergun Akleman, Computing Through Time: The Changing Face of the Turing Test. Computer. 59(2): (13) 2026. + [4] Whitfield Diffie and Martin E. Hellman. New Directions in Cryptography. IEEE Transactions on Information Theory. + [5] EFF. Unnecessary and disproportionate. How NSA violates international human rights. https://www.eff.org/deeplinks/2014/05/unnecessary-and-disproportionate-how-nsa-violates-international-human-rights. ## ID 9f6e3afac68606c07d394e22c725486dd6b9067b93a4945702fdde46402b29bd bc2b6db02c99f2ef914bdc54141b5a9be8cf97d650fed8a8e50bedf2765b1dc87a52c334af6133f684f755970f09d22158e20577e8776770ce800b41e47100d8