/* Topic des codeurs [7] */

grim7reaper · Le 14/06/2012, à 04:05

cm-t a écrit :

AAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

Et sinon, tu as un truc constructif à dire ?
On est pas sur le TdCT là, y’a pas de point à gagner…

Édit :

Eclipse : a Computing Legend In Performance Sucking Environment

:]

Dernière modification par grim7reaper (Le 14/06/2012, à 06:03)

Kanor · Le 14/06/2012, à 08:52

grim7reaper a écrit :

cm-t a écrit :
AAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
Et sinon, tu as un truc constructif à dire ?
On est pas sur le TdCT là, y’a pas de point à gagner…

grim7reaper: je crois pas ce n'est pas une question de point, je crois que c'est plus un pétage de câble sur son projet.

grim7reaper · Le 14/06/2012, à 10:03

Ha oui, c’est l’évidence même !
J’ai du rater un h, ce qui fait que je n’avais pas compris…

Plus sérieusement, ça ne retire rien à ce que j’ai dit, le post est pas constructif pour 2 sous (y’a aucun contexte, comment tu veux deviner de quoi il parle…).

tshirtman · Le 14/06/2012, à 10:31

/me corrige le déploiement d'une application rails 2.3.5, étant apparement l'expert ruby/rails de la boite, bon, pour l'instant j'ai surtout corrigé des soucis d'inclusions js (la cohabitation jquery/prototype…), mais hier soir, j'ai «enfin» touché aux controlleurs, et pile sur la fonction qui m'intéressait, y'avait un magnifique

#TODO: redo

(j'ai réussis à faire le changement que je voulais, quand même)

et bien sur c'est urgent, donc j'y retourne…

Dernière modification par tshirtman (Le 14/06/2012, à 10:32)

grim7reaper · Le 14/06/2012, à 10:57

C’est quoi l’intérêt de ce site ?
À part passer Google Translate sur Stack Overflow pour avoir un résultat imbitable, polluer les résultats de recherche et me donner envie de vomir…
On devrait brûler les gens qui font des sites de ce genre…

The Uploader · Le 14/06/2012, à 11:03

Ah, t'es en Rails 2. ^^
Quand on a goûté à Rails 3, c'est un peu difficile de revenir à Rails 2 (je suis aussi sur la version 2 en ce moment vu que je retravaille sur mon plugin pour Redmine).

Bien sûr on y perd des trucs utiles comme remote_form_for (et je crois qu'on y perd aussi RJS), mais à la place il y a UJS :

Rails 3 release notes a écrit :

Unobtrusive JavaScript helpers with drivers for Prototype, jQuery, and more coming (end of inline JS)

Tu peux pas passer en Rails 3 ?

@grim':
Rajoute "UbuntuUpdates" dans le feu. Pas lisible, pas à jour, et surtout il m'emmerde sur Google quand je veux la liste *officielle* des paquets...

Dernière modification par The Uploader (Le 14/06/2012, à 11:07)

tshirtman · Le 14/06/2012, à 13:56

Ouais non pour l'instant le but c'est que ça marche rapidement, là je cherche a comprendre comment passer une option a observe_field pour que le delayedObserver écoute sur event: 'change' et pas juste keyup (par ce que pour un select c'est pas terrible keyup -_-

tshirtman · Le 14/06/2012, à 15:08

En fait je ne comprends pas, observe_field est sensé utiliser prototype, pas jquery… comment ils se sont débrouillés… (c'est pas jrails qui me fait ça remarque ? je check - reedit: putain oui c'était ça… -_-)

ah au passage. ce sur quoi je bosse est dispo en libre… http://redmine.tosca-project.net/

Dernière modification par tshirtman (Le 14/06/2012, à 15:29)

Dr Le Rouge · Le 14/06/2012, à 16:34

Dites, vous auriez une astuce pour qu'un script bash puisse faire "ding" (ou n'importe quel son) quand il a fini de s'éxécuter ? Je suis en train de faire des mesures de temps d'éxécution ^^

Pylades · Le 14/06/2012, à 16:38

echo $'\a'

Ou sinon, tu peux carrément installer beep.

Mais pour les mesures de temps d’exécution, il y a plus simple et plus propre :

time (./prog)

Dernière modification par Πυλάδης (Le 14/06/2012, à 16:45)

Dr Le Rouge · Le 14/06/2012, à 16:55

Πυλάδης a écrit :

echo $'\a'

Marche pas.

Ou sinon, tu peux carrément installer beep.

Marche nickel (après le modprob qui va bien) \o/

Mais pour les mesures de temps d’exécution, il y a plus simple et plus propre :
time (./prog)

Je sais, le bip est là pour m'avertir quand la mesure est dispo, pas pour que j'arrête le chrono ^^

Pylades · Le 14/06/2012, à 17:08

Le Rouge a écrit :

Marche pas.

Le Rouge a écrit :

Marche nickel (après le modprob qui va bien) \o/

Ceci explique cela, hein…

Le Rouge a écrit :

Je sais, le bip est là pour m'avertir quand la mesure est dispo, pas pour que j'arrête le chrono ^^

J’me disais, aussi.

Ça fera 42 k€, payables en trois fois sans frais sur six mois (je suis magnanime).

Dr Le Rouge · Le 14/06/2012, à 17:13

Πυλάδης a écrit :

Ceci explique cela, hein…

Nope, la méthode avec le "echo" ne marche toujours pas.

Ça fera 42 k€, payables en trois fois sans frais sur six mois (je suis magnanime).

<naheulbeuk>Va mourir ! T'auras pas mon or !</naheulbeuk>

(t'façon j'en ai pas )

grim7reaper · Le 14/06/2012, à 17:17

J’en profite pour signaler que le builtin de time offert par le shell est très limité par rapport à /usr/bin/time.
Mais bon, si on veut que le temps d’exécution, c’est suffisant bien sûr.

Au fait Le Rouge, tu te rappelles de ma question ou tu es encore très occupé (y’a pas de soucis, c’est juste pour savoir ).

Dr Le Rouge · Le 14/06/2012, à 17:25

J'ai pas oublié, t'inquiète ^^ En fait, je ne pense pas qu'il y ait de réponse générale simple, ça dépend du générateur de nombre aléatoire et, surtout, de la qualité de la sécurisation des fichiers (si une paire chiffre/clair est trouvée, la clef tombe tout de suite). Tu utilises quoi comme prg ?

grim7reaper · Le 14/06/2012, à 17:59

Le Rouge a écrit :

J'ai pas oublié, t'inquiète ^^ En fait, je ne pense pas qu'il y ait de réponse générale simple, ça dépend du générateur de nombre aléatoire et, surtout, de la qualité de la sécurisation des fichiers (si une paire chiffre/clair est trouvée, la clef tombe tout de suite). Tu utilises quoi comme prg ?

Oui, si une paire tombe tout tombe ça je le sais ^^
En fait, y’a pas vraiment de PRNG, je vais essayer d’expliquer le truc.
Je découpe ma mémoire en blocs, et quand j’envoie un message je le XOR avec un bloc que je choisi d’une manière ou d’une autre (sachant que l’identifiant du bloc utilisé est indiqué en clair, concatené au message chiffré).
Je change de bloc au fure et à mesure bien sûr, mais la mémoire ayant une taille limité, c’est amené à se répéter.

Bien entendu, si un gus dump la mémoire c’est la fête du slip et tout tombe ça c’est clair et je le sais. Mais dans l’hypothèse (pas réaliste, je te l’accorde) que le gus ne puisse pas dumper la mémoire, quels genre d’attaques il peut faire là-dessus ?
J’me doute que ça doit pas être très costaud, mais bon…

Je rappelle que les messages chiffrés ne sont pas du texte (ça peut peut-être avoir une influence sur l’analyse de fréquence, je ne sais pas…).

Dernière modification par grim7reaper (Le 14/06/2012, à 17:59)

Dr Le Rouge · Le 14/06/2012, à 18:03

Le contenu des blocs sort d'où ? C'est des données utilisées par ton programme ?

Elzen · Le 14/06/2012, à 22:27

Le Rouge a écrit :

Πυλάδης a écrit :
Ceci explique cela, hein…
Nope, la méthode avec le "echo" ne marche toujours pas.

P't'être parce que la bonne syntaxe (celle suggérée par le man, en tout cas) est

echo -ne "\a"

-e pour qu'il interprète les caractères échappés (donc le -a, en l'occurrence), et -n pour qu'il n'affiche pas le retour à la ligne sur la sortie standard, ça n'sert à rien de mettre quelque chose sur la sortie standard quand tu veux juste que ça joue un son.

Ceci dit,

echo $'\a'

fonctionne, chez moi.

Après, perso, dans mon réglage de volume, je laisse mon beep système sur muet quasiment en permanence, parce que ça m'énerve de l'entendre s'exprimer quand j'abuse un peu trop des pgup/pgdwn dans un éditeur de texte (que ce soit vim ou un truc basé sur le gtksourceview) ou que je remonte/redescend trop dans l'historique bash. Ce qui m'arrive vachement souvent.

grim7reaper · Le 15/06/2012, à 04:00

Le Rouge a écrit :

Le contenu des blocs sort d'où ? C'est des données utilisées par ton programme ?

Non.
Ma mémoire contiendrait du code exécutable, par exemple le code (enfin le binaire plus exactement) de l’OS, et c’est ça qui serait utilisé.
Ça resterait assez difficile à retrouver, même en ayant le code source je pense. Si je prend l’exemple de Linux, le binaire va dépendre :
- de la version de Linux
- de la configuration du noyau (modules activés, patch appliqués, architecture ciblé, etc.)
- du compilateur utilisé (gcc ou icc (clang compile pas encore Linux il me semble mais des gens y travaillent))
- de la version du compilateur utilisé
- des options de compilations
- de l’éditeur de liens utilisé
- …

Ouch ^^

Dernière modification par grim7reaper (Le 15/06/2012, à 04:03)

Pylades · Le 15/06/2012, à 05:04

Ça ne m’étonne même pas. ^^

Dr Le Rouge · Le 15/06/2012, à 19:53

@ grim : m'kay, je ne pense pas que ce soit "trop" facile à casser. Mais si la sécurité est importante, oublie quand même : il ne serait pas si difficile de tenter toutes les tuples (OS,plate-forme,compilo,...) possibles.

En plus, suivant l'information que veut le vilain, il pourrait peut-être y accéder facilement quand même ! Explication : mettons que je ne m'intéresse pas au contenu des messages mais à leur évolution. Vu que le XOR de deux textes chiffrés avec la même clef est le même que le XOR des deux messages clairs, un attaquant pourrait peut-être obtenir ce qu'il veut. Si tu veux faire plus sécurisé sans consommer trop de puissance de calcul/de mémoire, tu peux te tourner vers des algos basés sur du LFSR, genre des trucs dans ce goût là (utilisé dans le chiffrement des communications GSM, plutôt solide).

Si la sécurité n'est pas très importante, pas besoin de s'embêter évidemment ^^

Rien à voir mais pas faux ^^

Dernière modification par Dr Le Rouge (Le 15/06/2012, à 19:54)

Steap · Le 15/06/2012, à 23:51

Dîtes-donc jeunes gens, avez-vous vu ce concours ?

Dernière modification par Steap (Le 15/06/2012, à 23:51)

tshirtman · Le 16/06/2012, à 00:34

Vu, mais j'aurais pas le temps…

sinon je viens de découvrir ça, http://angularjs.org/ et dans le concept, ça me plait beaucoup…

grim7reaper · Le 16/06/2012, à 05:05

Le Rouge a écrit :

@ grim : m'kay, je ne pense pas que ce soit "trop" facile à casser. Mais si la sécurité est importante, oublie quand même : il ne serait pas si difficile de tenter toutes les tuples (OS,plate-forme,compilo,...) possibles.

Ok, finalement c’est pas si mauvais que ça.
Mais on est d’accord, c’est pas pour des trucs super sensibles ^^

Le Rouge7 a écrit :

En plus, suivant l'information que veut le vilain, il pourrait peut-être y accéder facilement quand même ! Explication : mettons que je ne m'intéresse pas au contenu des messages mais à leur évolution. Vu que le XOR de deux textes chiffrés avec la même clef est le même que le XOR des deux messages clairs, un attaquant pourrait peut-être obtenir ce qu'il veut.

Oui, j’était arrivé jusqu’à ce point là, où on peut récupérer le XOR de deux messages clairs. Après ils disaient que les bon cryptographes pouvaient savoir ce qu’ils voulaient à partir de ça mais sans plus de détail.
Tu sais comment ?

Le Rouge a écrit :

Si tu veux faire plus sécurisé sans consommer trop de puissance de calcul/de mémoire, tu peux te tourner vers des algos basés sur du LFSR, genre des trucs dans ce goût là (utilisé dans le chiffrement des communications GSM, plutôt solide).

Oui, j’avais commencé à regarder dans ce sens là aussi, les stream cipher. Le problème des trucs basés sur LFSR c’est que c’est très bien en hard, mais niveau logiciel c’est pas top. Du coup j’était tombé sur Rabbit qui semblait bien de ce point de vue là.

Le Rouge a écrit :

Si la sécurité n'est pas très importante, pas besoin de s'embêter évidemment ^^

Non, en fait c’était surtout pour voir jusqu’où on pouvait aller avec une idée un peu sortie de derrière les fagots et sans connaissance particulière en crypto.
Bah ça donne un truc pas très sûr (là, je suis pas surpris), mais pas trop facile non plus (ça je m’y attendais moins).
Bon, au moins ça m’aurait fait lire pas mal de choses et découvrir 2-3 algos donc c’était pas du temps perdu.
Et merci pour tes réponses

Le Rouge a écrit :

Rien à voir mais pas faux ^^

Ça sent le vécu, non ? ^^

Dr Le Rouge · Le 16/06/2012, à 10:54

grim7reaper a écrit :

Après ils disaient que les bon cryptographes pouvaient savoir ce qu’ils voulaient à partir [du XOR de deux clairs] mais sans plus de détail.
Tu sais comment ?

Non mais m'est avis que c'est des genres d'attaques statistiques.

Le problème des trucs basés sur LFSR c’est que c’est très bien en hard, mais niveau logiciel c’est pas top. Du coup j’était tombé sur Rabbit qui semblait bien de ce point de vue là.

Ouais, le LFSR est utilisé pour « chiffrer » les communications des puces RFID (en fait, l'algo utilisé est en carton).

Non, en fait c’était surtout pour voir jusqu’où on pouvait aller avec une idée un peu sortie de derrière les fagots et sans connaissance particulière en crypto. Bah ça donne un truc pas très sûr (là, je suis pas surpris), mais pas trop facile non plus (ça je m’y attendais moins).

Ce qu'il faut voir c'est que les standards actuels pour qu'un algo soit considéré comme solide sont colossaux ! Genre les seules « attaques » contre AES sont en fait contre des versions affaiblies (par exemple 10 tours au lieu de 16) et nécessite des nombres énormes de pairs chiffres/clairs chiffrés avec la même clef pour qu'on retrouve celle-ci (cryptanalyse différentielle ou linéaire). C'est un peu moins vrai dans les chiffrements assymétriques dans la mesures où ils sont toujours probabilistes et dépendent donc d'un fragile PRG.

Mais bref : je veux en venir au fait que même si un algo n'est pas considéré comme sûr, il faut quand même souvent s'accrocher pour pouvoir exploiter leur vulnérabilité. Donc à moins d'avoir des cryptographes professionnels à ses trousses et vu le niveau de maths requis pour faire des attaques un poil sophistiquée, le Kevin de base a très peu de chance d'accéder à des infos même mal chiffrées. À l'inverse, si tu sors le AES-256 avec un mdp qui fait effectivement 256 bits, t'es tranquille… mais alors, tranquille : il sera beaucoup moins coûteux de « tricher » et pirater ton ordi pour prendre directement les textes clairs là où ils sont que de tenter de casser les chiffres.

A mon humble avis ^^

Le Rouge a écrit :
Rien à voir mais pas faux ^^
Ça sent le vécu, non ? ^^

pas content

Sinon, gollum est de retour. Il nous la joue à la fight club où il est conscient d'avoir deux personnalités ?

edit : pour revenir sur ce que je disais plus haut : ça fait un moment (5 ans ?) que md5 n'est plus considéré comme sécurisé. Et pourtant, la première « vraie » utilisation pratique de sa faiblesse est dans Flame et repose sur une nouvelle attaque (source). Ce qui tend à prouver par ailleurs que Flame était développé par des gens sérieux. Le premier employeur de mathématicien au monde peut-être ?

Dernière modification par Dr Le Rouge (Le 16/06/2012, à 11:23)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1001 Le 14/06/2012, à 04:05

Re : /* Topic des codeurs [7] */

#1002 Le 14/06/2012, à 08:52

Re : /* Topic des codeurs [7] */

#1003 Le 14/06/2012, à 10:03

Re : /* Topic des codeurs [7] */

#1004 Le 14/06/2012, à 10:31

Re : /* Topic des codeurs [7] */

#1005 Le 14/06/2012, à 10:57

Re : /* Topic des codeurs [7] */

#1006 Le 14/06/2012, à 11:03

Re : /* Topic des codeurs [7] */

#1007 Le 14/06/2012, à 13:56

Re : /* Topic des codeurs [7] */

#1008 Le 14/06/2012, à 15:08

Re : /* Topic des codeurs [7] */

#1009 Le 14/06/2012, à 16:34

Re : /* Topic des codeurs [7] */

#1010 Le 14/06/2012, à 16:38

Re : /* Topic des codeurs [7] */

#1011 Le 14/06/2012, à 16:55

Re : /* Topic des codeurs [7] */

#1012 Le 14/06/2012, à 17:08

Re : /* Topic des codeurs [7] */

#1013 Le 14/06/2012, à 17:13

Re : /* Topic des codeurs [7] */

#1014 Le 14/06/2012, à 17:17

Re : /* Topic des codeurs [7] */

#1015 Le 14/06/2012, à 17:25

Re : /* Topic des codeurs [7] */

#1016 Le 14/06/2012, à 17:59

Re : /* Topic des codeurs [7] */

#1017 Le 14/06/2012, à 18:03

Re : /* Topic des codeurs [7] */

#1018 Le 14/06/2012, à 22:27

Re : /* Topic des codeurs [7] */

#1019 Le 15/06/2012, à 04:00

Re : /* Topic des codeurs [7] */

#1020 Le 15/06/2012, à 05:04

Re : /* Topic des codeurs [7] */

#1021 Le 15/06/2012, à 19:53

Re : /* Topic des codeurs [7] */

#1022 Le 15/06/2012, à 23:51

Re : /* Topic des codeurs [7] */

#1023 Le 16/06/2012, à 00:34

Re : /* Topic des codeurs [7] */

#1024 Le 16/06/2012, à 05:05

Re : /* Topic des codeurs [7] */

#1025 Le 16/06/2012, à 10:54

Re : /* Topic des codeurs [7] */

Pied de page des forums