Tai : communs des protocoles

éléments conceptuels communs pour les protocoles d'échanges du Téléphone arabe informatisé

Pour préciser le remue-méninges collectif appelé ici de nos voeux , nous exposerons d'abord ici quelques rappels ou remarques préliminaires, avant de suggérer des principes de base à utiliser dans les divers protocoles d'échanges  envisagés pour notre Tai ...  voir :

https://tackk.com/tai

et :
lexique KDO :  une archive du lexique KDO

Comment Stream

2 years ago
0

Quelques considérations préliminaires :

Considérons un réseau-Tai de contributeurs-KDO déjà identifiés :
Chaque participant ne communique (dans le cadre de Tai) qu'avec une poignée de contacts-KDO :
-désignons par Nb_déjà_Tai le nombre (confidentiel) de ces contacts-KDO déjà membres du réseau au moment où ce participant est devenu membre.
-désignons par Nb_nouveaux_Tai le nombre (confidentiel) de ces contacts-KDO devenus membres du réseau après l'incorporation de ce participant au réseau.

Le protocole Tai de recrutement exigera que la valeur minimum de Nb_déjà_Tai vérifie : Nb_déjà_Tai >=2
Ce même protocole Tai pourra exiger que, pour chacun, et à tout instant :
(Nb_déjà_Tai+ Nb_nouveaux_Tai) < Nb_MAX_Tai , avec Nb_MAX_Tai >=2 et, par exemple Nb_MAX_Tai <= 8

(ces limites devraient permettre d'évaluer les valeurs pratiques extrêmes des volumes d'échanges impliqués par nos protocoles Tai - matheux : à vos crayons ! )

2 years ago
0


Rappel (cf lexique KDO)
- identitéKdo = celle d'un participants-Kdo se réduit à :

1. son pseudonyme
>>> connu entre contacts-KDO mais pas nécessairement entre tous les membres du réseau Tai
(cf notion de "jeton d'échange")

2. son adresse IP (= adresse Internet) ou son e-mail .... pas forcément indispensable d'avoir les deux selon les outils du socle-commun-Kdo qui seront mis en place [TODO = y réfléchir ] )
>>> en fait, il nous faut une référence entre contacts-KDO pour permettre un auto-contrôle d'appartenance au réseau Tai : un échange confidentiel de clés secrètes (de cryptage) entre contacts-KDO devrait pouvoir suffire
( Rappel : on devrait pouvoir permettre des échanges Tai sans e-mail ni même Internet)

3. son adresseKdo (éventuelle ... [TODO = y réfléchir ]
>>> un "jeton d'échange" pourra faire office de cette adresseKdo )

4. un éventuel mot de passe secret ou clé personnelle secrète pour communiquer avec ses contact-Kdo [TODO = y réfléchir ] ...
>>> on envisagera ici les timbre@envois et timbre@réceptions de l'outil : manageur Tai ...
cf http://okidor.free.fr/reflects/file/manage_tai.html

Open in New Window
2 years ago
0

distingons "messages" et "échanges" :
- désignons par "message" un texte lisible en langage naturel
- chaque message pourra, temporairement (le temps d'une session de communication), être remplacé par un couple d'objets appelés :
"cryptage" (du message) et "clé" (ou "cluster" entre nous, pour le fun) du message.
- on utilisera alors la dénomination générique de "échange" pour désigner ce qui peut être un "cryptage" ou une "clé/cluster".(Ce terme pourra peut-être recouvrir aussi, dans certains cas à signaler, des "messages" )

2 years ago
0

notions de timbre@envois et timbre@réceptions :
Chaque membre du réseau Tai devra protéger notre réseau de toute intrusion de messages ou échanges étrangers à l'ensemble des participants admis dans ce réseau :
nos communications Tai ne pourront ni être lues par des non-admis, ni être pollées par des données émises par des non-admis.

Pour ce faire, voici le mécanisme :
Chaque paire de participants qui s'accordent entre eux pour être un "contact-KDO" l'un pour l'autre se confient (secrètement) l'un à l'autre deux "timbres" qu'ils garderont connus d'eux seuls.
(un "timbre" étant une courte chaîne de caractères, unique et associée à une date très précise : cf https://tackk.com/stamp )

L'un de ces 'timbres' sera le 'timbre@envois' de l'un de ces 2 participants et le 'timbre@réceptions' de l'autre participant.
Idem pour le second timbre, en inversant les dénominations.

Dès lors, toute information émise d'un participant A à son contact-KDO B sera cryptée par A avec la clé de cryptage résultant d'une transformation convenue du 'timbre@envois' de A.
A se contentera d'émettre le cryptage obtenu.
B, sachant qu'il reçoit un 'échange' de A, retrouvera la clé de cryptage avec la même transformation convenue de son 'timbre@envois de A', et traduira ainsi l'information émise par A.
Le processus est symétrique pour la réception.

( Noter que le fait d'entretenir des timbres secrets distincts pour l'émission et la réception limite les risques d'intrusion en cas de violation du secret d'un des timbres )

Open in New Window
2 years ago
0

Pour se faire une idée de la "transformation convenue" que nous pouvons tous adopter, voir la suggestion implantée dans l'outil "manageur Tai" par la fonction :
tarabiscoter( timbreEnvoi, txtEnvoi.value.length );

2 years ago
0

correctif :

2 years ago
0

remplacer (Nb_déjà_Tai+ Nb_nouveaux_Tai) < Nb_MAX_Tai

2 years ago
0

par : (Nb_déjà_Tai+ Nb_nouveaux_Tai) <= Nb_MAX_Tai