Ely a écrit 114 commentaires

A la base, x265 sort des fichiers "HEVC brut". C'est moi qui ai pris la décision de les mettre dans des MKV, car sinon il manque des métadonnées comme la durée de la vidéo, etc. (et VLC n'aime pas trop)

Il est tout à fait possible de mettre du HEVC dans du MP4, mais la commande "mkvmerge" est tellement simple et pratique que je suis pas allé chercher plus loin..

Tu sais, il n'est pas rare que Linus envoie chier des gens pour moins que ça.

Et puis je vais faire l'avocat du diable, mais personnellement je comprends les gens qui refusent des changements sur des systèmes en production si ce n'est pas critique. Typiquement, mettre à jour la somme de contrôle, si c'est risquer un effondrement de la stack réseau pour 0,1% de perf sur la plateforme, est-ce vraiment un pari à prendre ?

Exact, la CVE-2014-0195 est pas mal aussi : dépassement de tampon avec exécution de code arbitraire. 3 autres permettent de faire du déni de service.. Rien ne va plus pour les libs SSL en ce moment

Qu'apporterait Caliopen par rapport à une solution déjà existante, BitMessage ?

J'en profite pour linker un article très intéressant intitulé "What Heartbleed Can Teach The OSS Community About Marketing" : http://www.kalzumeus.com/2014/04/09/what-heartbleed-can-teach-the-oss-community-about-marketing/

Ca explique en gros comment le fait d'avoir donné un nom à la fois émotionnel et informatif ainsi qu'un logo au bug a permis une prise de conscience ainsi qu'une réaction immédiate vers la résolution du bug dans le monde entier.

Si le bug avait été "marketé" comme les autres, c'est-à-dire juste par sa fiche "CVE-2014-0160", il n'y aurait jamais eu cet élan de communication.

Quand il faut ouvrir 20 connexions vers des domaines différents, même en 4G, c'est lent. Ce n'est pas une question de débit.

Entre visiter un site sans extension et avec AdBlock+Ghostery, il n'y a juste pas photo niveau rapidité.

Au contraire, la technique est "pas trop mal" et ça invalide les rainbow table "classiques".

Le problème, c'est qu'utiliser un login comme sel n'est pas une donnée suffisamment forte. Il existe probablement déjà des rainbow table calculées avec différents sels tirés de mots ordinaires. Or, il se peut très bien qu'un de ces mots soit "obiwan" par exemple.

Donc certes il faut une rainbow table par haché dans ta base, mais vu la sécurité de tes sels (caractères alpha-numériques), on peut estimer qu'elles existent déjà (genre si tu as des utilisateurs qui ont un login entre 2 et 5 lettres.. c'est mort pour eux).

Le mieux reste donc de générer un sel aléatoire et suffisament grand, et de le stocker dans la base. Au moins, pas de mauvaise surprise comme ça.

Je partage ton avis, et je rajoute un point qui n'a pas été abordé dans l'article ou ton commentaire : la discrimination positive.

Je vais prendre le seul exemple que j'ai en tête : les subventions pour encourager les filles à faire des études qui sont majoritairement masculines (statistiquement, rien à voir avec les compétences demandées), notamment en sciences.

A mon IUT en informatique par exemple, y'avait deux filles qui, au-delà d'être mauvaises, mettaient de la mauvaise volonté à bosser, n'en avaient rien à faire (choix "par défaut"), rendaient des projets à peine entamés.. et pourtant elles ont fini avec une super moyenne et un classement vraiment potable (top 15).

J'ai appris plus tard de l'aveu d'un prof qu'ils avaient des directives : augmentation de la note de sélection post-bac, augmentation des notes des devoirs, plus de clémence pour les retards, et j'en passe..
Critère pour avoir droit à ces "perks" : être une fille dans une filière info. Rien de plus.

J'ai été un peu choqué d'apprendre ça. Encore, le coup des 1000€ de subventions pour encourager les filles à faire des filières scientifiques, pourquoi pas. Mais alors là on dépasse tout entendement.

Moi aussi si je veux faire une filière statistiquement féminine (infirmier par exemple), j'ai droit à des sous et des meilleures notes ? Non ?! Ah mince, quelle déception..

Bref je rejoins cette notion "d'égalitarisme" plutôt que de parler de "féminisme"..

Il n'y a en effet que sur linuxfr qu'on trouve des récapitulatifs kernel de cette qualité. Bravo aux contributeurs :) .

Ouaip, je pensais plus aux HSM type serveur plutôt que clé usb. Au boulot on a des Thalès PayShield, et ça douille niveau prix..!

Justement non. Un sel idéal, c'est un sel le plus aléatoire possible, et dont les octets peuvent prendre toutes les valeurs (0 -> 255). Pour faire ça sur un PC, on se base sur ce que l'on peut récupérer sur les différentes entrées et capteurs que l'ordinateur possède : tensions, températures, mouvements de la souris, frappes au clavier… On fait un mic-mac binaire de tout ça, et on obtient de l'aléatoire "cryptographiquement sécurisé".

Tu invalides aussi "totalement" les rainbow tables, mais en encore mieux qu'avec un sel qui ne contiendrait que des caractères imprimables (valeurs de 32 à 175 dans la table ascii).

Attention, la majorité des choses que tu as dites sont fausses.

Il n'y a pas de mal à utiliser AES avec une clé constante pour toute la BDD si l'on chiffre un haché bien fait, comme dans le niveau 1 que j'ai décrit : AES(bcrypt($perUserSalt, $pwd), $secretKey)

Tu dis aussi "on peut retrouver la clef, parce qu'AES est symétrique" : et bien non. Même si tu connais un clair et son chiffré AES, il n'y a aucun moyen de retrouver la clé. Et heureusement d'ailleurs, sinon ça serait cassé depuis longtemps…

Quant à la méthode que tu décris qui fait x fois sha256() pour ralentir la procédure, c'est exactement ce à quoi sert bcrypt ou scrypt : boucler plein de fois pour ralentir l'opération et prolonger la durée de vie d'un mot de passe.

Alors là, je ne saurais te répondre.

Un HSM, c'est peu probable. C'est du matériel qui coûte hyper cher (genre 15.000€ l'entrée de gamme).

Par contre, un SSM (Software Security Module), pourquoi pas. C'est en gros un HSM sans la partie "protection physique". Un bête serveur sur lequel tu as mis des règles iptables, des droits d'accès aux fichiers les plus stricts possibles, et qui fait tourner un démon réseau de chiffrement/déchiffrement.

Qu’apporte le sel différent pour chaque utilisateur, dans la mesure où si le code est leaké, le pirate peut avoir accès à la méthode aussi bien qu’à un sel global ?

Que veux-tu qu'il découvre dans ta "méthode" ? La force de la cryptographie moderne, c'est que tous les algorithmes (AES, SHA-X, bcrypt, RSA…) sont open-source, et pourtant on n'arrive pas à les casser.

Le sel différent pour chaque utilisateur fait qu'il faut recalculer une rainbow table à chaque fois. Car même si deux utilisateurs ont le même mot de passe, le haché sera différent à cause du sel différent justement.
Avec un algorithme lent comme bcrypt, recalculer une rainbow table peut prendre des plombes.

Règle de base en cryptographie : ne jamais assumer qu'une information "non communiquée" ne sera jamais découverte. La cryptographie par obfuscation (on cache les algorithmes et les constantes) a toujours échoué à un moment ou un autre.

Le problème de prendre un nom d'utilisateur comme $perUserSalt, c'est que ce n'est pas une donnée cryptographiquement sécurisée. Par exemple, les octets qui le composent ne peuvent pas prendre toutes les valeurs possibles : seulement des caractères imprimables.
Le fait de limiter "l'aléatoire" du sel peut faciliter une attaque.

Il est donc préférable de générer un sel aléatoire qui sera plus fiable.

EDIT : Sauf si bien sûr l'algorithme est bcrypt, là calculer une rainbow table peut prendre lonnngttemmppss.

Calculer une rainbow table : pas longtemps avec une carte graphique. Une Radeon 7970 est capable de faire 600 millions de SHA2 à la seconde. Sachant qu'une rainbow table ne contient que des mots de passe "populaires", je pense que ta table est très vite générée.

Je vais faire avec un exemple.

Mettons que tu aies un compte sur le site dont le mot de passe est "1234". La BDD est leakée, tu retrouves ton compte avec le mot de passe haché associé : c6c4940b323ff81c66e02a02e0281c370c535008

Premier réflexe, tu regardes la longueur du haché. En l'occurence, c'est 20 octets, ce qui laisse présumer que le site a utilisé SHA-1. Tu essaies donc naïvement :

SHA1("1234") : 7110eda4d09e062aa5e4a390b0a572ac0d2c0220

Argl, pas le même résultat ! Tu lances alors une attaque brute-force, qui prendra plus ou moins de temps selon la longueur du sel :

for(s = 'a'; s < 'zzzzzzzzzzzzzzzzz'; ++s) {
   comparer(SHA1(s+"1234"), "c6c4940b323ff81c66e02a02e0281c370c535008");
}

et là, à un moment… bingo !

SHA1('azerty1234') = c6c4940b323ff81c66e02a02e0281c370c535008

Le sel est donc "azerty".

Ensuite, tu recalcules toute une rainbow table en prenant en compte ce sel (ce qui n'est pas très long) :

SHA1('azertysoleil') = e49603f863140f3444392730a685573d19f044df

etc etc.

Je suis d'accord avec toi que si le sel fait 100 caractères de long, ça sera beaucoup plus long à casser. Le vrai problème réside en fait dans ce que j'ai dit dans l'article :

A noter aussi que si l'attaquant a un accès plus important que la BDD (code source de la plateforme), il peut directement trouver le fichier dans lequel est stocké le sel.. Dans ce cas, on retrouve le même niveau de sécurité qu'en -2.

EDIT : j'oubliais le plus important : avec un sel constant, deux utilisateurs qui ont le même mot de passe auront le même haché ! Et ça c'est grave.

En effet, j'aurais pu rajouter ce niveau.

Par contre, attention aux préjugés, un site qui est capable de te renvoyer ton mot de passe en clair peut très bien incorporer un mécanisme de protection des mots de passe tout à fait potable.

Je prends l'exemple suivant : $passwordInDatabase = AES($password, DerivateKey($constantSecretKey, $perUserSalt))

En fait, le site ne procède qu'à un chiffrement du mot de passe, pas de hash. Si ceci est bien implémenté, c'est-à-dire que la clé secrète constante est protégée dans un élément sécurisé (ex. HSM) et que le sel unique par utilisateur est généré de façon cryptographiquement secure, c'est une technique qu'on ne cassera pas.

Et évidemment, avantage (ou pas), c'est que le site est capable de déchiffrer le mot de passe si besoin est.

La seule attaque contre ça, c'est de prendre le contrôle totale de la plateforme, et d'envoyer les mots de passe un par un au HSM pour les déchiffrer. Faut déjà y aller pour un attaquant.

Super projet, je découvre seulement. L'idée est simple (même si techniquement ça doit être un sacré challenge) et efficace.

Par contre, s'il y en a qui ont essayé, on peut avoir des retours ? Peut-on configurer la taille maximum qu'on est prêt à dédier à "héberger les fichiers des autres" ? Qu'en est-il des débits ? Ca plombe pas trop le système et notre connexion internet si un peer se met à télécharger un de ses fichiers à partir de chez nous ?

Salut,

pour pouvoir faire une opération homomorphe entre deux chiffrés, il faut la clé publique qui a servi à les chiffrer.

Le résultat de cette multiplication est déjà chiffré en fait, pas besoin de le "rechiffrer".

Le même problème existe dans le cryptosystème de Gentry. Chaque addition/multiplication homomorphe ajoute du bruit gaussien au résultat. Une fois que le bruit dépasse un certain seuil, le chiffré devient inutilisable.

Cependant, il a trouvé l'astuce du "bootstrapping" pour rafraîchir un chiffré et supprimer son bruit. Cette étape doit être appelée toutes les X opérations pour s'assurer que le chiffré reste "sain". C'est cette méthode qui rend à la fois le cryptosystème réellement complètement homomorphe, mais c'est aussi celle qui est la plus coûteuse en performances.

Bien évidemment. La prouesse technique du vote électronique m'intéresse, après socialement il est clair qu'on est très loin d'accepter cela.

Cependant, on a aussi très souvent relevé des cas de triches avec le vote papier. Car on a beau compter et faire une somme juste à un bureau local de vote, rien ne garantit que ça ne sera pas altéré dans les niveaux supérieurs..!

Comme les votes sont chiffrés, tu peux les lier dans une base de données avec des informations nominatives sur leur propriétaire, sans risque de briser l'anonymat du vote bien sûr. Tout ce que ça te permet de savoir, c'est qui a voté et qui n'a pas voté, ce que l'on sait déjà avec les listes..

Ca te permet aussi d'être sûr que seuls des personnes autorisées ont voté.

La seule difficulté, c'est que normalement un vote électronique, c'est un "1" chiffré pour celui pour qui on vote, et des "0" chiffrés pour les autres. Ensuite, on fait la somme homomorphe.

Bien sûr, je te laisse pas imaginer si quelqu'un arrive à voter "99999" chiffré.. Il existe des solutions qui permettent de s'assurer qu'on vote bien 0 ou 1 et pas autre chose, mais là on sort de mes connaissances sur le sujet..!

Dans le cas du vote électronique, la clé privée est découpée entre plusieurs autorités de confiance. La force de cette méthode, c'est qu'il n'en faut qu'une seule qui soit honnête pour que tout le système soit fiable.

Après si tu tombes sur un cas où toutes les autorités de confiance choisies sont corrompues, c'est que le choix a été mal fait dès le départ. Si un jour le vote électronique arrive, le choix de ces autorités sera l'une des étapes les plus importantes. La façon de choisir aussi..