J'avais pensé à utiliser un couple de clés PGP échangé lors de la connexion entre les amis celui qui crée le canal de conversation, génère une clé publique/privée qui est envoyé via la clé publique de chaque utilisateur pour chiffré les échanges juste pendant cette conversation (ce qui ne retire pas le fait que si la clé est corrompu, l'envoie de la clé de discussion également) mais on peux penser à un échange de ce couple par un autre canal (mail chiffré ou autre) ce qui permet aussi de convier d'autres personnes à une "conférence" sans échanger avec celles-ci ses propres clés.
C'est différent. La crypto asymétrique est connu pour être moins fiable que la symétrique (genre AES en XTS). Ce que tu proposes est différent, tu propose de refaire un échange de clef asymétrique jetable. Cela doit te donner la propriété de forward secrecy une fois la clef privé jeté. C'est pas mal, je pense.
Fait aussi très attention à tes générateurs aléatoires, toute la sécurité repose dessus. Encore une fois, tu peux faire des couches : 128 bits d'entropie minimum par couche (genre /dev/urandom et une toutouille à toi) et le mélange des couches doit aussi être cryptographique et non un simple XOR (genre sha2). Attention à ne jamais dériver les clefs, tout doit être aléatoire.
de plus ce qui devrait pouvoir être fait, c'est de signer sa clé publique "publique" (qui est stockée dans l'application) avec une clé privée qui n'est JAMAIS publiée (utiliser une fois à chaque renouvellement de clé et stocké dans un coffre derrière un pitbull, ou chez la belle mère).
Du coup lors du changement de clé on peut vérifier celle-ci avec la signature de la clé publique "de référence" dont la clé privée est bien cachée.
Ici, le problème est de faire simple. J'aime bien la propriété qui consiste à dire que l'on peut garantir un réseau si >50% des nœuds du réseau sont fiables. En gros, un noeud compromis ne peut tout compromettre. Dans ton cas, cela reviendrait à partager tes informations.
Regardes les protocoles comme celui proposé dans la dépêche qui utilise git et bittorrent. Celui-ci te garanti contre tout modification (un serveur deviendrait membre d'un réseau et ne serait pas isoler). Tu dois même pouvoir rajouter une couche d'authentification en utilisant le réseau bitcoin.
[^] # Re: cryptocat ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 3.
C'est différent. La crypto asymétrique est connu pour être moins fiable que la symétrique (genre AES en XTS). Ce que tu proposes est différent, tu propose de refaire un échange de clef asymétrique jetable. Cela doit te donner la propriété de forward secrecy une fois la clef privé jeté. C'est pas mal, je pense.
Fait aussi très attention à tes générateurs aléatoires, toute la sécurité repose dessus. Encore une fois, tu peux faire des couches : 128 bits d'entropie minimum par couche (genre /dev/urandom et une toutouille à toi) et le mélange des couches doit aussi être cryptographique et non un simple XOR (genre sha2). Attention à ne jamais dériver les clefs, tout doit être aléatoire.
Ici, le problème est de faire simple. J'aime bien la propriété qui consiste à dire que l'on peut garantir un réseau si >50% des nœuds du réseau sont fiables. En gros, un noeud compromis ne peut tout compromettre. Dans ton cas, cela reviendrait à partager tes informations.
Regardes les protocoles comme celui proposé dans la dépêche qui utilise git et bittorrent. Celui-ci te garanti contre tout modification (un serveur deviendrait membre d'un réseau et ne serait pas isoler). Tu dois même pouvoir rajouter une couche d'authentification en utilisant le réseau bitcoin.
"La première sécurité est la liberté"