Comparaison digests

Code qui ne sert qu’à comparer les performances des variantes de Generate digest.

<code 4D>
$path1_t:=Convert path POSIX to system("/Users/arnaud/Desktop/doc1.pdf")
$path2_t:=$path1_t //Convert path POSIX to system("/Users/arnaud/Desktop/doc2.pdf")

$expected_b:=($path2_t=$path1_t)

C_BLOB($1_x;$2_x)
DOCUMENT TO BLOB($path1_t;$1_x)
DOCUMENT TO BLOB($path2_t;$2_x)

ARRAY TEXT($test_at;0)
ARRAY LONGINT($ms_al;0)
$duration_l:=60*2
$i_l:=0

//$i_l:=$i_l+1
//$j_l:=0
//$end_l:=Tickcount+$duration_l
//BLOB TO PICTURE($1_x;$1_i)
//BLOB TO PICTURE($2_x;$2_i)
//C_PICTURE($mask_i)
//Repeat
//$j_l:=$j_l+1
//$_b:=Equal pictures($1_i;$2_i;$mask_i)
//ASSERT($_b=$expected_b)
//Until (Tickcount>$end_l)
//APPEND TO ARRAY($test_at;“Equal pictures”)
//APPEND TO ARRAY($test_al;$j_l)

$i_l:=$i_l+1
$j_l:=0
$end_l:=Tickcount+$duration_l
Repeat
$j_l:=$j_l+1
$1_t:=Generate digest($1_x;MD5 digest)
$2_t:=Generate digest($2_x;MD5 digest)
ASSERT(($1_t=$2_t)=$expected_b)
Until (Tickcount>$end_l)
APPEND TO ARRAY($test_at;“MD5 digest”)
APPEND TO ARRAY($test_al;$j_l)

$i_l:=$i_l+1
$j_l:=0
$end_l:=Tickcount+$duration_l
Repeat
$j_l:=$j_l+1
$1_t:=Generate digest($1_x;SHA1 digest)
$2_t:=Generate digest($2_x;SHA1 digest)
ASSERT(($1_t=$2_t)=$expected_b)
Until (Tickcount>$end_l)
APPEND TO ARRAY($test_at;“SHA1 digest”)
APPEND TO ARRAY($test_al;$j_l)

$i_l:=$i_l+1
$j_l:=0
$end_l:=Tickcount+$duration_l
Repeat
$j_l:=$j_l+1
$1_t:=Generate digest($1_x;SHA256 digest)
$2_t:=Generate digest($2_x;SHA256 digest)
ASSERT(($1_t=$2_t)=$expected_b)
Until (Tickcount>$end_l)
APPEND TO ARRAY($test_at;“SHA256 digest”)
APPEND TO ARRAY($test_al;$j_l)

$msg_t:=Choose($expected_b;“equal”;“different”)
For ($i_l;1;Size of array($test_al))
$msg_t:=$msg_t+"\r"+$test_at{$i_l}+"="+String($test_al{$i_l})
End for
ALERT($msg_t)
</code 4D>

Salut Arnaud,

Une remarque quand à la comparaison de digest…

Si tu stockes ton blob dans un enregistrement (ou ailleurs d’ailleurs), c’est une bonne idée de calculer le digest au moment du stockage (dans le trigger de la table ?) et de stocker le digest dans un champ alpha “digestSha1” par exemple.
Ceci te permet de faire des recherche et comparaison sans recalculer le digest de chaque blob, de vérifier que les données stockées/récupérées n’ont pas été corrompues (assert), etc…

Si tu compresses ton blob avec 4D, je conseille de calculer le digest avant la compression.

Idem pour la taille (utile si tu veux faire des stats sur tes blobs, taille cumulée, taille moyenne, taille max, taille min). Si tu compresse ton blob, qu’est ce qui t’intéresse la taille originale, la taille compressée ou les deux ? Donc un ou deux champs entier long (je pense que des blob de plus de 2Go c’est quand même “chaud”).

Et enfin, je gère aussi généralement un type (mime/type ou une extension).

Et pour une “ged”, des informations sur le fichier original (nom, date/heure création, date/heure modification)

ouala, je ne sais pas si ça t’aide…

A+

Que si, que si, ça aide ! Que de bonnes idées…

Un seul truc m’emm… dans cette histoire de sha plus rapide que md5 :

“MD5 est une séquence de 16 octets retournée en tant que chaîne de 32 caractères hexadécimaux.”
chouette : stockage uuid = 16 octets = bon pour les perfs

“SHA-1 est une séquence de 20 octets retournée en tant que chaîne de 40 caractères hexadécimaux.”
heu… 80 octets, si je ne m’abuse…

Bonjour,

Je pense que tu dois d’abord raisonner en terme de besoin et contexte avant de regarder les notions secondaires d’optimisation (temps et stockage).

Tu pourrais aussi envisager un checksum CRC8 (1 octet), CRC16 ccitt ou kermit (2 octets), CRC32 (4 octets = 1 entier long)…

L’algorithme de hachage md5 est considéré aujourd’hui comme dépassé d’un point de vue cryptographique, mais quels sont tes besoins ? De la cryptographie ? sans doute pas. Quels sont les occurrences de collisions dans un jeu de donnée représentatif ?

En théorie l’algorithme md5 est plus ancien et plus simple (et donc plus rapide) que le sha1.
Mais après il y a des algorithmes, des librairies, plus ou moins optimisés (en fonction de l’implémentation elle même, du compilateur, des optimisations matérielles, etc…).

A+

: Bruno LEGAY

Je pense que tu dois d’abord raisonner en terme de besoin et contexte
avant de regarder les notions secondaires d’optimisation (temps et
stockage).
Oui, mais un gestion de documents, ça a rapidement du succès…
Tu pourrais aussi envisager un checksum CRC8 (1 octet), CRC16 ccitt
ou kermit (2 octets), CRC32 (4 octets = 1 entier long)…
[…]
occurrences de collisions dans un jeu de donnée représentatif ?
Ha, faudrait que je regarde. Mais si le but est de répondre à “est-ce que ces deux documents sont identiques ?”, je doute que ça suffise, non ?
En théorie l’algorithme md5 est plus ancien et plus simple (et donc
plus rapide) que le sha1.
C’est ce à quoi je m’attendais, mais l’essai avec Générer digest m’a dit non - sous réserve que je n’ai pas passé une grande variété de documents en revue, 5 ou 6 tout au plus.

<code 4D>
C’est ce à quoi je m’attendais, mais l’essai avec Générer digest m’a dit non - sous réserve que je n’ai pas passé une grande variété de documents en revue, 5 ou 6 tout au plus.
</code 4D>
Je ne sais pas comment sont codés les algorithmes digest de 4D…
On peut en déduire que, dans 4D, l’algorithme sha1 est peut-être plus optimisé que l’algorithme de md5… Est-ce que c’est grave ? pas vraiment… C’est très relatif tout ça.

Quelques recherches Google pour te montrer les différences pour un même algorithme entre des optimisations plus ou moins avancées :
https://web.njit.edu/~hz278/md5/report.php

https://www.nayuki.io/page/fast-sha1-hash-implementation-in-x86-assembly

: Bruno LEGAY

Est-ce que c’est grave ? pas vraiment… C’est très relatif tout ça.
Je pense la même chose. En fait j’ai fait ce test suite à un échange sur le nug, quelqu’un demandait s’il y avait plus rapide que le md5 pour déterminer si documentA=documentB. Si je l’ai posté ici, ce n’est pas pour dire que tel hash est mieux que tel autre, mal implémenté dans 4d ou que sais-je, mais à titre purement informel. Si ça suscite des commentaires constructifs comme les tiens, c’est parfait :slight_smile:

Oui, c’est vrai…

La première étape c’est de comparer la taille. C’est super rapide, ça coute rien, mais ça peut déjà éliminer certains pas mal de cas, selon le contexte.

A+