Re: [SPAM] Truc et astuces - openssl password et encryption

Daniel Cordey via gull <gull-04vmY7CpswVinyhjFObuvR+/[email protected]> Tue, 24 Mar 2026 15:04:05 +0100
Newsgroups gmane.org.user-groups.gull.general
Message-ID <[email protected]>
--===============0927948517==
Content-Type: multipart/alternative;
	boundary="------------IsAMXWXujT6gx2e1gxibC6lM"
Content-Language: es-ES, fr, en-US

--------------IsAMXWXujT6gx2e1gxibC6lM
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit

Hola,

On 3/23/26 19:53, Félix Hauri via gull wrote:
>      Voici ce que mon raspberry-pi II model B à produit:
>          Sums texte:   64b        1:     0.63s -> match, Ok!
>          Sums image: 1.00M        1:     7.20s -> match, Ok!
>          Sums texte:   64b       10:     0.64s -> match, Ok!
>          Sums image: 1.00M       10:     7.22s -> match, Ok!
>          Sums texte:   64b      100:     0.66s -> match, Ok!
>          Sums image: 1.00M      100:     7.20s -> match, Ok!
>          Sums texte:   64b     1000:     0.86s -> match, Ok!
>          Sums image: 1.00M     1000:     7.47s -> match, Ok!
>          Sums texte:   64b    10000:     3.06s -> match, Ok!
>          Sums image: 1.00M    10000:     9.55s -> match, Ok!
>          Sums texte:   64b   100000:    22.85s -> match, Ok!
>          Sums image: 1.00M   100000:    30.92s -> match, Ok!
>          Sums texte:   64b  1000000:   243.59s -> match, Ok!
>          Sums image: 1.00M  1000000:   233.45s -> match, Ok!
>
>      Comme je m'y attendais, un plus gros fichier est plus long à chiffrer
>      qu'un petit, et de la même manière, 100'ooo itération sont plus longues
>      que 10... Et la différences dûe à la taille tend à s'estomper avec un
>      nombre d'itération important.

S'il est évident qu'encrypter un fichier plus gros prend plus de temps, 
je ne comprends pas du tout pourquoi, au-delà de 10'000 itérations, on a 
soudain un accroissement du temps d'exécution. Je m'attendais aussi à 
avoir le calcul du nombre de bytes/s que l'on arrive à encrypter, ou 
performance/itération ; qui sont en fait les valeurs les plus 
intéressantes. Aussi, il aurait été intéressant de calculer ces temps 
d'exécution pour différentes tailles de fichier, afin de déterminer si 
le temps d'exécution était une fonction linéaire en fonction de la 
taille. De même, je ne comprends pas ce que tu essaies de démonter avec 
tes N itérations... Car, si j'en crois ta conclusion ; à partir d'un 
certain nombre d'itérations... la taille n'a plus d'importance. Donc, si 
le delta T tend vers 0, la variable taille devient donc non 
significative... Ce qui contredit la première phrase de la conclusion 
ci-dessus. Il doit y avoir une explication, mais j'avoue ne pas 
comprendre, ni comment je peux utiliser ces valeurs.

dc

--------------IsAMXWXujT6gx2e1gxibC6lM
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html data-lt-installed="true">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body style="padding-bottom: 1px;">
    <p>Hola,</p>
    <div class="moz-cite-prefix">On 3/23/26 19:53, Félix Hauri via gull
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">
    Voici ce que mon raspberry-pi II model B à produit:
        Sums texte:   64b        1:     0.63s -&gt; match, Ok!
        Sums image: 1.00M        1:     7.20s -&gt; match, Ok!
        Sums texte:   64b       10:     0.64s -&gt; match, Ok!
        Sums image: 1.00M       10:     7.22s -&gt; match, Ok!
        Sums texte:   64b      100:     0.66s -&gt; match, Ok!
        Sums image: 1.00M      100:     7.20s -&gt; match, Ok!
        Sums texte:   64b     1000:     0.86s -&gt; match, Ok!
        Sums image: 1.00M     1000:     7.47s -&gt; match, Ok!
        Sums texte:   64b    10000:     3.06s -&gt; match, Ok!
        Sums image: 1.00M    10000:     9.55s -&gt; match, Ok!
        Sums texte:   64b   100000:    22.85s -&gt; match, Ok!
        Sums image: 1.00M   100000:    30.92s -&gt; match, Ok!
        Sums texte:   64b  1000000:   243.59s -&gt; match, Ok!
        Sums image: 1.00M  1000000:   233.45s -&gt; match, Ok!

    Comme je m'y attendais, un plus gros fichier est plus long à chiffrer
    qu'un petit, et de la même manière, 100'ooo itération sont plus longues
    que 10... Et la différences dûe à la taille tend à s'estomper avec un
    nombre d'itération important.
</pre>
    </blockquote>
    <p>S'il est évident qu'encrypter un fichier plus gros prend plus de
      temps, je ne comprends pas du tout pourquoi, au-delà de 10'000
      itérations, on a soudain un accroissement du temps d'exécution. Je
      m'attendais aussi à avoir le calcul du nombre de bytes/s que l'on
      arrive à encrypter, ou performance/itération ; qui sont en fait
      les valeurs les plus intéressantes. Aussi, il aurait été
      intéressant de calculer ces temps d'exécution pour différentes
      tailles de fichier, afin de déterminer si le temps d'exécution
      était une fonction linéaire en fonction de la taille. De même, je
      ne comprends pas ce que tu essaies de démonter avec tes N
      itérations... Car, si j'en crois ta conclusion ; à partir d'un
      certain nombre d'itérations... la taille n'a plus d'importance.
      Donc, si le delta T tend vers 0, la variable taille devient donc
      non significative... Ce qui contredit la première phrase de la
      conclusion ci-dessus. Il doit y avoir une explication, mais
      j'avoue ne pas comprendre, ni comment je peux utiliser ces
      valeurs.</p>
    <p>dc</p>
  </body>
  <lt-container></lt-container>
</html>

--------------IsAMXWXujT6gx2e1gxibC6lM--

--===============0927948517==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZ3VsbCBtYWls
aW5nIGxpc3QKZ3VsbEBmb3J1bS5saW51eC1ndWxsLmNoCmh0dHBzOi8vZm9ydW0ubGludXgtZ3Vs
bC5jaC9tYWlsbWFuL2xpc3RpbmZvL2d1bGw=

--===============0927948517==--