Bonjour,
Il y a environ 2 ans, j'avais commencé à étudier le langage C mais j'ai
dû m'arrêter quelques temps après. J'ai donc beaucoup oublié de ce langage
C.
J'ai développé un nouvel algorithme de cryptage et cet algo doit faire
partie de la version 3.0 d'AllCrypter (version 3.0 dont les licences
d'utilisations qui seront accordées seront gratuites) qui sera disponible
gratuitement lorsque les 2 procédures VB (cryptage et décryptage) seront en
langage C dans une DLL chacune. Ces 2 procédures sont déjà en code VB et
fonctionnent très bien; mais il me reste à convertir en langage C (en DLL)
ces 2 procédures principales pour rendre leur exécution plus rapide qu'en
VB.
http://logicipc.no-ip.com/allcrypter/algorh2a.html (explication de l'algo)
http://logicipc.no-ip.com/allcrypter/algorh2b.html (code VB à convertir en
langage C pour une exécution plus rapide; 1re procédure en haut de la page
que j'ai copié ci-dessous.)
Je chercherais une personne poussée en langage C (utilisant des
pointeurs) qui pourrait m'aider à convertir cette procédure ci-dessous en C
pour compiler dans une DLL (j'ai déjà 'DEV C++') mais avec des pointeurs
puisque c'est la rapidité du code que je cherche avant tout. Tout est déjà
fait et il ne resterait qu'à le convertir fidèlement. Bien que ça puisse me
prendre quelques dizaines de minutes convertir en VB, cela est différent
pour moi de convertir en C car je n'ai pas la même expérience que le VB
(même si je sais que c'est plus simple en C; par exemple, les 8 lignes VB
pour l'inversion d'une chaîne de caractères n'en ferait peut-être qu'une
seule ligne en C (avec un appel); et la conversion d'un caractère VB en
ascii puis en valeur serait plus simple car, si je me souviens bien en C le
caractère est déjà au départ en ascii. Il faudrait que la DLL soit en C pur
pour être lu sous différentes plateformes et non seulement sous Windows.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Public Sub MoteurCryptData(VSa As String, VSb As String, VRep As Double,
VDat As String)
'Cette procédure VB doit être convertie en langage C pur pour une
plus grande rapidité d'exécution.
'=============== Procédure exécutant le chiffrement de chaque bloc
de données à crypter.
'VSa contient la 1re clef de session initiale.
'VSb contient la 2e clef de session initiale.
'VRep contient zéro (0) au départ.
'VDat contient les données à crypter.
Dim VLenVSa As Long
VLenVSa = Len(VSa)
Dim VLenDat As Long
VLenDat = Len(VDat)
Dim VXor As Integer, VXor2 As Integer
Dim V1A As Integer, V3A As Integer, V4A As Integer, V5A As Integer,
V2A As String
Dim VRép1 As Long
'--Inversion de la chaîne de caractères. Chaque groupe doit être lu
à partir de la fin jusqu'au début du fichier en question.
Dim VDemiLenVDat As Long
VDemiLenVDat = VLenDat / 2
Dim VDatTemp As String
For VRép1 = 1 To VDemiLenVDat
VDatTemp = Mid(VDat, VRép1, 1)
Mid(VDat, VRép1, 1) = Mid(VDat, VLenDat - VRép1 + 1, 1)
Mid(VDat, VLenDat - VRép1 + 1, 1) = VDatTemp
Next VRép1
VSa = VSa & Space(VLenDat)
VSb = VSb & Space(VLenDat) 'Idem.
'--Brouillement des données et prolongement des 2 clefs de session.
For VRép1 = 1 To VLenDat
'--Brouillement.
V2A = Right(Str(Asc(Mid(VSb, VRép1 + 3, 1))), 1)
V1A = Val(Right(Str(Asc(Mid(VSa, VRép1 + 1, 1))), 1) & V2A)
V3A = Val(Asc(Mid(VSb, VRép1 + 6 + Val(V2A), 1)))
V4A = Val(Asc(Mid(VDat, VRép1, 1)))
V5A = (V1A + V3A + VRep + V4A) Mod 256
Mid(VDat, VRép1, 1) = Chr(V5A)
VRep = VRep + 1
'--Prolongement des 2 clefs de session.
'-sa> = ((sa_1 + sa_7) Xor (sa_13 + m_1)) Mod 256
Mid(VSa, VLenVSa + VRép1, 1) = Chr(((Val(Asc(Mid(VSa, VRép1,
1))) + Val(Asc(Mid(VSa, VRép1 + 6, 1)))) Xor (Val(Asc(Mid(VSa, VRép1 + 12,
1))) + V5A)) Mod 256)
'-sb> = ((sb1 + sb3) Xor (sb5 + m1)) Mod 256
Mid(VSb, VLenVSa + VRép1, 1) = Chr(((Val(Asc(Mid(VSb, VRép1,
1))) + Val(Asc(Mid(VSb, VRép1 + 2, 1)))) Xor (Val(Asc(Mid(VSb, VRép1 + 4,
1))) + V5A)) Mod 256)
'--Xorer..
'm4_1 = ((sa_10> || sb_2>) xor (sa_17 + sb_6) xor m3_1) mod
256' .
VXor2 = V5A Xor Val(Right(Str(Asc(Mid(VSa, VRép1 + 9, 1))),
1) & Right(Str(Asc(Mid(VSb, VRép1 + 1, 1))), 1))
VXor = Val(Asc(Mid(VSa, VRép1 + 16, 1))) + Val(Asc(Mid(VSb,
VRép1 + 5, 1)))
Mid(VDat, VRép1, 1) = Chr((Val(VXor2) Xor Val(VXor)) Mod
256)
Next VRép1
VRep = VRep Mod 256
VSa = Right(VSa, VLenVSa)
VSb = Right(VSb, VLenVSa)
End Sub
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
a+
Raymond H.
www.allcrypter.com
contact@allcrypter.com
Avec le dialecte Basic de la machine que j'ai sous la main, Asc() retourne un nombre (entre 1 et 65535 disons), Str() retourne une chaîne commençant par un espace (pour le signe, ici positif) suivi de plusieurs caractères numériques, donc Right() retourne systématiquement le caractère espace. Autrement dit, ces deux instructions n'ont pour effet que d'assigner un espace à V2A, puis rabouter un autre espace devant V2A, soit " ", avant d'utiliser Val (qui plante, ou renvoie systématiquement 0).
Est-ce correct ?
V3A = Val(Asc(Mid(VSb, VRép1 + 6 + Val(V2A), 1)))
... me pose un problème quand VSb est initialement de longueur < 6
Antoine
En news:fk1ci2$u6b$1@talisker.lacave.net, Raymond H. va escriure:
Avec le dialecte Basic de la machine que j'ai sous la main, Asc() retourne
un nombre (entre 1 et 65535 disons), Str() retourne une chaîne commençant
par un espace (pour le signe, ici positif) suivi de plusieurs caractères
numériques, donc Right() retourne systématiquement le caractère espace.
Autrement dit, ces deux instructions n'ont pour effet que d'assigner un
espace à V2A, puis rabouter un autre espace devant V2A, soit " ", avant
d'utiliser Val (qui plante, ou renvoie systématiquement 0).
Est-ce correct ?
V3A = Val(Asc(Mid(VSb, VRép1 + 6 + Val(V2A), 1)))
... me pose un problème quand VSb est initialement de longueur < 6
Avec le dialecte Basic de la machine que j'ai sous la main, Asc() retourne un nombre (entre 1 et 65535 disons), Str() retourne une chaîne commençant par un espace (pour le signe, ici positif) suivi de plusieurs caractères numériques, donc Right() retourne systématiquement le caractère espace. Autrement dit, ces deux instructions n'ont pour effet que d'assigner un espace à V2A, puis rabouter un autre espace devant V2A, soit " ", avant d'utiliser Val (qui plante, ou renvoie systématiquement 0).
Est-ce correct ?
V3A = Val(Asc(Mid(VSb, VRép1 + 6 + Val(V2A), 1)))
... me pose un problème quand VSb est initialement de longueur < 6
Antoine
Antoine Leca
En news:fk1ci2$u6b$, Raymond H. va escriure:
Je chercherais une personne poussée en langage C [Anastasie]
Ces 2 procédures sont déjà en code VB et fonctionnent très bien; mais il me reste à convertir en langage C (en DLL) ces 2 procédures principales pour rendre leur exécution plus rapide qu'en VB.
<NOTES> Préalable : je me suis initialement vautré un peu en interprétant Gauche() alors que le code disait Right()... 8-< Cette erreur-là devrait être oubliée (confus sur le coup, N'Antoine)
Décharge 1 : je ne suis pas « poussée » Décharge 2 : je n'ai vu qu'une seule procédure Décharge 3 : c'est la première fois que je code du code cryptographique, pas taper (ou pas trop fort) Décahrge 4 : il est évident qu'il faut améliorer ce code en vue de l'utiliser en cryptographie; à tout le moins, il faudrait empêcher les tampons de se perdre dans le swap... et tout plein d'autres choses qui ne sont pas le sujet ici Décharge 5 : ce code n'est pas testé, je n'ai même pas essayé de l'exécuter « pour voir » (surtout parce que je ne comprend rien à la manière de le faire fonctionner)
Remarque 1 : plutôt que de prolonger au-delà du raisonnable les « clés de session » en mémoire, j'ai basculé les « clés initiales » dans un tampon, puisqu'il me semble qu'il s'agit en fait d'un simple chiffre de flux. Remarque 2 : le retournement en place est consommateur de ressources CPU, et en plus [surtout?] cela risque de déborder du cache. Une autre manière plus habile serait de faire un chiffre vers un autre tampon, en commençant par la fin du bloc à chiffrer (seconde boucle for(;;) parcourue à l'envers).
if( !VLenDat || !VDat ) /* non au boulot inutile */ return;
/* Note: on alloue un octet de plus que la longueur de clé, * pour pouvoir y stocker la valeur « suivante » qui sera générée; * ensuite on décalera d'un le bloc */ if( VLenVS<16 || !(Sa=malloc(VLenVS+1)) || !(Sb=malloc(VLenVS+1)) ) { /*traitement d'erreur, throw, comme on veut...*/ longjmp(env, ERR_MOTEUR); return; }
/* Inversion de la chaîne de caractères. */ for( p=&VDat[0], q=&VDat[VLenDat-1] ; p<q ; ) { *p ^= *q; *q ^= *p; *p++ ^= *q--; }
/* Décalage */ memmove(Sa, Sa+1, VLenVS); memmove(Sb, Sb+1, VLenVS); } *VRep &= 0xFF; /* juste pour faire comme le code original */ free(Sa); free(Sb); }
En news:fk1ci2$u6b$1@talisker.lacave.net, Raymond H. va escriure:
Je chercherais une personne poussée en langage C
[Anastasie]
Ces 2 procédures sont déjà en code VB et fonctionnent très bien;
mais il me reste à convertir en langage C (en DLL)
ces 2 procédures principales pour rendre leur exécution plus
rapide qu'en VB.
<NOTES>
Préalable : je me suis initialement vautré un peu en interprétant Gauche()
alors que le code disait Right()... 8-< Cette erreur-là devrait être oubliée
(confus sur le coup, N'Antoine)
Décharge 1 : je ne suis pas « poussée »
Décharge 2 : je n'ai vu qu'une seule procédure
Décharge 3 : c'est la première fois que je code du code cryptographique, pas
taper (ou pas trop fort)
Décahrge 4 : il est évident qu'il faut améliorer ce code en vue de
l'utiliser en cryptographie; à tout le moins, il faudrait empêcher les
tampons de se perdre dans le swap... et tout plein d'autres choses qui ne
sont pas le sujet ici
Décharge 5 : ce code n'est pas testé, je n'ai même pas essayé de l'exécuter
« pour voir » (surtout parce que je ne comprend rien à la manière de le
faire fonctionner)
Remarque 1 : plutôt que de prolonger au-delà du raisonnable les « clés de
session » en mémoire, j'ai basculé les « clés initiales » dans un tampon,
puisqu'il me semble qu'il s'agit en fait d'un simple chiffre de flux.
Remarque 2 : le retournement en place est consommateur de ressources CPU, et
en plus [surtout?] cela risque de déborder du cache. Une autre manière plus
habile serait de faire un chiffre vers un autre tampon, en commençant par la
fin du bloc à chiffrer (seconde boucle for(;;) parcourue à l'envers).
if( !VLenDat || !VDat )
/* non au boulot inutile */
return;
/* Note: on alloue un octet de plus que la longueur de clé,
* pour pouvoir y stocker la valeur « suivante » qui sera générée;
* ensuite on décalera d'un le bloc
*/
if( VLenVS<16
|| !(Sa=malloc(VLenVS+1)) || !(Sb=malloc(VLenVS+1)) ) {
/*traitement d'erreur, throw, comme on veut...*/
longjmp(env, ERR_MOTEUR);
return;
}
/* Inversion de la chaîne de caractères. */
for( p=&VDat[0], q=&VDat[VLenDat-1] ; p<q ; ) {
*p ^= *q; *q ^= *p; *p++ ^= *q--;
}
/* Décalage */
memmove(Sa, Sa+1, VLenVS);
memmove(Sb, Sb+1, VLenVS);
}
*VRep &= 0xFF; /* juste pour faire comme le code original */
free(Sa);
free(Sb);
}
Je chercherais une personne poussée en langage C [Anastasie]
Ces 2 procédures sont déjà en code VB et fonctionnent très bien; mais il me reste à convertir en langage C (en DLL) ces 2 procédures principales pour rendre leur exécution plus rapide qu'en VB.
<NOTES> Préalable : je me suis initialement vautré un peu en interprétant Gauche() alors que le code disait Right()... 8-< Cette erreur-là devrait être oubliée (confus sur le coup, N'Antoine)
Décharge 1 : je ne suis pas « poussée » Décharge 2 : je n'ai vu qu'une seule procédure Décharge 3 : c'est la première fois que je code du code cryptographique, pas taper (ou pas trop fort) Décahrge 4 : il est évident qu'il faut améliorer ce code en vue de l'utiliser en cryptographie; à tout le moins, il faudrait empêcher les tampons de se perdre dans le swap... et tout plein d'autres choses qui ne sont pas le sujet ici Décharge 5 : ce code n'est pas testé, je n'ai même pas essayé de l'exécuter « pour voir » (surtout parce que je ne comprend rien à la manière de le faire fonctionner)
Remarque 1 : plutôt que de prolonger au-delà du raisonnable les « clés de session » en mémoire, j'ai basculé les « clés initiales » dans un tampon, puisqu'il me semble qu'il s'agit en fait d'un simple chiffre de flux. Remarque 2 : le retournement en place est consommateur de ressources CPU, et en plus [surtout?] cela risque de déborder du cache. Une autre manière plus habile serait de faire un chiffre vers un autre tampon, en commençant par la fin du bloc à chiffrer (seconde boucle for(;;) parcourue à l'envers).
if( !VLenDat || !VDat ) /* non au boulot inutile */ return;
/* Note: on alloue un octet de plus que la longueur de clé, * pour pouvoir y stocker la valeur « suivante » qui sera générée; * ensuite on décalera d'un le bloc */ if( VLenVS<16 || !(Sa=malloc(VLenVS+1)) || !(Sb=malloc(VLenVS+1)) ) { /*traitement d'erreur, throw, comme on veut...*/ longjmp(env, ERR_MOTEUR); return; }
/* Inversion de la chaîne de caractères. */ for( p=&VDat[0], q=&VDat[VLenDat-1] ; p<q ; ) { *p ^= *q; *q ^= *p; *p++ ^= *q--; }
/* Décalage */ memmove(Sa, Sa+1, VLenVS); memmove(Sb, Sb+1, VLenVS); } *VRep &= 0xFF; /* juste pour faire comme le code original */ free(Sa); free(Sb); }
Antoine Leca
<HORS-SUJET>
En news:fk5p0d$16p1$, Marc Espie va escriure:
Vous n'avez toujours pas repondu a ma principale objection: si aujourd'hui vous voulez publier un algo cryptographique, il faut le faire face a un public international, donc en anglais,
Pas d'accord. *Avant* de publier face à un public international, on *peut* proposer son truc à un public essentiellement francophone (ou russophone, ou sinophone, ce n'est pas le propos de faire de du cocorico), lequel a probablement suffisament de compétence pour faire le tri et donner des conseils utiles. Un public « international », c'est tout de suite beaucoup plus de cacophonie, des gens qui ne s'expriment pas dans leurs langues maternelles donc ont plus de difficultés à s'exprimer donc dont la contribution est pus difficile à appréhender, etc.
Évidemment, il faut aussi pour l'auteur savoir écouter...
et avec une diffusion moins anecdotique que usenet.
Là oui, je suis d'accord, en général Usenet n'est pas le bon endroit pour discuter de sujets de Recherche... :-)
</HORS-SUJET>
Et j'encouragerai *fortement* les gens qui passent par ici a faire des trucs interessants en C, plus utiles que convertir un mauvais algo de crypto de VB en C...
D'un autre côté, il peut être utile aux cryptologues de pouvoir évaluer l'algorithme par eux-mêmes (cf. la remarque préalable de M. Henry sur le fait qu'une version antérieure dépassait ses capacités d'analyses mathématiques pures); avec une implémentation, on peut faire facilement des tests bêtes et c*ns. Et une implémentation en C, c'est plus facile à réutiliser qu'une écrite en VB.
En plus, et dans ce cas particulier, en réécrivant l'algorithme on peut éventuellement le simplifier ; en l'occurence je crois que ce à quoi je suis arrivé est sensiblement plus _simple_ que le code initial en VB ; ÀMHA, évidemment.
Antoine
<HORS-SUJET>
En news:fk5p0d$16p1$1@biggoron.nerim.net, Marc Espie va escriure:
Vous n'avez toujours pas repondu a ma principale objection: si
aujourd'hui vous voulez publier un algo cryptographique, il faut le
faire face a un public international, donc en anglais,
Pas d'accord.
*Avant* de publier face à un public international, on *peut* proposer son
truc à un public essentiellement francophone (ou russophone, ou sinophone,
ce n'est pas le propos de faire de du cocorico), lequel a probablement
suffisament de compétence pour faire le tri et donner des conseils utiles.
Un public « international », c'est tout de suite beaucoup plus de
cacophonie, des gens qui ne s'expriment pas dans leurs langues maternelles
donc ont plus de difficultés à s'exprimer donc dont la contribution est pus
difficile à appréhender, etc.
Évidemment, il faut aussi pour l'auteur savoir écouter...
et avec une diffusion moins anecdotique que usenet.
Là oui, je suis d'accord, en général Usenet n'est pas le bon endroit pour
discuter de sujets de Recherche... :-)
</HORS-SUJET>
Et j'encouragerai *fortement* les gens qui passent par ici a faire des
trucs interessants en C, plus utiles que convertir un mauvais algo de
crypto de VB en C...
D'un autre côté, il peut être utile aux cryptologues de pouvoir évaluer
l'algorithme par eux-mêmes (cf. la remarque préalable de M. Henry sur le
fait qu'une version antérieure dépassait ses capacités d'analyses
mathématiques pures); avec une implémentation, on peut faire facilement des
tests bêtes et c*ns.
Et une implémentation en C, c'est plus facile à réutiliser qu'une écrite en
VB.
En plus, et dans ce cas particulier, en réécrivant l'algorithme on peut
éventuellement le simplifier ; en l'occurence je crois que ce à quoi je suis
arrivé est sensiblement plus _simple_ que le code initial en VB ; ÀMHA,
évidemment.
Vous n'avez toujours pas repondu a ma principale objection: si aujourd'hui vous voulez publier un algo cryptographique, il faut le faire face a un public international, donc en anglais,
Pas d'accord. *Avant* de publier face à un public international, on *peut* proposer son truc à un public essentiellement francophone (ou russophone, ou sinophone, ce n'est pas le propos de faire de du cocorico), lequel a probablement suffisament de compétence pour faire le tri et donner des conseils utiles. Un public « international », c'est tout de suite beaucoup plus de cacophonie, des gens qui ne s'expriment pas dans leurs langues maternelles donc ont plus de difficultés à s'exprimer donc dont la contribution est pus difficile à appréhender, etc.
Évidemment, il faut aussi pour l'auteur savoir écouter...
et avec une diffusion moins anecdotique que usenet.
Là oui, je suis d'accord, en général Usenet n'est pas le bon endroit pour discuter de sujets de Recherche... :-)
</HORS-SUJET>
Et j'encouragerai *fortement* les gens qui passent par ici a faire des trucs interessants en C, plus utiles que convertir un mauvais algo de crypto de VB en C...
D'un autre côté, il peut être utile aux cryptologues de pouvoir évaluer l'algorithme par eux-mêmes (cf. la remarque préalable de M. Henry sur le fait qu'une version antérieure dépassait ses capacités d'analyses mathématiques pures); avec une implémentation, on peut faire facilement des tests bêtes et c*ns. Et une implémentation en C, c'est plus facile à réutiliser qu'une écrite en VB.
En plus, et dans ce cas particulier, en réécrivant l'algorithme on peut éventuellement le simplifier ; en l'occurence je crois que ce à quoi je suis arrivé est sensiblement plus _simple_ que le code initial en VB ; ÀMHA, évidemment.
Antoine
Sylvain
Antoine Leca wrote on 17/12/2007 17:56:
<HORS-SUJET>
En news:fk5p0d$16p1$, Marc Espie va escriure:
Vous n'avez toujours pas repondu a ma principale objection: si aujourd'hui vous voulez publier un algo cryptographique, il faut le faire face a un public international, donc en anglais,
Pas d'accord. *Avant* de publier face à un public international, on *peut* proposer son truc à un public essentiellement francophone [...]
si le but était de proposer quelque de neuf et intéressant, oui.
mais sans chercher à préter une intention particulière à RH - et prenons ce point comme "en général" - on voit hélas souvent des inventeurs venir chercher qu'une reconnaissance / valorisation; quelque soit de prestige en espérant les bravos d'experts ou technique par la contribution volontaire et spontanée de techniciens.
dès lors leur attente n'est pas celle du dialogue, de la remise en cause, et leur motivation, assez souvent mercantile, ne peut pas trouvé de réponses sur usenet (un espace de dialogue).
Et j'encouragerai *fortement* les gens qui passent par ici a faire des trucs interessants en C, plus utiles que convertir un mauvais algo de crypto de VB en C...
D'un autre côté, il peut être utile aux cryptologues de pouvoir évaluer l'algorithme par eux-mêmes [...]
ce qui aurait du modifier l'auteur a s'initier lui même au C.
En plus, et dans ce cas particulier, en réécrivant l'algorithme on peut éventuellement le simplifier ; en l'occurence je crois que ce à quoi je suis arrivé est sensiblement plus _simple_ que le code initial en VB ; ÀMHA, évidemment.
le simplifier certes, se rendre compte de ce que l'on fait encore plus. par exemple: le PO cherche une traduction en C parce que les mauvaises perfs actuelles "ne sont que" dû à l'écriture actuelle en VB - le langage devenant le bouc-émissaire de ces défauts, on s'affranchit d'une véritable analyse.
Sylvain.
Antoine Leca wrote on 17/12/2007 17:56:
<HORS-SUJET>
En news:fk5p0d$16p1$1@biggoron.nerim.net, Marc Espie va escriure:
Vous n'avez toujours pas repondu a ma principale objection: si
aujourd'hui vous voulez publier un algo cryptographique, il faut le
faire face a un public international, donc en anglais,
Pas d'accord.
*Avant* de publier face à un public international, on *peut* proposer son
truc à un public essentiellement francophone [...]
si le but était de proposer quelque de neuf et intéressant, oui.
mais sans chercher à préter une intention particulière à RH - et prenons
ce point comme "en général" - on voit hélas souvent des inventeurs venir
chercher qu'une reconnaissance / valorisation; quelque soit de prestige
en espérant les bravos d'experts ou technique par la contribution
volontaire et spontanée de techniciens.
dès lors leur attente n'est pas celle du dialogue, de la remise en
cause, et leur motivation, assez souvent mercantile, ne peut pas trouvé
de réponses sur usenet (un espace de dialogue).
Et j'encouragerai *fortement* les gens qui passent par ici a faire des
trucs interessants en C, plus utiles que convertir un mauvais algo de
crypto de VB en C...
D'un autre côté, il peut être utile aux cryptologues de pouvoir évaluer
l'algorithme par eux-mêmes [...]
ce qui aurait du modifier l'auteur a s'initier lui même au C.
En plus, et dans ce cas particulier, en réécrivant l'algorithme on peut
éventuellement le simplifier ; en l'occurence je crois que ce à quoi je suis
arrivé est sensiblement plus _simple_ que le code initial en VB ; ÀMHA,
évidemment.
le simplifier certes, se rendre compte de ce que l'on fait encore plus.
par exemple: le PO cherche une traduction en C parce que les mauvaises
perfs actuelles "ne sont que" dû à l'écriture actuelle en VB - le
langage devenant le bouc-émissaire de ces défauts, on s'affranchit d'une
véritable analyse.
Vous n'avez toujours pas repondu a ma principale objection: si aujourd'hui vous voulez publier un algo cryptographique, il faut le faire face a un public international, donc en anglais,
Pas d'accord. *Avant* de publier face à un public international, on *peut* proposer son truc à un public essentiellement francophone [...]
si le but était de proposer quelque de neuf et intéressant, oui.
mais sans chercher à préter une intention particulière à RH - et prenons ce point comme "en général" - on voit hélas souvent des inventeurs venir chercher qu'une reconnaissance / valorisation; quelque soit de prestige en espérant les bravos d'experts ou technique par la contribution volontaire et spontanée de techniciens.
dès lors leur attente n'est pas celle du dialogue, de la remise en cause, et leur motivation, assez souvent mercantile, ne peut pas trouvé de réponses sur usenet (un espace de dialogue).
Et j'encouragerai *fortement* les gens qui passent par ici a faire des trucs interessants en C, plus utiles que convertir un mauvais algo de crypto de VB en C...
D'un autre côté, il peut être utile aux cryptologues de pouvoir évaluer l'algorithme par eux-mêmes [...]
ce qui aurait du modifier l'auteur a s'initier lui même au C.
En plus, et dans ce cas particulier, en réécrivant l'algorithme on peut éventuellement le simplifier ; en l'occurence je crois que ce à quoi je suis arrivé est sensiblement plus _simple_ que le code initial en VB ; ÀMHA, évidemment.
le simplifier certes, se rendre compte de ce que l'on fait encore plus. par exemple: le PO cherche une traduction en C parce que les mauvaises perfs actuelles "ne sont que" dû à l'écriture actuelle en VB - le langage devenant le bouc-émissaire de ces défauts, on s'affranchit d'une véritable analyse.
Sylvain.
Sylvain
Antoine Leca wrote on 17/12/2007 17:03:
Remarque 1 : plutôt que de prolonger au-delà du raisonnable les « clés de session » en mémoire, j'ai basculé les « clés initiales » dans un tampon, puisqu'il me semble qu'il s'agit en fait d'un *simple chiffre de flux*. Remarque 2 : le *retournement* en place est consommateur de ressources CPU, et en plus [surtout?] cela risque de déborder du cache. Une autre manière plus habile serait de faire un chiffre vers un autre tampon, en commençant par la fin du bloc à chiffrer (seconde boucle for(;;) parcourue à l'envers).
un chiffrement de flux à retourner, ça donne quoi ? pour déchiffrer à la volée, on réceptionne en remontant le temps ? pour lire le début d'un DVD on fait quoi des 4Go inutilement retournés ?
Sylvain.
Antoine Leca wrote on 17/12/2007 17:03:
Remarque 1 : plutôt que de prolonger au-delà du raisonnable les « clés de
session » en mémoire, j'ai basculé les « clés initiales » dans un tampon,
puisqu'il me semble qu'il s'agit en fait d'un *simple chiffre de flux*.
Remarque 2 : le *retournement* en place est consommateur de ressources CPU, et
en plus [surtout?] cela risque de déborder du cache. Une autre manière plus
habile serait de faire un chiffre vers un autre tampon, en commençant par la
fin du bloc à chiffrer (seconde boucle for(;;) parcourue à l'envers).
un chiffrement de flux à retourner, ça donne quoi ?
pour déchiffrer à la volée, on réceptionne en remontant le temps ?
pour lire le début d'un DVD on fait quoi des 4Go inutilement retournés ?
Remarque 1 : plutôt que de prolonger au-delà du raisonnable les « clés de session » en mémoire, j'ai basculé les « clés initiales » dans un tampon, puisqu'il me semble qu'il s'agit en fait d'un *simple chiffre de flux*. Remarque 2 : le *retournement* en place est consommateur de ressources CPU, et en plus [surtout?] cela risque de déborder du cache. Une autre manière plus habile serait de faire un chiffre vers un autre tampon, en commençant par la fin du bloc à chiffrer (seconde boucle for(;;) parcourue à l'envers).
un chiffrement de flux à retourner, ça donne quoi ? pour déchiffrer à la volée, on réceptionne en remontant le temps ? pour lire le début d'un DVD on fait quoi des 4Go inutilement retournés ?
Sylvain.
Antoine Leca
En news:4766cf86$0$889$, Sylvain va escriure:
Antoine Leca wrote on 17/12/2007 17:56:
En plus, et dans ce cas particulier, en réécrivant l'algorithme on peut éventuellement le simplifier ; en l'occurence je crois que ce à quoi je suis arrivé est sensiblement plus _simple_ que le code initial en VB ; ÀMHA, évidemment.
le simplifier certes, se rendre compte de ce que l'on fait encore plus.
Pouvez-vous expliciter votre propos, j'ai peur de comprendre.
par exemple: le PO cherche une traduction en C parce que les mauvaises perfs actuelles "ne sont que" dû à l'écriture actuelle en VB - le langage devenant le bouc-émissaire de ces défauts, on s'affranchit d'une véritable analyse.
C'est bien possible, et c'est en tous cas un point que j'ai présupposé dans ma démarche. Mais je ne suis pas sûr d'en tirer les mêmes conclusions que vous. En effet, si le langage ou la formulation utilisés sont des obstacles pour que les cryptologues sérieux comme vous puissent analyser l'algorithme, en quoi le fait de mettre à votre disposition un code plus facile à manipuler serait-il un problème ? Au cas où ce ne serait pas évident, je précise que vous êtes libres de réutiliser le code que j'ai pondu pour effectuer des tests ; vous pouvez même considérer que le dit code est sous GPL, si vous voulez, histoire de freiner un peu les aspects mercantilistes.
Évidemment, il est inutile d'attendre que le PO fasse lui-même de telles recherches. Comme vous l'avez très bien rappelé au début de ce fil, avec les références à ce qui s'est passé en 2004.
Antoine
En news:4766cf86$0$889$ba4acef3@news.orange.fr, Sylvain va escriure:
Antoine Leca wrote on 17/12/2007 17:56:
En plus, et dans ce cas particulier, en réécrivant l'algorithme on
peut éventuellement le simplifier ; en l'occurence je crois que ce à
quoi je suis arrivé est sensiblement plus _simple_ que le code
initial en VB ; ÀMHA, évidemment.
le simplifier certes, se rendre compte de ce que l'on fait encore
plus.
Pouvez-vous expliciter votre propos, j'ai peur de comprendre.
par exemple: le PO cherche une traduction en C parce que les mauvaises
perfs actuelles "ne sont que" dû à l'écriture actuelle en VB - le
langage devenant le bouc-émissaire de ces défauts, on s'affranchit
d'une véritable analyse.
C'est bien possible, et c'est en tous cas un point que j'ai présupposé dans
ma démarche.
Mais je ne suis pas sûr d'en tirer les mêmes conclusions que vous. En effet,
si le langage ou la formulation utilisés sont des obstacles pour que les
cryptologues sérieux comme vous puissent analyser l'algorithme, en quoi le
fait de mettre à votre disposition un code plus facile à manipuler serait-il
un problème ?
Au cas où ce ne serait pas évident, je précise que vous êtes libres de
réutiliser le code que j'ai pondu pour effectuer des tests ; vous pouvez
même considérer que le dit code est sous GPL, si vous voulez, histoire de
freiner un peu les aspects mercantilistes.
Évidemment, il est inutile d'attendre que le PO fasse lui-même de telles
recherches. Comme vous l'avez très bien rappelé au début de ce fil, avec les
références à ce qui s'est passé en 2004.
En plus, et dans ce cas particulier, en réécrivant l'algorithme on peut éventuellement le simplifier ; en l'occurence je crois que ce à quoi je suis arrivé est sensiblement plus _simple_ que le code initial en VB ; ÀMHA, évidemment.
le simplifier certes, se rendre compte de ce que l'on fait encore plus.
Pouvez-vous expliciter votre propos, j'ai peur de comprendre.
par exemple: le PO cherche une traduction en C parce que les mauvaises perfs actuelles "ne sont que" dû à l'écriture actuelle en VB - le langage devenant le bouc-émissaire de ces défauts, on s'affranchit d'une véritable analyse.
C'est bien possible, et c'est en tous cas un point que j'ai présupposé dans ma démarche. Mais je ne suis pas sûr d'en tirer les mêmes conclusions que vous. En effet, si le langage ou la formulation utilisés sont des obstacles pour que les cryptologues sérieux comme vous puissent analyser l'algorithme, en quoi le fait de mettre à votre disposition un code plus facile à manipuler serait-il un problème ? Au cas où ce ne serait pas évident, je précise que vous êtes libres de réutiliser le code que j'ai pondu pour effectuer des tests ; vous pouvez même considérer que le dit code est sous GPL, si vous voulez, histoire de freiner un peu les aspects mercantilistes.
Évidemment, il est inutile d'attendre que le PO fasse lui-même de telles recherches. Comme vous l'avez très bien rappelé au début de ce fil, avec les références à ce qui s'est passé en 2004.
Antoine
Sylvain
Antoine Leca wrote on 18/12/2007 12:31:
En news:4766cf86$0$889$, Sylvain va escriure:
Antoine Leca wrote on 17/12/2007 17:56:
En plus, et dans ce cas particulier, en réécrivant l'algorithme on peut éventuellement le simplifier ; en l'occurence je crois que ce à quoi je suis arrivé est sensiblement plus _simple_ que le code initial en VB ; ÀMHA, évidemment. le simplifier certes, se rendre compte de ce que l'on fait encore
plus.
Pouvez-vous expliciter votre propos, j'ai peur de comprendre.
je faisais notamment référence au point 1 de la description de l'algo (numérotation selon le site du PO) que vous commentez dans une autre branche de ce fil.
certaines contraintes de l'algo (en fait son protocole opératoire) me font considérer qu'il n'est pas utilisable - au sens où on l'entend pour un algo de crypto ordinaire, certes il est peut être utilisable pour chiffrer sans contrainte temps / mémoire de petits volumes de données.
par exemple: le PO cherche une traduction en C parce que les mauvaises perfs actuelles "ne sont que" dû à l'écriture actuelle en VB - le langage devenant le bouc-émissaire de ces défauts, on s'affranchit d'une véritable analyse.
C'est bien possible, et c'est en tous cas un point que j'ai présupposé dans ma démarche. Mais je ne suis pas sûr d'en tirer les mêmes conclusions que vous. En effet, si le langage ou la formulation utilisés sont des obstacles pour que les cryptologues sérieux comme vous puissent analyser l'algorithme, en quoi le fait de mettre à votre disposition un code plus facile à manipuler serait-il un problème ?
je n'ai pas insinué être un "cryptologue sérieux" - en aucun cas un expert en cryptanalyse - je pense malgré tout que la formulation a une grande importance sur la compréhension correcte de l'algo - les communications de l'auteur n'ont pas toujours été satisfaisantes à cet égard, données parfois en base 64, parfois en base 10 (mais préfixé comme en base 8), code peu/mal documenté, variables inutiles, etc.
votre contribution pour un "code plus facile" n'est d'aucune façon un problème; mon point sur les performances de l'algo soulignait au contraire que le langage seul ne doit pas être l'excuse.
Au cas où ce ne serait pas évident, je précise que vous êtes libres de réutiliser le code que j'ai pondu pour effectuer des tests ; vous pouvez même considérer que le dit code est sous GPL, si vous voulez, histoire de freiner un peu les aspects mercantilistes.
je ne qualifiais nullement votre effort ! la demande initiale (celle datant de 2 ans) du PO pour un portage en C était liée à une démarche commerciale: ie le produit final était vendu, aujourd'hui le discours est plus confus avec une license gratuite pour 2008 et un flou artistique au dela. je ne critique nullement la motivation commerciale d'une entreprise (au contraire) mais dans le respect des éventuels contractants et bien sur du client final; factuellement le PO propose aujourd'hui 152,45 euros pour ce travail de portage en C (fil sur f.m.crypto) soit de l'ordre de 2 heures de travail (est-ce à dire qu'il n'y reconnait aucune valeur ?) et ne me semble pas apporter toute les garanties au client final.
si j'ai utilisé "motivation mercantile" avec un conotation négative, c'est seulement à cause de ce qui semble se dégager de ces points: un travail coutant le moins possible pour rapporter le plus vite possible.
Évidemment, il est inutile d'attendre que le PO fasse lui-même de telles recherches. Comme vous l'avez très bien rappelé au début de ce fil, avec les références à ce qui s'est passé en 2004.
je ne veux pas qualifier ce qui est possible d'attendre ou non du PO, je ne commente que ce qu'il réalise ou a réalisé. qu'un auteur pense proposer quelque chose d'original et pertinant (et il y a 2 ans je notais les aspects positifs d'une intégration de service crypto dans une interface unifiée style clicodrome pour utiliateur peu expérimenté) mais refuse de faire des recherches pour éprouver, tester, mettre en situation réelle sa création, me laisserait très perplexe.
Sylvain.
Antoine Leca wrote on 18/12/2007 12:31:
En news:4766cf86$0$889$ba4acef3@news.orange.fr, Sylvain va escriure:
Antoine Leca wrote on 17/12/2007 17:56:
En plus, et dans ce cas particulier, en réécrivant l'algorithme on
peut éventuellement le simplifier ; en l'occurence je crois que ce à
quoi je suis arrivé est sensiblement plus _simple_ que le code
initial en VB ; ÀMHA, évidemment.
le simplifier certes, se rendre compte de ce que l'on fait encore
plus.
Pouvez-vous expliciter votre propos, j'ai peur de comprendre.
je faisais notamment référence au point 1 de la description de l'algo
(numérotation selon le site du PO) que vous commentez dans une autre
branche de ce fil.
certaines contraintes de l'algo (en fait son protocole opératoire) me
font considérer qu'il n'est pas utilisable - au sens où on l'entend pour
un algo de crypto ordinaire, certes il est peut être utilisable pour
chiffrer sans contrainte temps / mémoire de petits volumes de données.
par exemple: le PO cherche une traduction en C parce que les mauvaises
perfs actuelles "ne sont que" dû à l'écriture actuelle en VB - le
langage devenant le bouc-émissaire de ces défauts, on s'affranchit
d'une véritable analyse.
C'est bien possible, et c'est en tous cas un point que j'ai présupposé dans
ma démarche.
Mais je ne suis pas sûr d'en tirer les mêmes conclusions que vous. En effet,
si le langage ou la formulation utilisés sont des obstacles pour que les
cryptologues sérieux comme vous puissent analyser l'algorithme, en quoi le
fait de mettre à votre disposition un code plus facile à manipuler serait-il
un problème ?
je n'ai pas insinué être un "cryptologue sérieux" - en aucun cas un
expert en cryptanalyse - je pense malgré tout que la formulation a une
grande importance sur la compréhension correcte de l'algo - les
communications de l'auteur n'ont pas toujours été satisfaisantes à cet
égard, données parfois en base 64, parfois en base 10 (mais préfixé
comme en base 8), code peu/mal documenté, variables inutiles, etc.
votre contribution pour un "code plus facile" n'est d'aucune façon un
problème; mon point sur les performances de l'algo soulignait au
contraire que le langage seul ne doit pas être l'excuse.
Au cas où ce ne serait pas évident, je précise que vous êtes libres de
réutiliser le code que j'ai pondu pour effectuer des tests ; vous pouvez
même considérer que le dit code est sous GPL, si vous voulez, histoire de
freiner un peu les aspects mercantilistes.
je ne qualifiais nullement votre effort !
la demande initiale (celle datant de 2 ans) du PO pour un portage en C
était liée à une démarche commerciale: ie le produit final était vendu,
aujourd'hui le discours est plus confus avec une license gratuite pour
2008 et un flou artistique au dela.
je ne critique nullement la motivation commerciale d'une entreprise (au
contraire) mais dans le respect des éventuels contractants et bien sur
du client final; factuellement le PO propose aujourd'hui 152,45 euros
pour ce travail de portage en C (fil sur f.m.crypto) soit de l'ordre de
2 heures de travail (est-ce à dire qu'il n'y reconnait aucune valeur ?)
et ne me semble pas apporter toute les garanties au client final.
si j'ai utilisé "motivation mercantile" avec un conotation négative,
c'est seulement à cause de ce qui semble se dégager de ces points: un
travail coutant le moins possible pour rapporter le plus vite possible.
Évidemment, il est inutile d'attendre que le PO fasse lui-même de telles
recherches. Comme vous l'avez très bien rappelé au début de ce fil, avec les
références à ce qui s'est passé en 2004.
je ne veux pas qualifier ce qui est possible d'attendre ou non du PO, je
ne commente que ce qu'il réalise ou a réalisé.
qu'un auteur pense proposer quelque chose d'original et pertinant (et il
y a 2 ans je notais les aspects positifs d'une intégration de service
crypto dans une interface unifiée style clicodrome pour utiliateur peu
expérimenté) mais refuse de faire des recherches pour éprouver, tester,
mettre en situation réelle sa création, me laisserait très perplexe.
En plus, et dans ce cas particulier, en réécrivant l'algorithme on peut éventuellement le simplifier ; en l'occurence je crois que ce à quoi je suis arrivé est sensiblement plus _simple_ que le code initial en VB ; ÀMHA, évidemment. le simplifier certes, se rendre compte de ce que l'on fait encore
plus.
Pouvez-vous expliciter votre propos, j'ai peur de comprendre.
je faisais notamment référence au point 1 de la description de l'algo (numérotation selon le site du PO) que vous commentez dans une autre branche de ce fil.
certaines contraintes de l'algo (en fait son protocole opératoire) me font considérer qu'il n'est pas utilisable - au sens où on l'entend pour un algo de crypto ordinaire, certes il est peut être utilisable pour chiffrer sans contrainte temps / mémoire de petits volumes de données.
par exemple: le PO cherche une traduction en C parce que les mauvaises perfs actuelles "ne sont que" dû à l'écriture actuelle en VB - le langage devenant le bouc-émissaire de ces défauts, on s'affranchit d'une véritable analyse.
C'est bien possible, et c'est en tous cas un point que j'ai présupposé dans ma démarche. Mais je ne suis pas sûr d'en tirer les mêmes conclusions que vous. En effet, si le langage ou la formulation utilisés sont des obstacles pour que les cryptologues sérieux comme vous puissent analyser l'algorithme, en quoi le fait de mettre à votre disposition un code plus facile à manipuler serait-il un problème ?
je n'ai pas insinué être un "cryptologue sérieux" - en aucun cas un expert en cryptanalyse - je pense malgré tout que la formulation a une grande importance sur la compréhension correcte de l'algo - les communications de l'auteur n'ont pas toujours été satisfaisantes à cet égard, données parfois en base 64, parfois en base 10 (mais préfixé comme en base 8), code peu/mal documenté, variables inutiles, etc.
votre contribution pour un "code plus facile" n'est d'aucune façon un problème; mon point sur les performances de l'algo soulignait au contraire que le langage seul ne doit pas être l'excuse.
Au cas où ce ne serait pas évident, je précise que vous êtes libres de réutiliser le code que j'ai pondu pour effectuer des tests ; vous pouvez même considérer que le dit code est sous GPL, si vous voulez, histoire de freiner un peu les aspects mercantilistes.
je ne qualifiais nullement votre effort ! la demande initiale (celle datant de 2 ans) du PO pour un portage en C était liée à une démarche commerciale: ie le produit final était vendu, aujourd'hui le discours est plus confus avec une license gratuite pour 2008 et un flou artistique au dela. je ne critique nullement la motivation commerciale d'une entreprise (au contraire) mais dans le respect des éventuels contractants et bien sur du client final; factuellement le PO propose aujourd'hui 152,45 euros pour ce travail de portage en C (fil sur f.m.crypto) soit de l'ordre de 2 heures de travail (est-ce à dire qu'il n'y reconnait aucune valeur ?) et ne me semble pas apporter toute les garanties au client final.
si j'ai utilisé "motivation mercantile" avec un conotation négative, c'est seulement à cause de ce qui semble se dégager de ces points: un travail coutant le moins possible pour rapporter le plus vite possible.
Évidemment, il est inutile d'attendre que le PO fasse lui-même de telles recherches. Comme vous l'avez très bien rappelé au début de ce fil, avec les références à ce qui s'est passé en 2004.
je ne veux pas qualifier ce qui est possible d'attendre ou non du PO, je ne commente que ce qu'il réalise ou a réalisé. qu'un auteur pense proposer quelque chose d'original et pertinant (et il y a 2 ans je notais les aspects positifs d'une intégration de service crypto dans une interface unifiée style clicodrome pour utiliateur peu expérimenté) mais refuse de faire des recherches pour éprouver, tester, mettre en situation réelle sa création, me laisserait très perplexe.
Sylvain.
Antoine Leca
En news:4767cc4e$0$902$, Sylvain va escriure: <tout plein de choses>
Ok. J'ai bien lu votre message, mais vous avouerez avec moi qu'il n'a aucun rapport avec ce groupe. Aussi je ne vais pas en rajouter, surtout que cela n'ajoutera rien à mon sens.
Je dois dire que j'ai réagi (probablement trop vivement) à votre message, parce que c'était une réponse au mien, et que je ne comprenais pas le rapport entre ma réponse (anecdotique) au propos de Marc et votre message ; j'ai maintenant compris que votre message avait disons une portée plus large...
Antoine
En news:4767cc4e$0$902$ba4acef3@news.orange.fr, Sylvain va escriure:
<tout plein de choses>
Ok. J'ai bien lu votre message, mais vous avouerez avec moi qu'il n'a aucun
rapport avec ce groupe. Aussi je ne vais pas en rajouter, surtout que cela
n'ajoutera rien à mon sens.
Je dois dire que j'ai réagi (probablement trop vivement) à votre message,
parce que c'était une réponse au mien, et que je ne comprenais pas le
rapport entre ma réponse (anecdotique) au propos de Marc et votre message ;
j'ai maintenant compris que votre message avait disons une portée plus
large...
En news:4767cc4e$0$902$, Sylvain va escriure: <tout plein de choses>
Ok. J'ai bien lu votre message, mais vous avouerez avec moi qu'il n'a aucun rapport avec ce groupe. Aussi je ne vais pas en rajouter, surtout que cela n'ajoutera rien à mon sens.
Je dois dire que j'ai réagi (probablement trop vivement) à votre message, parce que c'était une réponse au mien, et que je ne comprenais pas le rapport entre ma réponse (anecdotique) au propos de Marc et votre message ; j'ai maintenant compris que votre message avait disons une portée plus large...
Antoine
Raymond H.
Bonjour Antoine, Excusez le temps que j'ai mis à répondre. Merci pour le temps que vous avez mis à produire le code C; j'apprécie beaucoup :-) Ça va peut-être aller au début de la 2e semaine de janvier avant de recommencer à étudier plus sérieusement le C et ainsi tenter de comprendre minutieusement votre code C et le tester. À vue d'oeil, le C a l'air plus simple et plus court que le code VB. Je veux vous revenir au début de janvier. Passez une bonne fin d'année et un bon jour de l'an. Raymond H.
"Antoine Leca" a écrit dans le message de news: fk66lg$mpu$
En news:fk1ci2$u6b$, Raymond H. va escriure:
Je chercherais une personne poussée en langage C [Anastasie]
Ces 2 procédures sont déjà en code VB et fonctionnent très bien; mais il me reste à convertir en langage C (en DLL) ces 2 procédures principales pour rendre leur exécution plus rapide qu'en VB.
<NOTES> Préalable : je me suis initialement vautré un peu en interprétant Gauche() alors que le code disait Right()... 8-< Cette erreur-là devrait être oubliée (confus sur le coup, N'Antoine)
Décharge 1 : je ne suis pas « poussée » Décharge 2 : je n'ai vu qu'une seule procédure Décharge 3 : c'est la première fois que je code du code cryptographique, pas taper (ou pas trop fort) Décahrge 4 : il est évident qu'il faut améliorer ce code en vue de l'utiliser en cryptographie; à tout le moins, il faudrait empêcher les tampons de se perdre dans le swap... et tout plein d'autres choses qui ne sont pas le sujet ici Décharge 5 : ce code n'est pas testé, je n'ai même pas essayé de l'exécuter « pour voir » (surtout parce que je ne comprend rien à la manière de le faire fonctionner)
Remarque 1 : plutôt que de prolonger au-delà du raisonnable les « clés de session » en mémoire, j'ai basculé les « clés initiales » dans un tampon, puisqu'il me semble qu'il s'agit en fait d'un simple chiffre de flux. Remarque 2 : le retournement en place est consommateur de ressources CPU, et en plus [surtout?] cela risque de déborder du cache. Une autre manière plus habile serait de faire un chiffre vers un autre tampon, en commençant par la fin du bloc à chiffrer (seconde boucle for(;;) parcourue à l'envers).
if( !VLenDat || !VDat ) /* non au boulot inutile */ return;
/* Note: on alloue un octet de plus que la longueur de clé, * pour pouvoir y stocker la valeur « suivante » qui sera générée; * ensuite on décalera d'un le bloc */ if( VLenVS<16 || !(Sa=malloc(VLenVS+1)) || !(Sb=malloc(VLenVS+1)) ) { /*traitement d'erreur, throw, comme on veut...*/ longjmp(env, ERR_MOTEUR); return; }
/* Inversion de la chaîne de caractères. */ for( p=&VDat[0], q=&VDat[VLenDat-1] ; p<q ; ) { *p ^= *q; *q ^= *p; *p++ ^= *q--; }
/* Décalage */ memmove(Sa, Sa+1, VLenVS); memmove(Sb, Sb+1, VLenVS); } *VRep &= 0xFF; /* juste pour faire comme le code original */ free(Sa); free(Sb); }
Bonjour Antoine,
Excusez le temps que j'ai mis à répondre. Merci pour le temps que vous
avez mis à produire le code C; j'apprécie beaucoup :-)
Ça va peut-être aller au début de la 2e semaine de janvier avant de
recommencer à étudier plus sérieusement le C et ainsi tenter de comprendre
minutieusement votre code C et le tester. À vue d'oeil, le C a l'air plus
simple et plus court que le code VB. Je veux vous revenir au début de
janvier.
Passez une bonne fin d'année et un bon jour de l'an.
Raymond H.
"Antoine Leca" <root@localhost.invalid> a écrit dans le message de news:
fk66lg$mpu$1@shakotay.alphanet.ch...
En news:fk1ci2$u6b$1@talisker.lacave.net, Raymond H. va escriure:
Je chercherais une personne poussée en langage C
[Anastasie]
Ces 2 procédures sont déjà en code VB et fonctionnent très bien;
mais il me reste à convertir en langage C (en DLL)
ces 2 procédures principales pour rendre leur exécution plus
rapide qu'en VB.
<NOTES>
Préalable : je me suis initialement vautré un peu en interprétant Gauche()
alors que le code disait Right()... 8-< Cette erreur-là devrait être
oubliée
(confus sur le coup, N'Antoine)
Décharge 1 : je ne suis pas « poussée »
Décharge 2 : je n'ai vu qu'une seule procédure
Décharge 3 : c'est la première fois que je code du code cryptographique,
pas
taper (ou pas trop fort)
Décahrge 4 : il est évident qu'il faut améliorer ce code en vue de
l'utiliser en cryptographie; à tout le moins, il faudrait empêcher les
tampons de se perdre dans le swap... et tout plein d'autres choses qui ne
sont pas le sujet ici
Décharge 5 : ce code n'est pas testé, je n'ai même pas essayé de
l'exécuter
« pour voir » (surtout parce que je ne comprend rien à la manière de le
faire fonctionner)
Remarque 1 : plutôt que de prolonger au-delà du raisonnable les « clés de
session » en mémoire, j'ai basculé les « clés initiales » dans un tampon,
puisqu'il me semble qu'il s'agit en fait d'un simple chiffre de flux.
Remarque 2 : le retournement en place est consommateur de ressources CPU,
et
en plus [surtout?] cela risque de déborder du cache. Une autre manière
plus
habile serait de faire un chiffre vers un autre tampon, en commençant par
la
fin du bloc à chiffrer (seconde boucle for(;;) parcourue à l'envers).
if( !VLenDat || !VDat )
/* non au boulot inutile */
return;
/* Note: on alloue un octet de plus que la longueur de clé,
* pour pouvoir y stocker la valeur « suivante » qui sera générée;
* ensuite on décalera d'un le bloc
*/
if( VLenVS<16
|| !(Sa=malloc(VLenVS+1)) || !(Sb=malloc(VLenVS+1)) ) {
/*traitement d'erreur, throw, comme on veut...*/
longjmp(env, ERR_MOTEUR);
return;
}
/* Inversion de la chaîne de caractères. */
for( p=&VDat[0], q=&VDat[VLenDat-1] ; p<q ; ) {
*p ^= *q; *q ^= *p; *p++ ^= *q--;
}
/* Décalage */
memmove(Sa, Sa+1, VLenVS);
memmove(Sb, Sb+1, VLenVS);
}
*VRep &= 0xFF; /* juste pour faire comme le code original */
free(Sa);
free(Sb);
}
Bonjour Antoine, Excusez le temps que j'ai mis à répondre. Merci pour le temps que vous avez mis à produire le code C; j'apprécie beaucoup :-) Ça va peut-être aller au début de la 2e semaine de janvier avant de recommencer à étudier plus sérieusement le C et ainsi tenter de comprendre minutieusement votre code C et le tester. À vue d'oeil, le C a l'air plus simple et plus court que le code VB. Je veux vous revenir au début de janvier. Passez une bonne fin d'année et un bon jour de l'an. Raymond H.
"Antoine Leca" a écrit dans le message de news: fk66lg$mpu$
En news:fk1ci2$u6b$, Raymond H. va escriure:
Je chercherais une personne poussée en langage C [Anastasie]
Ces 2 procédures sont déjà en code VB et fonctionnent très bien; mais il me reste à convertir en langage C (en DLL) ces 2 procédures principales pour rendre leur exécution plus rapide qu'en VB.
<NOTES> Préalable : je me suis initialement vautré un peu en interprétant Gauche() alors que le code disait Right()... 8-< Cette erreur-là devrait être oubliée (confus sur le coup, N'Antoine)
Décharge 1 : je ne suis pas « poussée » Décharge 2 : je n'ai vu qu'une seule procédure Décharge 3 : c'est la première fois que je code du code cryptographique, pas taper (ou pas trop fort) Décahrge 4 : il est évident qu'il faut améliorer ce code en vue de l'utiliser en cryptographie; à tout le moins, il faudrait empêcher les tampons de se perdre dans le swap... et tout plein d'autres choses qui ne sont pas le sujet ici Décharge 5 : ce code n'est pas testé, je n'ai même pas essayé de l'exécuter « pour voir » (surtout parce que je ne comprend rien à la manière de le faire fonctionner)
Remarque 1 : plutôt que de prolonger au-delà du raisonnable les « clés de session » en mémoire, j'ai basculé les « clés initiales » dans un tampon, puisqu'il me semble qu'il s'agit en fait d'un simple chiffre de flux. Remarque 2 : le retournement en place est consommateur de ressources CPU, et en plus [surtout?] cela risque de déborder du cache. Une autre manière plus habile serait de faire un chiffre vers un autre tampon, en commençant par la fin du bloc à chiffrer (seconde boucle for(;;) parcourue à l'envers).
if( !VLenDat || !VDat ) /* non au boulot inutile */ return;
/* Note: on alloue un octet de plus que la longueur de clé, * pour pouvoir y stocker la valeur « suivante » qui sera générée; * ensuite on décalera d'un le bloc */ if( VLenVS<16 || !(Sa=malloc(VLenVS+1)) || !(Sb=malloc(VLenVS+1)) ) { /*traitement d'erreur, throw, comme on veut...*/ longjmp(env, ERR_MOTEUR); return; }
/* Inversion de la chaîne de caractères. */ for( p=&VDat[0], q=&VDat[VLenDat-1] ; p<q ; ) { *p ^= *q; *q ^= *p; *p++ ^= *q--; }
/* Décalage */ memmove(Sa, Sa+1, VLenVS); memmove(Sb, Sb+1, VLenVS); } *VRep &= 0xFF; /* juste pour faire comme le code original */ free(Sa); free(Sb); }
Antoine Leca
En news:fl6242$1nc$, Raymond H. va escriure:
À vue d'oeil, le C a l'air plus simple et plus court que le code VB.
Ce n'est pas dû au langage. Pour comprendre ce que faisait votre code, j'ai dû l'analyser. Faisant cela, j'ai largement simplifié l'algorithmique, qui était pour ainsi dire emberlificotée dans le code VB.
J'ai réalisé depuis qu'une amélioration pourrait être de mélanger les deux blocs Sa et Sb ensemble, allouant le double d'octets (2*longueur+2) et piochant alternativement, indices pairs pour Sa et impairs pour Sb; il n'y alors plus qu'un seul memmove(S, S+2, 2*longueur); cela permettrait à un cryptologue de revenir à des structures plus proches de l'habitude (l'existence des deux blocs différents est source de confusion inutile, ÀMHA).
En news:fl6242$1nc$1@talisker.lacave.net, Raymond H. va escriure:
À vue d'oeil, le C a l'air plus simple et plus court que le code VB.
Ce n'est pas dû au langage. Pour comprendre ce que faisait votre code, j'ai
dû l'analyser. Faisant cela, j'ai largement simplifié l'algorithmique, qui
était pour ainsi dire emberlificotée dans le code VB.
J'ai réalisé depuis qu'une amélioration pourrait être de mélanger les deux
blocs Sa et Sb ensemble, allouant le double d'octets (2*longueur+2) et
piochant alternativement, indices pairs pour Sa et impairs pour Sb; il n'y
alors plus qu'un seul memmove(S, S+2, 2*longueur); cela permettrait à un
cryptologue de revenir à des structures plus proches de l'habitude
(l'existence des deux blocs différents est source de confusion inutile,
ÀMHA).
À vue d'oeil, le C a l'air plus simple et plus court que le code VB.
Ce n'est pas dû au langage. Pour comprendre ce que faisait votre code, j'ai dû l'analyser. Faisant cela, j'ai largement simplifié l'algorithmique, qui était pour ainsi dire emberlificotée dans le code VB.
J'ai réalisé depuis qu'une amélioration pourrait être de mélanger les deux blocs Sa et Sb ensemble, allouant le double d'octets (2*longueur+2) et piochant alternativement, indices pairs pour Sa et impairs pour Sb; il n'y alors plus qu'un seul memmove(S, S+2, 2*longueur); cela permettrait à un cryptologue de revenir à des structures plus proches de l'habitude (l'existence des deux blocs différents est source de confusion inutile, ÀMHA).
