Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implémentation du serveur #4

Closed
alan-mushi opened this issue Jan 14, 2016 · 2 comments
Closed

Implémentation du serveur #4

alan-mushi opened this issue Jan 14, 2016 · 2 comments
Assignees
Milestone

Comments

@alan-mushi
Copy link
Owner

Pour la signature portant sur St il faudrait faire une structure permettant de changer d'algo de signature asymétrique facilement.

Sur le serveur il serait préférable d'utiliser le logger python en lieu et place de print() "sauvages".

Il serait de bon ton de commencer par concevoir un serveur émettant St par appel de fonction, puis d'ajouter la sérialisation des objets pythons échangés, enfin de rendre le serveur accessible sur un port TCP (issue #7). Pour réellement bien finir les choses une "message queue" (tel que RabbitMQ) des requêtes serait intéressant à ajouter et permettrait de scaler très facilement.

@alan-mushi
Copy link
Owner Author

La signature des requêtes s'effectue pour le moment par appels de méthodes en utilisant RSA avec PKCS1 v1.5. On ne peut pas signer (x, ID_C) comme prévu (problèmes de compatibilité) donc on signe: SHA1(x, ID_C). Je vais essayer de changer SHA1 pour une fonction de hachage plus robuste. Il est possible de d'échanger RSA pour DSA ou ElGamal à moindre effort (attention il y a cependant des problèmes avec DSA en Python 3.5).

La sérialisation et la restauration de certificats clients pour le serveur est ma prochaine étape.

@alan-mushi
Copy link
Owner Author

Après étude:

  • Il n'est pas possible de changer SHA1 pour une fonction de hachage plus robuste. La librairie Crypto ne dispose pas de meilleure fonction et rendre compatible un objet python fabriqué par la hashlib n'est possible que si on sous-classe les objets crées par la hashlib. Or sous-classer nous priverait du choix de la fonction de hachage utilisée. (Rappel: hashlib est utilisé pour les hashs dans l'arbre de Merkle).
  • Sérialiser les certificats clients maintenus dans le KSIServer (dans un format standard tel que JSON/YAML/XML) demande le même effort à implémenter que l'utilisation d'une base de données. Or la réalisation d'une vraie infrastructure KSI comprendra nécessairement une BDD, j'estime donc que le stockage des certificats clients utilisés par le serveur sera à implémenter quand nous mettrons en place une BDD (issue Utilisation d'une BDD #9) pour la KSI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant