Les
Il faut donc utiliser la
Voici donc un protocole possible, suivi de son application au service OpenDHT. L'expérience prouve largement que les amateurs (et même parfois les professionnels) ne voient jamais les failles de sécurité des protocoles cryptographiques qu'ils conçoivent : les critiques sont donc les bienvenues.
Pour éviter les collisions sur le mot « clé », je ne l'utilise que pour la clé cryptographique. Je nomme « nom de l'attribut » (ou index) l'« endroit » où on veut stocker et « valeur de l'attribut » la chose qu'on veut stocker.
Chaque entité qui veut stocker des trucs dans la DHT a une clé cryptographique
Les failles que je vois pour l'instant :
Voici une mise en œuvre possible en
Le
% python put.py -k 82AEEF63 quelquechose.example.org 192.0.2.42
La ligne ci-dessus stocke la valeur
key = Binary(sha.new(pgp_key + attribute).digest())
key_for_sig = Binary(sha.new(pgp_key + attribute + ".SIGNATURE").digest())
puis écrit dans la DHT :
proxy.put(key, bin_value, ttl, "put-authentic.py")]
proxy.put(key_for_sig, Binary(signature), ttl, "put-authentic.py")
Le
% python get.py -k 82AEEF63 quelquechose.example.org
À noter que rien n'empêche plusieurs écritures sur le même nom (les
attributs sont multi-valués dans OpenDHT) donc le programme doit
boucler sur tous les résultats obtenus. Autrement, il fait simplement
l'inverse du programme d'écriture :
signatures, pm = proxy.get(key_for_sig, maxvals, pm, "get-authentic.py")
vals, pm = proxy.get(key, maxvals, pm, "get-authentic.py")
Si un méchant a essayé d'insérer de fausses données, cela se voit
tout de suite (rappelons qu'on ne peut pas empêcher cette insertion,
juste la détecter a posteriori) :
Value is "192.0.2.42"
BAD signature from:
uid: OpenDHT Authenticity Test (Test only, not a real user)