Reprise du message précédent :

 
Je vois que tu ne comprends toujours pas ce qu'on te dit :
 
Quand tu fais ta requête vers ta Base de données, tu dois FOURNIR LE CODE. Que ce soit en PHP, en ASP ou n'importe quel autre langage, tu appelles donc ta BDD. Cette page d'appel est TOUJOURS DISPONIBLE pour l'admin du serveur et il n'a aucunement besoin de connaitre ta clé, il lui suffit de récupérer la ligne d'appel à la BDD.
 
Peut importe que dans ton code tu aies par exemple :  
 
sql_blabla(user, exec(blablabla...) (ou exec(blablabla) serait le résultat d'un appel à une fonction secrête, protégée).
 
Tu saisis ? T'es un peu borné comme mec quand même...    

Ah et puis un autre détail : création d'une clé à la volée, non. Si ta base est cryptée, elle l'est de manière uniforme, sinon, c'est inutilisable... Et puis de toutes manières, le principe est toujours le même... A partir du moment ou le serveur lit les entrées de ta BDD, quelque soit le moyen qu'il utilise pour les lire, l'admin y a accès.
 
Bref, fin du topic. Et si tu ne me crois pas, adresse toi à des experts en sécurité qui te diront la même chose...  La seule manière de protéger des données sensibles est d'EXTERNALISER les moyens de les lire et de séparer le stockage de la lecure.
 
A ton niveau, le seul moyen 'raisonnable' serait par exemple de fournir un plugin de lecture des données à tes utilisateurs sous forme de javascipt, AJAX et consort et de décrypter à la volée CHEZ LE CLIENT les informations puisées dans ta BDD.
 
Sinon, il est également possible d'avoir un serveur X qui contient ta BDD et un serveur Y placé chez qqu en qui tu as toutes confiance qui va lire les données et les envoyer au client. Dans ce cas précis, l'admin du serveur X ne peut pas déchiffrer les données présente dans la BDD. Par contre, l'admin du serveur Y lui, pourra forcément y avoir accès, puisque c'est lui qui possède l'outil de déchiffrement.
 
Tant que l'outil de déchiffrement est disponible à une personne, la BDD est également dispo pour cette personne. Le fait de connaitre ou non la clé n'a aucune importance.

Non.
 
Je crois qu'avant de parler de "cryptage", il faut cibler le danger potentiel.
1) si le but est de protéger les infos "contre une récupération pirate" (style un type rentre chez toi et fait un dump bas-niveau de la partition contenant la bdd), alors un cryptage de la partition suffit. On trouve des tas d'outils pour crypter des partitions. Et comme toutes les fonctions bas niveau lecture/écriture utilisent ces outils, les octets sont écrits en cryptés sur le disque mais entrent et sortent en clair. Et c'est transparent pour l'utilisateur. Mais ça ne protège pas contre le type qui se connecte sur ta bdd et qui fait un dump "sql" de ta bdd
2) si le but est de crypter seulement certaines infos (comme le mot de passe du client pour éviter qu'un admin du serveur peu scrupuleux ou aigri (ça existe) utilise ce mot de passe à son compte), alors faut passer par des fonctions de cryptage/décryptage lors de l'insertion/suppression des données. Mais il faut impérativement que la clef de cryptage soit du coté du client sinon cela ne sert à rien.
3) si le but est d'empêcher un tiers d'intercepter les infos passant par le canal de transmission, alors il faut crypter le canal (style SSH)
 
Tout le reste sera un mélange de ces 3 solutions. Sinon je ne vois pas trop le but de crypter une bdd et de fournir à un client (forcément anonyme au début) les outils de décryptage car n'importe quel hackeur recevra ces mêmes outils. Sauf si on dit au client "tes infos, tu ne les récupèreras qu'après être allé chercher la clef de décryptage en appelant 150 fois allopass" mais là, on entre dans une autre optique...
 

Tu sors cette info de radio Bozo ??? Je me bien à quoi servent toutes ces clefs et tous ces keygen sur tous les logiciels (comme MsOffice, COD2, AOE3, etc...) qu'on trouve sur un tas de site spécialisés...

 
Voilà, tu as bien fait le point sur la situation...  
 
Et je rappelle quand même la question du mec : crypter une BDD pour empêcher l'admin du serveur d'avoir accès aux infos de cette BDD y compris les messages.  

Ben il fait passer ses messages via une interface php de cryptage /décryptage avec la clef fournie par le client. Peut-être un peu lourd mais rien de bien compliqué...

 
ben si l'interface de décryptage se trouve sur le serveur, je vois mal comment on pourrait empêcher l'admin du serveur de lire ce qui se trouve dans la BDD. C'est extrêmement facile de capter ce qu'envoie un client à un serveur quand on est admin du serveur et qu'on sait en plus quelle page fait le traitement.
 
Mais de toutes manières,  il est évident que cela ne sera pas transparent pour l'utilisateur et qu'au minimum la clé devra se trouver chez le client. C'est bien pour cela qu'à mon avis la seule manière de garantir que l'admin du serveur ne pourra jamais lire les données présentes sur son propre serveur, c'est d'externaliser le module de décryptage chez le client parce qu'à ce moment là, ce qui circulera sur le net, ce sont des infos cryptées et pas les messages en clair sur la BDD

 
Je me répond à moi-même pour préciser un truc :
 
Il y a une différence fondamentale entre crypter un mot de passe pour un forum et crypter l'ensemble des messages de ce forum en tentant de faire en sorte que seuls ceux disposant du password aient accès aux messages.
 
Dans le premier cas, le password est unique pour chaque client, il n'est jamais décrypté. On se contente de comparer une clé cryptée à un résultat également crypté dans la BDD.  
 
Dans le second cas, la clé est la même pour TOUS les clients, les procédures d'appel identiques et il y a un module de décryptage sur le SERVEUR aisément accessible pour l'admin.

Pas forcement, Tu peux tres bien faire un couple cle <-> client.
Pour un systeme de cle symetrique c'est un peu moyen, tu peux ecouter et intecepter les cles
 
Par contre, si tu utilise un systeme de cle assymetrique, tu n'a plus ce probleme : il faut tout chiffrer avec la cle publique et seul le client pourra dechiffrer avec sa cle privee. (mais effectivement dans ce cas encore, le systeme de dechiffrement est chez le client)
 
PS : le cryptage n'existe pas le chiffrement oui

non mais ce que je veux dire par la, c'est qu'il est possible que tu n'ai pas une cle unique par client, et que ca sert a rien de la part de l'admin dans ce cas la d'ecouter. Sinon jsuis d'accord sur le fait que pour dechiffrer, c'est chez le client (ou un tier).

 
Dans le cas du passwd, il ne s'agit pas d'un chiffrement bijectif (partant de l'arrivé on peut remonter au départ) mais d'une chiffrement réductif (partant de l'arrivée on ne peut pas remonter au départ). Comme si on te disait "le résultat de l'algo 'carré' est 25". Tu ne sauras jamais si le départ était "5" ou "-5".
D'ailleurs l'algo "DES" utilisé en 1970 a été remplacé en 1996 par "MD5". On réduit le mot de passe fourni par l'utilisateur et on compare le résultat avec le résultat stocké. Une telle méthode ne peut pas servir à chiffrer des infos car on ne pourra jamais les déchiffrer.
 
Dans le second cas, il s'agit d'un chiffement bijectif. En partant de l'arrivé, on peut revenir au départ. La clef de déchiffrement peut être la même que la clef de chiffrement (chiffrement symétrique comme DES ou ROT13 ou ENIGMA) ou différente (chiffrement asymétrique comme RSA). Mais il n'y a aucune raison que la clef soit la même pour tout le monde. Faut pas confondre "algo de chiffement/déchiffrement" et "clef". Ex: dans le chiffre de César, l'algo était un décalage de lettres. La clef de chiffrement était "+3" et la clef de déchiffrement était "-3" (d'où la conclusion que RSA n'a pas été le premier exemple de chifferment asymétrique ).

Les initiatives comme md5 reverse lookup compromettent d'ailleurs (encore plus) le MD5... et à terme ce type de cryptage chiffrement.

De toute façon, la collision MD5 est maintenant possible.
Exemple: Les 2 URL suivantes mênent à 2 pages HTMl totalement différentes... mais les 2 ont la même signature MD5
http://www.doxpara.com/t1.html
http://www.doxpara.com/t2.html
 
Et à l'adresse suivante: http://www.codeproject.com/useritems/HackingMd5.asp, il y a un code en C# qui permet de donner le même MD5 aux fichiers que l'on veut.