PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → Cryptage de nombres
Cryptage de nombres
Débuté par Diamondsoftware, 08 aoû. 2024 23:47 - 13 réponses
Membre enregistré
152 messages
Popularité : +6 (8 votes)
Posté le 08 août 2024 - 23:47
Bonjour à tous,
pour un projet assez special je cherche comment crypter des nombres.
J'explique:
Dans une table de la base de donnees, on a deux rubriques contenant des monetaires (prix en USD)
Chacune de ces deux rubriques doit est cryptee a partir d'une cle mais le resultat du cryptage doit rester un nombre
afin de pouvoir le replacer dans la rubrique monetaire de la table de la base de donnees
J'ai regarde les fonctions de cryptage, mais le resultat est une chaine ce que je ne veux pas.
Je dois conserver la structure de la database avec les deux rubriques en monetaire.
J'espere etre clair...
Petit details: la premiere rubrique monetaire doit etre crypte/decrypte avec une cle , la 2eme rubrique doit etre crypte/decrypte avec une autre cle.
En fait il y a deux utilisateurs qui doivent chacun crypter leur prix. Utilisateur 1 crypte le prix 1 avec sa cle et utilisateur 2 crypte le prix 2 avec sa cle, le but etant qu' un utilisateur ne puisse voir le prix de l'autre utilisateur.
Merci d'avance pour vos suggestion.
Stephane

--
Stephane Dujourdy
Softwares made on measure and computing advice since 1980
Softwares made on measure for Diamond and Luxe sector since 1999
info@diamondsoftware.net
http://www.diamondsoftware.net
Membre enregistré
4 064 messages
Popularité : +227 (347 votes)
Posté le 09 août 2024 - 06:27
Bonjour,
Ton problème n'est pas un problème de crytage, mais un problème d'affichage. Il vient du fait que tu raisonnes en octet et non en 64 bits. En fait tu vois le résultat comme une chaine et non comme un buffer.
IEE754 permet de traduire en binaire un réel sur 64 bits (qword.) C'est sur, si on le décompose octet par octet, on a l'impression d'avoir une chaine sur 4.
Ainsi par exemple −118,625 (dec) = 1100 0010 1110 1101 0100 0000 0000 0000 (bin) = C2ED4000 (hexa), et C2ED4000 représente aussi la chaîne :
-a majuscule accent circonflexe-, -i minuscule accent aigu-, -Arobase-, -NULL-

IEE754 permet aussi l'opération inverse (BinaireVersRéel.)

Ton problème revient donc à :
1-Crypter ton prix, tu obtiens un buffer sur 64 bits.
2-Appliquer BinaireVersRéel au résultat pour avoir un affichage en réel.

--
Il y a peut être plus simple, mais, ça tourne
Quand tout a échoué utilises l'option RTFM.
Message modifié, 09 août 2024 - 07:02
Membre enregistré
1 635 messages
Popularité : +100 (114 votes)
Posté le 09 août 2024 - 09:15
Pourquoi ne pas faire une formule qui prend un inconnu (x) et que tu applique au prix ?
Alors ca ne va pas "crypter" comme tu l'entend mais ca va modifier la valeur et la rendre de fait inutilisable par l'autre utilisateur.
Posté le 09 août 2024 - 12:14
Bonjour Stéphane,

Ca doit faire au moins 20 ans ;-)

Merci pour cette récréation estivale. Je me suis amusé à chercher une solution.
Précisions :
- l'algo de "chiffrement" est léger, et ne résistera pas longtemps à la NSA
- les montants supportés vont jusqu'à 999999.99 (cause limite de valeur maxi des monétaires)
- la clé ne doit contenir que des caractères dont le code ASCII est compris entre 1 et 127

Si une de ces contraintes est incompatible avec ton besoin, j'essaierai d'améliorer.
Voici un bout de code qui a fonctionné dans tous les cas que j'ai testés (mais à éprouver de ton côté).

Au plaisir,

Michel Fages
CODE LINE

mMonetaire est monétaire = 987654.32
mMonetaireChiffré est monétaire
mMonetaireDéchiffré est monétaire
bClé est Buffer = "~"+Caract(111)+"ztoto123456"

mMonetaireChiffré = piChiffreMonetaire(mMonetaire, bClé)
mMonetaireDéchiffré = piDechiffreMonetaire(mMonetaireChiffré, bClé)


Info(mMonetaire, mMonetaireChiffré, mMonetaireDéchiffré)

PROCEDURE INTERNE piChiffreMonetaire(pMonetaire est monétaire, pClé est Buffer) : monétaire
ePosition est entier
bMonetaire est Buffer = NumériqueVersChaîne(pMonetaire, "%.2f").Remplace(".", "")
cResult est chaîne
mResult est monétaire
eTailleClé est entier = pClé.Taille()

POUR i=1 _À_ bMonetaire.Taille()
ePosition++
SI ePosition>eTailleClé ALORS
ePosition=1
FIN
cResult += NumériqueVersChaîne(OUExclusifBinaire(Asc(bMonetaire[[i]]), Asc(pClé[[ePosition]])), "02d")
FIN

mResult = NumériqueVersChaîne(cResult)
RENVOYER mResult
FIN

PROCEDURE INTERNE piDechiffreMonetaire(pMonetaireChiffré est monétaire, pClé est Buffer) : monétaire
bMonetaire est Buffer = NumériqueVersChaîne(pMonetaireChiffré)
ePosition est entier
cResult est chaîne
mResult est monétaire
eValue est entier
eTailleClé est entier = pClé.Taille()

POUR i=1 _À_ bMonetaire.Taille() PAS 2
ePosition++
SI ePosition>eTailleClé ALORS
ePosition=1
FIN
eValue = OUExclusifBinaire(Val(bMonetaire[[i À i+1]]), Asc(pClé[[ePosition]]))
SI eValue>255 ALORS
//Théoriquement impossible avec un buffer et une clé licites, tentative probable d'intrusion
CONTINUER
FIN
cResult += Caract(eValue)
FIN

mResult = Val(cResult)/100
RENVOYER mResult


FIN
Posté le 09 août 2024 - 17:04
Une deuxième proposition, qui tient plus de la dissimulation que du véritable chiffrement, mais il y a néanmoins de quoi décourager un éventuel curieux.

Avantage par rapport à la précédente, les contraintes techniques ont disparu.

mMonetaire est monétaire = 9459987654.32
mMonetaireChiffré est monétaire
mMonetaireDéchiffré est monétaire
bClé est Buffer = "blablabla123"


mMonetaireChiffré = piChiffreMonetaire(mMonetaire, bClé)
mMonetaireDéchiffré = piDéchiffreMonetaire(mMonetaireChiffré, bClé)

Info(mMonetaire, mMonetaireChiffré, mMonetaireDéchiffré)
STOP


PROCEDURE INTERNE piChiffreMonetaire(pMonetaire est monétaire, pClé est Buffer) : monétaire
bMonetaire est Buffer = NumériqueVersChaîne(pMonetaire*100, "%015d")
ePositionClé est entier
bHashClé est Buffer = HashChaîne(HA_HMAC_SHA_256, pClé)

POUR i=1 _À_ bMonetaire.Taille()
ePositionClé++
SI ePositionClé>bHashClé.Taille() ALORS
ePositionClé=1
FIN
piRotationChiffres(bMonetaire[[i]], Asc(bHashClé[[ePositionClé]]))
FIN

RENVOYER Val(bMonetaire)
FIN

PROCEDURE INTERNE piDéchiffreMonetaire(pMonetaireChiffré est monétaire, pClé est Buffer) : monétaire
bMonetaireChiffré est Buffer = NumériqueVersChaîne(pMonetaireChiffré)
ePositionClé est entier
bHashClé est Buffer = HashChaîne(HA_HMAC_SHA_256, pClé)

POUR i=1 _À_ bMonetaireChiffré.Taille()
ePositionClé++
SI ePositionClé>bHashClé.Taille() ALORS
ePositionClé=1
FIN
piDérotationChiffres(bMonetaireChiffré[[i]], Asc(bHashClé[[ePositionClé]]))
FIN

RENVOYER Val(bMonetaireChiffré)/100

FIN

PROCEDURE INTERNE piRotationChiffres(pChiffre est Buffer, pRotations est entier)

eChiffre est entier = Val(pChiffre)

POUR i=1 _À_ pRotations
eChiffre++
SI eChiffre>9 ALORS
eChiffre=0
FIN
FIN
pChiffre = NumériqueVersChaîne(eChiffre)
FIN

PROCEDURE INTERNE piDérotationChiffres(pChiffre est Buffer, pRotations est entier)

eChiffre est entier = Val(pChiffre)

POUR i=1 _À_ pRotations
eChiffre--
SI eChiffre<0 ALORS
eChiffre=9
FIN
FIN
pChiffre = NumériqueVersChaîne(eChiffre)
FIN
Membre enregistré
152 messages
Popularité : +6 (8 votes)
Posté le 09 août 2024 - 17:25
Bonjour à tous.
Merci pour vos reponses :)
@Voroltinquo: merci pour l'info mais je dois avouer que je comprend pas completement ta response. Et je parle bien de cryptage de valeur monetaire pas de probleme d'affichage.
@François C. : il me faut un cryptage assez fort car on parle de valeur monetaire importante (plusieurs millions de USD en jeu)
@Michel Fages: Super ta propo, je t'en remercie :merci:, mais deux contraintes: la cle doit etre plus forte avec des Lettres majuscules, minuscules, des chiffres et des caracteres speciaux style (? etc...
La 2eme contrainte sont les valeurs monetaires a crypter/decrypter: on parle de prix de diamants (surtout des gros) et donc les prix peuvent monter jusqu'a 100 millions de USD.
Le cryptage ne doit pas etre 'compatible NSA' mais il faut que ca resiste quand meme un peu car les enjeux sont importants au vu des valeurs de la marchandise...

--
Stephane Dujourdy
Softwares made on measure and computing advice since 1980
Softwares made on measure for Diamond and Luxe sector since 1999
info@diamondsoftware.net
http://www.diamondsoftware.net
Message modifié, 09 août 2024 - 17:42
Membre enregistré
152 messages
Popularité : +6 (8 votes)
Posté le 09 août 2024 - 17:47
Salut Michel,
merci pour la 2eme propo, je vais tester et voir ce que ca donne
Salutations
Stephane

--
Stephane Dujourdy
Softwares made on measure and computing advice since 1980
Softwares made on measure for Diamond and Luxe sector since 1999
info@diamondsoftware.net
http://www.diamondsoftware.net
Membre enregistré
152 messages
Popularité : +6 (8 votes)
Posté le 09 août 2024 - 20:25
Salut Michel,
j'ai integre ta 2eme methode dans le logiciel et ca marche tres bien expecte une 'bizarrerie'
Merci beaucoup
Certaines cles que j'utilise ne marche pas au decodage elle ne me redonne pas le prix correctement.
Serait-ce lie a certains caracteres , suite de caracteres ou la longueur de la cle?
Ex de cles:
dfg134641d35fg@tt( ne marche pas
ABCabc123@ marche
abdsdbscsdcssdcsdcscscscs marche
LdfgdER@445/sf(GFD marche
j'ai fait plusieurs tests de cles mais j'arrive pas a trouver la raison.
Peux etre a tu un idee?
Merci d'avance.
Stephane

--
Stephane Dujourdy
Softwares made on measure and computing advice since 1980
Softwares made on measure for Diamond and Luxe sector since 1999
info@diamondsoftware.net
http://www.diamondsoftware.net
Membre enregistré
4 064 messages
Popularité : +227 (347 votes)
Posté le 09 août 2024 - 20:36
Je parlais bien de cryptage.
Les fonctions de cryptage cryptent des buffers, le résultat est un buffer. Après, c'est une question d'interprétation.
Un buffer, selon la manière dont on l'interprète, peut être une chaine, un nombre, une série de commandes ...
Il suffit d'interpréter ton buffer en tant que nombre et non en tant que chaine.

--
Il y a peut être plus simple, mais, ça tourne
Message modifié, 09 août 2024 - 20:38
Membre enregistré
4 064 messages
Popularité : +227 (347 votes)
Posté le 11 août 2024 - 05:17
Je reformule.
On a vu plus haut que −118,625 (dec) = 1100 0010 1110 1101 0100 0000 0000 0000 (bin) = C2 ED 40 00 (hexa), c'est cette valeur (numérique), de taille fixe (C2 ED 40 00,) qu'il faut crypter, et non 2D 31 31 38 2E 36 32 35, qui est la représentation de la chaine -118.625, c'est pour cela que je parle de valeur "affichée", ce qui se fait lors d'un cryptage "classique" :
moPrix est un monétaire
bufPrix est Buffer
bufRes est Buffer
bufClé est Buffer

<BLOC affectation des valeurs de test>
moPrix = -118.625
bufPrix = moPrix
bufClé = HashChaîne(HA_CKSUM_64,"Mot de passe")
<FIN>

bufRes=CrypteStandard(bufPrix,bufClé,crypte3DES)


--
Il y a peut être plus simple, mais, ça tourne
Message modifié, 11 août 2024 - 05:20
Membre enregistré
152 messages
Popularité : +6 (8 votes)
Posté le 12 août 2024 - 10:18
@Voroltinquo
Bonjour,
merci pour les eclairsissements. :)
S.

--
Stephane Dujourdy
Softwares made on measure and computing advice since 1980
Softwares made on measure for Diamond and Luxe sector since 1999
info@diamondsoftware.net
http://www.diamondsoftware.net
Membre enregistré
152 messages
Popularité : +6 (8 votes)
Posté le 12 août 2024 - 10:20
@Michel,
pour eviter les cles qui ne fonctionne pas, j'ai ajoute un check quand l'utilisateur veux creer un clé.
Je cree quelques prix au hasard entre 0 et 100M$ et je teste un cryptage/decryptage pour voir si ca marche.
S.

--
Stephane Dujourdy
Softwares made on measure and computing advice since 1980
Softwares made on measure for Diamond and Luxe sector since 1999
info@diamondsoftware.net
http://www.diamondsoftware.net
Membre enregistré
443 messages
Popularité : +6 (6 votes)
Posté le 13 août 2024 - 19:31
Je pense qu'avec la version 2024, on peut arriver à gérer celà et ça serait plus facile.
Membre enregistré
152 messages
Popularité : +6 (8 votes)
Posté le 14 août 2024 - 11:36
Bonjour Ralph,
merci pour ton message, en pratique je ne passe a une nouvelle version de Windev qu'apres 1 an, pour eviter au maximum les problemes.
Vu les clients que j'ai et les sommes en jeux pour eux, je peux pas me permettre d'avoir des defaillances sur leur outils de productions/gestions/decisions.
Donc le passage en version 2024 ca sera pour plus tard une fois que tout sera fonctionnelle et utilisé par le client depuis quelques mois. Ca me permet de bien tester le passage dans une nouvelle version sans prendre de risque.

--
Stephane Dujourdy
Softwares made on measure and computing advice since 1980
Softwares made on measure for Diamond and Luxe sector since 1999
info@diamondsoftware.net
http://www.diamondsoftware.net