ret decrypt(const char* inStr, size_t inLen, char*[*] outStr);
Ben oui, c'est exactement ce que je fais...
dès lors les chaines chiffrées n'ont pas besoin d'être recopiées dans un élément de 'tab', au contraire ce tableau sera initialisé avec des null et le résultat du déchiffrement y sera stocké après allocation.
Ben oui, c'est exactement ce que je fais...
Résumons.
- J'ai une table de chaînes chiffrées, donc constantes. - J'ai une table de pointeurs sur des chaînes. - Je lis une chaîne de la table chiffrée, j'alloue la mémoire pour la version déchiffrée. - Une fois déchiffrée, je mets à jour le pointeur correspondant dans la table des pointeurs.
Bref, tu redécris exactement ce que je fais. Je pige pas ton intervention.
Note au passage, que si je faisais ça en assembleur, j'utiliserai une seule table, la table chiffrée, dans laquelle j'écraserai par les chaînes déchiffrées les chaînes chiffrées. Gros gain de place. En C/C++, on est obligé de perdre de la place. Soit tu dupliques la table originale, mais en ce cas, il faut créer dès le départ une table "ghost" de la chiffrée et tu te contentes donc de doubler la place mémoire. Soit tu utilises une table de pointeur vers les chaînes allouées et donc tu consommes 2 tables (bah vi, les chaînes allouées, ça prend la même place que les chiffrées :p) plus la table de pointeurs.
Vive l'assembleur.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Sylvain wrote:
ret decrypt(const char* inStr, size_t inLen, char*[*] outStr);
Ben oui, c'est exactement ce que je fais...
dès lors les chaines chiffrées n'ont pas besoin d'être recopiées dans
un élément de 'tab', au contraire ce tableau sera initialisé avec des
null et le résultat du déchiffrement y sera stocké après allocation.
Ben oui, c'est exactement ce que je fais...
Résumons.
- J'ai une table de chaînes chiffrées, donc constantes.
- J'ai une table de pointeurs sur des chaînes.
- Je lis une chaîne de la table chiffrée, j'alloue la mémoire pour la
version déchiffrée.
- Une fois déchiffrée, je mets à jour le pointeur correspondant dans la
table des pointeurs.
Bref, tu redécris exactement ce que je fais. Je pige pas ton intervention.
Note au passage, que si je faisais ça en assembleur, j'utiliserai une seule
table, la table chiffrée, dans laquelle j'écraserai par les chaînes
déchiffrées les chaînes chiffrées. Gros gain de place. En C/C++, on est
obligé de perdre de la place. Soit tu dupliques la table originale, mais en
ce cas, il faut créer dès le départ une table "ghost" de la chiffrée et tu
te contentes donc de doubler la place mémoire. Soit tu utilises une table de
pointeur vers les chaînes allouées et donc tu consommes 2 tables (bah vi,
les chaînes allouées, ça prend la même place que les chiffrées :p) plus la
table de pointeurs.
ret decrypt(const char* inStr, size_t inLen, char*[*] outStr);
Ben oui, c'est exactement ce que je fais...
dès lors les chaines chiffrées n'ont pas besoin d'être recopiées dans un élément de 'tab', au contraire ce tableau sera initialisé avec des null et le résultat du déchiffrement y sera stocké après allocation.
Ben oui, c'est exactement ce que je fais...
Résumons.
- J'ai une table de chaînes chiffrées, donc constantes. - J'ai une table de pointeurs sur des chaînes. - Je lis une chaîne de la table chiffrée, j'alloue la mémoire pour la version déchiffrée. - Une fois déchiffrée, je mets à jour le pointeur correspondant dans la table des pointeurs.
Bref, tu redécris exactement ce que je fais. Je pige pas ton intervention.
Note au passage, que si je faisais ça en assembleur, j'utiliserai une seule table, la table chiffrée, dans laquelle j'écraserai par les chaînes déchiffrées les chaînes chiffrées. Gros gain de place. En C/C++, on est obligé de perdre de la place. Soit tu dupliques la table originale, mais en ce cas, il faut créer dès le départ une table "ghost" de la chiffrée et tu te contentes donc de doubler la place mémoire. Soit tu utilises une table de pointeur vers les chaînes allouées et donc tu consommes 2 tables (bah vi, les chaînes allouées, ça prend la même place que les chiffrées :p) plus la table de pointeurs.
ret decrypt(const char* inStr, size_t inLen, char*[*] outStr);
Ben oui, c'est exactement ce que je fais...
dès lors les chaines chiffrées n'ont pas besoin d'être recopiées dans un élément de 'tab', au contraire ce tableau sera initialisé avec des null et le résultat du déchiffrement y sera stocké après allocation.
Ben oui, c'est exactement ce que je fais...
Résumons.
- J'ai une table de chaînes chiffrées, donc constantes. - J'ai une table de pointeurs sur des chaînes. - Je lis une chaîne de la table chiffrée, j'alloue la mémoire pour la version déchiffrée. - Une fois déchiffrée, je mets à jour le pointeur correspondant dans la table des pointeurs.
Bref, tu redécris exactement ce que je fais. Je pige pas ton intervention.
Note au passage, que si je faisais ça en assembleur, j'utiliserai une seule table, la table chiffrée, dans laquelle j'écraserai par les chaînes déchiffrées les chaînes chiffrées. Gros gain de place.
Ben si tes chaines dechiffrées sont plus longues que les chiffrées tu retombes sur le même probleme. De plus si le compilo place les chaines chiffrées constantes dans un segment readonly tu pourras pas les modifier, que ce soit C ou assembleur (sauf hack).
ret decrypt(const char* inStr, size_t inLen, char*[*] outStr);
Ben oui, c'est exactement ce que je fais...
dès lors les chaines chiffrées n'ont pas besoin d'être recopiées dans
un élément de 'tab', au contraire ce tableau sera initialisé avec des
null et le résultat du déchiffrement y sera stocké après allocation.
Ben oui, c'est exactement ce que je fais...
Résumons.
- J'ai une table de chaînes chiffrées, donc constantes.
- J'ai une table de pointeurs sur des chaînes.
- Je lis une chaîne de la table chiffrée, j'alloue la mémoire pour la
version déchiffrée.
- Une fois déchiffrée, je mets à jour le pointeur correspondant dans
la table des pointeurs.
Bref, tu redécris exactement ce que je fais. Je pige pas ton
intervention.
Note au passage, que si je faisais ça en assembleur, j'utiliserai une
seule table, la table chiffrée, dans laquelle j'écraserai par les
chaînes déchiffrées les chaînes chiffrées. Gros gain de place.
Ben si tes chaines dechiffrées sont plus longues que les chiffrées tu
retombes sur le même probleme. De plus si le compilo place les chaines
chiffrées constantes dans un segment readonly tu pourras pas les modifier,
que ce soit C ou assembleur (sauf hack).
ret decrypt(const char* inStr, size_t inLen, char*[*] outStr);
Ben oui, c'est exactement ce que je fais...
dès lors les chaines chiffrées n'ont pas besoin d'être recopiées dans un élément de 'tab', au contraire ce tableau sera initialisé avec des null et le résultat du déchiffrement y sera stocké après allocation.
Ben oui, c'est exactement ce que je fais...
Résumons.
- J'ai une table de chaînes chiffrées, donc constantes. - J'ai une table de pointeurs sur des chaînes. - Je lis une chaîne de la table chiffrée, j'alloue la mémoire pour la version déchiffrée. - Une fois déchiffrée, je mets à jour le pointeur correspondant dans la table des pointeurs.
Bref, tu redécris exactement ce que je fais. Je pige pas ton intervention.
Note au passage, que si je faisais ça en assembleur, j'utiliserai une seule table, la table chiffrée, dans laquelle j'écraserai par les chaînes déchiffrées les chaînes chiffrées. Gros gain de place.
Ben si tes chaines dechiffrées sont plus longues que les chiffrées tu retombes sur le même probleme. De plus si le compilo place les chaines chiffrées constantes dans un segment readonly tu pourras pas les modifier, que ce soit C ou assembleur (sauf hack).
Sylvain
Arnold McDonald (AMcD) wrote on 10/05/2007 14:18:
Bref, tu redécris exactement ce que je fais. Je pige pas ton intervention.
mon intervention est basée sur ce que tu as posté:
PTCHAR p = new TCHAR[20]; lstrcpy(p,TEXT("héhé"));
où "héhé" existe en data et ne mérite pas (ne semble pas mériter) d'être dupliqué.
elle ne se base pas sur ce que tu n'as pas posté (mais fait déjà peut être).
Note au passage, que si je faisais ça en assembleur, j'utiliserai une seule table, la table chiffrée, dans laquelle j'écraserai par les chaînes déchiffrées les chaînes chiffrées. Gros gain de place.
selon dépends de l'algo (nécessité de chainage ou non), de son implémentation (le chainage peut être réalisé par des vecteurs sur la pile) et des attributs des segments RO ou RW; cela ne dépends pas vraiment du langage.
Soit tu dupliques la table originale, mais en ce cas, il faut créer dès le départ une table "ghost" de la chiffrée et tu te contentes donc de doubler la place mémoire. Soit tu utilises une table de pointeur vers les chaînes allouées
soit, encore, tu déchiffres sur la pile quand tu en as besoin, ne gardant qu'un bloc chiffré en data const. soit tu charges le bloc chiffré depuis des ressources et tu le déchiffres (globalement d'ailleurs, pas string par string) sur place (le bloc est spontanément RW dans ce cas).
donc tu consommes 2 tables (bah vi, les chaînes allouées, ça prends la même place que les chiffrées :p) plus la table de pointeurs.
euh, en rot13 ? généralement le chiffré prends plus de place pour le padding imposé par l'algo.
Sylvain.
Arnold McDonald (AMcD) wrote on 10/05/2007 14:18:
Bref, tu redécris exactement ce que je fais. Je pige pas ton intervention.
mon intervention est basée sur ce que tu as posté:
PTCHAR p = new TCHAR[20];
lstrcpy(p,TEXT("héhé"));
où "héhé" existe en data et ne mérite pas (ne semble pas mériter) d'être
dupliqué.
elle ne se base pas sur ce que tu n'as pas posté (mais fait déjà peut être).
Note au passage, que si je faisais ça en assembleur, j'utiliserai une seule
table, la table chiffrée, dans laquelle j'écraserai par les chaînes
déchiffrées les chaînes chiffrées. Gros gain de place.
selon dépends de l'algo (nécessité de chainage ou non), de son
implémentation (le chainage peut être réalisé par des vecteurs sur la
pile) et des attributs des segments RO ou RW; cela ne dépends pas
vraiment du langage.
Soit tu dupliques la table originale, mais en
ce cas, il faut créer dès le départ une table "ghost" de la chiffrée et tu
te contentes donc de doubler la place mémoire. Soit tu utilises une table de
pointeur vers les chaînes allouées
soit, encore, tu déchiffres sur la pile quand tu en as besoin, ne
gardant qu'un bloc chiffré en data const.
soit tu charges le bloc chiffré depuis des ressources et tu le
déchiffres (globalement d'ailleurs, pas string par string) sur place (le
bloc est spontanément RW dans ce cas).
donc tu consommes 2 tables (bah vi, les chaînes allouées, ça prends
la même place que les chiffrées :p) plus la table de pointeurs.
euh, en rot13 ? généralement le chiffré prends plus de place pour le
padding imposé par l'algo.
Bref, tu redécris exactement ce que je fais. Je pige pas ton intervention.
mon intervention est basée sur ce que tu as posté:
PTCHAR p = new TCHAR[20]; lstrcpy(p,TEXT("héhé"));
où "héhé" existe en data et ne mérite pas (ne semble pas mériter) d'être dupliqué.
elle ne se base pas sur ce que tu n'as pas posté (mais fait déjà peut être).
Note au passage, que si je faisais ça en assembleur, j'utiliserai une seule table, la table chiffrée, dans laquelle j'écraserai par les chaînes déchiffrées les chaînes chiffrées. Gros gain de place.
selon dépends de l'algo (nécessité de chainage ou non), de son implémentation (le chainage peut être réalisé par des vecteurs sur la pile) et des attributs des segments RO ou RW; cela ne dépends pas vraiment du langage.
Soit tu dupliques la table originale, mais en ce cas, il faut créer dès le départ une table "ghost" de la chiffrée et tu te contentes donc de doubler la place mémoire. Soit tu utilises une table de pointeur vers les chaînes allouées
soit, encore, tu déchiffres sur la pile quand tu en as besoin, ne gardant qu'un bloc chiffré en data const. soit tu charges le bloc chiffré depuis des ressources et tu le déchiffres (globalement d'ailleurs, pas string par string) sur place (le bloc est spontanément RW dans ce cas).
donc tu consommes 2 tables (bah vi, les chaînes allouées, ça prends la même place que les chiffrées :p) plus la table de pointeurs.
euh, en rot13 ? généralement le chiffré prends plus de place pour le padding imposé par l'algo.
Sylvain.
Arnold McDonald \(AMcD\)
Sylvain wrote:
mon intervention est basée sur ce que tu as posté:
On s'arrange toujours pour poster un exemple reproduisant le bug le plus simplement possible. Si je devais poster le code réel, ça prendrait des centaines de lignes...
elle ne se base pas sur ce que tu n'as pas posté (mais fait déjà peut être).
Posté ou pas, j'ai détaillé.
selon dépends de l'algo (nécessité de chainage ou non), de son implémentation (le chainage peut être réalisé par des vecteurs sur la pile) et des attributs des segments RO ou RW; cela ne dépends pas vraiment du langage.
À peine... La moitié de ce que je code habituellement, n'y songe même pas une minute en dehors de langages comme le C ou l'ASM... En assembleur, ça me prend 5 lignes d'écrire où je veux comme je veux quand je veux. En C#, heu...
soit tu charges le bloc chiffré depuis des ressources
Si c'est en ressources, c'est vachement discret ! Inutile de s'emmerder à chiffrer à ce compte là...
euh, en rot13 ? généralement le chiffré prends plus de place pour le padding imposé par l'algo.
Généralement ? Il existe des centaines d'algorithmes qui laissent la taille inchangée, du clair et du chiffré.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Sylvain wrote:
mon intervention est basée sur ce que tu as posté:
On s'arrange toujours pour poster un exemple reproduisant le bug le plus
simplement possible. Si je devais poster le code réel, ça prendrait des
centaines de lignes...
elle ne se base pas sur ce que tu n'as pas posté (mais fait déjà peut
être).
Posté ou pas, j'ai détaillé.
selon dépends de l'algo (nécessité de chainage ou non), de son
implémentation (le chainage peut être réalisé par des vecteurs sur la
pile) et des attributs des segments RO ou RW; cela ne dépends pas
vraiment du langage.
À peine... La moitié de ce que je code habituellement, n'y songe même pas
une minute en dehors de langages comme le C ou l'ASM... En assembleur, ça me
prend 5 lignes d'écrire où je veux comme je veux quand je veux. En C#,
heu...
soit tu charges le bloc chiffré depuis des ressources
Si c'est en ressources, c'est vachement discret ! Inutile de s'emmerder à
chiffrer à ce compte là...
euh, en rot13 ? généralement le chiffré prends plus de place pour le
padding imposé par l'algo.
Généralement ? Il existe des centaines d'algorithmes qui laissent la taille
inchangée, du clair et du chiffré.
mon intervention est basée sur ce que tu as posté:
On s'arrange toujours pour poster un exemple reproduisant le bug le plus simplement possible. Si je devais poster le code réel, ça prendrait des centaines de lignes...
elle ne se base pas sur ce que tu n'as pas posté (mais fait déjà peut être).
Posté ou pas, j'ai détaillé.
selon dépends de l'algo (nécessité de chainage ou non), de son implémentation (le chainage peut être réalisé par des vecteurs sur la pile) et des attributs des segments RO ou RW; cela ne dépends pas vraiment du langage.
À peine... La moitié de ce que je code habituellement, n'y songe même pas une minute en dehors de langages comme le C ou l'ASM... En assembleur, ça me prend 5 lignes d'écrire où je veux comme je veux quand je veux. En C#, heu...
soit tu charges le bloc chiffré depuis des ressources
Si c'est en ressources, c'est vachement discret ! Inutile de s'emmerder à chiffrer à ce compte là...
euh, en rot13 ? généralement le chiffré prends plus de place pour le padding imposé par l'algo.
Généralement ? Il existe des centaines d'algorithmes qui laissent la taille inchangée, du clair et du chiffré.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Vincent Burel
"Arnold McDonald (AMcD)" wrote in message news:46432178$0$30313$
Sylvain wrote:
> elle ne se base pas sur ce que tu n'as pas posté (mais fait déjà peut > être).
Posté ou pas, j'ai détaillé.
10 messages sans que ca parte en sucette ! quel suspens ! Alors que : - le sujet est chiant (la string). - y'a eu des petits pics genre "tu vieillis" etc... - y'a eu des parenthèses polémiques "(déchiffrer in-place n'est que rarement le meilleur choix)". - y'a eu des questions moqueuses : "comment tu modifies des chaînes *statiques* ?" - y'a eu des tentatives de ridiculisation par usage de termes barbaro-pédantique, exemple : "...est de pouvoir utiliser des block-ciphers tel CBC" - l'un parle de ce qui n'a pas été posté. - l'autre assure qu'il ne voit pas le problème.
Y a tous les éléments pour faire un troll, alors qu'est ce qu'il se passe ? :-)
VB
"Arnold McDonald (AMcD)" <killspammers@free.fr> wrote in message
news:46432178$0$30313$426a34cc@news.free.fr...
Sylvain wrote:
> elle ne se base pas sur ce que tu n'as pas posté (mais fait déjà peut
> être).
Posté ou pas, j'ai détaillé.
10 messages sans que ca parte en sucette ! quel suspens !
Alors que :
- le sujet est chiant (la string).
- y'a eu des petits pics genre "tu vieillis" etc...
- y'a eu des parenthèses polémiques "(déchiffrer in-place n'est que rarement
le meilleur choix)".
- y'a eu des questions moqueuses : "comment tu modifies des chaînes
*statiques* ?"
- y'a eu des tentatives de ridiculisation par usage de termes
barbaro-pédantique, exemple : "...est de pouvoir
utiliser des block-ciphers tel CBC"
- l'un parle de ce qui n'a pas été posté.
- l'autre assure qu'il ne voit pas le problème.
Y a tous les éléments pour faire un troll, alors qu'est ce qu'il se passe ?
:-)
"Arnold McDonald (AMcD)" wrote in message news:46432178$0$30313$
Sylvain wrote:
> elle ne se base pas sur ce que tu n'as pas posté (mais fait déjà peut > être).
Posté ou pas, j'ai détaillé.
10 messages sans que ca parte en sucette ! quel suspens ! Alors que : - le sujet est chiant (la string). - y'a eu des petits pics genre "tu vieillis" etc... - y'a eu des parenthèses polémiques "(déchiffrer in-place n'est que rarement le meilleur choix)". - y'a eu des questions moqueuses : "comment tu modifies des chaînes *statiques* ?" - y'a eu des tentatives de ridiculisation par usage de termes barbaro-pédantique, exemple : "...est de pouvoir utiliser des block-ciphers tel CBC" - l'un parle de ce qui n'a pas été posté. - l'autre assure qu'il ne voit pas le problème.
Y a tous les éléments pour faire un troll, alors qu'est ce qu'il se passe ? :-)
VB
Arnold McDonald \(AMcD\)
Vincent Burel wrote:
10 messages sans que ca parte en sucette !
Pourtant, je fais tout mon possible !
- y'a eu des petits pics genre "tu vieillis" etc...
Ouaip, ça... c'est inéluctable.
- y'a eu des questions moqueuses : "comment tu modifies des chaînes *statiques* ?"
Rhô. Tu crois que c'était moqueur :-) ?
- y'a eu des tentatives de ridiculisation par usage de termes barbaro-pédantique, exemple : "...est de pouvoir utiliser des block-ciphers tel CBC"
Non, ça va, après plus de 25 ans de crypto, jusque là j'arrive à suivre.
- l'un parle de ce qui n'a pas été posté.
Avec une mauvaise fois digne d'un homme politique ! Alors que j'ai isolé le problème sous une forme minimaliste digne des plus grands codeurs de packers.
Y a tous les éléments pour faire un troll, alors qu'est ce qu'il se passe ? :-)
Que veux-tu, ces djeuns baissent vite les armes. D'ailleurs, existe-t-il encore des djeuns qui codent ? Aujourdh'ui, avec tous ces cliquodromes...
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Vincent Burel wrote:
10 messages sans que ca parte en sucette !
Pourtant, je fais tout mon possible !
- y'a eu des petits pics genre "tu vieillis" etc...
Ouaip, ça... c'est inéluctable.
- y'a eu des questions moqueuses : "comment tu modifies des chaînes
*statiques* ?"
Rhô. Tu crois que c'était moqueur :-) ?
- y'a eu des tentatives de ridiculisation par usage de termes
barbaro-pédantique, exemple : "...est de pouvoir
utiliser des block-ciphers tel CBC"
Non, ça va, après plus de 25 ans de crypto, jusque là j'arrive à suivre.
- l'un parle de ce qui n'a pas été posté.
Avec une mauvaise fois digne d'un homme politique ! Alors que j'ai isolé le
problème sous une forme minimaliste digne des plus grands codeurs de
packers.
Y a tous les éléments pour faire un troll, alors qu'est ce qu'il se
passe ? :-)
Que veux-tu, ces djeuns baissent vite les armes. D'ailleurs, existe-t-il
encore des djeuns qui codent ? Aujourdh'ui, avec tous ces cliquodromes...
- y'a eu des petits pics genre "tu vieillis" etc...
Ouaip, ça... c'est inéluctable.
- y'a eu des questions moqueuses : "comment tu modifies des chaînes *statiques* ?"
Rhô. Tu crois que c'était moqueur :-) ?
- y'a eu des tentatives de ridiculisation par usage de termes barbaro-pédantique, exemple : "...est de pouvoir utiliser des block-ciphers tel CBC"
Non, ça va, après plus de 25 ans de crypto, jusque là j'arrive à suivre.
- l'un parle de ce qui n'a pas été posté.
Avec une mauvaise fois digne d'un homme politique ! Alors que j'ai isolé le problème sous une forme minimaliste digne des plus grands codeurs de packers.
Y a tous les éléments pour faire un troll, alors qu'est ce qu'il se passe ? :-)
Que veux-tu, ces djeuns baissent vite les armes. D'ailleurs, existe-t-il encore des djeuns qui codent ? Aujourdh'ui, avec tous ces cliquodromes...
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Sylvain
Vincent Burel wrote on 10/05/2007 17:15:
10 messages sans que ca parte en sucette ! quel suspens !
c'était vraiment pas le but.
Alors que : - le sujet est chiant (la string).
vrai
- y'a eu des petits pics genre "tu vieillis" etc...
mais non, c'est Arnie qui a titré ainsi dès le début.
- y'a eu des parenthèses polémiques "(déchiffrer in-place n'est que rarement le meilleur choix)".
pas de polémiques, un consensus (imposé par l'algo ou l'emplacement des données)
- y'a eu des questions moqueuses : "comment tu modifies des chaînes *statiques* ?"
c'est au contraire une vrai bonne question pratique, en asm on ferait cela spontanément!
- y'a eu des tentatives de ridiculisation par usage de termes barbaro-pédantique, exemple : "...est de pouvoir utiliser des block-ciphers tel CBC"
ceci est trivial pour Arnold et tenter de ridiculiser sa crypto serait perdu d'avance.
- l'un parle de ce qui n'a pas été posté.
pour m'excuser d'avoir (longgguement) décrit ce qui était évident.
- l'autre assure qu'il ne voit pas le problème.
un problème ? où ça ?
Y a tous les éléments pour faire un troll, alors qu'est ce qu'il se passe ?
+1
Sylvain.
Vincent Burel wrote on 10/05/2007 17:15:
10 messages sans que ca parte en sucette ! quel suspens !
c'était vraiment pas le but.
Alors que :
- le sujet est chiant (la string).
vrai
- y'a eu des petits pics genre "tu vieillis" etc...
mais non, c'est Arnie qui a titré ainsi dès le début.
- y'a eu des parenthèses polémiques "(déchiffrer in-place n'est que rarement
le meilleur choix)".
pas de polémiques, un consensus (imposé par l'algo ou l'emplacement des
données)
- y'a eu des questions moqueuses : "comment tu modifies des chaînes
*statiques* ?"
c'est au contraire une vrai bonne question pratique, en asm on ferait
cela spontanément!
- y'a eu des tentatives de ridiculisation par usage de termes
barbaro-pédantique, exemple : "...est de pouvoir
utiliser des block-ciphers tel CBC"
ceci est trivial pour Arnold et tenter de ridiculiser sa crypto serait
perdu d'avance.
- l'un parle de ce qui n'a pas été posté.
pour m'excuser d'avoir (longgguement) décrit ce qui était évident.
- l'autre assure qu'il ne voit pas le problème.
un problème ? où ça ?
Y a tous les éléments pour faire un troll, alors qu'est ce qu'il se passe ?
Que veux-tu, ces djeuns baissent vite les armes. D'ailleurs, existe-t-il encore des djeuns qui codent ? Aujourdh'ui, avec tous ces cliquodromes...
tu me rends au moins 15 jours, je crains (non, je suis content) que cela ne fasse pas de moins un tel djeun.
Sylvain.
Arnold McDonald \(AMcD\)
Sylvain wrote:
ceci est trivial pour Arnold
Laisse tomber, Vincent est en fait jaloux. Ce n'est qu'un technicien/codeur de traitement du son, tu sais. Deux, trois timer, un petit contrôle graphique, voilà son univers. Je le soupçonne même d'utiliser des DLLs propriétaires. Pouah.
Gnhihihihi.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Sylvain wrote:
ceci est trivial pour Arnold
Laisse tomber, Vincent est en fait jaloux. Ce n'est qu'un technicien/codeur
de traitement du son, tu sais. Deux, trois timer, un petit contrôle
graphique, voilà son univers. Je le soupçonne même d'utiliser des DLLs
propriétaires. Pouah.
Laisse tomber, Vincent est en fait jaloux. Ce n'est qu'un technicien/codeur de traitement du son, tu sais. Deux, trois timer, un petit contrôle graphique, voilà son univers. Je le soupçonne même d'utiliser des DLLs propriétaires. Pouah.
Gnhihihihi.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Sylvain
Arnold McDonald (AMcD) wrote on 10/05/2007 15:43:
cela ne dépends pas vraiment du langage.
À peine... [...]
je pensais: ne dépends pas du langage pour peu que ce soit un vrai langage, asm, c ou c++.
soit tu charges le bloc chiffré depuis des ressources
Si c'est en ressources, c'est vachement discret ! Inutile de s'emmerder à chiffrer à ce compte là...
si le but est de dissimuler le fait que des données sont présentes ce n'est p.e. pas la solution; si le but est seulement de dissimuler le clair de ses données, ça me va.
généralement le chiffré prends plus de place []
Généralement ? Il existe des centaines d'algorithmes qui laissent la taille inchangée, du clair et du chiffré.
des algos de permutation dignes de petit manuel initiatique alors :)))
Sylvain.
Arnold McDonald (AMcD) wrote on 10/05/2007 15:43:
cela ne dépends pas vraiment du langage.
À peine... [...]
je pensais: ne dépends pas du langage pour peu que ce soit un vrai
langage, asm, c ou c++.
soit tu charges le bloc chiffré depuis des ressources
Si c'est en ressources, c'est vachement discret ! Inutile de s'emmerder à
chiffrer à ce compte là...
si le but est de dissimuler le fait que des données sont présentes ce
n'est p.e. pas la solution; si le but est seulement de dissimuler le
clair de ses données, ça me va.
généralement le chiffré prends plus de place []
Généralement ? Il existe des centaines d'algorithmes qui laissent la taille
inchangée, du clair et du chiffré.
des algos de permutation dignes de petit manuel initiatique alors :)))
je pensais: ne dépends pas du langage pour peu que ce soit un vrai langage, asm, c ou c++.
soit tu charges le bloc chiffré depuis des ressources
Si c'est en ressources, c'est vachement discret ! Inutile de s'emmerder à chiffrer à ce compte là...
si le but est de dissimuler le fait que des données sont présentes ce n'est p.e. pas la solution; si le but est seulement de dissimuler le clair de ses données, ça me va.
généralement le chiffré prends plus de place []
Généralement ? Il existe des centaines d'algorithmes qui laissent la taille inchangée, du clair et du chiffré.
des algos de permutation dignes de petit manuel initiatique alors :)))
