Publié par Guillaume Champeau, le Mercredi 15 Juin 2011

Le contenu de Dropbox est chiffré, mais pas confidentiel

La gratuité a un coût. Lorsqu'un utilisateur envoie des fichiers sur Dropbox, ceux-ci sont chiffrés avec un algorithme et une clé de chiffrage en principe suffisants pour garantir la confidentialité des données stockées. Mais Dropbox conserve un double de la clé, et ne se prive pas de l'utiliser pour réaliser des économies dans ses data-centers.

Sylvain Métille, auteur du blog Nouvelles technologies et droit, publie un billet très instructif sur Dropbox, le fameux service en ligne de stockage et de synchronisation de fichiers. Dropbox offre un espace de stockage gratuit de 2 Go, et un utilitaire sous Windows, Mac, Linux, iOS, Android et BlackBerry, qui permet d'accéder à distance aux fichiers qui y sont déposés. Il peut être utilisé seul, pour accéder à ses documents personnels depuis n'importe quel poste, ou à plusieurs en partageant l'accès à des dossiers avec d'autres utilisateurs.

Parmi ses promesses, Dropbox annonce que "tous les fichiers stockés sur Dropbox sont chiffrés (AES-256)", ce qui doit garantir la confidentialité de leur contenu. Impossible de les lire sans posséder la clé de déchiffrage. Or c'est là que réside l'ambiguïté, comme l'explique Sylvain Métille :

Jusqu'à récemment, Dropbox affirmait que les fichiers hébergés étaient soumis à un chiffrement (AES-256) et qu'ils étaient inaccessibles sans le mot de passe de l'utilisateur, laissant croire que personne d'autre que l'utilisateur ne détenait la clé de cryptage, autrement dit seul l'utilisateur avait les moyens de lire les données (Dropbox ne voyant en quelque sorte qu'un coffre fort fermé).

Christopher Soghoian a démontré que cela n'était pas le cas et Dropbox a modifié les informations contenues sur son site. Maintenant Dropbox indique seulement que tous les fichiers sont chiffrés (AES-256) et admet que les employés peuvent accéder aux données (même si cela leur est interdit). Pour reprendre la comparaison, Dropbox admet avoir la clé du coffre

Dropbox a ainsi mis son contrat en conformité avec ses pratiques, sans abandonner le stockage de la clé de chiffrement. Il apparaît d'ailleurs évident que le service utilise cette clé dont il possède le double, puisque "pour éviter de stocker un fichier déjà téléchargé par un autre utilisateur, Dropbox compare les fichiers avec ceux déjà enregistrés et n'en conserve qu'une seule version". Or il serait techniquement impossible de comparer les fichiers sans les déchiffrer. L'option choisie par Dropbox se fait au détriment de la vie privée de ses clients.

"Les services de sauvegarde en cloud n'ont pas besoin de concevoir leurs produits de cette manière", faisait remarquer Christopher Soghoian en avril dernier, lors de ses révélations. "Spideroak et Tarnsap sont deux services concurrents qui chiffrent les données de leurs utilisateurs avec une clé connue seulement de l'utilisateur. Ces sociétés ont choisi de privilégier d'abord la vie privée de leurs utilisateurs, mais l'effet de bord est qu'ils ont besoin de davantage d'espace de stockage. Si 20 utilisateurs uploadent le même fichiers, les deux sociétés conservent 20 copies ce fichier".

Publié par Guillaume Champeau, le 15 Juin 2011 à 12h56
 
40
Commentaires à propos de «Le contenu de Dropbox est chiffré, mais pas confidentiel»
Inscrit le 06/07/2010
147 messages publiés
Arf… Bon ben, vivement Syncany (voire FTPBox ) ! Dommage pour Dropbox.
[message édité par Diti le 15/06/2011 à 13:09 ]
Inscrit le 30/04/2005
12571 messages publiés
Le problème était connu.

De plus pas mal de gens mettent aussi pas mal de photos dans l'espace public.

Il faut prendre ce service pour ce qu'il est: échanger des fichiers légaux et sans données sensibles sur plusieurs de ses plateformes (PC tablettes & téléphones). Ni plus ni moins.
[message édité par L-observateur le 15/06/2011 à 13:52 ]
Inscrit le 11/03/2009
3541 messages publiés
Sur quels critères considèrent ils que c'est le meme fichier et par conséquent , qu'il peuvent le supprimer . Taille, extention, nom ????

exemple: X et Y downloadent ubuntu-11.04-desktop-fr.iso , taille 643Mo.

à la fin du down; X l 'envoi direct sur dropbox.
à la fin du down; Y envoi par mégarde Kubuntu mal renommé en ubuntu-11.04-desktop-fr.iso , taille 643Mo aussi .

dropbox vire un doublon , celui de X ,
Donc quand X récupère son fichier il récupère Kubuntu ??????????

Des détails sur le principe de fonctionnement du "repérage doublon" ?

Je vois pas comment ça peut marcher sans aucune erreur.
[message édité par speed le 15/06/2011 à 13:26 ]
Inscrit le 15/06/2011
2 messages publiés
Sur quels critères ils considèrent que c'est le meme fichier et par conséquent il peuvent le supprimer . Taille, extention, nom ????


Une des solutions possible serait de faire une somme de contrôle (Checksum, voir http://fr.wikipedia....wiki/Checksum). Si deux checksums sont identiques, les fichiers sont les mêmes.
Inscrit le 05/04/2011
1587 messages publiés
Les employés de dropbox vont bien s'amuser : je n'y mets que du porno...
Inscrit le 14/06/2007
571 messages publiés
speed, le hash MD5 du fichier et autres vérifications de ce genre ne te disent rien ?
Inscrit le 05/04/2011
1587 messages publiés
speed, le 15/06/2011 - 13:20
Sur quels critères considèrent ils que c'est le meme fichier et par conséquent , qu'il peuvent le supprimer . Taille, extention, nom ????

exemple: X et Y downloadent ubuntu-11.04-desktop-fr.iso , taille 643Mo.

à la fin du down; X l 'envoi direct sur dropbox.
à la fin du down; Y envoi par mégarde Kubuntu mal renommé en ubuntu-11.04-desktop-fr.iso , taille 643Mo aussi .

dropbox vire un doublon , celui de X ,
Donc quand X récupère son fichier il récupère Kubuntu ??????????

Des détails sur le principe de fonctionnement du "repérage doublon" ?

Je vois pas comment ça peut marcher sans aucune erreur.

Non ! car il doit en plus y avoir une vérification sur le hashage
Si les deux sommes sont différentes alors les deux fichiers sont différents (l'inverse n'est pas vrai !)
le nom et la taille ne suffisent pas !
Inscrit le 05/04/2011
1587 messages publiés
guicab, le 15/06/2011 - 13:28
Sur quels critères ils considèrent que c'est le meme fichier et par conséquent il peuvent le supprimer . Taille, extention, nom ????


Une des solutions possible serait de faire une somme de contrôle (Checksum, voir http://fr.wikipedia....wiki/Checksum). Si deux checksums sont identiques, les fichiers sont les mêmes.

Non, c'est l'inverse : si deux sommes sont différentes, alors les fichiers sont différents !
[message édité par ccomp le 15/06/2011 à 13:33 ]
Inscrit le 30/07/2009
2 messages publiés
Sur quels critères considèrent ils que c'est le meme fichier et par conséquent , qu'il peuvent le supprimer . Taille, extention, nom ????

exemple: X et Y downloadent ubuntu-11.04-desktop-fr.iso , taille 643Mo.

à la fin du down; X l 'envoi direct sur dropbox.
à la fin du down; Y envoi par mégarde Kubuntu mal renommé en ubuntu-11.04-desktop-fr.iso , taille 643Mo aussi .

dropbox vire un doublon , celui de X ,
Donc quand X récupère son fichier il récupère Kubuntu ??????????

Des détails sur le principe de fonctionnement du "repérage doublon" ?

Je vois pas comment ça peut marcher sans aucune erreur.

Hash MD5 a la volée, lors de la reception du fichier, une signature est créée, à l'issue du transfert le système est alors capable de voir si le fichier est déja stocké ou pas.

En clair cela permet d'économiser du stockage mais en aucun cas de la bande passante puisque techniquement le fichier est envoyé à DropBox qui choisit alors de le stocker ou non
Inscrit le 14/07/2004
7722 messages publiés
flob (Modérateur(rice)) le 15/06/2011 à 13:49
franch, le 15/06/2011 - 13:37

Hash MD5 a la volée, lors de la reception du fichier, une signature est créée, à l'issue du transfert le système est alors capable de voir si le fichier est déja stocké ou pas.

En clair cela permet d'économiser du stockage mais en aucun cas de la bande passante puisque techniquement le fichier est envoyé à DropBox qui choisit alors de le stocker ou non

Y a un truc, que je ne comprends pas.....En quoi le fait que Dropbox possède la clé lui permet d'effectuer une comparaison de checksum (si c'est bien la méthode utilisée) (si la clé est envoyée en meme temps que le fichier)? Et inversement en quoi les autres services de cloud ne peuvent pas faire pareil lorsqu'ils recoivent le fichier ainsi que la clé ?
Inscrit le 11/03/2009
3541 messages publiés
@ guicab;Killua , ccomp et franch . Merci pour vos réponses , je comprends mieux maintenant .

Allez savoir pourquoi ,j' étais persuadé que le hashage était une chose qui ne fonctionnait uniquement que dans l' univers du p2p un petit coup de wiki hash MD5 et hop , je me coucherais moins bete ce soir

Edit : Par contre ça ouvre des perspectives que j' imaginai pas . tout dépends si l'identification ne peut se faire que fichier 100% uploadé ou pas , mais s' il est possible de savoir à 15% du up que le data center le possède j 'imagine le gain de temps pour l utilisateur , l économie de BP toussa .

ça reviens presque à envoyer une requette as tu le fichier untel , si non upload et si oui link et hop .
[message édité par speed le 15/06/2011 à 13:54 ]
Inscrit le 05/03/2008
922 messages publiés
Il est possible de savoir si deux fichier sont identiques même s'ils sont chiffré si le mode d'opération est de l'ECB... enfin, j'immagine que c'est réalisable.
http://fr.wikipedia.org/wiki/Mode_d'opération_(cryptographie)#Dictionnaire_de_codes_:_.C2.AB_Electronic_codebook_.C2.BB_.28ECB.29
Inscrit le 20/08/2010
909 messages publiés
Pour utiliser ce genre de services, il suffit de chiffrer soi-même ses données avant de les envoyer dans le nuage. On peut par exemple coupler Dropbox et encfs et utiliser la même clé sur les machines synchronisées. Ce qui est dans le nuages reste inaccessible aux curieux.
Inscrit le 21/12/2005
1566 messages publiés
Je suis utilisateur pro de dropbox, il est effectivement vrai, qu il y a quelques temps, il y avait bien un system de cache pour les fichier, aujourd'hui c est fini
Inscrit le 15/08/2008
2851 messages publiés
speed, le 15/06/2011 - 13:20
Sur quels critères considèrent ils que c'est le meme fichier et par conséquent , qu'il peuvent le supprimer . Taille, extention, nom ????

exemple: X et Y downloadent ubuntu-11.04-desktop-fr.iso , taille 643Mo.

à la fin du down; X l 'envoi direct sur dropbox.
à la fin du down; Y envoi par mégarde Kubuntu mal renommé en ubuntu-11.04-desktop-fr.iso , taille 643Mo aussi .

dropbox vire un doublon , celui de X ,
Donc quand X récupère son fichier il récupère Kubuntu ??????????

Des détails sur le principe de fonctionnement du "repérage doublon" ?

Je vois pas comment ça peut marcher sans aucune erreur.


Plutôt par hashage je pense. Il y a vraiment peu de chance qu'un même fichier ait le même nom, même taille et même hash.
Inscrit le 25/01/2007
2899 messages publiés
Le problème était connu.

De plus pas mal de gens mettent aussi pas mal de photos dans l'espace public.

Il faut prendre ce service pour ce qu'il est: échanger des fichiers légaux et sans données sensibles sur plusieurs de ses plateformes (PC tablettes & téléphones). Ni plus ni moins.


bah 7zip chiffré et protégé par mot de passe et voila...

edit : liladou dit que ce serait possible de déchiffrer un fichier malgré tout. qqun a un avis ? si on fait 7zip avec un chiffrement aes par dessus et mdp ca protège ou pas ?
[message édité par pleindeuss le 15/06/2011 à 14:13 ]
Inscrit le 31/08/2010
91 messages publiés
Zut alors. J'utilise l'offre gratuite de Dropbox à des fins professionnelles pour le backup de mes bases de données et comme plateforme de téléchargement pour les fichiers trop lourds pour envoyer par mail. Elle est commercialement la meilleure offre sur le marché avec ses 2Go (il ne m'en faut pas plus, mais pas moins de 1 Go). Son pire inconvénient reste la quantité de mémoire nécessaire au programme qui tourne en permanence en arrière-plan (de l'ordre de 50 Mo sur mes 4Go et entre 5 et 10 % de CPU sur un quadricoeur 2,8 Ghz en cours de synchronisation). C'est plutôt lourd pour un programme de veille.

Alors, qu'un employé lambda de chez Dropbox puisse supposément accéder à mes dernières factures ou à mes lexiques est gênant mais pas un danger pour mes activités. en revanche, qu'un hacker récupère des clés stockées chez Dropbox et foute le boxon dans l'espace de stockage (pour distribuer un logiciel malicieux par exemple, qui sera automatiquement téléchargé sur les PC connectés pour synchronisation), ça, ça fout les boules.

De plus, il y a légalement tout simplement un certain problème de confidentialité. Théoriquement, je dois respecter la confidentialité de tous les échanges avec mes clients. Le fait de savoir qu'un tiers peu dans l'absolu accéder à mes fichiers, me met en tort.

Bref, on n'est jamais aussi bien servi que par son propre serveur FTP, encore faut-il avoir les connaissances requises pour en assurer la sécurité.
Inscrit le 11/03/2009
3541 messages publiés
Ah je suis désolé avec mes tas de questions mais j' aime bien comprendre .

Le principe décris dans l'article est visiblement pour le data center d éviter la redondensce des fichiers et gagner en espace de stockage . l'aspect économie je le cerne bien , mais l' aspect débit me pose une interrogation.
si 100 personnes téléchargent simultanément un meme fichier (mais unique) ce fichier vas provenir selon le downloadeur du hd 127 du hd 254,du hd 752 etc . Mais là le fichier mutualisé ne proviens que d une seule source .
Alors j imagine les hd des datas center differents de ceux de mon pc , gros cache , vitesse elevée mais quand meme ......
[message édité par speed le 15/06/2011 à 14:20 ]
Inscrit le 31/08/2010
91 messages publiés
En même temps, s'ils cherchent à économiser de l'espace de stockage, ils peuvent tout simplement supprimer l'option de récupération de fichiers historiques, hein. Le back-up de versions précédentes d'un même fichier n'a d'utilité que pour une infime partie de la clientèle (tout du moins en offre gratuite).
Inscrit le 16/02/2010
4 messages publiés
Or il serait techniquement impossible de comparer les fichiers sans les déchiffrer

Ce n'est pas une preuve: le hash peut très bien être calculé du côté client *avant* d'envoyer le fichier.
De cette manière, la sécurité est conservée, et le fichier n'a même pas besoin d'être envoyé s'il existe déjà, donc économise de la bande passante.
Inscrit le 10/07/2008
3081 messages publiés
Quelque chose m'échappe peut-être, mais il me semble que si j'avais besoin de stocker des données sensibles dans le nuage, je les crypterais en local avant de les expédier.
Inscrit le 11/02/2009
304 messages publiés
speed, le 15/06/2011 - 14:17
Ah je suis désolé avec mes tas de questions mais j' aime bien comprendre .

Le principe décris dans l'article est visiblement pour le data center d éviter la redondensce des fichiers et gagner en espace de stockage . l'aspect économie je le cerne bien , mais l' aspect débit me pose une interrogation.
si 100 personnes téléchargent simultanément un meme fichier (mais unique) ce fichier vas provenir selon le downloadeur du hd 127 du hd 254,du hd 752 etc . Mais là le fichier mutualisé ne proviens que d une seule source .
Alors j imagine les hd des datas center differents de ceux de mon pc , gros cache , vitesse elevée mais quand meme ......


Il peut y avoir des economies en bande passante, mais legere, en effet, on parle d'un hash pour comparer les fichiers, sauf qu'il y a un client lourd, si c'est ce client lourd qui genere ce dit hash et l'envoie au serveur, le serveur peut repondre "je le connais deja, pas besoin de le DL". Donc economie de bande passante pour l'upload.

Maintenant pas dans l'autre sens, sur internet il n'existe pas de Broadcast ou de multicast a proprement parler, seulement de l'unicast. Comprendre, quand on envoie des fichier a 10 personnes, il y aura 10 connection sortante et pas une seule avec les clients qui prennent ce qu'ils veulent (comme le broadcast), donc 10 personnes telecharge le meme fichier, 10 fois la bande passante necessaire...

Voir Broadcast, multicast unicast sur wikipedia pour le completement necessaire
Inscrit le 22/11/2010
2 messages publiés
Je vous conseille plutot un service comme spideroak, là c'est du "zéro knowledge managment". Inconvénient c'est que si on perd son mot de passe on ne peut rien récupérer mais par contre personne d'autre que moi ne peut accéder à mes données !

https://spideroak.co...e0636e9f3b56d14

Il pourrait même peut être devenir open source d'ailleurs, mais bon ils l'annoncent depuis longtemps sans le faire...
Inscrit le 22/11/2010
2 messages publiés
Je vous conseille plutot un service comme spideroak, là c'est du "zéro knowledge managment". Inconvénient c'est que si on perd son mot de passe on ne peut rien récupérer mais par contre personne d'autre que moi ne peut accéder à mes données !

https://spideroak.co...e0636e9f3b56d14

Il pourrait même peut être devenir open source d'ailleurs, mais bon ils l'annoncent depuis longtemps sans le faire...
Inscrit le 17/03/2008
2648 messages publiés
Ce que je comprends pas c'est qu'on peux effectivement gagner de la place sans déchiffrer: Il suffit de comparer les hash des fichiers (à condition de choisir un algo de hash fiable, donc sans méthode connue pour créer des collisions). Ensuite on stocke le fichier binaire (chiffré) à l'identique... non ? (ça implique que chaque fichier soit chiffré séparément, et non pas comme dans une seule grosse archive)

Nul besoin de savoir la clé pour ça: Si 2 fichiers chiffré ont le même hash , alors ce sont les mêmes, et on ne peux les stocker qu'une fois.
C'est de la déduplication "classique".

Il n'en est pas moins vrai que le chiffrement de dropbox se fait coté serveur, via une clé que le client n'a pas généré: C'est donc potentiellement vulnérable, à la fois par malice (employé indélicat, intrusion,..) ou par réquisition judiciaire.

La "solution" est simple, et valable pour TOUT services de ce type, quel qu'ils soient: Chiffrer localement avant d'envoyer si les documents sont confidentiels, quitte à utiliser une méthode qui supporte plusieurs clés pour plusieurs utilisateurs (type fichier image LUKS sous linux, FreeOTFE sous windows)
Dans le cas de fichiers publics , par définition pas de chiffrement nécessaire.
Inscrit le 28/01/2010
20 messages publiés
https://spideroak.co...y-you-if-we-did

pas si simple et donc spideroak ne veux pas le faire
Inscrit le 24/02/2009
783 messages publiés
bunam, le 15/06/2011 - 15:33

https://spideroak.co...y-you-if-we-did

pas si simple et donc spideroak ne veux pas le faire

C'est pas que une question de simplicité, c'est que ce serait stupide: si les utilisateurs sont pas trop cons, ils chiffrent en local d'abord. Et alors la technique du hash sert plus à rien.
Donc pourquoi implementer une technique qui tend à être peu efficace, en plus d'être vraiment douteuse niveau sécurité/confidentialité? spideroak a raison (encore que tarsnap est plus a recommender car open source).
Dropbox fout par terre sa feature "chiffrement" avec cet histoire de hash.
Inscrit le 15/06/2011
4 messages publiés
obcd -> Non ça ne fonctionne pas, si le serveur n'a pas la clef il ne peut pas économiser de la place.
Parce que si effectivement stocké en clair le hash d'un fichier chiffré permettrait de savoir quand un autre utilisateur poste le même, cela ne permettrait pas à l'autre utilisateur de pouvoir lire le fichier chiffré du premier utilisateur, il faut donc stocké son fichier chiffré à lui également (à moins que tout le monde est la même clef et du coup le chiffrement n'aurait aucun intérêt). Sinon un service de stockage où l'on poste des fichiers sans pouvoir les relire c'est pas terrible.
Ensuite pour des raisons de sécurité ce serait nul de stocké un hash clair d'un fichier chiffré. Sinon quand on détecte que deux fichiers sont identiques il suffit de connaître celui de l'un des deux utilisateurs pour connaître celui de l'autre.
Et puis qu'un fichier soit publique ne signifie pas forcément que tu veuille que l'on soit au courant que tu l'ai.
[message édité par mac.aque le 15/06/2011 à 15:56 ]
Inscrit le 24/02/2009
783 messages publiés
@obcd
Nan, ce que tu dis ne fonctionnerait que si tout le monde chiffrait avec la même clé, ce qui aurait peu d'interet.
Après chiffrage avec 2 clé différentes du même fichier, on obtient deux "fichiers" différents... qui auront donc un hash différent ;-).
C'est le "prix" du chiffrage. Autre exemple: impossible de mettre du traffic SSL en cache. D'ailleurs si tu réussissais à le faire, tu te transformerais en attaquant du type man-in-the-middle.
[message édité par thedarklord le 15/06/2011 à 16:31 ]
Inscrit le 17/03/2008
2648 messages publiés
@mac.aque , @thedarklord :

Oui, en fait vous avez carrément raison.
Désolé pour le bruit, me suis complètement fourvoyé.
Inscrit le 29/09/2010
182 messages publiés
Sur quels critères considèrent ils que c'est le meme fichier et par conséquent , qu'il peuvent le supprimer . Taille, extention, nom ????

exemple: X et Y downloadent ubuntu-11.04-desktop-fr.iso , taille 643Mo.

à la fin du down; X l 'envoi direct sur dropbox.
à la fin du down; Y envoi par mégarde Kubuntu mal renommé en ubuntu-11.04-desktop-fr.iso , taille 643Mo aussi .

dropbox vire un doublon , celui de X ,
Donc quand X récupère son fichier il récupère Kubuntu ??????????

Des détails sur le principe de fonctionnement du "repérage doublon" ?

Je vois pas comment ça peut marcher sans aucune erreur.


Et bien renseigne toi sur le net, il y a des tonnes de softs qui font ca depuis des années sans jamais eliminer un faux doublon ( par contre en cas de doute ils conservent le doublon soupsonné mais non avéré pour eviter la perte de data). Le fonctionnement de ces logiciels est connu ( tu as tous les details en ligne) et efficace, j en utilise depuis des annes sur les serveurs que j administre dans ma boite, et jamais perdu de fichier, mais quelques doublons sont présent...
Inscrit le 29/09/2010
182 messages publiés
Waylandes, le 15/06/2011 - 14:00
Je suis utilisateur pro de dropbox, il est effectivement vrai, qu il y a quelques temps, il y avait bien un system de cache pour les fichier, aujourd'hui c est fini


peut etre mais l article ne parle pas du cache !
Inscrit le 19/04/2011
1421 messages publiés
speed, le 15/06/2011 - 13:20
Sur quels critères considèrent ils que c'est le meme fichier et par conséquent , qu'il peuvent le supprimer . Taille, extention, nom ????

exemple: X et Y downloadent ubuntu-11.04-desktop-fr.iso , taille 643Mo.

à la fin du down; X l 'envoi direct sur dropbox.
à la fin du down; Y envoi par mégarde Kubuntu mal renommé en ubuntu-11.04-desktop-fr.iso , taille 643Mo aussi .

dropbox vire un doublon , celui de X ,
Donc quand X récupère son fichier il récupère Kubuntu ??????????

Des détails sur le principe de fonctionnement du "repérage doublon" ?

Je vois pas comment ça peut marcher sans aucune erreur.


Après avoir comparé le nom, puis la taille, il n'est pas difficile de comparer bit à bit (ou tranche par tranche) le contenu de deux fichiers. Surtout que dès qu'il y a un bit de différence, cela s'arrête. Il faudrait pas de bol pour que ce soit le dernier bit du dernier octet qui soit différent.
Inscrit le 19/04/2011
1421 messages publiés

Bref, on n'est jamais aussi bien servi que par son propre serveur FTP, encore faut-il avoir les connaissances requises pour en assurer la sécurité.


1) Ton serveur ftp peut être en interne dans ta société, sans accès Web.
2) Tu peux crypter tes fichiers AVANT de les envoyer à DropBox (il existe plein de solutions pas chères - Steganos par exemple)
Inscrit le 10/04/2011
88 messages publiés
Liane_, le 15/06/2011 - 14:34
Or il serait techniquement impossible de comparer les fichiers sans les déchiffrer

Ce n'est pas une preuve: le hash peut très bien être calculé du côté client *avant* d'envoyer le fichier.
De cette manière, la sécurité est conservée, et le fichier n'a même pas besoin d'être envoyé s'il existe déjà, donc économise de la bande passante.

Je ne pense pas... Tu calcules le hash cote client:
- il est different des hashs deja connus, ton fichier est different, il faut le transmettre
- il est egal a un autre hash: c'est peut-etre le meme fichier, ou non. Il faut le transmettre en entier, et faire la comparaison avec l'autre fichier, ce qui explique que les clefs soient conservees pour pouvoir dechiffrer le fichier deja en stockage.
[message édité par mif92 le 15/06/2011 à 18:54 ]
Inscrit le 16/02/2010
4 messages publiés
mif92, le 15/06/2011 - 18:53
Liane_, le 15/06/2011 - 14:34

Ce n'est pas une preuve: le hash peut très bien être calculé du côté client *avant* d'envoyer le fichier.
De cette manière, la sécurité est conservée, et le fichier n'a même pas besoin d'être envoyé s'il existe déjà, donc économise de la bande passante.

Je ne pense pas... Tu calcules le hash cote client:
- il est different des hashs deja connus, ton fichier est different, il faut le transmettre
- il est egal a un autre hash: c'est peut-etre le meme fichier, ou non. Il faut le transmettre en entier, et faire la comparaison avec l'autre fichier, ce qui explique que les clefs soient conservees pour pouvoir dechiffrer le fichier deja en stockage.


Non, le calcul du hash, quel qu'il soit, est sensé être bon, que ce soit côté client ou serveur.
L'algorithme n'est pas en cause, seule la procédure.

Par contre... comme mentionné précédemment, cette méthode n'est pas utilisable car même si le fichier *non crypté* est identique, un 2ème utilisateur du même fichier ne peut/doit pas connaître ma clé de cryptage, et donc ne pourra pas récupérer *ma* version cryptée de ce fichier.

Mon intervention était donc... au moins à moitié fausse:
- il est effectivement possible de déterminer si un fichier est identique avant de l'encrypter
- mais cela ne sert à rien :-/

Je suis donc d'accord avec les contributeur précédents, ainsi bien sûr que l'auteur de l'article: il n'est pas possible de manière sécurisée de procéder à ce genre *d'optimisation*
Inscrit le 31/03/2009
39 messages publiés
Sans vouloir faire de pub le service Wuala de LaCie fournit à peu près le même service que DropBox (1GO gratuit) mais les fichiers sont chiffrés côté client avant d'être envoyé.
Si on perd la passphrase on est mort par contre.
Inscrit le 16/06/2009
692 messages publiés
Liane_, le 15/06/2011 - 14:34
Or il serait techniquement impossible de comparer les fichiers sans les déchiffrer

Ce n'est pas une preuve: le hash peut très bien être calculé du côté client *avant* d'envoyer le fichier.
De cette manière, la sécurité est conservée, et le fichier n'a même pas besoin d'être envoyé s'il existe déjà, donc économise de la bande passante.

C'est même lamentable que les développeurs de DropBox n'aient pas pensé à le faire côté client plutôt que côté serveur...

P'tet que les développeurs de solutions proprios centrées sur l'infrastructure serveur devraient parfois, quand même, regarder un peu plus les technos utilisées par les solutions distribuées client-to-client, style P2P.
Franchement, recevoir 600 Mo de données puis les déchiffrer illégalement pour calculer le hash le tout en consommant et bande passante et ressource de stockage temporaire et ressource de calcul alors qu'on maîtrise le code du logiciel côté client qui intervient en *amont* de tout cela et sur lequel la ressource de calcul et de stockage ne vous coûte pas un rond à vous entreprise, c'est tellement... tellement...
Pfff. J'préfère pas y penser, tiens.
Inscrit le 19/07/2007
74 messages publiés
Juste une chose: l'un d'entre vous peut m'expliquer comment DropBox ferait pour donner un accès Web en cryptant coté client? C'est peut-être là la seule raison pour DropBox d'avoir fait ce choix, non?
Répondre

Tous les champs doivent être remplis.

OU

Tous les champs doivent être remplis.

FORUMS DE NUMERAMA
Poser une question / Créer un sujet
vous pouvez aussi répondre ;-)
Numerama sur les réseaux sociaux
Juin 2011
 
Lu Ma Me Je Ve Sa Di
30 31 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 1 2 3
4 5 6 7 8 9 10