Le problème est que si j'entre seulement le premiere lettre ou chiffre il
accepte alors que celles qui suivent sont fausses. Comment je peux faire
pour que le programme teste un à un les caratères?
| pense-tu qu'une implémentation non balancée, à temps variable et | proportionnel à la longueur de la phrase de passe candidate, soit plus | pertinente ?
Pardon ?
-- Gaby
Sylvain <noSpam@mail.net> writes:
| pense-tu qu'une implémentation non balancée, à temps variable et
| proportionnel à la longueur de la phrase de passe candidate, soit plus
| pertinente ?
| pense-tu qu'une implémentation non balancée, à temps variable et | proportionnel à la longueur de la phrase de passe candidate, soit plus | pertinente ?
Pardon ?
-- Gaby
Sylvain
Gabriel Dos Reis wrote on 22/06/2006 05:13:
et quel est le rapport avec l'âge du capitaine ?
le fait d'évaluer le bon age ... quitte à vouloir en traiter.
Sylvain.
Gabriel Dos Reis wrote on 22/06/2006 05:13:
et quel est le rapport avec l'âge du capitaine ?
le fait d'évaluer le bon age ... quitte à vouloir en traiter.
pour que le programme teste un à un les caratères?"
une réponse, un peu plus sécuritaire, est:
const size_t PASS_LENGTH = ?; // could be a hash block size
bool state = true; for (register int i = 0; i < PASS_LENGTH; ++i) state &= (candidate[i] == reference[i]);
au moins ici le temps ne varira pas avec la saisie.
mais c'est vrai que la réponse très normée et formattée std::machin est surement suffisante si on ne se pose aucune question, d'age ou autre.
Sylvain.
Gabriel Dos Reis
Sylvain writes:
| Gabriel Dos Reis wrote on 22/06/2006 01:44: | > Sylvain writes: | > | pense-tu qu'une implémentation non balancée, à temps variable et | > | proportionnel à la longueur de la phrase de passe candidate, soit plus | > | pertinente ? | > Pardon ? | > | [reposté après correction des coquilles] | | une "implémentation balancée" garantirait que chaque cycle | d'instruction omis (du fait de la taille des registres, du nombre | d'opérations scalairisées (faite en simultanée) serait balancé par un | NOP fournissant un temps constant pour une opération donnée.
et quel est le rapport avec l'âge du capitaine ?
-- Gaby
Sylvain <noSpam@mail.net> writes:
| Gabriel Dos Reis wrote on 22/06/2006 01:44:
| > Sylvain <noSpam@mail.net> writes:
| > | pense-tu qu'une implémentation non balancée, à temps variable et
| > | proportionnel à la longueur de la phrase de passe candidate, soit plus
| > | pertinente ?
| > Pardon ?
| >
| [reposté après correction des coquilles]
|
| une "implémentation balancée" garantirait que chaque cycle
| d'instruction omis (du fait de la taille des registres, du nombre
| d'opérations scalairisées (faite en simultanée) serait balancé par un
| NOP fournissant un temps constant pour une opération donnée.
| Gabriel Dos Reis wrote on 22/06/2006 01:44: | > Sylvain writes: | > | pense-tu qu'une implémentation non balancée, à temps variable et | > | proportionnel à la longueur de la phrase de passe candidate, soit plus | > | pertinente ? | > Pardon ? | > | [reposté après correction des coquilles] | | une "implémentation balancée" garantirait que chaque cycle | d'instruction omis (du fait de la taille des registres, du nombre | d'opérations scalairisées (faite en simultanée) serait balancé par un | NOP fournissant un temps constant pour une opération donnée.
et quel est le rapport avec l'âge du capitaine ?
-- Gaby
Gabriel Dos Reis
Sylvain writes:
| Gabriel Dos Reis wrote on 22/06/2006 05:13: | > et quel est le rapport avec l'âge du capitaine ? | > | le fait d'évaluer le bon age ... quitte à vouloir en traiter.
Ah.
-- Gaby
Sylvain <noSpam@mail.net> writes:
| Gabriel Dos Reis wrote on 22/06/2006 05:13:
| > et quel est le rapport avec l'âge du capitaine ?
| >
| le fait d'évaluer le bon age ... quitte à vouloir en traiter.
| Gabriel Dos Reis wrote on 22/06/2006 05:13: | > et quel est le rapport avec l'âge du capitaine ? | > | le fait d'évaluer le bon age ... quitte à vouloir en traiter.
Ah.
-- Gaby
Gabriel Dos Reis
Sylvain writes:
| Gabriel Dos Reis wrote on 22/06/2006 05:13: | > et quel est le rapport avec l'âge du capitaine ? | > | et aussi qu'à la question: "Comment je peux faire | pour que le programme teste un à un les caratères?" | | une réponse, un peu plus sécuritaire, est: | | const size_t PASS_LENGTH = ?; // could be a hash block size | | bool state = true; | for (register int i = 0; i < PASS_LENGTH; ++i) | state &= (candidate[i] == reference[i]); | | au moins ici le temps ne varira pas avec la saisie.
Parce que ?
-- Gaby
Sylvain <noSpam@mail.net> writes:
| Gabriel Dos Reis wrote on 22/06/2006 05:13:
| > et quel est le rapport avec l'âge du capitaine ?
| >
| et aussi qu'à la question: "Comment je peux faire
| pour que le programme teste un à un les caratères?"
|
| une réponse, un peu plus sécuritaire, est:
|
| const size_t PASS_LENGTH = ?; // could be a hash block size
|
| bool state = true;
| for (register int i = 0; i < PASS_LENGTH; ++i)
| state &= (candidate[i] == reference[i]);
|
| au moins ici le temps ne varira pas avec la saisie.
| Gabriel Dos Reis wrote on 22/06/2006 05:13: | > et quel est le rapport avec l'âge du capitaine ? | > | et aussi qu'à la question: "Comment je peux faire | pour que le programme teste un à un les caratères?" | | une réponse, un peu plus sécuritaire, est: | | const size_t PASS_LENGTH = ?; // could be a hash block size | | bool state = true; | for (register int i = 0; i < PASS_LENGTH; ++i) | state &= (candidate[i] == reference[i]); | | au moins ici le temps ne varira pas avec la saisie.
Parce que ?
-- Gaby
Vincent Lascaux
une implémentation à temps constant non proportionelle à la longueur du passphrase candidat garantirait qu'aucune attaque basée sur le temps (les plus faciles) ne peut être utilisée.
Tu peux donner un exemple d'une telle attaque ?
-- Vincent
une implémentation à temps constant non proportionelle à la longueur du
passphrase candidat garantirait qu'aucune attaque basée sur le temps (les
plus faciles) ne peut être utilisée.
une implémentation à temps constant non proportionelle à la longueur du passphrase candidat garantirait qu'aucune attaque basée sur le temps (les plus faciles) ne peut être utilisée.
Tu peux donner un exemple d'une telle attaque ?
-- Vincent
Vincent Lascaux
une implémentation à temps constant non proportionelle à la longueur du passphrase candidat garantirait qu'aucune attaque basée sur le temps (les plus faciles) ne peut être utilisée.
Tu peux donner un exemple d'une telle attaque ?
Ah d'accord, pour les lents comme moi, l'idée étant de mesurer le temps que le systeme met à trouver l'erreur pour savoir combien de caracteres sont bons
-- Vincent
une implémentation à temps constant non proportionelle à la longueur du
passphrase candidat garantirait qu'aucune attaque basée sur le temps (les
plus faciles) ne peut être utilisée.
Tu peux donner un exemple d'une telle attaque ?
Ah d'accord, pour les lents comme moi, l'idée étant de mesurer le temps que
le systeme met à trouver l'erreur pour savoir combien de caracteres sont
bons
une implémentation à temps constant non proportionelle à la longueur du passphrase candidat garantirait qu'aucune attaque basée sur le temps (les plus faciles) ne peut être utilisée.
Tu peux donner un exemple d'une telle attaque ?
Ah d'accord, pour les lents comme moi, l'idée étant de mesurer le temps que le systeme met à trouver l'erreur pour savoir combien de caracteres sont bons
-- Vincent
Jean-Marc Bourguet
Sylvain writes:
Cyrille wrote on 21/06/2006 22:15:
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
pense-tu qu'une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate, soit plus pertinente ?
Par rapport a une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate et sujette aux depassements de buffer comme celle presentee par l'OP, oui.
Les attaques par depassement de buffer sont d'un ordre de grandeur ou deux plus courantes que les attaques temporelles. (On va passer ensuite aux attaques par mesure de la consommation et des emissions electro-magnetiques.)
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Sylvain <noSpam@mail.net> writes:
Cyrille wrote on 21/06/2006 22:15:
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur
l'utilisation de std::string. Les tableaux de char à taille fixe, surtout
dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
pense-tu qu'une implémentation non balancée, à temps variable et
proportionnel à la longueur de la phrase de passe candidate, soit plus
pertinente ?
Par rapport a une implémentation non balancée, à temps variable et
proportionnel à la longueur de la phrase de passe candidate et sujette
aux depassements de buffer comme celle presentee par l'OP, oui.
Les attaques par depassement de buffer sont d'un ordre de grandeur ou
deux plus courantes que les attaques temporelles. (On va passer
ensuite aux attaques par mesure de la consommation et des emissions
electro-magnetiques.)
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
pense-tu qu'une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate, soit plus pertinente ?
Par rapport a une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate et sujette aux depassements de buffer comme celle presentee par l'OP, oui.
Les attaques par depassement de buffer sont d'un ordre de grandeur ou deux plus courantes que les attaques temporelles. (On va passer ensuite aux attaques par mesure de la consommation et des emissions electro-magnetiques.)
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
kanze
Sylvain wrote:
Cyrille wrote on 21/06/2006 22:43:
Cyrille wrote on 21/06/2006 22:15:
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
Ben utilisés comme ça, il suffit que l'utilisateur balance plus de 20 caractères pour écrire dans de la mémoire dans laquelle il ne devrait pas écrire. Je suppose que tu ne l'ignores pas.
je l'ignore pas, et c'est pour cela que je n'utilise jamais gets() ni ce pale wrapper de "cin".
la question des buffer overflow n'est toutefois pas liée au "contexte de sécurité", donc je repose ma question: en quoi une taille variable serait un plus ici?
La question est plutôt : en quoi un code simple et correct serait un plus ici ? Le code initialement posté plante carrément dès que l'utilisateur entre quelque chose d'imprévu. On peut bien le « corriger » pour qu'il marche, tout en gardant le char[], mais à coût de pas mal de complications en plus. Or qu'avec std::string, il marche comme il faut d'office.
En fait, le seul cas que je peux imaginer où la solution avec char[] a un avantage ici, c'est si on est payé à la ligne.
Bon, c'est vrai on peut aussi utiliser des versions sécurisées des fonctions de string C pour éviter les problèmes les plus évidents.
on aimerait aussi/surtout définir dynamiquement des opérateurs pour des types inconnus de la std; difficile pour une classe fournie par le runtime.
Je ne suis pas sûr de comprendre ce que tu veux. Est-ce que par dynamiquement, tu veux dire : lors de l'exécution ? C'est la signification habituelle, mais alors, ça veut dire quoi, définir des opérateurs lors de l'exécution. Et sinon, où est le problème ?
pense-tu qu'une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate, soit plus pertinente ?
Généralement oui.
hmmm, 100% des cryptologes sont dans l'erreur alors, j'aimerais en lire plus ici aussi.
J'avoue ne pas comprendre ces histoires de « balancée » et d'autres. C'est peut-être une préjudice personnelle, mais je trouve qu'une solution simple et correcte soit plus pertinante à une solution complexée et erronée. Quant à la performance : sur ma machine, les opérations sur std::string sont toujours bien plus rapide que le temps qu'il me faut pour tapper le texte en entrée. Au point où on pourrait carrément ignorer leur temps d'exécution.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain wrote:
Cyrille wrote on 21/06/2006 22:43:
Cyrille wrote on 21/06/2006 22:15:
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment
sur l'utilisation de std::string. Les tableaux de char à
taille fixe, surtout dans un contexte de sécurité, comme
ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une
taille fixe ?
Ben utilisés comme ça, il suffit que l'utilisateur balance
plus de 20 caractères pour écrire dans de la mémoire dans
laquelle il ne devrait pas écrire. Je suppose que tu ne
l'ignores pas.
je l'ignore pas, et c'est pour cela que je n'utilise jamais
gets() ni ce pale wrapper de "cin".
la question des buffer overflow n'est toutefois pas liée au
"contexte de sécurité", donc je repose ma question: en quoi
une taille variable serait un plus ici?
La question est plutôt : en quoi un code simple et correct
serait un plus ici ? Le code initialement posté plante
carrément dès que l'utilisateur entre quelque chose d'imprévu.
On peut bien le « corriger » pour qu'il marche, tout en
gardant le char[], mais à coût de pas mal de complications en
plus. Or qu'avec std::string, il marche comme il faut d'office.
En fait, le seul cas que je peux imaginer où la solution avec
char[] a un avantage ici, c'est si on est payé à la ligne.
Bon, c'est vrai on peut aussi utiliser des versions
sécurisées des fonctions de string C pour éviter les
problèmes les plus évidents.
on aimerait aussi/surtout définir dynamiquement des opérateurs
pour des types inconnus de la std; difficile pour une classe
fournie par le runtime.
Je ne suis pas sûr de comprendre ce que tu veux. Est-ce que par
dynamiquement, tu veux dire : lors de l'exécution ? C'est la
signification habituelle, mais alors, ça veut dire quoi, définir
des opérateurs lors de l'exécution. Et sinon, où est le
problème ?
pense-tu qu'une implémentation non balancée, à temps
variable et proportionnel à la longueur de la phrase de
passe candidate, soit plus pertinente ?
Généralement oui.
hmmm, 100% des cryptologes sont dans l'erreur alors,
j'aimerais en lire plus ici aussi.
J'avoue ne pas comprendre ces histoires de « balancée » et
d'autres. C'est peut-être une préjudice personnelle, mais je
trouve qu'une solution simple et correcte soit plus pertinante à
une solution complexée et erronée. Quant à la performance : sur
ma machine, les opérations sur std::string sont toujours bien
plus rapide que le temps qu'il me faut pour tapper le texte en
entrée. Au point où on pourrait carrément ignorer leur temps
d'exécution.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
Ben utilisés comme ça, il suffit que l'utilisateur balance plus de 20 caractères pour écrire dans de la mémoire dans laquelle il ne devrait pas écrire. Je suppose que tu ne l'ignores pas.
je l'ignore pas, et c'est pour cela que je n'utilise jamais gets() ni ce pale wrapper de "cin".
la question des buffer overflow n'est toutefois pas liée au "contexte de sécurité", donc je repose ma question: en quoi une taille variable serait un plus ici?
La question est plutôt : en quoi un code simple et correct serait un plus ici ? Le code initialement posté plante carrément dès que l'utilisateur entre quelque chose d'imprévu. On peut bien le « corriger » pour qu'il marche, tout en gardant le char[], mais à coût de pas mal de complications en plus. Or qu'avec std::string, il marche comme il faut d'office.
En fait, le seul cas que je peux imaginer où la solution avec char[] a un avantage ici, c'est si on est payé à la ligne.
Bon, c'est vrai on peut aussi utiliser des versions sécurisées des fonctions de string C pour éviter les problèmes les plus évidents.
on aimerait aussi/surtout définir dynamiquement des opérateurs pour des types inconnus de la std; difficile pour une classe fournie par le runtime.
Je ne suis pas sûr de comprendre ce que tu veux. Est-ce que par dynamiquement, tu veux dire : lors de l'exécution ? C'est la signification habituelle, mais alors, ça veut dire quoi, définir des opérateurs lors de l'exécution. Et sinon, où est le problème ?
pense-tu qu'une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate, soit plus pertinente ?
Généralement oui.
hmmm, 100% des cryptologes sont dans l'erreur alors, j'aimerais en lire plus ici aussi.
J'avoue ne pas comprendre ces histoires de « balancée » et d'autres. C'est peut-être une préjudice personnelle, mais je trouve qu'une solution simple et correcte soit plus pertinante à une solution complexée et erronée. Quant à la performance : sur ma machine, les opérations sur std::string sont toujours bien plus rapide que le temps qu'il me faut pour tapper le texte en entrée. Au point où on pourrait carrément ignorer leur temps d'exécution.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
