[PP-discussions] Fwd: Fwd: Lupo Libero : un cloud qui protège votre vie privée !

Dim 25 Mai 13:34:17 CEST 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bonjour,

Je me permets de répondre même si vous ne me parlez pas directement.

J'ai connu SeaFile il y 6 mois environ, quand j'ai fait le tour de ce
qui existait pour déterminer si je pouvais trouver une solution
répondant à mon cahier des charges et je l'ai écarté. Malheureusement je
n'ai pas pris de note à ce moment là sur pourquoi j'ai écarté telle ou
telle solution. Du coup, je suis retourner voir SeaFile de très près et
voici ce qu'il en ressort :

1. SeaFile prétend faire du chiffrement côté-client mais c'est faux, ou
du moins pas dans la version de SeaCloud (qui d'un point de vue
graphique, semble être la dernière) :
 * Wiki :
"https://seacloud.cc/group/3/wiki/faq-for-security-features/
    The server sends back the encrypted data, then *the browser decrypts
them with JavaScript on the client side*;
    *The browser encrypts the data with JavaScript on the client side*
then sends encrpted data to the server. The server just store the
encrypted result directly.

In both cases, *your password won't be transferred to the server side.*"

 * avec Firefox et son outil d'analyse des requêtes, on voit très
clairement que le mot de passe est envoyé au serveur et que celui
renvoie au navigateur du contenu déchiffré ; de la même manière si l'on
crée un document chiffré, il est envoyé en clair au serveur ;

 * ils se démentent eux mêmes : dans l'application apparaît le message
suivant lorsque l'on veut accéder à du contenu chiffré : "This library
is encrypted. Please input the password if you want to browse it online.
And *the password will be kept on the server for only 1 hour.*"

Le plus étrange étant que les librairies de chiffrement JS existent dans
le dépôt.
Mais peut-être leur utilisation est-elle optionnelle et est-elle
désactivée pour SeaCloud (ce qui ne me pousse pas à leur faire confiance).

2. Les fichiers ne sont pas chiffrés par défaut : il faut volontairement
créer une "library" (une collection de documents et répertoires)
chiffrée. Dans le système que je propose tout est chiffré est c'est
important car c'est une protection additionnelle pour les données
sensibles : elles n'attirent pas plus l'attention que des données sans
importance.

3. Si on chiffre une library, on peut la partager, mais on ne peut pas
partager un seul fichier ou répertoire à l'intérieur ce cette library.
Donc on ne peut pas compenser le #2 en mettant tous ses fichiers dans
une library chiffrée sans renoncer à la possibilité de partager ses
fichiers.

4. Lorsque l'on partage une library avec une autre personne utilisatrice
de SeaCloud, il faut lui communiquer le mot de passe manuellement. La
probabilité que cet échange de mot de passe se fasse par un canal peu ou
pas sécurisée me semble malheureusement assez grande. D'un certain côté
cela peut-être vu comme un avantage : il faut plus de mots de passe pour
accéder à une donnée partagée. Mais c'est à mon avis une erreur : si 23
personnes partagent avec moi des libraries chiffrées, je dois retenir 24
mots de passe (23 + celui d'authentification à mon compte), donc je
vais.... les écrire sur un bout de papier ou demander à ces 23 personnes
d'arrêter de chiffrer leurs données. La sécurité résiste très mal face à
l'expérience utilisateur.

L'outil que je cherche (que je ne trouve pas et donc que je veux
construire) doit permettre le partage sélectif parce que c'est une des
principales fonctionnalités utilisées par M. et Mme Toutlemonde et doit
tout chiffrer par défaut. Et il doit être au minimum open source et si
possible sous licence libre.

A ma connaissance ce logiciel n'existe pas.

Pour la solution OwnCloud + encFS (ou autre), elle souffre également des
inconvénients #2, #3 et #4 : soit on chiffre tout et dans ce cas, si on
veut partager, il faut tout partager, soit on ne chiffre que ce qui est
sensible (et cela ne règle pas le problème du fait que l'on ne veut pas
forcément partager les différents éléments sensibles avec les mêmes
personnes) et dans ce cas une personne mal intentionnée sait tout de
suite ce qui est important et ce qui ne l'est pas. Et il reste le
problème des mots de passe.

Donc cette solution (tout comme SeaFile installé chez soi ou SeaCloud +
encFS) peut convenir à un certain usage (exemple : archivage personnel
synchronisé), mais cela ne peut pas remplacer Dropbox ou Google Drive.

Et oui, je suis d'accord que c'est généralement une bonne idée de partir
de l'existant et de l'améliorer, mais dans ce cas, ça n'est pas
pertinent car pour résoudre les problèmes #3 et #4 (qui sont
particulièrement complexes), il faudrait réécrire quasiment
intégralement (ou du moins toutes les parties importantes) de OwnCloud
ou SeaFile. Sachant que ces logiciels ont déjà leurs publics, satisfaits
de ce qu'ils font.
Je précise d'ailleurs que le fait de permettre la gestion automatisée
des clés de chiffrement et leur transfert automatisé aux personnes avec
qui on partage des données (car c'est cela qui se cache derrière la
résolution de #3 et #4) représente une grosse partie du financement
demandée. L'interface et la synchronisation seront rapidement
implémentées comparativement.

Il est délicat de communiquer sur ce point sans noyer les lecteurs sous
une tonne d'informations pas forcément compréhensible par tous. A
première vu le partage semble être une problématique simple à résoudre
techniquement. Mais le partage d'un seul fichier avec une personne,
alors que tout est chiffré et que l'on ne souhaite pas ajouter de mots
de passe supplémentaires est loin d'être simple.
A ceux qui veulent savoir comment nous allons faire cela, nous allons
utiliser un système développer par Wuala (un concurrent très sérieux
d'un point de vue technique mais peu connu et surtout qui n'a pas fait
le choix du logiciel libre) : CrypTree,
http://dcg.ethz.ch/publications/srds06.pdf

Amitiés,
Sylvain

Le 24/05/2014 01:05, Olivier Ricou a écrit :die 23/05/14, ad 23h21,
Jérôme Micucci <micucci at online.fr> dixit :
>> Je trouve la réponse d'Olivier un peu raide.
>
> oui, tu as raison mais je pense sincèrement qu'ils vont droit dans le
> mur. Le dire c'est aussi leur rendre service.
>
> Le fait qu'il ne parlent pas de SeaFile qui est libre, qui chiffre de
> bout en bout et qui offre l'hébergement, est mauvais signe. Il
> faudrait une comparaison avec l'existant (état de l'art) et expliquer
> en quoi ce projet diffère (le classique tableau avec des croix pas
> croix le fait pas mal).
>
> Il souligne que OwnCloud ne chiffre pas chez toi mais ce n'est pas
> nécessaire, d'autres produits le font en interceptant tes données
> avant qu'elles aillent dans le nuage (j'utilise encfs au niveau du
> système de fichier mais il y a aussi des couches applicatives comme
> TrueCrypt).
>
> Le fait qu'ils n'indiquent rien sur leur compétences n'est pas rassurant
> non plus. La sécurité c'est difficile et faire un tel produit c'est
> très difficile, tant pour les aspects de crypto que de génie logiciel.
>
> Ils ne sont pas dans l'esprit du libre qui veut qu'on programme la base,
> qu'on la diffuse avec les idées fondatrices et seulement après on appelle
> à l'aide. Là plus besoin de sortir ses diplômes, on montre directement
> ce qu'on sait faire et où on va.
>
> Je me demande aussi bien pourquoi ils ne collaborent pas à OwnCloud
> ou SeaFile plutôt que de vouloir tout refaire.
>
> Enfin dans l'esprit du financement collaboratif, ce projet rappelle
> celui de git-annexe assistant sur Kickstarter sauf que l'auteur était
> connu, il avait déjà fait des logiciels libres diffusés et il ne
> demandait que 3000 $ et non 80 000 ? (il a obtenu 25 000 $ :)
>
> Donc oui ma réponse peut être vue comme raide. Elle peut aussi être
> vue comme une perche puisque je souligne les points faibles. À eux
> de rebondir
>
>                                               Olivier.
>
>
> _______________________________________________
> Discussions mailing list
> Discussions at lists.partipirate.org
> http://lists.partipirate.org/mailman/listinfo/discussions

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTgdU5AAoJEILeBvAmO3gwye8P/3UFkH5qP/AQe91TSiW/rG+A
Vtm3YFdUqM9x3bKePBHFMnS6sr4PZHDaCna76UCYV6EQEFaR7YUzAvjiNjkhUCJR
glyN/I4BeGocgYrvVetP0nOGqyOPDE1NWzzt4iS1VB35EkknuQ0N1eBgByvrwy+2
HkvyaorGLBgXMkgVy82czZQQ6dkBu4KRB+YvRe4hU0FD0SUIbXwFTXOYC8De1o0I
foHxJhQBHb8IAThJe3u+hgFn7iHCoPwpMtqI4JG3nP8GwMcKBR4rJVGpWK57MQue
wUCbwLv78NsQI+O6krqju1Nm1nr0fSQPl2G7lNOpQ49FkBxFNQ+Pk7ytBrJmBxQg
YKVlZXrLouXL3CJ3z5BNVdQe54BhXPfDnE5kBFJe4Ckj6A3J+5hK6s6XmVrVXtae
1wSJr0wfhFPdsOGGkkcCEDymf1oAwq/URw0c/hQ8xgcF1mgkFR/C2tF22NDVLucC
R08CPYm1xdbcwXOV6CYuoKZ8sUdYSAxproLht9OdHQAfOTXsji0KqQXwpPBOG2zL
Z7OrFEarp7clLtYSn2xCOKH4+II7rmPtLi9jmpsX9Agtb+hfTBRdc+BlJp+GJm8I
aomPm440LlknnRMcHbEy95A2D/4K5AXCAPpuX3QSZ34gySp/SUhd1PevxYnVWSGE
OrcdlODjiaLfikbTIorl
=CzbR
-----END PGP SIGNATURE-----

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.partipirate.org/pipermail/discussions/attachments/20140525/638743b1/attachment.html>