Confiance en AES

According to Pierre Vandevenne <pierre@datarescue.com>:

On dirait qu'il a changé d'avis... ;-)

Ben oui, entretemps Coppersmith s'est mis à causer plus en détail
qu'auparavant. On peut toujours supposer qu'il ne parle que selon les
souhaits de la NSA et que c'est une opération de couverture, mais je
trouve néanmoins beaucoup plus plausible et probable que les chercheurs
de chez IBM aient effectivement découvert la cryptanalyse différentielle
en 1974, et que l'action de la NSA se soit bornée à une exigence de
réduction de la taille de la clé, et une vérification que le boulot
avait été bien fait (c'est leur job, après tout).

Non que ça change grand chose, en fait. Les cryptanalyses linéaire et
différentielles sont rarement praticables dans des situations d'attaque
concrète (il est difficile de trouver une situation où le méchant peut
faire chiffrer un million de paires de blocs pour ensuite attaquer la
clé, et dans le cas de DES, il faut 2^46 paires de blocs, c'est-à-dire
64 millions de millions). La vraie faiblesse de DES est celle qui crève
les yeux depuis le début et que tout le monde a vu, à savoir la clé de
56 bits.


--Thomas Pornin

pornin@nerim.net (Thomas Pornin) wrote in news:bnikp9$cjb$1
@biggoron.nerim.net:

Non que ça change grand chose, en fait. Les cryptanalyses linéaire et

Tout à fait d'accord, c'était plus pour le clin d'oeil que le reflet d'une
divergence fondamentale.

Cela étant, je discerne la faille volontaire de la faille heu, due au
processus industriel ;o). La première c'est l'éditeur du soft qui
cherche à te coincer. Là seconde, elle profite plutôt à ses clients.

C'est une propriété intrinsèque du processus de développement logiciel
actuel.

Vous pouvez m'expliquer en quoi le processus industriel est il
*forcément* générateur de failles ? Et en quoi cela profite aux
clients, je ne comprends pas.

pas.de.spam@wanadoo.fr (olivier) wrote in
news:f01030a9.0311050117.6dcdca8@posting.google.com:

Cela étant, je discerne la faille volontaire de la faille heu, due
au

processus industriel ;o). La première c'est l'éditeur du soft qui
cherche à te coincer. Là seconde, elle profite plutôt à ses
clients.

C'est une propriété intrinsèque du processus de développement
logiciel

actuel.

Vous pouvez m'expliquer en quoi le processus industriel est il
*forcément* générateur de failles ?

La très très grande majorité des programmeurs qui sortent des écoles
aujourd'hui n'a reçu _aucune_ formation en programmation sûre (ne
serait-ce qu'éviter les manipulations de buffers douteuses).

En outre, en l'absence de sensibilisation au problème, ils sont tous
convaincus que LEUR code est sûr.

Pour éviter intelligement certaines pratiques peu sures, l'idéal serait
de comprendre ce qui se passe à un bas niveau plutôt que de gérer le
problème sur base de recettes de cuisines. Peu de personnes connaissent
/comprennent encore le bas niveau.

Les sociétés qui les emploient ne sont pas non plus sensibilisées et, ce
qu'elles demandent, ce sont en général plus de fonctionnalités le plus
rapidement possible...

Et on pourrait allonger la liste.

Et en quoi cela profite aux
clients, je ne comprends pas.

Cela, ce n'est pas de moi mais d'AMcD je pense. Essayez de citer
correctement, cela aidera le suivi.

olivier wrote:

Cela étant, je discerne la faille volontaire de la faille heu, due au
processus industriel ;o). La première c'est l'éditeur du soft qui
cherche à te coincer. Là seconde, elle profite plutôt à ses clients.

C'est une propriété intrinsèque du processus de développement logiciel
actuel.

Vous pouvez m'expliquer en quoi le processus industriel est il
*forcément* générateur de failles ?

Dans le processus de dévellopement actuel, quel qu'il soit, on ne sait
pas faire en sorte qu'il n'y ait pas de faille.
Ou mieux, on sait faire en sorte que l'on diminue les failles, mais
c'est une fonction logarythmique de l'effort et du temps dépensé, et le
nombre de failles restantes n'est jamais nul.

A un moment donné, le coût d'augmenter l'effort et le temps dépasse
celui des failles restante, il n'est donc plus rentable de les augmenter.

L'aspect industriel vient à travers le souci de la rentabilité, et donc
que le seuil où l'on s'arrète est souvent assez faible, car on ne
poursuivra pas les efforts jusqu'au moment où ils vont dépasser le coût
des failles restante, mais jusqu'au moment où un delta d'effort ne
produira plus un delta de réduction de faille avec une facteur
suffisament élevé.

Et en quoi cela profite aux
clients, je ne comprends pas.

Les failles concernent tous les aspects du logiciel, y compris ceux
censés le protéger contre une utilisation abusive.
Les failles sur les aspects fonctionnels gènent le client, mais celles
sur les protections contre les utilisations abusives lui permettent de
détourner le soft de l'usage voulu par l'éditeur.

Exemple concret : La faille de buffer overflow dans le logiciel de base
de la Xbox Microsoft dont l'utilisation permet facilement de démarrer la
machine sur un autre OS que celui de l'éditeur.

Pierre Vandevenne wrote:

La très très grande majorité des programmeurs qui sortent des écoles
aujourd'hui n'a reçu _aucune_ formation en programmation sûre (ne
serait-ce qu'éviter les manipulations de buffers douteuses).
En outre, en l'absence de sensibilisation au problème, ils sont tous
convaincus que LEUR code est sûr.

Ce n'est pas tellement lié à la formation des ingénieurs en particulier,
mais plus à la (auto) formation annexe des développeurs. On ne devient
pas programmeur de talent sensibilisé aux problèmes de sécurité après 3
ans en école, on le devient après de très longues années d'expérience et
de code. Je suis persusadé que les les mauvais programmeurs sont
simplement des programmeurs sans expérience. On peut d'ailleurs rester
mauvais programmeur longtemps, faute de pratique et/ou d'interêt pour la
chose.

"Xavier Roche" <xroche@free.fr.NOSPAM.invalid> a écrit dans le message de
news:boaplt$lmv$1@s1.read.news.oleane.net...

Pierre Vandevenne wrote:

La très très grande majorité des programmeurs qui sortent des écoles
aujourd'hui n'a reçu _aucune_ formation en programmation sûre (ne
serait-ce qu'éviter les manipulations de buffers douteuses).
En outre, en l'absence de sensibilisation au problème, ils sont tous
convaincus que LEUR code est sûr.

Ce n'est pas tellement lié à la formation des ingénieurs en particulier,
mais plus à la (auto) formation annexe des développeurs. On ne devient
pas programmeur de talent sensibilisé aux problèmes de sécurité après 3
ans en école, on le devient après de très longues années d'expérience et

Je ne suis pas d'accord avec toi : si tu ne mets pas ça dans la formations
des ingénieurs et développeurs on ne pourra pas se plaindre ensuite de voir
des buffer overflow dans du code tout neuf.

Donc un minimum de sensibilisation en école ça pourrait aider.

Quand on voit des profs ne pas connaitre le problème...
Et je ne parle pas de ceux qui donnent des passwords "internes à
l'établissement" à certains élèves pour installer plus vite certains trucs.
Ceux là ce n'est pas à la programmation "sure" qu'il faut les initier, mais
déjà à la prudence et au bon sens :(.

de code. Je suis persusadé que les les mauvais programmeurs sont
simplement des programmeurs sans expérience. On peut d'ailleurs rester
mauvais programmeur longtemps, faute de pratique et/ou d'interêt pour la
chose.

Il est clair qu'il y a un monde entre "l'école" et la "vraie" vie. Mais de
la à ne pas aborder ce qui *est* actuellement important (sans compter que la
formation devrait un peu anticiper, mais il faut former les formateurs :) )
il ne faut pas charrier.

Eric.

Pierre Vandevenne wrote:

Cela, ce n'est pas de moi mais d'AMcD je pense. Essayez de citer
correctement, cela aidera le suivi.

Heu, moi, je n'en pense pas moins et l'ai d'ailleurs déjà formulé autrement
sur d'autres NGs. Mais cette forme là doit plutôt être de Roland Garcia...

Cela étant, ajoutons aussi la notions de faisabilité vis-àvis du contexte.
Prenons un gars qui développe du code privé pour une boîte. Cela ne sortira
jamais des besoins internes à l'entreprise, etc. Il suffit que celui-ci
applique de bonnes règles algorithmiques, soit méthodique et organisé et les
bugs de ses applications ne dépasseront pas le taux généralement admis. Les
utilisateurs de la boîte verront un bug par an et c'est bon.

Si ce gars bosse sur des logiciels commerciaux, allez, compliquons un peu,
devant fonctionner en réseau (ne parlons même pas de logiciels critiques ou
sécuritaires), imagine la différence ! Il faut que le gars pense aux buffers
overflows, aux strings overflows, aux integers overflows, aux stack
overflows, aux détournement de privilège, aux injections de code, aux races
conditions, aux... stop ! Si le chef de projet à du buget à faire rentrer,
je doute que les programmeurs aient le temps de penser à ça, de mettre en
oeuvre des tests élaborés, de la vérification de code, etc. Y sont-ils
formés d'ailleurs ? Dans un univers ou le code doit toujours pêtre prêt pour
avant-hier, est-ce vraiment la faute du programmeur si il y a des failles.
Suivant le contexte, les programmeurs auront ou pas la possibilité et le
temps de penser à tout ça. Suivant le contexte, des gens seront payés pour
veiller à ça. Parce que on ne peux pas non plus demander au programmeur de
en plus de son boulot se tenir au courant des dernières techniques
d'attaques. Il le fait quand ? il dort plus, il mange plus ?

À mon humble avis, le problème est beaucoup plus simple, ils s'appelle la
rentabilité. Que le code sorte le plus tôt possible avec le moins de bug
possible avec le coût de revient le plus bas possible est en gros la loi
actuelle. Il ne faut pas s'étonner que ça marche sur la tête. Les faille
sont donc bien inhérentes au processus industriel tel qu'il est pratiqué
aujourd'hui.

--
AMcD

http://arnold.mcdonald.free.fr/

According to Pierre Vandevenne <pierre@datarescue.be>:

Peu de personnes connaissent/comprennent encore le bas niveau.

Il arrive que des gens me posent benoîtement la question suivante :
"mon petit frère/cousin/collègue/camarade de beuverie/autre voudrait
apprendre à programmer, il doit commencer par quel langage ?"

Si je ne suis pas seul à ce moment, la question dégénère toujours en
une flamewar monumentale ; mais sinon, ma réponse est en général : "le
transistor, puis l'assembleur". C'est la méthode la plus rude pour
commencer, mais c'est celle qui donne le plus de maîtrise après. On
comprend tout au C quand on sait ce que le compilateur fait du code
source et ce qu'il produit. On domine pleinement le Java quand on sait
comment on ferait pour implémenter une JVM.

(En tous cas, cette réponse m'assure en général une originalité de bon
aloi au milieu de la flamewar que j'évoquais plus haut. Vanter C, Java,
CaML, Perl ou Python, c'est très banal. Mais le transistor, ça a du
cachet.)


Sinon, force est de reconnaître que tout le monde n'est pas suffisamment
tenace (ou plutôt têtu et borné) pour apprendre à programmer en
commençant par conceptualiser le déplacement (statistique !) d'atomes
de bore dans le silicium, et que dans la société moderne on manque
de programmeurs et qu'il faut faire avec ce qu'on a sous la main.
Industriellement, un programmeur qui fait n'importe quoi, c'est toujours
un programmeur qui fait quelque chose, ce qui est plus que ce que fait
un programmeur qui n'existe pas, et, industriellement parlant, "plus"
c'est "mieux".


La tendance actuelle est de concevoir des langages et environnement
de programmation qui s'assurent que les trous de sécurités les plus
usuels et béants ne surviennent pas trop souvent. Par exemple, en Java,
les accès aux tableaux sont vérifiés, et les buffer overflows sont
automatiquement contrés et sanctionnés. Non que ça résolve tout, mais ça
limite les dégâts. Le coût en performances est négligeable. On y perd
beaucoup en élégance. Ça permet au Vrai Programmeur de continuer à faire
de vrais programmes sûrs et efficace en C/assembleur/Forth en prenant ça
pour de l'Art.


--Thomas Pornin

Thomas Pornin wrote:

[...]. Le coût en performances est négligeable. On y perd
beaucoup en élégance.

Y perd on vraiment en élégance ?
En tout cas sur cet aspect particulier.
Ada est un exemple de language très élégant, qu'un certain nombre de
vrai programmeurs aiment beaucoup et qui a les même mécanismes de
protection.

Et puis pour les performances ... Java est aussi lent qu'un language de
script, mais doit être compilé. Je pense qu'à terme PHP vaincra.

J'ai bien lancé la flamewar ?