Salut

Je viens de finir mon algorithme de chiffrement en C et j'aimerais le soumettre sur le forum pour voir s'il est robuste.
C'est un algorithme de chiffrement symétrique.
La taille de clé et de texte clair est libre, aucune restriction.

Je vous donne le chiffré, à vous de retrouver le clair:

"CsCXkZZt1yJqmOVPyPazOBzeVxi8Zs713ikLXtPTwL4tPUEk63iwUVGNPlgbPSTChNhWszFC3FEBRWWxMxPAOJ7VC0OKPPOgrhBZdFkcRgHwdKW2zl5sB924onKPl0zakpY8rywPKXh10wntX9p9nPibN8J8VEw8IidHk2AvOyElje08BXJ3oi4PmDtp7kagKLiKTzOPp2EQEyz5OtZdgvTLWlCLmOML9GIij0zJoVwoKOVD"

Bonne chance

Bonsoir,

Pour que l'algorithme soit solide, tu dois tout nous donner sauf la clé, et l'on ne doit pas être capable de retrouver la clé.
Tout, c'est l'algorithme, le texte clair, le texte chiffré...

Avec ce que tu nous donnes, on peut tout au plus vérifier que l'algorithme n'est pas pitoyable. ;-)

Je suis bien d'accord avec ce principe mais imaginons que je fasse partie d'une entreprise de sécurité qui chiffre des documents pour d'autre entreprise. Si j'étais le patron de cette entreprise, je choisirai de ne divulguer en rien l'algorithme de chiffrement. Il est clair que c'est contre le principe de Kerckhoff mais il me semble bien plus sécuritaire de ne rien divulguer comme dans le sujet de ce post.

Et l'algorithme est absolument énorme, je ne peux le décrire en "vrai français" clairement et simplement et je ne peux poster le code source simplement parce que j'aimerais tout autant le garder secret.

Tom Clabault a écrit:

Je suis bien d'accord avec ce principe mais imaginons que je fasse partie d'une entreprise de sécurité qui chiffre des documents pour d'autre entreprise. Si j'étais le patron de cette entreprise, je choisirai de ne divulguer en rien l'algorithme de chiffrement. Il est clair que c'est contre le principe de Kerckhoff mais il me semble bien plus sécuritaire de ne rien divulguer comme dans le sujet de ce post.

Ne rien divulguer est impossible, ou nécessite des ressources aussi formidables que vaines. Dis-toi, en tant que patron :), qu'il y aura toujours un jour ou l'autre un stagiaire qui va poser des questions sur un forum, comme par exemple : https://openclassrooms.com/forum/sujet/de-melanger-un-texte qui donnent des indications ... pire, si ça se trouve il a même lo code source sur un clé usb qu'il perd dans une soirée … voire même qu'il donne parce qu'on lui promet une vie de rêve aux Caïmans

Ce que j'entends par ne rien divulguer, c'est bien sûr sciemment, on ne va pas parler du stagiaire qui obtiens le code source par on ne sait quel moyen ou du stagiaire qui va récupérer des informations sur un forum.
Plus longtemps l'algorithme reste caché, mieux c'est:

"HHIMLXBAWTOADJSORYQDNCJSUJHBNJMAHIHYJZLP"
Rien qu'avec ça, je ne pense pas que ce soit si simple que ça de décrypter le message.
Là, l'algorithme est caché et je pense bien que ça va être compliqué d'imaginer comment ça a pu être chiffré.

Si maintenant je donne l'algorithme:

char* encrypt(char string[], int key)
{
	int i = 0;
	int mod = 0;

	for (i = 0; i < strlen(string); i++)
	{
		string[i] += key;
		if (string[i]>90)
		{
			string[i] %= 91;
			string[i] += 65;
		}

		if (mod % 2)
			key += 3;
		else
			key -= 2;

		mod++;
	}

	return string;
}

Il sera beaucoup plus simple de trouver la clé.
Même si un algorithme comme celui-ci n'est pas le meilleur exemple, le but du chiffrement et de "cacher" des informations aux yeux des autres alors pourquoi leur donner de quelconques informations ?

Salut,

Ton "challenge" n'en est pas un. En cryptographie, on distingue plusieurs types de sécurité, mais tous offrent à l'attaquant beaucoup plus de latitude qu'un seul chiffré. Pourquoi ? Parce que dans la vraie vie, un attaquant dispose quasiment toujours de plus d'un chiffré, et parce que dans la plupart des cas on ne peut rien dire d'intéressant avec un seul chiffré.

Par exemple, l'application de communication chiffrée telegram a lancé un challenge semblable au tien. Personne ne s'y est intéressé, parce que on ne peut rien faire avec un unique chiffre. Et que si quelqu'un veut attaquer telegram, il dispose qu'un nombre énorme de chiffrés à disposition (les messages envoyés par le vilain terroriste qu'ils veulent arrêter).

Donc, effectivement, si tu as respecté les règles de base ton algo sera peut-être résistant sur un seul chiffré. Mais rien ne dit qu'il sera résistant sur plus, et tant que tu ne donneras pas plus de données, on ne pourra rien dire de plus.

Salut,

Comme il a été expliqué si tu nous donne juste un chiffre, même si on n'arrivait pas à le casser en y perdant du temps ça ne prouverait rien du tout sur la qualité de l'algo, mais en plus comme on à aucun intérêt à le faire, il est peu probable que quelqu'un perde du temps à cela.
Un exemple, prenons un algo très simple qui chiffre en prenant pour chaque caractère du message en clair le caractère correspondant de la clef, fait la somme des deux puis un modulo pour trouver pour trouver le caractère dans le message chiffré (donc avec un message "12345" et une clef "45678" le chiffre serait "57913" si les caractères autorisés ne sont que des chiffres).
Et bien cet algo bidon produit un chiffre complètement inviolable du moment que la clef est complètement aléatoire, au moins aussi grande que le message en clair et n'est utilisée qu'une seule fois.
Pourtant on est bien d'accord que l'algo est nul dans tous les autres cas d'utilisation (avec une clef courte, des échanges de plusieurs messages,  ou pour garantir le protection de la clef si on possède à la fois le message en clair et le message chiffré).

Même sans dévoiler l'algo, tu pourrais éventuellement offrir une API où l'on peut utiliser ton aglo avec les valeurs que l'on veut (sans savoir ce qu'il fait), (et si tu veux que des gens y passe du temps sérieusement, il faudra offrir une récompense à celui qui le casse).

Il est probable que ton algorithme ne soit pas terrible puisque les algorithmes de chiffrement vraiment solides comme AES repose sur des principes mathématiques solides et vu ton message il soit probable que ce tu es plus réalisé un algorithme "jouet" sans vraiment te plonger à fond dans les théories de chiffrement (et il y a pas de mal à ça).

Un indice en défaveur de ton algo est le résultat avec que des chiffres et des lettres. Ca laisse penser que ton algo ne sera pas capable de chiffrer du binaire ou même juste des lettres accentuées. Et si jamais il l'était, cela voudrait dire qu'il fait grossir la taille des messages inutilement.

Un autre indice en défaveur de ton algo est qu'il y a presque 6% de P dans ton texte chiffré. Ca semble être plus que dans un tirage parfaitement aléatoire du même nombre de caractères mais avec un seul chiffre à étudier ça doit être statistiquement possible.

-
Edité par macaque 18 février 2017 à 16:21:25

En effet, l'algorithme ne gère pas les caractères accentués et le binaire Et il ne repose pas non plus sur des principes mathématiques ou quoi que ce soit.

il n'est fait que pour les caractères représentables de l'ASCII

Je posterai l'algorithme dans peu de temps si quelqu'un a répondu après moi ou alors j'editerai ce message

-
Edité par Tom Clabault 19 février 2017 à 10:23:52

Tom Clabault a écrit:

Je suis bien d'accord avec ce principe mais imaginons que je fasse partie d'une entreprise de sécurité qui chiffre des documents pour d'autre entreprise. Si j'étais le patron de cette entreprise, je choisirai de ne divulguer en rien l'algorithme de chiffrement.

Oui mais les clients d'une telle entreprise seraient tous des gogos (voir https://www.schneier.com/crypto-gram/archives/1999/0215.html#snakeoil Warning Sign #3 Proprietary Cryptography).

Voici l'algorithme :

keyEncrypt:
http://pastebin.com/Nv4suGi5

Les fonctions:
http://pastebin.com/C1r6SYZR

-
Edité par Tom Clabault 19 février 2017 à 18:58:22

Des critiques ?

Honnêtement je pense que ceux qui on jeter un œil comme moi n'ont pas eu envie d'aller plus loin pour chercher à comprendre.

Je pensais que tu avais fait un truc simple pour jouer un peu avec le chiffrement, mais maintenant je me demande surtout combien de temps tu as pu y passer et dans quel intérêt ?
C'est une impression personnelle, mais en regardant comme ca donne plus l'impression d'avoir voulu rendre l'algo incompréhensible plutôt que d'avoir voulu remplir le but rechercher avec un algo simple et efficace. Or je ne pense pas que ce soit le but qu'il faille rechercher en écrivant un algo de chiffrement. Il faudrait plutôt ce dire "tient je vais faire ca parce que ca va apporter telle propriété a mon algo".

Je pense que ton algo est peu utilisable en pratique (du simple fait qu'il de la limitation sur les caractères autorisés) et demanderait beaucoup trop d'effort pour le faire évoluer et le maintenir.
Je surtout que personne n'aura envie d'auditer ce code pour savoir son niveau de securite donc personne ne voudra l'utiliser par manque de confiance.

N'étant pas rentré dans le contenu, je vais juste donner un avis sur la forme :

- 1 énorme fonction : il faudrait la découper pour rendre ca plus lisible

- beaucoup de ligne de code et de block de code tres semblables qu'il faudrait sûrement refactorer.

- des tableaux "braille" : c'est pour quoi faire, de la substitution ? Qu'est-ce que ça apporte comme propriété intéressante autre que complexifier l'algo ?

- beaucoup de boucle et des allocations de memoire dans un tableau a multiples dimensions : l'algo est sans doute gourmant en CPU et utilisation memoire

- on repete plusieurs fois des etapes similaires comme des rotations. Mais si on est capable de faire le code pour en reverser une, on sera capable de les reverser toutes donc c'est surtout pour compliquer la vie d'une personne qui n'a pas l'algo, ca ne veut pas dire que ce n'est pas reversible.

- un nombre d'imbrication de for/if/switch assez effrayant

Ceci étant dit si ca fonctionne sans aucun bug, bravo quand même d'avoir réussi a te retrouver la dedans. Je ne suis pas persuader que tu auras toi même envie de t'y replonger si tu veux/doit changer.

En fait, n'ayant pas du tout les compétences mathématiques ou quoi que ce soit pour savoir quelles sont les fonctions qui seront efficaces dans la sécurité de l'algorithme, disons que je suis parti sur un algo long, dont beaucoup de choses dépendent de la clé... Après, est-ce que c'est réussi, c'est ce que je viens vous demander

Oui, la fonction est plutôt grosse et j'ai déjà mis certaines étapes dans dans d'autre fonction, il y a encore beaucoup à faire et peut-être que je le ferai.

Pour les lignes de code semblables, c'est sûr qu'on peut faire mieux mais disons que l'algo n'est pas encore optimisé au maximum

Les tableaux de "braille", de "morse" etc... sont là pour la substitution, oui et comme je partais du fait que je ne donnerai pas l'algorithme, c'était pour rendre le décryptage impossible sans les tables de morse et de braille etc...

Gourmand en CPU --> Plutôt
Gourmand en mémoire --> Ça dépend de ce qu'on entend par là parce que de nos jours, les machines qui ont peu de RAM doivent se faire rare mais il ne consomme pas tant que ça mine de rien

Qu'entends-tu par "un nombre d'imbrication de for/if/switch assez effrayant" ? C'est vrai qu'il y a des parties ou y'en a pas mal mais je n'ai pas vu comment faire autrement

Ça fonctionne bien, pas de problème pour l'instant.

Pour éviter les imbrications et rendre le code plus lisible, il faut le découper en petite fonction.

Par exemple voici une implémentation d'AES : https://github.com/kokke/tiny-AES128-C/blob/master/aes.c

Je ne prétends pas comprendre cet implémentation non plus juste en regardant le code 5mn, mais on voit tout de suite que le code est "propre". La main fonction "cipher" est courte et explicite.

Sinon, le fait d'utiliser des tables de brailles et de morses rendent l'algo moins déchiffrable sans connaître ces tables reste à prouver. Mais surtout pourquoi utiliser ces tables là et pas juste des tables que tu aurais construites aléatoirement (qui pourraient du coup permettre des variations de ton algo à chaque fois que tu l'utilise dans un programme différent pour un usage différent) ?

Ajouter des étapes peut ajouter de la complexité à déchiffrer un message (surtout s'il y a une notion de modulo à chaque étape), mais ce n'est pas nécessairement le cas/ Si ça se trouve ton algo peut être factorisé en un algo plus simple qui produit le même résultat, ou bien cela rajoute des biais permettant de déchiffrer le message.

Je veux dire par exemple, peut être que dans ton algo tu passe par ces tables de conversion là, mais un attaquant qui utiliserait des outils mathématiques pour attaquer tes chiffres sur des grands quantité de données arriverait peut être à reconstruire une table de conversion plus grande qui mélangerait les données de ta clef et de ces deux tables et qui permettrait de faire le déchiffrement.

Et peut être qu'en utilisant trop souvent la clef dans différentes étapes de ton algorithme rend plus facile le fait de retrouver cette clef à partir de long message chiffré.

C'est sur que si tu n'utilises ton algo que pour toi sur des données qui n'ont pas grande importance pour personne, il est très peu probable qu'une personne prenne la peine d'essayer de le casser dans ce cadre là. Mais dans ce cadre là utiliser un AES avec une clef privée que tu garde pour toi semblait largement suffisant et t'aurais fait économiser beaucoup d'effort.
Et si tu veux utiliser ce produit à plus grande échelle, par exemple dans un produit que tu distribuerait et que les gens utiliseraient pour stocker des données de valeurs, ça devient tout autre chose. Déjà vu que tu distribuerais ton programme, les éventuels attaquants auront accès à ton implémentation de l'algo, en tout cas sous forme compilée qu'ils pourront désassemblée.

Mais c'est en faisant qu'on apprend donc je suis sur que le temps "perdu" à créer cet algo t'as aussi permis d'apprendre des choses. Si tu es vraiment intéressé par le chiffrement, essaie de trouver de la littérature sur le sujet, je pense que ça te permettra de trouver toi même des biais (moi je n'y connais presque rien).

-
Edité par macaque 4 mars 2017 à 11:41:03

Je verrai pour découper la grosse fonction en plusieurs petites fonctions, ça me paraît possible.

C'est vrai que je pourrai créer les tables de morse et de braille à partir de la clé ( Comme le SubBox ) plutôt que de les définir une fois pour toute dans le code.

J'utilise la clé un peu partout dans l'algorithme, oui, mais le problème est là, je ne peux pas savoir si ça rend le décryptage plus facile ou pas, je n'ai aucune idée de ce qu'il faudrait faire pour savoir si ça rend le décryptage plus facile ou pas.

Le but de cet algorithme n'est pas professionnel, c'est disons un projet que je me suis donné parce que je n'avais rien d'autre à faire