Suivre

Est ce qu'en terme de cryptage on peut considérer que coder un texte à l'aide d'un autre de même longueur (avec une fonction texte crypté = texte initial + texte codé) est un cryptage assez fort ? (Je n'y connais rien en cryptage).

Parce que sinon, utiliser un article wikipédia (une version daté) comme code de cryptage pourrait être une solution, non ?

@janolap1 Sous reserve que le second texte soit bien aléatoire, oui, c'esst fort, c'est même très très fort, puisque c'est incassable sans la clef. Ceci peut t'interesser : fr.wikipedia.org/wiki/Masque_j

Attention toutefois : c'est incassable seulement si la clef est vraiment aléatoire, et qu'elle n'est pas réutilisée.

@janolap1 Du coup, en théorie c'est assez cool, en pratique, il faut trouver un moyen d'échanger la clef en amont, pour chaque message.

@Bromind
@koantig
Merci, mais le problème de l'échange de la clef n'est-il pas les même partout ? On pourrait imaginer la clef suivante transmise en fin de message initial, non ?

@janolap1 @koantig L'échange de clef est souvent un problème. Mais dans notre cas, c'est un gros problème, puisqu'il faut que la clef fasse la taille du message, donc si on veut que le 1er et 2nd message fassent n_1 + n2 caractères, alors il faut envoyer, dans le 1er message n1 + n2 caractères (le message + la 2nde clef), donc que la 1ère clef fasse n1 + n2 caractères. À ce moment là, autant envoyer initialement les n1 + n2 caractères lors de l'échange, et d'utiliser chaque partie.

@janolap1 @koantig On voit donc, dans le cas général, qu'il n'est pas possible d'envoyer la clef suivante lors du message courant. Dans d'autres schémas, où une clef de taille n permet d'envoyer plus de n caractères, on peut envisager une telle chose, mais pas avec le masque jetable.

Ça ne veut pas dire que le masque jetable ne sert à rien : on peut se mettre d'accord en amont dans un contexte fiable, sur la clef, puis transmettre les données quand on les a.

@janolap1 @koantig Il faut juste être d'accord en amont sur le nombre de caractères qu'on va envoyer.

Ce qui motive une utilisation où on se met toujours d'accord en amont sur la clef, toujours dans un contexte fiable, mais où la méthode de chiffrement permet d'envoyer un nombre arbitraire de caractères.

@Bromind
Désolé, je n'ai pas les bons termes. Lorsque je parlais de clef, je pensais à que chose d'autre : le moyen d'avoir la clef. Par exemple, une URL qui renvoie vers un contenu, lequel est la clef.
En fait, on donne non pas une clef pour décrypter, mais le moyen, plus court, d'obtenir la clef.
@koantig

@janolap1 @koantig Ce que tu dis est interessant. Mais considère le point suivant : on se dit, en amont, dans un contexte sûr : au moment opportun, tu pourras aller chercher la clef sur : www.monsite.com ; avec l'hypothèse sous-jacente que ce site est fiable. Dans ce cas, pourquoi ne pas communiquer directement par ce site ? Le problème de passer par un site est qu'il suppose un canal fiable, et donc qu'il suppose la solution au problème (je simplifie : le site est un canal « directionnel »).

@janolap1 @koantig Maintenant, ce que tu dis peut aussi être étendu de la manière suivante : on peut se mettre d'accord en avance sur une fonction « f » qui servira à nous génerer un flux de caractères qu'on utilisera pour une clef « infinie », pour envoyer le caractère suivant, on dit juste à f : « donne moi le prochain caractère de la clef ».

C'est assez interessant : rappelons nous qu'il faut que notre clef soit aléatoire. Il nous faut donc un générateur de caractères aléatoires.

@janolap1 @koantig Générer des nombres (suffisamment) aléatoires est compliqué. Il y a toutefois une critique que l'on peut faire : pour garantir que notre fonction va bien générer « n » nombres aléatoires, alors *la description de cette fonction* prend au moins n caractères (il y a des liens avec la complexité de Kolmogorov et la théorie de la compression que je te laisse chercher).

Une partie de la crypto consiste justement à chercher des moyens de générer des sequences pseudo-aléatoires.

@janolap1 Rien à redire à ce qu'à répondu @Bromind mais si ton modèle de menace est plus modéré, un chiffrage classique c'est de convenir à l'avance d'un gros livre (e.g. Guerre et Paix) et de donner comme clé juste le numéro de la page qui a servi de point de départ au chiffrement.
C'est moins fort: le livre doit rester secret et le chiffrement se fait sur la base d'une langue naturelle donc loin d'être aléatoire. Mais ça peut être suffisant dans bien des cas.

@janolap1 C'est du one-time pad (fr.wikipedia.org/wiki/Masque_j)
C'est très fort mais le problème c'est de passer la clé de chiffrement à son interlocuteur sans qu'elle soit interceptée

Inscrivez-vous pour prendre part à la conversation
Framapiaf

Le réseau social de l'avenir : pas de publicité, pas de surveillance institutionnelle, conception éthique et décentralisation ! Gardez le contrôle de vos données avec Mastodon !