Bouygues a lancé hier une nouvelle box wifi 7 bi bande avec ethernet 2.5g qui va remplacer la box la l'offre must

C'est douteux, étant donné que TLS 1.3 c'est pas résistant aux attaques PQ dans sa forme actuelle (RFC 8446), les algos de négociation et d'échange des clefs standardisés sont basés sur les courbes elliptiques (ECDHE) et les corps finis (DHE) qui sont tous vulnérables aux attaques PQ connues.

La résistance aux attaques PQ passe par un mécanisme d'échange des clefs hybride, utilisant notamment ML-KEM (Kyber, algo standardisé NIST en 2024). Le travail est en cours avec un RFC draft : https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ qui est déjà en test dans Chrome depuis la version 131 (implémentation de X25519MLKEM768), et déployé côté serveur chez Cloudflare et Google. Le problème principal de cette solution, c'est l'augmentation considérable de la taille de clef, qui augmente la taille du ClientHello et peut poser problème avec les répartiteurs de charge et les middleboxes d'inspection du trafic TLS trop vieilles.

Ou rester sur du symétrique en augmentant un peu la taille de la clef (pour résister à Grover)

Vous avez vu passer des failles de sécurité pour TLS 1.2 utilisé avec les bonnes suites cryptographiques ?

C'est pour le post-quantique ?

Les décisions sont plutôt sous la forme de TLS1.3 par défaut, TLS1.2 en dérogation (en supprimant les algos obsolètes).
2 gains évoqués : sécurité (du fait des algos), performance (réduction des échanges lors de l'établissement de la connexion)

Vous avez vu passer des failles de sécurité pour TLS 1.2 utilisé avec les bonnes suites cryptographiques ?

C'est pour le post-quantique ?

C'est douteux, étant donné que TLS 1.3 c'est pas résistant aux attaques PQ dans sa forme actuelle (RFC 8446), les algos de négociation et d'échange des clefs standardisés sont basés sur les courbes elliptiques (ECDHE) et les corps finis (DHE) qui sont tous vulnérables aux attaques PQ connues.

La résistance aux attaques PQ passe par un mécanisme d'échange des clefs hybride, utilisant notamment ML-KEM (Kyber, algo standardisé NIST en 2024). Le travail est en cours avec un RFC draft : https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ qui est déjà en test dans Chrome depuis la version 131 (implémentation de X25519MLKEM768), et déployé côté serveur chez Cloudflare et Google. Le problème principal de cette solution, c'est l'augmentation considérable de la taille de clef, qui augmente la taille du ClientHello et peut poser problème avec les répartiteurs de charge et les middleboxes d'inspection du trafic TLS trop vieilles.

Bon j'ai tiré une nouvelle gaine toute propre toute droite toute déboucher pour que ça aille au plus vite pour n importe quel technicien.

Le problème maintenant c'est que a après 3 installations inabouties free ne veut plus m envoyer de techniciens de base. Ils veillent m envoyer des tech supérieurs d après ce qu'ils disent, et rien sur leur planning... Bref 1 semaine que ça ne bouge plus...

Donc ma nouvelle idée: m abonner au nom de ma conjointe (pour revenir au process avec les techniciens de base) et résilier mon offre actuelle (sans frais car depuis maintenant 6 semaines d interruption du service ça se justifie)

Je perdrai donc mon numéro de téléphone dans l' affaire (mais a mon avis il est déjà perdu mais tant pis) ainsi que des frais d' ouverture de ligne. Mais ça peut peut être relancer le process??

Salut,
je me trompe peut-etre, mais je pense l'identification de l'installation est liée à l'adresse postale, pas au nom du client, une fois la fibre raccordée, c'est lié au numéro de PTO.