Discussion :

[enzo68290]

Bonjour à tous,

Je développe actuellement un algo de chiffrage légé de mon cru, il n'a pas pour but de concurencé ce qui existe déjà, mais de rendre ilisible des infos en clair, et que la méthode ne soit pas quelque chose d'existant (usage professionnel donc je ne donnerais que peu de détail).

Actuellement mon moteur de chiffrement fonctionne mais sans gestion du retour chariot, à cause de la difficultée que je vais vous énoncer.

Sans rentrer dans les détails de mon algo, le retour à la ligne me pose beaucoup de problème.

En effet, selon wikipedia, il est différent suivant l'os employé :
- Windows - cariage return + line feed : \r\n - ascii(13) / ascii(10)
- MacOs - cariage return : \r - ascii(13)
- Linux - line feed : \n - ascii(10)

Je cherche un moyen simple de convertir les retours à la ligne quelques soit le système d'exploitation vers quelque chose d'uniforme.

Normalement l'algo sera coté serveur, qui recevra du client la chainse saisie.

Plutot que de forcer coté client la conversion, je préfère faire ce quil faut coté serveur.

Est ce que quelqu'un aurait-il déjà eu affaire à ce genre de conversion ?

J'ai quelques idées vagues, la première :

fonction qui détecte le type de retour chariot et qui retournerais l'os d'entrée détecté, qui serait capable de convertir un retour chariot en le caractère " ^ ".

Comme l'os d'entrée serait détecté, je retournerais une chaine chiffrer ou les retour chariot serait réecrit pour l'os d'entrée.

La seconde serait de convertir le retour quelque soit l'os vers " ^ ", sans me préocupé de l'os d'entrée.

Au moment du retour de la chaine chiffrer, je convertirais avec une autre fonction les " ^ " au format Windows (CRLF ascii(13) + ascii(10)).

Sans dire de bêtise, linux détecte et comprends les CRLF dans la pluspart des logiciels, et Mac de la même manière, est ce que quelqu'un aurait une idée plus précise que la mienne pour traiter ce soucis ?

[mith06]

Salut,

Je pense que tu te trompe de problème. Le plus simple serait que ton algo supporte les retours chariot.

Imagine que quelque t'énonce le même problème mais avec le la lettre 'A' ou le chiffre 42 en lieu et place de ton problème avec \r.

[kwariz]

Bonsoir,

je plussoie mith06. Tu as un problème de retour chariot mais tu risques aussi de te retrouver face à un problème d'encodage (encore). Ton client windows pourrait générer des chaines avec un encodage win1252/CRLF, ton client mac avec un encodage UTF8/CR et un client linux avec un encodage ISO8859-15/LF.
L'idéal est que chaque client transforme les chaines saisies vers un encodage de travail (par exemple UTF8/LF ou UCS4/CRLF) et l'envoie à la routine de chiffrage qui ne fera que chiffrer/déchiffrer une suite d'octets sans signification particulière (c'est ton workflow qui manque de détails, qui chiffre, qui déchiffre, comment est transmis la chaine ... ce n'est pas clair).
Je suppose que tu codes en C, que ton code client sera suffisamment portable pour ne garder qu'un ensemble de source aux define près pour toutes les plateformes ?

[enzo68290]

Bonsoir,

je plussoie mith06. Tu as un problème de retour chariot mais tu risques aussi de te retrouver face à un problème d'encodage (encore). Ton client windows pourrait générer des chaines avec un encodage win1252/CRLF, ton client mac avec un encodage UTF8/CR et un client linux avec un encodage ISO8859-15/LF.
L'idéal est que chaque client transforme les chaines saisies vers un encodage de travail (par exemple UTF8/LF ou UCS4/CRLF) et l'envoie à la routine de chiffrage qui ne fera que chiffrer/déchiffrer une suite d'octets sans signification particulière (c'est ton workflow qui manque de détails, qui chiffre, qui déchiffre, comment est transmis la chaine ... ce n'est pas clair).
Je suppose que tu codes en C, que ton code client sera suffisamment portable pour ne garder qu'un ensemble de source aux define près pour toutes les plateformes ?

Je ne peux donner aucun détail sur l'algo de chiffrement car il sera utilisé par mon entreprise.

On m'a imposé de le programmer en un temps record, et ne devant se basé sur rien d'existant, et supporter des contraintes qu'on m'à imposé.

C'est à cause de ces contraintes que ce pose le problème de retour chariot.

D'une part parce que je ne chiffre pas au niveau binaire, mais au niveau caractères ...

Très grossièrement, je récupère le code ascii d'un caractère que je modifie de façon XXXXX pour chiffrer.

Je suis obliger de chiffer au niveau ascii à cause de certaines contraintes xxxx, une d'entre elle est un stockage sur une base de donnée obsolète de la donnée chiffrer, qui ne supporte pas le type le donnée binaire, et utilise une table ascii assez restreinte.

J'ai par ailleurs proposé d'utiliser un algo au niveau binaire, plus facile à mettre en oeuvre et très facilement programmable.

Au lieu de ça, chiffrement sur la couche ascii et ça beaucoups de contraintes.

Je comprends vos point de vue, qui sont réellement justifiée... seulement ces arguments que j'ai eu avec mon chef de service n'ont servit à rien, pour une question de base de donnée, de budget, il m'a envoyé boulé.

Du coup retour à la case départ ... ou encore CRLF pour ne pas faire de mauvais jeu de mot.

Je suis obligé de gérré le retour chariot à la main et de faire avec donc ...

Que penser vous de mon idée de retourner à chaque fois CRLF, et de détecter les retour chariot en entrée afin de les convertir, quelque soit le type (windows linux mac) ?

[ternel]

J'imagine que tu as bien expliqué à ton chef de projet que ton implémentation personnelle en temps record serait évidemment au moins aussi sure que celle fournie dans des outils standards comme openSSL ou autre…

[enzo68290]

Le but principale de mon algo ne recherche pas une sécurité, mais juste une ilisibilité del a donnée au niveau utilisateur. Il n'a donc pas besoin d'être très fort comme d'autre solution.

Sinon, je ne me serais pas vraiment casser la tête à développer qq chose alors qu'il existe des solutions beaucoup plus sûr en terme de sécurité.

Le problème c'est qu'avec la somme des contraintes qui me sont donnée, je n'ai pas le choix, je suis obligé de développer quelque chose, rien d'existant ne se plie à tout ce qu'on m'impose, j'ai beau faire ou chercher.

[kwariz]

Je ne peux donner aucun détail sur l'algo de chiffrement car il sera utilisé par mon entreprise.

On m'a imposé de le programmer en un temps record, et ne devant se basé sur rien d'existant, et supporter des contraintes qu'on m'à imposé.

C'est à cause de ces contraintes que ce pose le problème de retour chariot.

D'une part parce que je ne chiffre pas au niveau binaire, mais au niveau caractères ...

Très grossièrement, je récupère le code ascii d'un caractère que je modifie de façon XXXXX pour chiffrer.

Je suis obliger de chiffer au niveau ascii à cause de certaines contraintes xxxx, une d'entre elle est un stockage sur une base de donnée obsolète de la donnée chiffrer, qui ne supporte pas le type le donnée binaire, et utilise une table ascii assez restreinte.

J'ai par ailleurs proposé d'utiliser un algo au niveau binaire, plus facile à mettre en oeuvre et très facilement programmable.

Bon on va faire un coup de out of the box si tu veux bien. Tu n'es pas obligé d'avoir un chiffrage ascii du tout, la contrainte n'est pas au niveau du chiffrage mais du stockage.
Stockage ascii me fait immédiatement penser à Base64. Ta base de donnée aussi obsolète soit elle sera certainement capable de supporter une chaine de caractères piochant ses valeurs dans un sous ensemble de 64 caractères ...
Ma première conclusion est : chiffre comme tu le sens, transforme la donnée binaire en ascii par base64. À la limite un algo Base64 un peu modifié sera peut-être même amplement suffisant pour tes besoins de chiffrage ...

Au lieu de ça, chiffrement sur la couche ascii et ça beaucoups de contraintes.

Je comprends vos point de vue, qui sont réellement justifiée... seulement ces arguments que j'ai eu avec mon chef de service n'ont servit à rien, pour une question de base de donnée, de budget, il m'a envoyé boulé.

Du coup retour à la case départ ... ou encore CRLF pour ne pas faire de mauvais jeu de mot.

Je suis obligé de gérré le retour chariot à la main et de faire avec donc ...

Que penser vous de mon idée de retourner à chaque fois CRLF, et de détecter les retour chariot en entrée afin de les convertir, quelque soit le type (windows linux mac) ?

Bah oui de toute façon il faudra bien le faire quelque part. Comme tu codes en C (apparemment avec la glibc) tu pourrais avoir un workflow comme :

saisie --- iconv ---> saisie transcodée en UTF8 (par ex.) --- remplacement des CR et LF par CRLF ---> saisie prête au format UTF8/CRLF ---- Chiffrage ---> donnée binaire illisible --- BASE64 ---> donnée toujours illisible mais ne contenant que des caractères ascii acceptés par la bdd obsolète : bingo

Dans l'autre sens tu déBase64, tu déchiffres, tu remplaces les CRLF par un \n et finalement tu transcodes de UTF8 vers l'encodage local.

C'est un workflow possible. Ensuite ce serait sympa de nous détailler juste quelle partie tu comptes implémenter côté serveur et quelle partie tu comptes implémenter côté client car (me concernant) ce n'est toujours pas clair.

[Médinoc]

Pour le coup des changements de ligne, si ton programme n'est pas censé traiter des fichiers avec un encodage des changements de ligne différent du système hôte, tu peux tout simplement ouvrir les fichier en mode texte, ce qui convertit les encodages du fichier hôte en \n.

Sinon, tu épluches toi-même avec une fonction capable d'examiner un caractère et le suivant:

• Si ton caractère lu est un \n, tu l'écris dans ton buffer tel quel (pourquoi le transformer, après tout?).
• Si ton caractère lu est un \r, tu regardes s'il est suivi d'un \n:
  
  • Si oui, tu l'ignores (tu le laisses tomber sans rien écrire dans le buffer).
  • Si non, tu le transformes en \n.

Bien sûr, dans tous les cas l'inconvénient est que le fichier ne sera pas idéntique au bit près en sortie qu'en entrée, vu que les erreurs ne seront pas préservées.

Ensuite, si ta table ne peut même pas stocker un \n, là l'idée du codage en base 64 ressort. Vu que ton texte doit être illisible de toute façon, pas besoin d'utiliser autre chose du genre UTF-7.