Welcome to Bukkit France

Inscrivez-vous maintenant pour profiter d'un accès total à tout le contenu offert par la meilleur communauté Bukkit française ! Une fois inscrit et connecté, vous pourrez contribuez à la communauté en postant vos propres sujets et questions ou en répondant à ceux existants. Vous pourrez aussi customiser votre profil, recevoir des points de réputations, communiquer avec les autres membres via le chat, et plus encore! 

  • Annonces

    • Pskyco

      Bukkit France passe sous Discord !   20/02/2016

      Bukkit France est désormais passé sur Discord, au revoir donc notre vieux Teamspeak ! Téléchargez le client et venez nous rejoindre sur notre salon en suivant les instructions suivantes.
Muonium

Muonium : un cloud chiffré et opensource

42 messages dans ce sujet

Pour répondre à @Technowix merci de ton commentaire qui représente assez bien notre état d'esprit.

Ensuite on préfère partir de notre propre code et travailler à notre façon que de suivre des directives d'autres projets.

Enfin, dans le futur on aura surement une alternative décentralisée pour Muonium :) .

 

PS :  Le "Y" était bien pour yahoo ;)

Modifié par Muonium

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 15 octobre 2016 à 23:15, Eldraeildor a dit :

Wow, c'est un superbe projet ça :o !

 

Si j'ai bien tout compris c'est un service similaire à OwnCloud mais en genre... qui marche ?

OwnCloud n'arrêtant pas de me procurer des problèmes je cherche justement une alternative, et votre projet m'a l'air vraiment intéressant.

 

S'il est possible d'auto-héberger votre solution je serais ravi de vous aider à tester.

 

C'est nextCloud maintenant :)

 

Sinon, projet intéressant que je vais suivre, bonne chance à vous.

2 personnes aiment ça

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a une heure, MrSquaare a dit :

 

C'est nextCloud maintenant :)

 

Sinon, projet intéressant que je vais suivre, bonne chance à vous.

Oh merci, je vais me rabattre dessus en attendant Muonium :3

Partager ce message


Lien à poster
Partager sur d’autres sites

Je viens vous donner quelques news,

normalement un développeur front-end nous rejoint cette semaine histoire d'avoir un design correct pour la bêta privée qui se déroulera dans quelques semaines.

C'est ici que l'on demande votre aide car on a besoin de testeurs pour trouver les bugs, vous pouvez donc nous passer vos mails si vous souhaitez devenir testeur par MP ou par mail à l'adresse [email protected]

Vous recevrez un mail contenant les informations nécessaires avant le lancement de la bêta privée.

Il faut aussi spécifier que c'est uniquement à but de test et que les fichiers peuvent-être supprimés à tout moment.

 

1 personne aime ça

Partager ce message


Lien à poster
Partager sur d’autres sites

Étant donné qu'il s'agit de mon domaine de spécialisation, je suis particulièrement intéressé par le partie crypto de Muonium.

J'ai regardé votre site Internet et votre GitHub, et pas mal de mes questions restent sans réponse (et sans justification) :

  • Quels sont les algorithmes utilisés pour chacun des étapes de l'architecture ?
    Pour la dérivation d'une clé à partir du mot de passe ? Suggestion : PBKDF#2.
    Pour la confidentialité des fichiers ? Suggestion : AES-256-CFB.
    Pour l'authentification et l'intégrité des fichiers ? Suggestion : HMAC-SHA512.
    Pour la confidentialité, l'authentification et l'intégrité des métadonnées ? Suggestion : AES-256-GCM.
  • Pourquoi, quand et comment sont utilisées les différentes clés ?
    Génération d'une clé maître ? Et génération d'une clé par fichier ?
    Génération d'une clé pour le chiffrement et d'une autre pour le MAC ?
    Utilisation d'un générateur aléatoire sûr ? Comment sont générés les IVs et les nonces ?
  • Qu'est-ce qui est stocké en clair et en chiffré sur le serveur ?
    Quelles sont les informations contenues sur le serveur, et sous quelle forme ?
    Comment se passe l'inscription de l'utilisation et la vérification de l'adresse e-mail ?
    Comment se passe l'authentification de l'utilisateur à partir des informations (challenge) ?
    Comment se passe l'envoi et la réception d'un fichier ? Et le parcours des l'arborescence des fichiers ?
  • Quelle sont les fonctionnalités de partage de fichiers prévues ?
    Utilisation d'un cryptosystème à clé publique pour identifier les utilisateurs ?
    Possibilité de partager les fichiers via un lien spécifique ? Utilisation du partage de secret ?
    L'utilisateur peut-il changer son mot de passe sans perdre tous ses fichiers ?

 

 

4 personnes aiment ça

Partager ce message


Lien à poster
Partager sur d’autres sites

Hey,

- On utilise effectivement pbkdf2 pour la dérivation de clé.

- AES-256-GCM est utilisé pour le chiffrement, l'authentification des données ainsi que leur intégrité.

 

En ce qui est du crypto-système d'implémentation d'AES, nous utilisons le deuxième mot de passe (passphrase) pour générer une clé pour chaque fichier. Pour en savoir plus sur le fonctionnement de SJCL et la génération aléatoire des IVs, je te recommande de te renseigner sur SJCL, je ne saurais pas te répondre correctement sur ce point, mais bien-entendu, les IVs sont générés aléatoirement.

 

Les mots de passes et phrase secrètes sont hashés SHA384 côté client puis hashés bCrypt() côté serveur, seul les nom d'utilisateurs ainsi que les adresses emails sont en clairs. Lorsqu'un utilisateur s'enregistre, il nous donne son mdp, passphrase, email et username, on envoie ensuite un code de validation à l'utilisateur pour vérifier son adresse email ainsi que son identité.

 

"Comment se passe l'authentification de l'utilisateur à partir des informations (challenge) ?"

Hmm, autrement dit ?

 

Les fichiers sont splités par tranche de 100Ko environ, chiffrés, ensuite, on joint tous les "morceaux" pour reconstruire le fichier. Puis, ils sont envoyé à coup d'Ajax sur les serveurs.

 

"Et le parcours des l'arborescence des fichiers ? "

Bien, en PHP ça récup' le contenu du dossier souhaité, de façon non récursive pour ne pas consommer trop de ressources.

 

"Quelle sont les fonctionnalités de partage de fichiers prévues ?"

Ne parles pas de ce qui fâche stp xD

 

"L'utilisateur peut-il changer son mot de passe sans perdre tous ses fichiers ? "

Ahah, c'est ce que me pose les auto-proclamés experts pour nous rabaisser xD

Bien-sûr que oui, c'est le but, si tu perds ta clé, tu perds tous tes fichiers... On a pas de backdoors ni de PC quantiques... Et même le quantique ne parvient pas encore à cracker AES-256-GCM...

 

Merci pour ces questions, je suppose que ça pourra éclairer ceux qui n'ont pas osé ou ne comprenaient pas trop le système.

 

-Paul

Modifié par Muonium

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 17 heures, Muonium a dit :

AES-256-GCM est utilisé pour le chiffrement, l'authentification des données ainsi que leur intégrité.

Quid des métadonnées (nom du fichier, taille, date de création, date de modification...) ? Elles doivent pouvoir être exploitables sans déchiffrer le fichier auquel elles sont rattachées. Si ce n'est pas le cas, il va être difficile de faire un explorateur de fichiers digne de ce nom. De plus, GCM qui utilise la même clé pour la confidentialité, l'authentification et l'intégrité ; et est plus rapide mais moins sûr que CFB + HMAC.

 

Il y a 17 heures, Muonium a dit :

En ce qui est du crypto-système d'implémentation d'AES, nous utilisons le deuxième mot de passe (passphrase) pour générer une clé pour chaque fichier.

J'en conclu que la clé aléatoire de chaque fichier est dérivée de la clé maître ? Et que cette clé maître est la même que la clé dérivée ? La clé de chaque fichier devrait générée aléatoirement et sauvée chiffrée dans les métadonnées du fichier mentionnées plus haut. La clé maître devrait être elle aussi générée aléatoirement (on va voir pourquoi plus bas) et sauvée chiffrée sur le serveur.

 

Il y a 17 heures, Muonium a dit :

Les mots de passes et phrase secrètes sont hashés SHA384 côté client puis hashés bCrypt() côté serveur, seul les nom d'utilisateurs ainsi que les adresses emails sont en clairs. Lorsqu'un utilisateur s'enregistre, il nous donne son mdp, passphrase, email et username, on envoie ensuite un code de validation à l'utilisateur pour vérifier son adresse email ainsi que son identité.

Hum, c'est donc la passphrase qui est utilisée pour dériver la clé dérivée ? Quel est le raisonnement derrière cette séparation entre mot de passe et passphrase ? Pourquoi donner deux choses à retenir à l'utilisateur, potentiellement moins complexes, qu'une seule chose plus complexe ? Le système devrait être capable de fonctionner sans même connaître l'adresse email de l'utilisateur (pour une anonymité maximale).

 

Il y a 17 heures, Muonium a dit :

Hmm, autrement dit ?

Et bien vu que votre système se compose d'un classique nom d'utilisateur/mot de passe, j'en déduis que l'authentification ne nécessite de challenge au sens cryptographique.

 

Il y a 17 heures, Muonium a dit :

Bien, en PHP ça récup' le contenu du dossier souhaité, de façon non récursive pour ne pas consommer trop de ressources.

Du coup tes métadonnées sont en clair sur le serveur (arborescence des fichiers, nom des fichiers), pas terrible. Normalement un attaquant qui compromet ton serveur ne devrait recueillir aucune information...

 

Il y a 17 heures, Muonium a dit :

Ne parles pas de ce qui fâche stp xD

Il serait bien d'avoir réfléchi à ce genre de problématique pour deux raisons : plusieurs concurrents proposent ce genre de fonctionnalités (avec un cryptosystème à clé publique), et cela risque d'être difficile d'implémenter ces nouveaux modes d'opération plus tard dans un système qui n'a pas été prévu pour ça à la base.

 

Il y a 17 heures, Muonium a dit :

Ahah, c'est ce que me pose les auto-proclamés experts pour nous rabaisser xD

Bien-sûr que oui, c'est le but, si tu perds ta clé, tu perds tous tes fichiers... On a pas de backdoors ni de PC quantiques... Et même le quantique ne parvient pas encore à cracker AES-256-GCM...

Je ne parle pas de perdre son mot de passe, mais de changer son mot de passe. En utilisant une clé maître aléatoire chiffrée à l'aide la clé dérivée, quand l'utilisateur souhaite changer son mot de passe, il suffit de rechiffrer sa clé aléatoire avec la nouvelle clé dérivée. De plus, avec son système on peut aussi changer fréquemment de clé maître si l'on a peur que celle-ci ai été compromise.

 

Je pense qu'il est nécessaire de réfléchir encore un peu au système que vous allez mettre en place avant de vous lancer dans l'aventure. J'ai vu que vous êtes tous les deux des lycéens et, on ne va pas se leurrer, mais vous n'êtes certainement pas des experts en cryptographie (moi non plus, et même si je fais mes études dans la sécurité informatique). Il est donc difficile pour vous de ne pas faire d'erreur, au moment de la conception, du développement ou même de l'intégration. Je ne suis pas convaincu que les potentiels utilisateurs de ce système, autres que les gens comme vous et moi qui l'utiliseraient pour mettre leur dernières photos de vacances, aient suffisamment de raisons de penser que le système est sécurisé. Il ne suffit pas de balancer quelques mots-clés comme AES, bcrypt, 256 bits, pour que le système soit sécurisé. Beaucoup de gens s'y sont essayé et s'y sont cassé les dents.

6 personnes aiment ça

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 26/11/2016 à 11:23, NeatMonster a dit :

Quid des métadonnées

Chiffrées. Après le chiffrement on récupère le nom + taille, et on récupère l'heure et la date une fois l'upload terminé.

 

Le 26/11/2016 à 11:23, NeatMonster a dit :

mais moins sûr que CFB + HMAC

Je ne connais pas CFB.

Étant en contact avec des spécialistes de la cryptographie symétrique, l'on m'a certifié que GCM demeurait le mode le plus sécurisé, avec CCM et OCB2. Pour comprendre AES, il faut un niveau M1 (première année de master) en mathématiques appliquées + informatique, n'ayant pas encore fait d'études supérieures, je ne peux que comprendre les bases d'AES, bien que j'étudie durement l'algorithme. Par conséquent, tu pourras me sortir n'importe quelle affirmation sur tel et tel mode, je ne pourrai les étudier et approuver ou non. Donc je me base sur les dires des cryptologues avec qui j'ai pu échanger. Sans oublier que, même en tapant AES sur Internet (j'exagère bien-entendu), tous les rapports de sécurité concluent de leur analyses que GCM est le mode le plus sûr.

 

#Dérivation de clé

Alors, je ne pourais pas te faire tout un cours sur ce forum, mais pour t'expliquer brièvement le fonctionnement de la dérivation de clé tu as un mot de passe, souvent appelé "passphrase" en Anglais, un renforcement de mot de passe par itérations, et un salage aléatoire. Pour faire simple (car encore une fois, comprendre le point de vue mathématique demande un master en maths appliquées + informatique), tu as besoin de ces trois éléments pour dériver une clé, cette dérivation sera issue de la combinaison de ces trois éléments. Par conséquent, lorsque Muonium chiffrera un fichier, il (il car le Muonium est un atome, exotique au passage) se servira d'une chaîne de caractère random (le "salt", salage en FR), le renforcement de mot de passe (on utilisera une itération de 2048), et le mot de passe de l'utilisateur, pour créer implicitement une clé dérivée de ces trois éléments, dont 1 random, ce qui fait que chaque fichier a SA PROPRE CLÉ DÉRIVÉE. Si je n'ai pas été clair je peux tenter de faire un plus gros pavé mais je promets rien xD

 

Le 26/11/2016 à 11:23, NeatMonster a dit :

Ne parles pas de ce qui fâche stp xD

Ce n'est pas quelque chose de simple. On ne peut pas dire "utilisons un algorithme de chiffrement asymétrique!", non. Nous avons besoin d'étudier les différentes solutions pour nous confronter à ce problème. Les fichiers seront chiffrés et indéchiffrables, on devra donc les télécharger, les rechiffrer par algo' asymétrique, etc... Donc c'est pas quelque chose sur laquelle on peut faire des hypothèses, on a besoin de temps.

 

Le 26/11/2016 à 11:23, NeatMonster a dit :

Du coup tes métadonnées sont en clair sur le serveur

Comme dit dans mon message précédent et plus haut dans celui-ci, on récupère trois infos avant le chiffrement : taille + nom, et après l'upload on prends la date d'upload (et l'heure).

 

Le 26/11/2016 à 11:23, NeatMonster a dit :

changer

Le changement de mot de passe est aussi un gros sujet, j'y travaille activement pour trouver une solution. Bien que j'ai déjà une petite idée...

 

 

Bien-entendu, nous ne sommes pas experts en cryptographie. C'est pour cette raison que je suis en contact avec différents cryptologues et cryptanalistes.

 

L'implémentation d'AES n'est pas nous qui la faisons, ce sont des cryptologues de Stanford (ref. se renseigner sur SJCL).

 

Merci pour ton intérêt.

 

-Paul

 

EDIT : J'ai dit trois éléments mais il y a aussi les IVs et les données d'intégrités, donc en soi on peut dire qu'il y a 5 éléments dont 3 random.

EDIT2 : Le projet est opensource, et nous ne sommes pas experts, donc les personnes étant expertes en la matière seront les bienvenues pour sécuriser d'avantage l'implémentation du crypto-système. Si tu penses être le messie de la crypto', fais-toi plaisir ! xD

 

Modifié par Muonium
1 personne aime ça

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 16 minutes, Muonium a dit :

Chiffrées. Avant le chiffrement on récupère le nom + taille, et on récupère l'heure et la date une fois l'upload terminé.

Chiffrées c'est bien beau, mais avec quel algorithme et quelle clé (la même que celle utilisée pour chiffrer le fichier) ? Je pense que je n'ai pas compris ta deuxième phrase car récupérer l'heure et la date sur un fichier chiffré, c'est impossible. Du coup, comment t'organises-tu pour afficher le contenu des dossiers ? Les métadonnées chiffrées sont-elles bien envoyées au client quand il veut voir la liste des fichiers ?

 

il y a 16 minutes, Muonium a dit :

Je ne connais pas CFB.

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Feedback_.28CFB.29

 

il y a 16 minutes, Muonium a dit :

Sans oublier que, même en tapant AES sur Internet (j'exagère bien-entendu), tous les rapports de sécurité concluent de leur analyses que GCM est le mode le plus sûr.

Pour le chiffrement, peut-être. Mais ce n'est pas la seule chose que tu dois assurer... Confidentialité, authentification et intégrité comme je ne cesse de le répéter. Un chiffrement tout seul, c'est vraiment loin d'être suffisant. Il y a plein d'autres problématiques comme la malléabilité et le re-jeu. Et même avec mon DIng en Info et Maths appli, et mon M2 en sécurité informatique, je sais ça.

 

il y a 16 minutes, Muonium a dit :

#Dérivation de clé

Alors, je ne pourais pas te faire tout un cours sur ce forum, mais pour t'expliquer brièvement le fonctionnement d'AES, ou plus généralement d'un algorithme symétrique, tu as un mot de passe, souvent appelé "passphrase" en Anglais, un renforcement de mot de passe par itérations, et un salage aléatoire. Pour faire simple (car encore une fois, comprendre le point de vue mathématique demande un master en maths appliquées + informatique), tu as besoin de ces trois éléments pour dériver une clé, cette dérivation sera issue de la combinaison de ces trois éléments.

Pas besoin de me faire de cours, je les ai déjà eus. Mais tu me sembles confus puisque tu parles d'AES dans ton paragraphe sur la dérivation de clé.

 

Généralement pour les algorithmes de chiffrement, on parle de clé et pas de passphrase.

Et pour décrire PBKDF#2 simplement :

CléDérivée = PBKDF2(PRF, mdp, salt, boucles, L)
i=0; CléDérivée = PRF(mdp, salt||i);
Pour j de 1 à boucles: CléDérivée = PRF(mdp, CléDérivée);

 

Il y a 1 heure, Muonium a dit :

Par conséquent, lorsque Muonium chiffrera un fichier, il (il car le Muonium est un atome, exotique au passage) se servira d'une chaîne de caractère random (le "salt", salage en FR), le renforcement de mot de passe (on utilisera une itération de 2048), et le mot de passe de l'utilisateur, pour créer implicitement une clé dérivée de ces trois éléments, dont 1 random, ce qui fait que chaque fichier a SA PROPRE CLÉ DÉRIVÉE. Si je n'ai pas été clair je peux tenter de faire un plus gros pavé mais je promets rien xD

Donc tu dérives une clé par fichier, qui se retrouve liée à la passphrase de l'utilisateur. Ça fonctionne, mais en cas de changement de mot de passe, il faudra rechiffrer tous tes fichiers...

 

Il y a 1 heure, Muonium a dit :

Ce n'est pas quelque chose de simple. On ne peut pas dire "utilisons un algorithme asymétrique!", non. Nous avons besoin d'étudier les différentes solutions pour nous confronter à ce problème. Les fichiers seront chiffrés et indéchiffrables, on devra donc les télécharger, les rechiffrer par algo' asymétrique, etc... Donc c'est pas quelque chose sur laquelle on peut faire des hypothèses, on a besoin de temps.

Tu risques d'en perdre du temps à vouloir en gagner au début. Tu as intérêt à bien penser tes nouvelles fonctionnalités, parce que seuls les utilisateurs détiendrons les clefs des fichiers. Et pas sûr que chacun d'entre-eux ait envie de se taper tous les déchiffrements/chiffrements, téléchargements/téléversements dans son navigateur pour tous ses fichiers...

 

Il y a 1 heure, Muonium a dit :

Le changement de mot de passe est aussi un gros sujet, j'y travaille activement pour trouver une solution. Bien que j'ai déjà une petite idée...

Tu vois qu'il reste encore des choses auxquelles réfléchir. Et c'est tant mieux, il s'agit quand même d'un projet d'un haut niveau de difficulté.

 

Il y a 1 heure, Muonium a dit :

Merci pour ton intérêt.

Personnellement, je suis intéressé par les méthodes que vous mettez en oeuvre pour assurer la sécurité de vos utilisateurs. Malheureusement comme pour les plupart des projets, seul le nom de quelques algorithmes et la taille des clés resort sur votre site Internet. C'est bien, mais ça ne nous informe sur pas grand chose vis à vis de la sécurité de nos données. Je préférerai savoir précisément ce qu'il se passe à chaque étape. Mais difficile d'avoir ces informations, peut-être que ne les avez-vous pas encore vous-mêmes.

1 personne aime ça

Partager ce message


Lien à poster
Partager sur d’autres sites

Euuuh, nan, j'ai "parlé" trop vite : le nom en frontend et la taille + heure d'upload en backend, au temps pour moi...

Oui, tout est chiffré et bien conservé.

EDIT : on prend les informations du fichier en son état, pas en ses méta-données.

 

il y a 40 minutes, NeatMonster a dit :

D'accord, donc ça ressemble très fortement au mode CCM x)

 

La clé de dérivation est issue d'un salage + mdp (passphrase) + itérations dans notre système. C'était effectivement une erreur de ma part avec tous ces termes techniques de dire qu'on utilisait une dérivation de clé à partir d'une clé maître... Oui, je comprends ce que tu voulais dire maintenant xD

https://en.wikipedia.org/wiki/Key_derivation_function

 

il y a 40 minutes, NeatMonster a dit :

Donc tu dérives une clé par fichier, qui se retrouve liée à la passphrase de l'utilisateur. Ça fonctionne, mais en cas de changement de mot de passe, il faudra rechiffrer tous tes fichiers...

Yep. Tu aurais une solution avec SJCL par hasard ? xD

EDIT : du coup oui, PBKDF2 est une solution.

 

il y a 40 minutes, NeatMonster a dit :

Tu risques d'en perdre du temps à vouloir en gagner au début. Tu as intérêt à bien penser tes nouvelles fonctionnalités, parce que seuls les utilisateurs détiendrons les clefs des fichiers. Et pas sûr que chacun d'entre-eux ait envie de se taper tous les déchiffrements/chiffrements, téléchargements/téléversements dans son navigateur pour tous ses fichiers...

Oui, mais justement, je préfère sécuriser un maximum le crypto-système et avoir à réfléchir sur ça longuement plutôt que de négliger l'un pour avoir l'autre.

 

il y a 40 minutes, NeatMonster a dit :

Tu vois qu'il reste encore des choses auxquelles réfléchir. Et c'est tant mieux, il s'agit quand même d'un projet d'un haut niveau de difficulté.

Bien-sûr, c'est pour cette même raison que je suis en contact avec des cryptologues qui m'aident lorsque je me questionne ! :)

 

il y a 40 minutes, NeatMonster a dit :

Personnellement, je suis intéressé par les méthodes que vous mettez en oeuvre pour assurer la sécurité de vos utilisateurs. Malheureusement comme pour les plupart des projets, seul le nom de quelques algorithmes et la taille des clés resort sur votre site Internet. C'est bien, mais ça ne nous informe sur pas grand chose vis à vis de la sécurité de nos données. Je préférerai savoir précisément ce qu'il se passe à chaque étape. Mais difficile d'avoir ces informations, peut-être que ne les avez-vous pas encore vous-mêmes.

Le site n'informe pas assez les utilisateurs, on en est conscient. On veut le refaire, mais on a pas le temps. Personnellement je voudrais mettre plus de schémas, sans trop entrer dans la technique comme on vient de le faire non plus... Enfin, le site est à refaire, on le sait car on s'en aperçoit, et beaucoup de gens nous ont aussi fait a remarque.

 

-Paul

Modifié par Muonium

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 17 heures, Muonium a dit :

Euuuh, nan, j'ai "parlé" trop vite : le nom en frontend et la taille + heure d'upload en backend, au temps pour moi...

Oui, tout est chiffré et bien conservé.

EDIT : on prend les informations du fichier en son état, pas en ses méta-données.

Moi je demandais surtout si une autre clé était utilisée pour ça et si les métadonnées étaient bien un élément annexe au fichier...

 

Il y a 17 heures, Muonium a dit :

La clé de dérivation est issue d'un salage + mdp (passphrase) + itérations dans notre système. C'était effectivement une erreur de ma part avec tous ces termes techniques de dire qu'on utilisait une dérivation de clé à partir d'une clé maître... Oui, je comprends ce que tu voulais dire maintenant xD

PBKDF = Password-Based Key Derivation Function, ça veut dire que ça veut dire.

 

Il y a 17 heures, Muonium a dit :

Yep. Tu aurais une solution avec SJCL par hasard ? xD

EDIT : du coup oui, PBKDF2 est une solution.

Je l'ai dis plus haut, générer une clé aléatoire par fichier utilisée pour en chiffrer le contenu, et stocker cette clé chiffrée par la clé maître "à côté" du fichier.

 

Il y a 18 heures, Muonium a dit :

Oui, mais justement, je préfère sécuriser un maximum le crypto-système et avoir à réfléchir sur ça longuement plutôt que de négliger l'un pour avoir l'autre.

En négliger aucun des deux me paraît quand même être la solution optimale...

 

Il y a 18 heures, Muonium a dit :

Le site n'informe pas assez les utilisateurs, on en est conscient. On veut le refaire, mais on a pas le temps. Personnellement je voudrais mettre plus de schémas, sans trop entrer dans la technique comme on vient de le faire non plus... Enfin, le site est à refaire, on le sait car on s'en aperçoit, et beaucoup de gens nous ont aussi fait a remarque.

Il n'y pas que le site qui n'informe pas suffisamment. J'ai l'impression que vous répondez un peu gauchement aux questions techniques, peut-être justement parce que c'est les gens avec qui vous êtes en contact qui maîtrisent ce genre de problématiques. Pour M. ToutLeMonde ça ne pose pas de problèmes, mais si vous vous attaquez à un public plus méfiant...

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 27/11/2016 à 14:37, NeatMonster a dit :

PBKDF = Password-Based Key Derivation Function, ça veut dire que ça veut dire

Yep, mais notre système fait qu'on doit tout déchiffrer et chiffrer à nouveau avec le nouveau mdp... Donc je suis en train de voir comment implémenter un système PBKDF2 comme tu l'as proposé.

 

Le 27/11/2016 à 14:37, NeatMonster a dit :

En négliger aucun des deux me paraît quand même être la solution optimale...

J'ai beau chercher, mise à part avec un algo' asymétrique (et encore... J'y vois un blocage aussi avec RSA...), je ne vois aucune solution pour le moment. Si tu en as une, n'hésites pas.

 

Yea, justement, je le dis haut et fort, on sait comment implémenter niveau code une librairie, mais pour ce qui est de la crypto' elle-même, ça nous demande beaucoup de réflexion et d'apprentissage. Le projet est libre, donc une personne telle que toi, voyant un problème d'implémentation pourra très bien contribuer. Bien-évidemment, les connaissances ne stagnent pas si on apprend continuellement, donc au fil du temps je répondrai beaucoup moins gauchement à ce genre de questions. Bien que j'ai aussi du mal à m'exprimer correctement, c'est pour cette raison que je réponds qu'aux questions très techniques (et d'ailleurs, je suis le sysadmin du projet, je suis ni codeur, ni cryptanaliste/cryptologue...), donc en ce qui est des questions orientées programmation, je répondrai aussi gauchement. Avant d'avoir tes questions sur notre système d'implémentation d'AES-256-GCM, c'était Giovanni qui répondait aux questions, donc ça pouvait très probablement paraître plus clair.

 

-Paul

 

EDIT : C'est bon, concernant le changement de passphrase, je sais comment l'implémenter. Un grand merci pour m'avoir fait penser à ce système qui en fait est tout bête quand on y repense xD

EDIT2 : mettons les fautes d'orthographe sur le dos de la fatigue... xD

Modifié par Muonium
4 personnes aiment ça

Partager ce message


Lien à poster
Partager sur d’autres sites

Hey quelques nouvelles,

Le chiffrement (via SJCL) est actuellement en cours d'implémentation et a été validée par un spécialiste si vous voulez plus de détails vous pouvez vous rendre ici : https://github.com/muonium/core/wiki/Crypto-details

On est dans la dernière ligne droite pour la bêta privée et on croise les doigts pour la sortir courant décembre,on vous tient au jus :).

Et finalement on a trouvé un développeur front-end (venant d'Australie) qui nous permet d’accélérer la cadence du projet.

Modifié par Muonium

Partager ce message


Lien à poster
Partager sur d’autres sites

Je viens de retourner sur votre GitHub, et j'avoue que je me fais toujours du soucis pour la sécurité dans ce projet. Qui est ce spécialiste qui a validé votre implémentation ?

 

IMO:

  • Le serveur ne devrait pas stocker la clé dérivée de la passphrase.
  • Le serveur ne devrait pas stocker de version hachée de la passphrase.
  • Une clé aléatoire pure devrait être générée pour chaque fichier, et pas dérivée.
  • Une fois de plus, il n'est pas question des métadonnées et de leur chiffrement.
  • Stocker des clés si importantes dans des cookies (facilement dérobés) est une idée saugrenue.

Je ne suis pas familier avec SJCL, mais à lire le code de l'issue #4, j'ai l'impression que l'authentification data n'est stockée nulle part.

2 personnes aiment ça

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 11 minutes, NeatMonster a dit :

Le serveur ne devrait pas stocker la clé dérivée de la passphrase

Celle-ci est chiffrée. Ou alors on la stocke pas et on laisse l'utilisateur apprendre une chaîne de caractères immense ?

 

il y a 11 minutes, NeatMonster a dit :

Le serveur ne devrait pas stocker de version hachée de la passphrase

Elle est doublement hashée, même en l'ayant, on ne peut rien faire avec. C'est de l'exagération ce que tu nous fais là...

 

il y a 11 minutes, NeatMonster a dit :

Une clé aléatoire pure devrait être générée pour chaque fichier, et pas dérivée.

 

On en revient à déchiffrer puis rechiffrer non pas tous les fichiers, mais toutes les clés maintenant ?

il y a 11 minutes, NeatMonster a dit :

Une fois de plus, il n'est pas question des métadonnées et de leur chiffrement.

"En cours d'implémentation".

 

il y a 11 minutes, NeatMonster a dit :

Stocker des clés si importantes dans des cookies (facilement dérobés) est une idée saugrenue.

 

Messie de la sécurité, auriez-vous une meilleure solution ?

il y a 11 minutes, NeatMonster a dit :

authentification data

Stockée dans le fichier chiffré.

 

-Paul.

Modifié par Muonium

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 11 heures, Muonium a dit :

Celle-ci est chiffrée. Ou alors on la stocke pas et on laisse l'utilisateur apprendre une chaîne de caractères immense ?

Bien sûr que non, tu ne la stockes pas. L'utilisateur n'apprend que son mot de passe, qui dérivé à chaque fois qu'on en a besoin, donne la clé dérivée.

 

Il y a 11 heures, Muonium a dit :

Elle est doublement hashée, même en l'ayant, on ne peut rien faire avec. C'est de l'exagération ce que tu nous fais là...

Peut-être, mais tu n'en as pas besoin si tu as un élément chiffré avec la clé dérivée pour vérifier son identité.

 

Il y a 11 heures, Muonium a dit :

On en revient à déchiffrer puis rechiffrer non pas tous les fichiers, mais toutes les clés maintenant ?

Oui, et c'est d'ailleurs ça que l'on cherche à faire puisque que c'est plus rapide (sauf peut-être si les fichiers font moins de 32 octets).

 

Il y a 11 heures, Muonium a dit :

Messie de la sécurité, auriez-vous une meilleure solution ?

Puisque je vois que tu veux le prendre sur ce ton-là, dorénavant je m'abstiendrais de venir commenter sur ton sujet. Je te souhaite bon courage pour la suite, l'entreprise me semble assez périlleuse quand on ne sait pas vraiment de quoi on parle, mais je ne peux que te souhaiter de réussir. Et tu pourras venir me voir pour me dire que j'avais tord le jour où Muonium sera mondialement reconnu et utilisé.

 

- Neat'

 

Oh, et juste pour le lawl, parce que celle-là elle est vraiment golden...

LUyaRwx.png?1
Modifié par NeatMonster
1 personne aime ça

Partager ce message


Lien à poster
Partager sur d’autres sites

Pourquoi se compliquer la vie ? La CEK sera chiffrée, donc déjà ici, il n'y a aucun problème concernant le stockage de celle-ci.

 

Ensuite, le double-hashage fait qu'il est impossible d'utiliser la KEK, donc on peut la stockée tant qu'elle est doublement hashée. J'ai déjà implémenté le système de la vérification par élément chiffré, mais je ne trouve pas le système suffisamment flexible.

 

Ici tu proposes un système et dénigres le nôtre car il ne te plaît pas, cela n'empêche pas que ce dernier soit sûr. Le fait que notre équipe est composée de deux lycéens ne crée aucune incompatibilité avec ce projet. En tous les cas, quel que soit le domaine, il y aura toujours des spécialistes (donc tu es a priori de cette catégorie) ou des auto-proclamés experts pour mettre leur grain de sel dans quelque chose qui fonctionne bien. Il y aura toujours des personnes ici et là pour se contre-dire.

 

Pour le cookie, effectivement, ça réduit les risques. C'est vrai que tous les projets similaires au notre utilisent les cookies, et base64 encode les données stockées dans le cookie pour minimiser les risques. Il n'est pas question ici d'invulnérabilité, mais de minimiser les risques (nous concernant).

 

-Paul

PS : rappelons que j'ai gardé la base de mon système, et que techniquement parlant il y a une clé dérivée par fichier.

 

EDIT : Par la même occasion, la question à se poser est : "On a ce système, peut-on déchiffrer les fichiers, obtenir la KEK et la CEK en clair ?"

Si tu me dis oui, envoie-moi un email avec les démonstrations mathématiques, je suis curieux x)

Modifié par Muonium

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !


Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.


Connectez-vous maintenant

  • En ligne récemment   0 membre est en ligne

    Aucun utilisateur enregistré regarde cette page.