S'identifier / Créer un compte
  • Actualités
  • Dossiers
  • Tests
  • Commentaires
  • INpactiens
Publicité
Avatar de vampire7 INpactien
vampire7 Inscrit le vendredi 19 janvier 07 - 958 commentaires -
Les derniers commentaires de vampire7 :
Je ne suis pas d'accord avec vous. Truecrypt utilise actuellement les aglos de chiffrement et les protocoles les plus récents et les plus éprouvés. J'attends toujours qu'est-ce que vous voudriez rajouter à AES, Serpent et Twofish pour le chiffrement et mieux que SHA512 pour le hash ...

Les algos de chiffrement, tout comme les les fonctions de hashs, ne s'utilisent pas seuls. C'est pas AES qui est utilisé dans TrueCrypt mais XTS-AES. Idem pour SHA-512 : c'est en réalité PBKDF2/SHA-512.
Et PBKDF2 est aujourd'hui considérée comme insuffisante (surtout avec seulement 1000 itérations), car facile à paralléliser (et donc à implémenter sur GPU...). Scrypt est une solution destinée à réduire ce problème.

Le code à revoir est du côté du code du software en lui-même. En terme de sécurité changer trop souvent le code ou venir rajouter des fonctions "plus modernes" adaptées aux OS et aux pratiques récentes risquerait de créer des brèches dans la sécurité. Il semble encore aujourd'hui être l'Etat de l'Art dans son domaine donc moi je pense que garder des versions de long terme comme ici avec l'audit à côté semble être une bonne idée.

Qu'est-ce que tu appelles une "brèche dans la sécurité" pour ce genre de logiciel ?
Même la chaîne "TRUE" qu'on trouve dans les en-têtes de volume TrueCrypt n'est pas encore une véritable vulnérabilité. Pas encore. Mais il est vrai que c'est un peu con, parce que ça pourrait le devenir (au lieu d'avoir 2^128 blocks déchiffrés différents possibles, on n'en a plus que 2^96).
Pour le reste, il est infiniment plus simple de chercher à foutre un keylogger, voir même un truc qui repère directement le volume déchiffré (jette donc un coup d’œil dans la clé de registre HKLM\SYSTEM\MountedDevices...) que de chercher à reconstituer une clé que TrueCrypt aurait permis de retrouver quelque part dans la RAM.

Faut arrêter de penser que de poser le doigt sur le code va casser tout un assemblage fragile. C'est même tout le contraire : tu préfèrerais que ton OS n'ait pas de mise à jour pendant 2 ans ?
Les techniques informatiques évoluent, et la cryptographie ne fait pas exception.

Edité par vampire7 le jeudi 17 avril 2014 à 19:06

A quoi bon, si le soft n'est plus développé ? Pour moi, TrueCrypt a trop de problèmes, que ce soit les traces qu'il laisse dans le système ou ses performances rachitiques (le code en C que j'utilise pour AES est plus rapide que leur code ASM, et ce n'est qu'un exemple). Sans parler de toutes ces fonctionnalités stupides et dangereuses comme celle de la clé dans un fichier (juste à tester chaque fichier de la machine un par un), celle du "déni plausible" (comme si on avait l'air "plausible" en disant "oui oui, ce gros volume chiffré en FAT32 avec presque rien dedans ne contient absolument pas de volume caché, promis-juré-craché"), l'OS chiffré où il n'y qu'à regarder le secteur de démarrage pour savoir s'il y en a un, etc...
Mais je ne me contente pas de me plaindre, puisque j'ai fini par développer une alternative.

Edité par vampire7 le jeudi 17 avril 2014 à 15:01
C'est pas comme si Truecrypt etait encore développé....

Ca fait plus de 2ans que aucune version n'a vu le jour

+1
Il suffit de jeter un coup d’œil au source pour voir que ce genre de soft requiert d'y foutre son nez en permanence pour y comprendre quelque chose (et donc pouvoir l'améliorer).

Cet audit sera peut-être justement l'occasion d'une nouvelle version.

Après, pour un soft destiné à la sécurité, sans faille découverte à ce jour, sans besoin flagrant de nouvelle fonctionnalité (support futur de Keccak/SHA-3 après SHA-2 512 ?), y a-t-il vraiment besoin de changer quoi que ce soit ?

La fonction de dérivation de clé scrypt serait plus utile, mais c'est une vraie misère à implémenter, même avec le code source de référence (scrypt utilise une fonction PBKDF2, laquelle utilise une fonction HMAC, laquelle utilise une fonction de hash, et le seul hash présenté avec les vecteurs de test est du SHA-256).

Enfin sinon oui, il y aurait besoin de changer un paquet de trucs : une implémentation SSE2 de Serpent se bricole en une heure et multiplie les perfs de cet algo par environ 2,5. Le problème est que dans leur cas, il faut rajouter au mieux une grosse journée de boulot pour la modification du mode XTS, vu le bazar de leur implémentation, modification requise par le fait que l'optimisation de Serpent consiste à traiter 4 blocs de 128-bit à la fois.

Ils pourraient aussi prendre en compte XTS dans leur benchmark histoire d'avoir un truc un peu plus réaliste, vu que les algos de chiffrement ne sont jamais utilisés seuls. Mais le résultat pourrait faire peur...

Et puis éviter d'écrire tout ce qu'on fait avec TrueCrypt dans le journal des évènements et la base de registre...
Là tu parles de performances, et tu confonds évolution des performances et innovation. L'architecture des processeurs ne cesse d'être améliorée, même si ça se voit moins dans les performances, du fait surtout de la stagnation des fréquences de fonctionnement.

Si un changement d'architecture n'a pas pour conséquence une amélioration visible des performances (et dans la pratique, 20% de plus, c'est rarement visible), alors ça ne sert pas à grand-chose.

Et le fait que les fréquences stagnent n'empêche pas une amélioration des performances, il suffit de voir ce qu'ont apporté les premiers core 2 duo : même sur un seul cœur, ils étaient déjà nettement plus performants que n'importe quel P4 prescott.

20% de perf en plus, quelques watts de moins, personne ne va cracher dessus. Mais même si Intel change complètement d'architecture, si les utilisateurs ne perçoivent rien, alors on ne peut pas parler d'innovation, parce que dans tout marché, c'est le point de vue de l'acheteur qui compte, pas celui du fabricant.
Tu ne connais pas bien le sujet je pense.
Tu confonds peut-être avec les fréquences de fonctionnement.

C'est toi qui connait mal le sujet. Regarde donc un peu les benchs : le core i7 2600k est sorti il y a 3 ans et demi. Aujourd'hui, dans la même gamme de prix, on a des CPU avec environ 20% de perf de plus. L'évolution n'a jamais été aussi lente.

Edité par vampire7 le mercredi 16 avril 2014 à 01:46
Ces Bay-trail supporte 4go et pourtant tout le monde n'en mets que 2. de peur que ça fasse de l'ombre aux machine a 600 euros ?

Intel indique sur ARK :
Max Memory Size (dependent on memory type) 2 GB

En plus, le lien est dans l'article.
Intel indique en outre qu'elle peut supporter des chutes d'une hauteur de 70 cm.

Sur un gros tapis ou sur du carrelage ? En tout cas, pour un ordi qui n'est même pas équipé de disque dur, ça ne parait vraiment pas extraordinaire... et très insuffisant pour confier ça à des gamins.
batterie non amovible


Sans appel ? Le plus intéressant dans ce genre de truc, c'est les commentaires (enfin, ceux de plus de 3 lignes).

Quant au SSE2... Les résultats montrent clairement qu'il ne suffit pas de "enable SSE/SSE2", comme il dit dans la conclusion. Le SSE2 n'est pas un switch à activer, c'est un ensemble d'instructions. Les compilateurs n'utilisent que très rarement ces instructions, pour la simple raison que pour traiter par exemple 4 entiers de 32 bits simultanément, il faut que l'algorithme soit conçu dans cette optique.

Par exemple, l'algorithme de chiffrement Serpent utilise des entiers de 32 bits pour chiffrer un bloc de 128 bits. Mais à ce niveau-là, il n'y a rien à faire avec le SSE2 parce que chaque entier subit des opérations différentes.
Toutefois, le premier entier 32 bits d'un bloc subit les mêmes opérations que le premier entier du second bloc. Et l'astuce est là : chiffrer 4 blocs (4*128 bits) simultanément. Comment un compilateur pourrait trouver ça ? Comment pourrait-il savoir que ça implique des modifications du mode d'opération XTS implémenté ailleurs ?
Et si on n'obtient qu'un gain d'environ 2,5x la vitesse d'origine, c'est uniquement à cause de l'absence d'opération de rotation de bits.

Bref, faut arrêter d'espérer que d'activer un switch va arranger votre algorithme comme il faut et trouver toutes les astuces à votre place.
Les données ne seront pas partagées mais elles pourront être communiquées : autrement dit on peut dupliquer les données d'un processus à l'autre via un protocole spécifié par le processus hôte.

Dupliquer des données : perte de perf. Et c'est loin d'être négligeable : regarde toutes les tentatives d'améliorer la vitesse de memcpy. Le problème est qu'il n'y a même pas de "meilleure solution" parce que, encore une fois, ça dépend du matériel (utilisation et quantité des caches CPU).

Sauf que le coût est en fait négligeable parce que le code asm produit est optimisé pour les algos "next line" typiquement mis en oeuvre dans les CPU.

Comme je l'ai dit, j'ai examiné le code ASM produit. Je passe même beaucoup de temps à ça... Et il n'y a pas de boucle dans mon exemple, seulement un saut conditionnel.

En quoi ne le permet-il pas ? Il n'y a aucune différence avec un autre langage de programmation. D'ailleurs inspecter le code asm généré est un jeu d'enfant sous VS.

Parce que le code est généré à l'exécution, pas à la compilation. Ou alors tu parles d'autre chose.

Un branchement conditionnel raté (avec vidange du pipeline) coûte trois à quatre fois le coût d'une addition d'entiers, pas cinq cent fois. Il est donc mathématiquement impossible que la plus sommaire des boucles (dix instructions dont un branchement) soit ralentie de plus d'une dizaine de pourcents par l'ajout d'une vérification indicielle statiquement invérifiable exécutée sur une plateforme exotique où l'on ne pourrait pas optimiser la prédiction des branchements.

Tu es très loin du compte...
Wikipedia : Modern microprocessors tend to have quite long pipelines so that the misprediction delay is between 10 and 20 clock cycles.
Et une addition d'entiers peut être exécutée avec plusieurs autres instructions en un seul cycle, on peut donc considérer que c'est moins d'un cycle.
Comme quoi l'accélération x12 de mon exemple n'a vraiment rien de surprenant.

C'est loin d'être le cas aujourd'hui : l'assembleur est de bien plus haut niveau que les instructions du processeur et ce dernier contient un sacré bazar qui ne te sert à rien. Par ailleurs tous tes programmes s'exécutent en espace utilisateur et le moindre accès mémoire passe sous les fourches caudines de la mémoire virtuelle.

Curieusement, les intrinsics permettent de redécouvrir certaines instructions inutilisées, comme par exemple _bit_scan_forward...
Bon sinon, pas la peine de me faire un cours sur les architectures RISC et CISC ou les vieilleries 16 bits, j'ai connu ce temps-là, un temps où on pouvait joyeusement écrire à l'adresse 0xA0000 pour faire apparaitre un pixel...

Et la ceinture de sécurité ne soigne pas le cancer.

Mais en es-tu vraiment persuadé ? Tu as l'air d'imaginer que le code managé est la solution à tous les problèmes de sécurité. Tout comme d'autres s'imaginent qu'une "sandbox" permet à navigateur d'être sûr...

De toute façon, outre le risque de perdre un marché pour Microsoft, il n'y a pas grand-monde qui veut d'un système aussi verrouillé que celui dont tu rêves : voir l'exemple du jailbreak d'iOS...

Edité par vampire7 le jeudi 10 avril 2014 à 16:20