Bibm@th

Forum de mathématiques - Bibm@th.net

Bienvenue dans les forums du site BibM@th, des forums où on dit Bonjour (Bonsoir), Merci, S'il vous plaît...

Vous n'êtes pas identifié(e).

Répondre

Veuillez composer votre message et l'envoyer
Nom (obligatoire)

E-mail (obligatoire)

Message (obligatoire)

Programme anti-spam : Afin de lutter contre le spam, nous vous demandons de bien vouloir répondre à la question suivante. Après inscription sur le site, vous n'aurez plus à répondre à ces questions.

Quel est le résultat de l'opération suivante (donner le résultat en chiffres)?
trente six plus quatre-vingt sept
Système anti-bot

Faites glisser le curseur de gauche à droite pour activer le bouton de confirmation.

Attention : Vous devez activer Javascript dans votre navigateur pour utiliser le système anti-bot.

Retour

Résumé de la discussion (messages les plus récents en premier)

Nayl
18-01-2018 01:38:33

Merci, je vais l'appliquer.

Rossignol
15-01-2018 19:34:39

Bonsoir,

Je pense qu'on peut durcir le chiffre autrement.

Vous utilisez deux flux $X_i$ et $Y_i$ pour chiffrer deux fois en Vigenère : $C_i = (P_i+X_i)+Y_i$ où $C_i$ et $P_i$ sont les octets de rang $i$ du chiffré et du clair (plaintext) et $+$ est l'addition modulo 256. 
Comme l'équation de chiffrement peut s'écrire $C_i = P_i+(X_i+Y_i)$, on voit que cela correspond à un seul chiffrement de Vigenère avec le flux $X_i+Y_i$.

De même si on chiffre deux fois en Vernam : $C_i = (P_i\oplus X_i)\oplus Y_i = P_i\oplus (X_i\oplus Y_i)$ cela correspond à un seul chiffrement de Vernam avec le flux $X_i\oplus Y_i$.

Par contre, si on chiffre d'abord en Vigenère et ensuite en Vernam, l'équation de chiffrement est $C_i = (P_i+X_i)\oplus Y_i$ et on ne peut pas regrouper les deux flux en un flux unique : on n'a pas un chiffrement de flux. Ce chiffrement est immunisé contre une "Bit-flipping attack".

Je vous conseille donc de modifier votre programme pour que le deuxième chiffrement utilise un xor plutôt que l'addition modulo 256. Attention pour déchiffrer, il faut faire le xor d'abord et la soustraction modulo 256 après.

$$C_i = (P_i+X_i)\oplus Y_i \Longleftrightarrow P_i = (C_i\oplus Y_i)-X_i$$

@+

Nayl
14-01-2018 21:41:50

Bonsoir

Rossignol a écrit :

À propos, pourquoi, dans votre code, utilisez-vous le module 255 et non 256 ? C'est pour tromper l'ennemi ?

Simple erreur de ma part, je vais corriger ça.

Du coup, si je comprends bien il vaut mieux utiliser un chiffrement par blocks plutot que par flux?

Si je chiffre "Prix 10" (Wkm0GwNEg1gzPtG4JUWj)
Puis je chiffre "00 euro" (ubQmhfwXiEtPOMLx1s9J)
Puis je chiffre "s." (+Q6X/MaukyVKZA==)

Est-ce que j'aurais un chiffrement par bloc ?

Rossignol
14-01-2018 18:54:44

Bonsoir,

Nayl a écrit :

Appart si on trouve un moyen de decrypter un hash, je ne vois toujours aucun moyen de casser mon algorithme...

C'est normal. Le concepteur d'un système cryptographique ne voit jamais les faiblesses de son système :-)

L'utilisation d'une fonction de hachage cryptographique pour créer un générateur de nombres pseudo-aléatoires n'est pas nouvelle. C'est l'une des deux méthodes courantes, l'autre étant d'utiliser un chiffrement par blocs : voir les recommandations du NIST (National Institute of Standards and Technology)

L'utilisation que vous faites de SHA-3 est correcte bien qu'un peu lourde : chiffrer deux fois le message est maladroit et est couteux en temps. Ce n'est pas trop gênant pour chiffrer un fichier. Mais on utilise généralement un chiffrement par flux pour crypter... un flux, par exemple un flux audio ou vidéo. Et là, la vitesse est cruciale.

Ce système utilise un nonce de 8 octets (64 bits). La probabilité de tirer au hasard deux nonces de même valeur est dérisoire. La formule des anniversaires montre qu'il faut tirer en moyenne $6.1\times 10^8$ nonces pour avoir une chance sur cent d'avoir deux valeurs identiques. Ça laisse de la marge.

Je ne vois pas de faille majeure dans ce système qui permettrait de retrouver le clair sans connaitre la clé.

Mais la cryptologie est pleine de subtilités. Il ne faut pas faire une fixation sur l'attaque à texte chiffré seul qui permet de "casser" le chiffre. Il existe des attaques subtiles qui sont très ennuyantes.

Comme tous les chiffrements par flux, ce chiffre est vulnérable à une "Bit-flipping attack" comme disent les anglo-saxons. C'est une attaque de l'homme du milieu.

Alice veut envoyer à Bob le message "Prix 1000 euros." avec la clé "secret".
En utilisant votre chiffre, elle obtient le crypto "RnLVTVgU+2zS+KJ51HoO6DRSmumpnx35".
(On peut le vérifier en déchiffrant ce message sur votre page.)

Supposons que M le malveillant intercepte et bloque le message. S'il connait le clair, il peut le modifier sans connaitre la clé :


from Base_64 import *
 
msg = 'RnLVTVgU+2zS+KJ51HoO6DRSmumpnx35'  # le message initial en Base64
f = base64.b64decode(msg)              # décodage : f est une bstring
g = [x for x in f]                     # transformation en liste d'octets
# xxxxxxxxPrix 1000 euros.
# 012345678901234567890123
#              ^ octet à modifier
g[13] = (g[13]-ord('1')+ord('9'))%255  # on remplace 1 par 9
msg_modifié = base64.b64encode(bytes(g)) # on recompose le message + Base64
print(msg_modifié)   # affiche : b'RnLVTVgU+2zS+KJ51IIO6DRSmumpnx35'
 

M obtient le message modifié : "RnLVTVgU+2zS+KJ51IIO6DRSmumpnx35".

M envoie à Bob ce message modifié. Avec votre page, Bob déchiffre "RnLVTVgU+2zS+KJ51IIO6DRSmumpnx35" avec la clé "secret" et obtient le clair "Prix 9000 euros."

Comme Alice et Bob sont les seuls à connaitre la clé, Bob est enclin à croire le message authentique. Erreur. À lui seul, un chiffrement par flux ne garantit pas l'authenticité.

Conclusion : il ne faut pas utiliser un chiffrement par flux dans les transactions bancaires :-)

À propos, pourquoi, dans votre code, utilisez-vous le module 255 et non 256 ? C'est pour tromper l'ennemi ?

Si vous chiffrez un fichier binaire, comme une image par exemple, un octet de valeur 255 sera considéré comme valant 0 d'où une erreur au déchiffrement.

Le diable est dans les détails.

@+

Nayl
13-01-2018 20:53:29

Appart si on trouve un moyen de decrypter un hash, je ne vois toujours aucun moyen de casser mon algorithme...

Quelqu'un pourrait-il me dire s'il y a un défault dans mon système ?

Nayl
10-01-2018 21:43:58

Bonsoir,
Merci pour votre réponse.

J'avais oublié de préciser que je résolvais le problème en chiffrant 2 fois le message :
1ere fois avec X0 = sha3 (Kp || Kj)
2eme fois avec X0 = sha3 (Kp || Kj || Kp || Kj)

Mais c'est beaucoup plus simple effectivement de prendre tout simplement Xi = sha3 (Kp || Kj || i)

Rossignol
10-01-2018 20:43:10

Bonjour,

Si j'ai bien compris, votre système cryptographique est un chiffrement par flux (stream cipher).

Le flux est obtenu à l'aide de la fonction de hachage SHA-3.

Vous chiffrez en combinant chaque octet du message avec un octet du flux en utilisant soit l'addition modulo 256 (Vigenère) soit un xor (Vernam).

La sécurité du système dépend donc de la qualité du flux.

Ce flux est engendré par récurrence :

$$\left\{
\begin{matrix}X_{0}=\mathrm{sha3}(K_{p}||K_{j}) \\ X_{i+1}=\mathrm{sha3}(X_{i})\quad & i\in \mathbb{N}
\end{matrix}\right. $$

Un générateur pseudo aléatoire doit être imprédictible : si on connait une partie du flux, on ne doit rien pouvoir en déduire sur le reste. Ce n'est pas le cas ici.

Si on connait le début du message chiffré, on peut en déduire $X_0$. Connaissant $X_0$, on en déduit  $X_{1}=\mathrm{sha3}(X_{0})$, puis $X_{2}=\mathrm{sha3}(X_{1})$ et ainsi de suite. On peut reconstituer le flux et déchiffrer tout le message sans connaitre les clés $K_p$ et $K_j$.

Une manière simple d'éviter cela est de concaténer un compteur aux clés :

$$X_{i}=\mathrm{sha3}(K_{p}||K_{j}||i)$$

Quant à la clé jetable $K_j$, qu'en cryptographie on appelle un nonce, il n'est pas nécessaire de la chiffrer. On peut la mettre telle quelle en début du crypto.

Pour une sécurité maximum il faut bien prendre garde à ne jamais utiliser deux fois le même nonce pour une même clé $K_p$ (sinon on a des cryptos "in depth").

@+

Nayl
10-01-2018 12:49:45

Voici l'alogorithme si vous voulez le tester :

http://149.91.88.117/Tests/Cryptage/Cryptage.html

Nayl
08-01-2018 18:56:32

Bonjour,

Je viens de m'intéresser à la cryptographie et j'ai fait un algorithme de chiffrement symétrique inspiré de Vernam, et j'aimerais l'avis de quelqu'un qui s'y connaît pour me dire où sont les failles.

Voici la description de mon système :

Soient Kp la clef permanente,
Kj la clé jetable unique à chaque msg, elle contient 8 nombres de 8 bits (0-255).

On génére Kj au hasard.
Le début du sha3 de Kp chiffre la clé jetable avec Vigenère. On mets ce crypte au tout début du message.

On génère un masque de longueur > ou = au message.
On fait : sha3(Kp || Kj)  ||  sha3(sha3(Kp || Kj)) || sha3(sha3(sha3(Kp + Kj))) + .....
On s’arrête quand : longueur masque >= longueur message

Enfin cette suite de hash va servir à chiffrer le message avec le principe de Vigenere (ou Vernam).

Du coup il y a environ autant de suites de hash possibles que de clé jetables possibles (10^19).

_____________________

Personellement je ne vois aucune faille, mais je ne suis pas un expert...

Merci de votre aide !

Pied de page des forums