HTTPS/SSH : quels algos utiliser ?

Bonjour,

Je recherche un document qui me permettrait de m'aiguiller sur quels algo de cryptages en 2019, il est préconisé d’utiliser et avec quelle taille de clef.

J'ai trouvé divers documents sur le web mais généralement non datés et non sourcés : donc difficile de s'y retrouver.

De ce que j'ai retenu :
- RSA : algo largement répandu, nécessitant l'utilisation d'une clef d'au moins 4096bits pour sécurisé
- DSA : ne pas utiliser car comporte une faille de sécurité. De plus, DSA ne peut pas être utilisé pour le chiffrement (uniquement pour de la signature).
- ECDSA : ne pas utiliser car il y a de grosse suspicion d"introduction de backdoors par la NSA dans certaines implémentations logicielles et hardwares.
- ED25519 : algo performant car basé sur les courbes elliptiques mais pose des problèmes de compatibilité du à sa jeunesse.
=> ces informations sont-elles bonnes et toujours d'actualité ?

Ce que je voudrai avoir, c'est une vue des différents types d'algo, de connaitre ceux qu'ils ne faut pas utiliser, et pour les autres, connaitre leurs avantages et inconvénients.

Merci d'avance,

Pour mes audits de sécurités, les auditeurs se réfèrent à ce site : https://www.ssllabs.com

ils éditent un draft des best practices : https://github.com/ssllabs/research/...Best-Practices

Après pas de références aux backdoors NSA

Bonjour,

C'est pour faire quoi ? Car selon que tu veuilles faire un logiciel de chat entre copains ou un logiciel professionnel ou bien militaire, les normes ne sont pas les mêmes.
C'est pour tourner où ? Car selon que tu aies un arduino ou un supercalculateur du top500, tu ne vas pas utiliser la même chose.
Quelles sont tes contraintes sécuritaires ? As-tu accès à un HSM, ou bien tout est logiciel ?

Citation:

---

Envoyé par fredoche

Pour mes audits de sécurités, les auditeurs se réfèrent à ce site : https://www.ssllabs.com

ils éditent un draft des best practices : https://github.com/ssllabs/research/...Best-Practices

Après pas de références aux backdoors NSA

---

Merci, je vais lire ça

Bonjour,

Citation:

---

Envoyé par gangsoleil

C'est pour faire quoi ? Car selon que tu veuilles faire un logiciel de chat entre copains ou un logiciel professionnel ou bien militaire, les normes ne sont pas les mêmes.

---

C'est pour le développement d'un équipement professionnel configurable à distance par Ethernet (et aussi par port console USB). L'équipement ne contiendra pas de données personnelles sensibles (à part logins et passwords).
Si la sécurisation est acceptable pour le militaire, c'est mieux : qui peut le plus, peu le moins.
=> quels sont les prérequis minimum ?
=> qu'est-ce qu’imposent les militaires ?

Citation:

---

Envoyé par gangsoleil

C'est pour tourner où ? Car selon que tu aies un arduino ou un supercalculateur du top500, tu ne vas pas utiliser la même chose.

---

Sur un µControtroleur 32bits.

Citation:

---

Envoyé par gangsoleil

Quelles sont tes contraintes sécuritaires ? As-tu accès à un HSM, ou bien tout est logiciel ?

---

Le µControleur n'intègre pas de fonctions de décryptage à la volée de la mémoire flash, mais il y a une fonction de protection en lecture (mais pas en écriture) contre les sondes type JTAG.
J'ai prévue d'utiliser une clef publique stockée dans le contrôleur pour valider la signature des fichiers de mise à jour pour éviter qu'un attaquant puisse injecter son propre firmware à distance. Pour le moment, je n'ai pas prévue de crypter les fichiers de mise à jour car ça ne me semble pas indispensable.
Pour le HTTPS, il y aura un certificat par défaut enregistré dans le firmware mais l’utilisateur pour injecter le sien (il sera enregistré dans une zone de flash interne du µControleur avec les logins et passwords).
=> Je compte imposer des certificats avec clef privées de 4096 bits (algo RSA).

ça vous semble suffisant ?

Remarque : pour les attaques sur site, ça me semble difficilement protégeable car l'attaquant pourra toujours écrire dans le µControleur via une sonde de programmation, il pourra donc modifier le comportement du produit et récupérer des données sensibles tel que logins/passwords et certificats/clefs HTTPS.

Citation:

---

Envoyé par boboss123

Si la sécurisation est acceptable pour le militaire, c'est mieux : qui peut le plus, peu le moins.

---

Certes, qui peut le plus peut le moins, mais à quel prix ?

Lorsque tu te promènes dans la rue, tu n'as probablement pas de garde du corps, parce que tu ne penses pas que la dépense en vaille la peine. Pourtant, qui peut le plus peut le moins, donc tu vas en prendre un ?

La liste des choses que tu ne protèges pas au quotidien parce que le coût est trop élevé est assez énorme, et c'est la même chose en entreprise : des calculs avec des clés RSA de 4096 bits, sur un microcontrolleur 32 bits, est-ce que tu sais combien de temps ça prend ? As-tu fait un essai pour voir ? Est-ce que ce temps est acceptable ?

Si oui, alors c'est bien, mais j'ai un sérieux doute.

Si tu veux faire un essai, tu peux installer openssl sur ton micro-controlleur, et lancer la commande suivante :

Code:

---

openssl speed rsa1024 rsa2048 rsa4096

---

Un temps acceptable représenterait combien environ ?

Citation:

---

Envoyé par gangsoleil

des calculs avec des clés RSA de 4096 bits, sur un microcontrolleur 32 bits, est-ce que tu sais combien de temps ça prend ? As-tu fait un essai pour voir ? Est-ce que ce temps est acceptable ?

---

Il faut que je fasse des tests pour voir mais c'est vrai qu'à priori 2048 bits devrait suffire pour être dans les normes des "bonnes pratiques à utiliser".
... après quand je vois les cahiers des charges des clients, ils demandent juste du HTTPS ou SSH (aucune autre précision)... ça fait un peu peur quand même... ok en faisant n'importe quoi, je réponds au besoin mais quand même...

Citation:

---

Envoyé par viper1094

Un temps acceptable représenterait combien environ ?

---

Tout dépend du produit et du système.
200ms peut être trop long pour certains systèmes alors que d'autres vont accepter 10 secondes.
Cela peut même aller plus loin si la sécurité est le cœur du système, si tu prends un téléphone Teorem par exemple la prise d'appel se fait en plusieurs dizaines de secondes (voir cela se compte peut être même en minute) en raison de la sécurité.

Je vois je vois^^. D'ailleurs vous savez si il est possible de crypter ses appels téléphoniques ?

Bonjour,

Attention, on ne peut pas crypter, on ne peut que chiffrer.

Tout est possible, c'est une question de prix. Pour chiffrer tes appels vocaux, tu peux :
- utiliser un logiciel dédié, comme signal. Attention néanmoins, il s'agit de data ici, pas d'un appel téléphonique (le réseau utilisé est différent)
- utiliser un logiciel qui va chiffrer sur ton terminal avant l'émission, et donc il faut que chacun de tes correspondants aient également ce même logiciel pour déchiffrer
- utiliser du matériel dédié

Merci pour la réponse. Faut que je voie au niveau d'un p'tit algo de crypto fait maison, que je foutrais sur l'appstore et proposerait a mes potes. J'vais voir ça x).

Citation:

---

Envoyé par gangsoleil

Attention, on ne peut pas crypter, on ne peut que chiffrer.

---

Quelle différence fais-tu entre "chiffrer" et "crypter" ?

-VX

Citation:

---

Envoyé par viper1094

Merci pour la réponse. Faut que je voie au niveau d'un p'tit algo de crypto fait maison, que je foutrais sur l'appstore et proposerait a mes potes. J'vais voir ça x).

---

:weird:

Moi, je sais pas quoi faire ce soir entre 20h et 22h...
Je me demande si je créerais pas un protocole de routage dynamique que je pourrais proposer au RIPE demain :lol:

-VX

Citation:

---

Envoyé par vxlan.is.top

Quelle différence fais-tu entre "chiffrer" et "crypter" ?

-VX

---

Pour moi crypter n'a pas de sens.

Chiffrer c'est le procédé de rendre incompréhensible une donnée pour toute personne qui n'a pas la clé de chiffrement.
Déchiffrer c'est le procédé de rendre compréhensible une donnée chiffrée grâce à la clé de chiffrement utilisée.
Décrypter c'est le procédé pour retrouver la donnée en clair alors que l'on ne possède pas la clé de chiffrement utilisée.

Parce que du coup crypter reviendrait à rendre incompréhensible une donnée avec une clé que nous ne connaissons pas... Chiffrement aléatoire et inutile ? :aie:

Citation:

---

Envoyé par viper1094

Merci pour la réponse. Faut que je voie au niveau d'un p'tit algo de crypto fait maison, que je foutrais sur l'appstore et proposerait a mes potes. J'vais voir ça x).

---

Pour info un algo de chiffrement maison, c'est pas très bien vu en sécurité : un algo est dit sécurisé lorsque son fonctionnement est publique est que personne n'a encore réussi à le casser. Baser son algo sur le fait que personne ne connait son fonctionnement est une erreur car il est peut être très vulnérable.

Citation:

---

Envoyé par vxlan.is.top

:weird:

Moi, je sais pas quoi faire ce soir entre 20h et 22h...
Je me demande si je créerais pas un protocole de routage dynamique que je pourrais proposer au RIPE demain :lol:

-VX

---

Il parait qu'en ce moment les création de ransomware est assez lucrative :)

Citation:

---

Envoyé par boboss123

Pour info un algo de chiffrement maison, c'est pas très bien vu en sécurité : un algo est dit sécurisé lorsque son fonctionnement est publique est que personne n'a encore réussi à le casser. Baser son algo sur le fait que personne ne connait son fonctionnement est une erreur car il est peut être très vulnérable.

---

Oui et non. Pour une utilisation domestique, j'vois vraiment mal un pirate lambda comprendre seul son fonctionnement. Après effectivement tu as raison

Citation:

---

Envoyé par viper1094

Oui et non. Pour une utilisation domestique, j'vois vraiment mal un pirate lambda comprendre seul son fonctionnement. Après effectivement tu as raison

---

Tout le monde est capable de créer un algorithme de chiffrement qu'il ne peut pas casser, mais créer un algo de chiffrement que d'autres ne peuvent pas casser, c'est autre chose. Tu prendras moins de temps à implémenter un algo existant (en utilisant openssl par exemple) plutôt que d'implémenter quelque chose toi même.

Pour chiffrer/déchiffrer/crypter, c'est bien ce qui est expliqué au-dessus.