Merci encore à ynx pour sa contribution qui m'a bien aidé.

Le complément est
$Chaine = <<<'EOT'
±²45`¯dL3'O*hq¹"2L;³r7£brbz*PbZj^µ8e<¿E@5¦²aS´rqx¢JG¢Yt½±»O(+¼jºy¸§:+5Xzh¬k¯\\$Q
EOT;

pour avoir une chaîne brute et sans interprétation, manipulable facilement.

Attention 'EOT' entraine une réaction bizarre de la coloration syntaxique sous SublimText semble-t-il, mais ça fonctionne.

En terme de sécurité informatique, réinventer la roue n'a jamais été une bonne pratique.

Bon, ton affirmation est définitive et met fin à tout débat. Même si elle me parait contredite par la simple évolution constatée depuis les débuts de la sécurité (informatique ou non) et ne répond pas aux failles découvertes dans les roues abandonnées depuis. Mais finalement c'est plus de la philo que du code donc je comprends bien que ce n'est pas le lieu.

Ok, alors revenons à ma question, php autorise t-il la manipulation d'une chaîne contenant n'importe quel valeur prise par l'octet et couvrant l'ensemble de la table ascii, y compris chr(34), chr(39) et chr(92) sans qu'il faille altérer la chaîne par des caractères "parasites" (en l'espèce des caractères d'échappement).

convaincu, ou au moins titillé ?

Non pas du tout convaincu. En terme de sécurité informatique, réinventer la roue n'a jamais été une bonne pratique.

Mais je ne veux pas lancer un débat, l'essentiel c'est au moins que tu le fasses en connaissance de cause.

@ @rthur.

Débat intéressant et éternel sur "le fait maison" et "l'achat sur étagère".

Raisons pour (à mon sens) :
- une solution propriétaire augmente très sensiblement la difficulté (je n'ai pas dis la qualité du chiffrement) pour l'assaillant. Donc élimine énormément de faiblesses (attaques par dico et autres) des solutions très largement diffusées (MD5 au hasard). Le but est de dire, suis-je suffisamment important pour que l'assaillant s'investisse à casser ma solution alors qu'avec un outil standard il forcera sans effort x autres cibles pendant ce temps là ?
- comprendre ce qu'est réellement le chiffrement. J'ai donné des cours là-dessus et les étudiants encouragés à se documenter sur le chiffrement dans l'histoire apprennent énormément sur le chiffrement, le haschage, la sécurité, l'informatique en général et découvrent ce qu'ils ne comprenaient pas si bien que ça (le salage par exemple) dans les contraintes de sécurité.
- une solution générale qui marche peut aussi te péter dans les doigts, exemple hélas nombreux de compromission comme truecrypt voir même de fort soupçons sur pas mal de certificats https par exemple. Et là quand il faut migrer en catastrophe c'est pas génial non plus.
- réinventer la roue ou remettre en question les acquis c'est aussi parfois découvrir un nouveau modèle de demain, donc c'est humain d'avoir un iconoclaste de temps en temps qui se fasse les dents (et se les casse parfois) sur les évidences qu'il cherche à contourner.
- et bien sûr le plaisir personnel de pondre un algo qui permet de disposer d'un seul outil pour un chiffrement/salage différencié jusqu'au niveau enregistrement dans une base. Par paresse je ne vais pas au niveau du champs mais ça pourrait le prendre en charge. Le tout inspirer des principes de chiffrement à feuillet unique par exemple.
- pouvoir disposer aussi d'une réversibilité.

Raison contre
- l'investissement recherche-temps de dév- mais ça ne me pose pas de problème,
- portabilité - je l'applique en principe général pas sur un outil de programmation ou un environnement particulier donc pas trop inquiet, même si parfois (la preuve avec mes questions) il peut dans un environnement y avoir un point de blocage. Reste à le lever.
- la complexité à transmettre ... environ 15 lignes de codes simples en php pour le chiffrement (autant en déchiffrement), séparer les clefs des algo (augmente du même coup le temps de compréhension de l'assaillant), avoir un échantillonnage très réduit pour l'attaquant (même valeur, avec même clef principale et même algo donne deux chiffrements différents sur deux enregistrements de la même base),
- l’orgueil ... oui un peu comme un artisan du code, je le confesse.

convaincu, ou au moins titillé ?

Bonjour,

Une question peut être naïve mais pourquoi ne pas utiliser mcrypt ?
http://php.net/manual/fr/mcrypt.ciphers.php

Car en matière de chiffrement vouloir réinventer la roue c'est généralement prendre des risques par rapport à des solutions éprouvées et reconnues.
Par ailleurs, le jour où tu veux faire une migration, c'est toujours plus pratique de se baser sur des modes de chiffrement standard que de faire du propriétaire.

Tout d'abord ynx, merci vraiment de ton aide qui m'a grandement fait avancer.
Je n'irais pas jusqu'à dire que je te remercie chaleureusement du fait des températures ambiantes, mais le cœur y est.

Il ne me reste plus qu'un problème dans l'exemple donné : pouvoir gérer les caractères d'échappement comme des caractères quelconques.

En effet je me retrouve avec le double antislash (générés aléatoirement) qui me met dedans, mais l'exemple aurait aussi pu contenir quote ou double quote, puisque je doit pouvoir trouver dans ma chaîne n'importe quel code ascii de 0 à 255.
Comment gérer la chaine de façon brute sans ajouter ou retirer de caractère et sans me retrouver avec une quote qui soit interprétée ?
Par exemple les 4 derniers éléments de la chaîne :
"±²45`¯dL3SO*hq¹N2L;³r7£brbz­PbZj^µ8e<¿E@5¦²aS´rqx¢JG¢Yt½±»O(+¼jºy¸§:+5Xzh¬k¯\\$Q"

La doc sur addslashes() & stripslashes() est conséquente mais va modifier ma chaîne.

En effet la chaine de caractères créée chr() est bien codée en ASCII et la fonction strlen() devrait retourner le bon résultat.
Par contre si je copie cette chaine dans un fichier php encodé en UTF8, cette chaine est alors codée en UTF8 le résultat de strlen() ne correspond pas à celui attendu.

Exemple (fichier source encodé en UTF8 sans BOM) :

<?php

$a = chr(175); // tiret haut encodé en ascii
var_dump($a);
var_dump(ord($a));
echo strlen($a);

echo '<br>';

$b = '¯'; // tiret haut encodé en utf8
var_dump($b);
var_dump(ord($b));
echo strlen($b); 

echo '<br>';

$c = utf8_decode('¯');
var_dump($c);
var_dump(ord($c));
echo strlen($c);

En espérant que cette piste t'aidera à trouver la solution.

Merci pour le rappel bienvenu au mb_*, mais ça ne change rien.

La longueur est toujours de 99 et j'ai donc toujours les même 20% de caractères supplémentaires parasites.

En réalité, je ne sais pas trop si c'est UTF-8 qui me pose problème.

Dans l'absolu, l'affectation de la chaîne et sa lecture à partir de ord() et chr() devraient me donner un résultat qui n'est pas celui que j'ai indépendamment d'un charset qui affecte l'affichage de la page ou le stockage en base ....

Salut,

Le problème vient du fait que les caractères UTF8 peuvent être encodé sur plus d'un octet, ce qui fausse le résultat des fonctions non multi-octets tel que strlen().
Tu peux utiliser les fonctions multi-octets pour résoudre ceci : http://php.net/manual/fr/ref.mbstring.php

Exemple :

echo strlen('père'); // retourne 5 car le è est codé sur 2 octets
echo mb_strlen('père'); // retourne 4

Bonne journée

Bonjour aux lecteurs,

J'ai des résultats incompréhensibles pour moi sur la manipulation de chaînes de caractères particulières. Bien que sans impact sur le problème rencontré le but est ici de faire du chiffrement.

- Création d'une chaîne de caractères partir d'un tirage aléatoire sur les valeurs de 0 à 255 avec utilisation de chr()
$Chaine = 'wµh®/¤d5¥b1dNvaB,f*G½j uV w;I[6®±gJ]|';

Cette chaîne devient un référent pour mon chiffrement.

Je vais donc appliquer un algo quelconque (opération mathématique, salage et déplacement dans la chaine, qui n'est pas l'objet de la question) pour obtenir une valeur entre 0 et 255 pour chaque caractère d'une cible.
Ainsi
$Cible = "Ceci n'est qu'1 chaîne quelconque à chiffrer en 2015 !"
$Resultat = Chiffrer($Cible);
donne "±²45`¯dL3SO*hq¹N2L;³r7£brbz­PbZj^µ8e<¿E@5¦²aS´rqx¢JG¢Yt½±»O(+¼jºy¸§:+5Xzh¬k¯\\$Q";

Pour aboutir à ceci l'algo produit un entier, caractère par caractère et cet entier résultant est traité par Chr() pour retourner une chaîne chiffrée de la cible :
algo('C') = 177 ---> Chr(177) = ±
algo('e') = 178 ---> Chr(178) = ²
algo('c') = 52 ---> Chr(52) = 4
algo('i') = 53 ---> Chr(53) = 5
algo(' ') = 96---> Chr(96) =`
algo('n') = 175 ---> Chr(175) = ¯
algo("'") = 100 ---> Chr(100) = d
algo('e') = 76 ---> Chr(76) = L
etc ...

Cette chaîne en résultat est destinée à être stockée dans une table (interclassée UTF-8).

Problème : avant même le stockage j'ai des incohérences de plusieurs types :
$Resultat = "±²45`¯dL3SO*hq¹N2L;³r7£brbz­PbZj^µ8e<¿E@5¦²aS´rqx¢JG¢Yt½±»O(+¼jºy¸§:+5Xzh¬k¯\\$Q";
$Borne = strlen($Resultat) - 1;
echo $Borne.'<br>';
for ($Index=0;$Index<=$Borne;$Index++) {echo substr($Resultat, $Index, 1).' '.Ord(substr($Resultat, $Index, 1)).'<br>';}

$Resultat est donc une suite ascci obtenue précédemment
$Borne devrait être de 79 et pourtant j'ai un echo de 99
J'attends une suite débutant par ± 177 - ² 178 - 4 52 - 5 53 - ` 96 -¯ 175 - d 100 -L 76 ...
alors que le retour obtenu est � 194 - � 177 - � 194 - � 178 - 4 52 - 5 53 - ` 96 - � 194 - � 175 - d 100 - L 76

Je bloque sur les caractères parasites (position 0, 2 et 7 par exemple) qui gonflent la longueur obtenue par StrLen() et sur le fait accessoirement que ma page (charset UTF-8) substitut le caractère � mais pas tout le temps.

Merci d'avance de votre aide (le chiffrement n'est pas le débat, mais si certains veulent échanger à ce sujet, pourquoi pas).