Produits Entr'ouvert » Passerelle

Je valide le chiffrement RSA/OAEP/AES/EAX recopié des example de pycryptodome (en général les exemples donnent les bonnes pratiques, donc bonne idée).

Tu peux utiliser passerelle.utils.files.atomic_write plutôt que ça :

        with self.named_tempfile() as tpf:
            write_encrypt(tpf, data, self.public_key)
            tpf.flush()
            os.fsync(tpf.file.fileno())
            tempfile_name = tpf.name
        os.rename(tempfile_name, content_filename)

from·passerelle.utils.files·import·atomic_write

...
        with atomic_write(full_path, dir=tmp_dir) as fd:
            self.render_to_file(fd)

Petite question ouverte, dont je ne prétends pas avoir la réponse : est-ce qu'on aurait intérêt à l'initialisation de la ressource de faire une rapide vérification que Cipher_{priv}(Cipher_{pub}('abc')) == 'abc', ou vice-versa, pour vérifier que les deux clés publique et privée se complémentent bien ?

Je souhaiterais éviter le cas où, en prod, le connecteur a mal été initialisé, et on ne s'en rend compte que lorsque des demandes ont déjà été soumises, et que des fichiers chiffrés des usagers ne sont plus déchiffrables car aïe dommage la clé privée ne correspond pas.

Paul Marillonnet a écrit :

Petite question ouverte, dont je ne prétends pas avoir la réponse : est-ce qu'on aurait intérêt à l'initialisation de la ressource de faire une rapide vérification que Cipher_{priv}(Cipher_{pub}('abc')) == 'abc', ou vice-versa, pour vérifier que les deux clés publique et privée se complémentent bien ?

À l'instanciation du service on aura généralement pas la clé privée, elle sera conservée par la collectivité sur un service en DMZ auquel on ne devrait pas avoir accès si j'ai bien compris; de leur coté ça peut être intéressant oui.

Je souhaiterais éviter le cas où, en prod, le connecteur a mal été initialisé, et on ne s'en rend compte que lorsque des demandes ont déjà été soumises, et que des fichiers chiffrés des usagers ne sont plus déchiffrables car aïe dommage la clé privée ne correspond pas.

La solution magique contre la connerie on ne l'a pas encore :)

Paul Marillonnet a écrit :

Petite question ouverte, dont je ne prétends pas avoir la réponse : est-ce qu'on aurait intérêt à l'initialisation de la ressource de faire une rapide vérification que Cipher_{priv}(Cipher_{pub}('abc')) == 'abc', ou vice-versa, pour vérifier que les deux clés publique et privée se complémentent bien ?
Je souhaiterais éviter le cas où, en prod, le connecteur a mal été initialisé, et on ne s'en rend compte que lorsque des demandes ont déjà été soumises, et que des fichiers chiffrés des usagers ne sont plus déchiffrables car aïe dommage la clé privée ne correspond pas.

Yep. Bon, en pratique jamais on mettra les deux clés sur la même instance, hein :) L'idée c'est qu'une passerelle avec la clé privée (decrypt) est installé sur un autre réseau que la passerelle de chiffrement (qui elle fera partie du "publik public")

Mais oui pour l'idée et c'est pour ça que j'écrivais dans la description : « idéalement, une fois stockée, ça serait bien que la clé privée ne soit pas affichée dans l'interface d'édition de l'instance. On afficherait uniquement son empreinte, ainsi que cette de la clé publique, pour vérification »... et puis basta, ça sera vraiment pas compliqué à vérifier au premier test d'un chiffrage/déchiffrage, alors je n'en ai pas fait une priorité.

Thomas Noël a écrit :

Yep. Bon, en pratique jamais on mettra les deux clés sur la même instance, hein :) L'idée c'est qu'une passerelle avec la clé privée (decrypt) est installé sur un autre réseau que la passerelle de chiffrement (qui elle fera partie du "publik public")

My bad, après une première lecture du code je pensais que chaque instance disposerait de sa paire de clés publique et privée – et qu'on exploiterait la commutativité de l'exponentiation modulatoire, i.e.

Cipher_{privB}(Cipher_{pubA}(Cipher_{pubB}(Cipher_{privA}('abc')))) ==
Cipher_{privB}(Cipher_{pubB}(Cipher_{pubA}(Cipher_{privA}('abc')))) ==
'abc'

Mais oui pour l'idée et c'est pour ça que j'écrivais dans la description : « idéalement, une fois stockée, ça serait bien que la clé privée ne soit pas affichée dans l'interface d'édition de l'instance. On afficherait uniquement son empreinte, ainsi que cette de la clé publique, pour vérification »... et puis basta, ça sera vraiment pas compliqué à vérifier au premier test d'un chiffrage/déchiffrage, alors je n'en ai pas fait une priorité.

Oui ok je comprends (et j'aurais dû lire la description ☺).

Sur le fond, je m'interroge sur redirect_url_base, je trouve "bizarre" que ça se trouve à ce niveau, je me dis que je l'aurais préféré en paramétrage du système de stockage dans wcs; mais n'en faisons rien.

Ajouter à debian/ la dépendance sur python-pycryptodome.

Grosse suggestion aussi :

--- a/passerelle/static/css/style.css
+++ b/passerelle/static/css/style.css
@@ -177,6 +177,10 @@ li.connector.dpark a::before {
        content: "\f1b9";  /* car */
 }

+li.connector.cryptor a::before {
+       content: "\f023";  /* lock */
+}
+
 li.connector.status-down span.connector-name::after {

contextlib et tempfile importés mais pas/plus utilisés.

-                                  verbose_name=_('Encrypt RSA public key (PEM format)'),
+                                  verbose_name=_('Encryption RSA public key (PEM format)'),
...
-                                   verbose_name=_('Decrypt RSA private key (PEM format)'),
+                                   verbose_name=_('Decryption RSA private key (PEM format)'),
...
-        verbose_name = _('Encrypt / Decrypt')
+        verbose_name = _('Encryption / Decryption')

        uuid = str(cfile.uuid)

J'ajouterais un commentaire "# get string representation of UUID object" parce que je me suis demandé pourquoi c'était nécessaire et j'ai crains que ça ne soit des bytes et que ça fasse "b'uuid ici'".