# QuantumLeap + Post Quantum StrongSwan : Algorithms & compagnies **URL:** \ **Category:** Pause Café\ **Tags:** securité, réseau\ **Created:** [Janvier 7, 2024, 7:33 UTC](https://www.debian-fr.org/t/quantumleap-post-quantum-strongswan-algorithms-compagnies/89398 "2024-01-07T07:33:57Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![anon36725218](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/8e8cbc/32.png) [@anon36725218](https://www.debian-fr.org/u/anon36725218)\ **Post date:** [Janvier 7, 2024, 7:33 UTC](https://www.debian-fr.org/t/quantumleap-post-quantum-strongswan-algorithms-compagnies/89398/1 "2024-01-07T07:33:57Z")
Bonjour, Je vous souhaites une bonne année 2024 🥳, en vous souhaitant des meilleurs vœux. Avant tout, je souhaite vous partager [cette information](https://zw3b.tv/sciences/quantum/des-chercheurs-realisent-la-premiere-teleportation-d-images-a-travers-un-reseau-quantique) (j’ai « copié », pour celles et ceux qui ne sont pas encore abonné·e·s, [l’article de Science & Vie](https://www.science-et-vie.com/technos-et-futur/des-chercheurs-realisent-la-premiere-teleportation-dimages-a-travers-un-reseau-quantique-122551.html) – Groupe [Reworld Media](https://fr.wikipedia.org/wiki/Reworld_Media)). > _« Désormais, il est possible de téléporter l’information de sorte qu’elle ne voyage jamais physiquement à travers la connexion – une technologie « Star Trek » devenue réalité »_ #Quantum #QuantumLeap #OptiqueNonLinéaire #NonlinearOptic #TransportQuantiqueHauteDimension #HighDimensionalQuantumTransport On saute dans le quantique pour cette année 😉 Sinon, je vous invite à voir/lire cette page : [PostQuantum StrongSwan v6.x](https://github.com/strongX509/docker) + la [documentation](https://docs.strongswan.org/). #PQStrongSwan #StrongSwan #vpn #Security Ci-dessous quelques Algorithmes de cryptage (authentification et encryption) : ```auto root@vps:/etc/swanctl # swanctl --list-algs encryption: AES_CBC[openssl] AES_CTR[openssl] AES_ECB[openssl] AES_CFB[openssl] CAMELLIA_CBC[openssl] CAMELLIA_CTR[openssl] CAST_CBC[openssl] BLOWFISH_CBC[openssl] 3DES_CBC[openssl] DES_CBC[openssl] DES_ECB[openssl] NULL[openssl] integrity: HMAC_MD5_96[openssl] HMAC_MD5_128[openssl] HMAC_SHA1_96[openssl] HMAC_SHA1_128[openssl] HMAC_SHA1_160[openssl] HMAC_SHA2_256_128[openssl] HMAC_SHA2_256_256[openssl] HMAC_SHA2_384_192[openssl] HMAC_SHA2_384_384[openssl] HMAC_SHA2_512_256[openssl] HMAC_SHA2_512_512[openssl] CAMELLIA_XCBC_96[xcbc] AES_XCBC_96[xcbc] AES_CMAC_96[cmac] aead: AES_GCM_16[openssl] AES_GCM_12[openssl] AES_GCM_8[openssl] AES_CCM_16[openssl] AES_CCM_12[openssl] AES_CCM_8[openssl] CHACHA20_POLY1305[openssl] hasher: HASH_SHA1[openssl] HASH_MD5[openssl] HASH_MD4[openssl] HASH_SHA2_224[openssl] HASH_SHA2_256[openssl] HASH_SHA2_384[openssl] HASH_SHA2_512[openssl] HASH_SHA3_224[openssl] HASH_SHA3_256[openssl] HASH_SHA3_384[openssl] HASH_SHA3_512[openssl] HASH_IDENTITY[openssl] prf: PRF_KEYED_SHA1[openssl] PRF_HMAC_MD5[openssl] PRF_HMAC_SHA1[openssl] PRF_HMAC_SHA2_256[openssl] PRF_HMAC_SHA2_384[openssl] PRF_HMAC_SHA2_512[openssl] PRF_AES128_XCBC[xcbc] PRF_CAMELLIA128_XCBC[xcbc] PRF_AES128_CMAC[cmac] xof: XOF_SHAKE128[openssl] XOF_SHAKE256[openssl] kdf: KDF_PRF[openssl] KDF_PRF_PLUS[openssl] drbg: DRBG_CTR_AES256[drbg] DRBG_CTR_AES128[drbg] DRBG_CTR_AES192[drbg] DRBG_HMAC_SHA1[drbg] DRBG_HMAC_SHA256[drbg] DRBG_HMAC_SHA384[drbg] DRBG_HMAC_SHA512[drbg] ke: MODP_3072[openssl] MODP_4096[openssl] MODP_6144[openssl] MODP_8192[openssl] MODP_2048[openssl] MODP_2048_224[openssl] MODP_2048_256[openssl] MODP_1536[openssl] MODP_1024[openssl] MODP_1024_160[openssl] MODP_768[openssl] MODP_CUSTOM[openssl] ECP_256[openssl] ECP_384[openssl] ECP_521[openssl] ECP_224[openssl] ECP_192[openssl] ECP_256_BP[openssl] ECP_384_BP[openssl] ECP_512_BP[openssl] ECP_224_BP[openssl] CURVE_25519[openssl] CURVE_448[openssl] FRODO_SHAKE_L1[frodo] FRODO_SHAKE_L3[frodo] FRODO_SHAKE_L5[frodo] FRODO_AES_L1[frodo] FRODO_AES_L3[frodo] FRODO_AES_L5[frodo] KYBER_L1[oqs] KYBER_L3[oqs] KYBER_L5[oqs] BIKE_L1[oqs] BIKE_L3[oqs] BIKE_L5[oqs] HQC_L1[oqs] HQC_L3[oqs] HQC_L5[oqs] rng: RNG_WEAK[openssl] RNG_STRONG[random] RNG_TRUE[random] nonce-gen: NONCE_GEN[nonce] ``` Exemple de certificats associés au VPN : > **root@vps:/etc/swanctl # swanctl --list-certs** > > ```auto > List of X.509 End Entity Certificates > > subject: "C=FR, O=Cyber, CN=moon.zw3b.eu" > issuer: "CN=FR, O=ZW3B, CN=Cyber Root CA" > validity: not before Jan 03 03:35:07 2024, ok > not after Jan 03 03:35:07 2028, ok (expires in 1460 days) > serial: 1d:53:f2:90:91:2a:65:9c > altNames: moon.zw3b.eu > flags: > authkeyId: 1b:25:0d:2e:19:51:22:0f:cc:54:d2:d3:26:4a:6b:a4:15:b5:16:03 > subjkeyId: d0:8a:b8:5b:f8:a9:9c:05:3c:1d:21:21:a0:3d:e5:f9:74:2e:74:9a > pubkey: Falcon1024 14344 bits, has private key > keyid: e8:c5:4d:79:f4:79:36:61:00:80:fd:88:91:de:ea:f9:39:d8:da:b6 > subjkey: d0:8a:b8:5b:f8:a9:9c:05:3c:1d:21:21:a0:3d:e5:f9:74:2e:74:9a > > List of X.509 CA Certificates > > subject: "CN=FR, O=ZW3B, CN=Cyber Root CA" > issuer: "CN=FR, O=ZW3B, CN=Cyber Root CA" > validity: not before Dec 20 02:17:23 2023, ok > not after Dec 19 02:17:23 2033, ok (expires in 3637 days) > serial: 18:9a:c0:0c:ab:57:44:8f > flags: CA CRLSign self-signed > OCSP URIs: utform > subjkeyId: d4:d6:18:86:8e:bd:8d:20:74:60:4a:a2:89:bb:75:cd:3e:7e:31:4f > pubkey: ECDSA 521 bits > keyid: 6b:83:6a:aa:a4:17:75:b3:2c:1e:3c:a8:af:be:80:4d:70:33:c6:ee > subjkey: d4:d6:18:86:8e:bd:8d:20:74:60:4a:a2:89:bb:75:cd:3e:7e:31:4f > > subject: "CN=FR, O=ZW3B, CN=Cyber Root CA" > issuer: "CN=FR, O=ZW3B, CN=Cyber Root CA" > validity: not before Dec 20 05:24:50 2023, ok > not after Dec 19 05:24:50 2033, ok (expires in 3638 days) > serial: 1c:80:73:15:85:2a:f7:5c > flags: CA CRLSign self-signed > OCSP URIs: utform > subjkeyId: 1b:25:0d:2e:19:51:22:0f:cc:54:d2:d3:26:4a:6b:a4:15:b5:16:03 > pubkey: ED448 456 bits > keyid: 27:eb:9e:6b:83:3b:a1:35:2d:ef:fd:76:5f:84:4f:7f:f2:c1:e4:ec > subjkey: 1b:25:0d:2e:19:51:22:0f:cc:54:d2:d3:26:4a:6b:a4:15:b5:16:03 > > ``` Voir un certificat avec la commande `pki`: > **root@vps:/etc/swanctl # pki --print --in x509/moonCert.pem --type x509** > > ```auto > subject: "C=FR, O=Cyber, CN=moon.zw3b.eu" > issuer: "CN=FR, O=ZW3B, CN=Cyber Root CA" > validity: not before Jan 03 03:35:07 2024, ok > not after Jan 03 03:35:07 2028, ok (expires in 1460 days) > serial: 1d:53:f2:90:91:2a:65:9c > altNames: moon.zw3b.eu > flags: > authkeyId: 1b:25:0d:2e:19:51:22:0f:cc:54:d2:d3:26:4a:6b:a4:15:b5:16:03 > subjkeyId: d0:8a:b8:5b:f8:a9:9c:05:3c:1d:21:21:a0:3d:e5:f9:74:2e:74:9a > pubkey: Falcon1024 14344 bits > keyid: e8:c5:4d:79:f4:79:36:61:00:80:fd:88:91:de:ea:f9:39:d8:da:b6 > subjkey: d0:8a:b8:5b:f8:a9:9c:05:3c:1d:21:21:a0:3d:e5:f9:74:2e:74:9a > > ``` Et pour finir : ```auto root@vps:/etc/swanctl # pki --gen --help strongSwan 6.0.0beta5 PKI tool usage: pki --gen [--type rsa|ecdsa|ed25519|ed448|dilithium2|dilithium3|dilithium5|falcon512|falcon1024] [--size bits] [--safe-primes] [--shares n] [--threshold l] [--outform der|pem] --help (-h) show usage information --type (-t) type of key, default: rsa --size (-s) keylength in bits, default: rsa 2048, ecdsa 384 --safe-primes (-p) generate rsa safe primes --shares (-n) number of private rsa key shares --threshold (-l) minimum number of participating rsa key shares --outform (-f) encoding of generated private key, default: der --debug (-v) set debug level, default: 1 --options (-+) read command line options from file ``` > **root@vps:~ # cat /etc/os-release** > > ```auto > PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" > NAME="Debian GNU/Linux" > VERSION_ID="11" > VERSION="11 (bullseye)" > VERSION_CODENAME=bullseye > ID=debian > HOME_URL="https://www.debian.org/" > SUPPORT_URL="https://www.debian.org/support" > BUG_REPORT_URL="https://bugs.debian.org/" > > ``` En vous souhaitant un bon dimanche à toutes et à tous. 🌐 ✨ 🌈 #internetQuantum : Sur la Opérating System Solar (la planete, and Moonlight) tu te transformeras en étoile ; dans un rayon de lumière (d’un point à un autre ^^) Romain. Note de Moi-même 20240128 : Mes certificats Krystals PQ Dilitium, Falcon ne sont toujours pas valable dans Windows 11 - La signature numérique de ce certificat n’est pas valide → Algoritme de Signature : 1.3.9999.3.4 et 1.3.101.112 😕 ---
**Author:** ![anon36725218](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/8e8cbc/32.png) [@anon36725218](https://www.debian-fr.org/u/anon36725218)\ **Post date:** [Janvier 9, 2024, 8:50 UTC](https://www.debian-fr.org/t/quantumleap-post-quantum-strongswan-algorithms-compagnies/89398/2 "2024-01-09T08:50:28Z")
J’ajoute ces sites web pour Post Archives 😉 > **CRYSTALS** → [https://pq-crystals.org/](https://pq-crystals.org/) > Cryptographic Suite for Algebraic Lattices > > La « Cryptographic Suite for Algebraic Lattices » (CRYSTALS) englobe deux primitives cryptographiques : **Kyber** , un mécanisme d’encapsulation de clé (KEM) sécurisé par IND-CCA2 ; et **Dilithium** , un algorithme de signature numérique fortement sécurisé EUF-CMA. Les deux algorithmes sont basés sur des problèmes difficiles sur les réseaux de modules, sont conçus pour résister aux attaques de grands ordinateurs quantiques et ont été soumis au projet de cryptographie post-quantique du NIST. > [CRYSTALS Dilithium (Lattice) - Digital Signature](https://asecuritysite.com/encryption/kyber3) > > À l’heure actuelle, CRYSTALS (Cryptographic Suite for Algebraic Lattices) prend en charge deux mécanismes quantiques robustes : Kyber pour le mécanisme d’encapsulation de clé (KEM) et l’échange de clés ; et Dilithium pour un algorithme de signature numérique. CRYSTALS Dilithium utilise des schémas Fiat-Shamir basés sur un réseau et produit l’une des plus petites signatures de toutes les méthodes post-quantiques, avec des tailles de clés publiques et privées relativement petites. Les trois principaux implémentations pour les paramètres utilisés sont : Dilithium 2, Dilithium 3 et Dilithium 5. > > Le NIST n’évalue actuellement que trois méthodes de signature numérique : CRYSTALS-DILITHIUM (dirigé par Vadim Lyubashevsky), FALCON (dirigé par Thomas Present) et RAINBOW (dirigé par Jintai Ding). Les trois principales implémentations de Dilithium sont : Dilithium 2 (2 479 octets – 19 832 bits – signature), Dilithium 3 (3 352 octets – 26 816 bits – signature) et Dilithium 5 (4 654 octets – 37 232 bits – signature). Globalement, Dilithium 3 équivaut à une signature de 128 bits et constitue peut-être le point de départ d’une implémentation. WikipediA « [Structure lattice](https://fr.wikipedia.org/wiki/Structure_lattice) ». 🙂 Bonne journée. ---
**Author:** ![anon36725218](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/8e8cbc/32.png) [@anon36725218](https://www.debian-fr.org/u/anon36725218)\ **Post date:** [Janvier 17, 2024, 12:57 UTC](https://www.debian-fr.org/t/quantumleap-post-quantum-strongswan-algorithms-compagnies/89398/3 "2024-01-17T12:57:11Z")
Bonjour, Pour vous parler aussi des algotithmes pour le Post Quantique côté protocole Web (HTTPS), ci-dessous ce lien : > **Serveur de test d’interopérabilité Open Quantum Safe pour une cryptographie à sécurité quantique** > > [https://test.openquantumsafe.org/](https://test.openquantumsafe.org/) > > _But_ > > _Ce serveur est une instance NGINX améliorée avec la prise en charge de la cryptographie à sécurité quantique (QSC) à l’aide de progiciels fournis par le projet Open Quantum Safe (OQS)._ > > _Afin de fournir aux clients un moyen de tester l’interopérabilité avec ce logiciel amélioré par QSC et les algorithmes QSC contenus, il comporte des ports séparés pour toutes les combinaisons d’algorithmes d’échange de signature/clé QSC prises en charge par la distribution OQS actuelle._ > […] Salutations, Romain * * * Je vous ajoute cette page que j’ai écris pour celles ou ceux qui n’auraient pas tout compris – l’histoire de la crypto Post Quantum, celle **à mettre en place aujourd’hui** pour l’après « entrée » des ordinateurs quantiques sur notre réseau Internet : [https://howto.zw3b.fr/internet-protocol-securited](https://howto.zw3b.fr/internet-protocol-securited) 😉 Bonne journée à toutes et à tous. * * * J’ai commencé à configurer « [StrongSwan](https://docs.strongswan.org/) » v6 (avec la [librairie _OQS_](https://tracker.debian.org/pkg/liboqs)) qui utilise l’interface de contrôle IKE (VICI : Versatile IKE Control Interface) moderne telle qu’implémentée par le plugin vici et l’outil de ligne de commande `swanctl`. Çà prend en charge le « TPM 2.0 », [IKE (Internet Key Exchange)](https://fr.wikipedia.org/wiki/Internet_Key_Exchange)v2, l’IPv4, l’IPv6 - [TPM (Trusted Platform Module](https://fr.wikipedia.org/wiki/Trusted_Platform_Module)) est une puce matériel qui permet de stocké nos clefs de cryptage dans du matériel et non pas dans l’Opérating System. Les Yubikey sont des TPM je crois. C’est assez simple si vous connaissez seulement strongSwan par « ipsec.conf » * * * Pour exemple une connexion par PQ-StrongSwan v6.x (c’est un début) : ```auto root@vps:/etc/swanctl # swanctl --list-sas gw-gw: #9, ESTABLISHED, IKEv2, da84ec1fab3489b5_i* 233f22e90032195c_r local 'vps.zw3b.eu' @ 135.125.133.51[4500] remote 'bw.zw3b.eu' @ 109.210.56.240[4500] [172.16.1.1 fec3::1] AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5 established 8770s ago, rekeying in 4740s gw-gw: #14, reqid 2, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA2_256_128/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3 installed 3112s ago, rekeying in 1905s, expires in 2828s in cfea19fe, 323128 bytes, 3107 packets, 1s ago out c37a3fb6, 319488 bytes, 3072 packets, 1s ago local 10.133.0.0/24 fec1::/120 remote 172.16.1.1/32 fec3::1/128 ``` J’arrive à ces algorithmes : ```auto # Par default (sans config de ciphers) : IKE IKE:AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256 # Configuration : IKE IKE:AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5 ``` ```auto # Par default (sans config de ciphers) : ESP ESP:AES_GCM_16-128 # Config ESP sur un strongSwan 5.9.13 + peut-être CURVE_25519 ;) ESP:AES_CBC-256/HMAC_SHA2_256_128 # Config ESP sur un strongSwan 6.0.0beta5 ESP:AES_CBC-256/HMAC_SHA2_256_128/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3 ESP:AES_CBC-256/HMAC_SHA2_256_128/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5 ``` Au passage j’ai remarqué qu’à l’initiate, l’algo ESP est en `ESP:AES_CBC-256/HMAC_SHA2_256_128` puis à la rekeying, la réponse à un `swan --list-sas` change en `ESP:AES_CBC-256/HMAC_SHA2_256_128/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5` > **En image :** > > ```auto > root@bw:~ # swanctl --initiate --child gw-gw > root@bw:~ # swanctl --list-sas > gw-gw: #1, ESTABLISHED, IKEv2, c92d7a824e241c73_i* 3bbbeb068f80f33d_r > local 'bw.zw3b.eu' @ 192.168.1.254[4500] [172.16.1.1 fec3::1] > remote 'vps.zw3b.eu' @ 135.125.133.51[4500] > AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5 > established 1584s ago, rekeying in 12607s > gw-gw: #2, reqid 2, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA2_256_128 > installed 81s ago, rekeying in 3239s, expires in 3879s > in c86530da, 0 bytes, 0 packets > out c1dcff3b, 0 bytes, 0 packets > local 172.16.1.1/32 fec3::1/128 > remote 10.133.0.0/24 fec1::/120 > > ``` > > ```auto > root@bw:~ # swanctl --list-sas > gw-gw: #1, ESTABLISHED, IKEv2, c92d7a824e241c73_i* 3bbbeb068f80f33d_r > local 'bw.zw3b.eu' @ 192.168.1.254[4500] [172.16.1.1 fec3::1] > remote 'vps.zw3b.eu' @ 135.125.133.51[4500] > AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5 > established 1584s ago, rekeying in 12607s > gw-gw: #11, reqid 2, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA2_256_128/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5 > installed 81s ago, rekeying in 3239s, expires in 3879s > in c86530da, 0 bytes, 0 packets > out c1dcff3b, 0 bytes, 0 packets > local 172.16.1.1/32 fec3::1/128 > remote 10.133.0.0/24 fec1::/120 > > ``` Je n’ai pas encore vérifier les trames ESP : [Taking Traffic Dumps on Linux :: strongSwan Documentation](https://docs.strongswan.org/docs/5.9/install/trafficDumps.html) pour savoir quel algorithme encode le trafic. **Quelqu’un aurait un Dump ?** C’est vraiment bon, çà change. 😍 😋 😁 * * * > Note de Moi-même 16h51 UTC+1 : > > Tiens « quand j’y pense », niveau IPv6 – on va se faire de belles grasses Secure Wide Area Networks : > > ```auto > vmbr1: flags=4163 mtu 1500 > inet 10.133.0.254 netmask 255.255.255.0 broadcast 10.133.0.255 > inet6 fe80::7069:deff:fe53:4683 prefixlen 64 scopeid 0x20 > inet6 fec1::1 prefixlen 120 scopeid 0x40 > inet6 fc00:41d0:701:1100::fffe prefixlen 104 scopeid 0x0 > ether 72:69:de:53:46:83 txqueuelen 1000 (Ethernet) > RX packets 63447245 bytes 13819783311 (12.8 GiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 58692045 bytes 7227968681 (6.7 GiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > ``` > > On pourrait bosser sur l’IPv6 ULA : > > - Les adresses ULA « postes »-\> `fc00::` > - Les adresses ULA « routeurs » → `fd00::` > - Les adresses ULA « encryptées » → `fe00::` > - Les liens locaux → `fe80::` et `fe85::` > - Les adresse ULA (Unique Local Area) → `ffff::` donc 😉 > > Par exemple IP address : > > ```auto > fec1::1/120 > > ``` > > Network range : > > ```auto > fec1:0000:0000:0000:0000:0000:0000:0000 > fec1:0000:0000:0000:0000:0000:0000:00ff > > Total IP addresses : 256 > > ``` > > CF : [IPv4/IPv6 subnet calculator and addressing planner](http://www.gestioip.net/cgi-bin/subnet_calculator.cgi) > **Unique\_local\_address** > > > [Unique local address - Wikipedia](https://en.wikipedia.org/wiki/Unique_local_address) > > Les adresses locales uniques utilisent le préfixe fc00::/7. Le premier bit suivant le préfixe indique, s’il est défini, que l’adresse est attribuée localement. Cela divise le bloc d’adresse en deux moitiés de taille égale, fc00::/8 et fd00::/8. > > > > Le bloc avec L = 0, fc00::/8, n’est actuellement pas défini. Il a été proposé qu’une autorité d’allocation le gère, mais cela n’a pas été accepté par l’IETF. > > > > Le bloc avec L = 1, fd00::/8 suit le format suivant. > > > > Il est divisé en préfixes /48, formés en définissant les quarante bits suivant le préfixe fd00/8 sur une chaîne de bits générée de manière aléatoire. Il en résulte le format fdxx:xxxx:xxxx::/48 pour un préfixe dans cette plage. La RFC 4193 propose une suggestion pour générer l’identifiant aléatoire afin d’obtenir un résultat de qualité minimale si l’utilisateur n’a pas accès à une bonne source de nombres aléatoires. > > > > Un préfixe de routage dans la plage fd00::/8 peut être construit en générant une chaîne hexadécimale aléatoire de 40 bits, prise pour cet exemple comme étant 0x123456789a. La chaîne est ajoutée au préfixe fd00::/8, qui forme le préfixe de routage 48 bits fd12:3456:789a::/48. Avec ce préfixe, 65536 sous-réseaux de taille /64 sont disponibles pour le réseau privé : fd12:3456:789a::/64 à fd12:3456:789a:ffff::/64. Par exemple, l’ID de sous-réseau 0x1 serait le sous-réseau fd12:3456:789a:1::/64. > > > > * * * > > > > Les préfixes de la plage fc00::/7 ont certaines caractéristiques communes avec les plages d’adresses privées IPv4 : ils ne sont pas attribués par un registre d’adresses et peuvent être utilisés dans les réseaux par n’importe qui sans implication extérieure. Il n’est pas mathématiquement garanti qu’ils soient uniques au monde, mais la probabilité d’une collision est néanmoins extrêmement faible. Les entrées DNS (Inverse Domain Name System) (dans ip6.arpa) pour les ULA fd00::/8 ne peuvent pas être déléguées dans le DNS global. > > > > Comme les ULA fc00::/7 ne sont pas destinés à être acheminés en dehors de leur domaine administratif (site ou organisation), les administrateurs de réseaux interconnectés n’ont normalement pas à se soucier du caractère unique des préfixes ULA. Cependant, si les réseaux nécessitent le routage des ULA entre eux en cas de fusion par exemple, le risque de collision d’adresses est très faible si l’algorithme de sélection RFC 4193 était utilisé. > **Link-local\_address** > > > [Link-local address - Wikipedia](https://en.wikipedia.org/wiki/Link-local_address) > > Dans les réseaux informatiques, une adresse lien-local est une adresse réseau unicast qui n’est valable que pour les communications au sein du sous-réseau auquel l’hôte est connecté. Les adresses lien-local sont le plus souvent attribuées automatiquement à l’aide d’un processus appelé configuration automatique d’adresse sans état (SLAAC) ou configuration automatique d’adresse lien-local, également connu sous le nom d’adressage IP privé automatique (APIPA) ou auto-IP. > > > > Il n’est pas garanti que les adresses lien-local soient uniques au-delà de leur segment de réseau. Par conséquent, les routeurs ne transmettent pas les paquets avec des adresses source ou de destination lien local. > > > > Les adresses lien-local IPv4 sont attribuées à partir du bloc d’adresses 169.254.0.0/16 (169.254.0.0 à 169.254.255.255). En IPv6, ils sont attribués à partir du bloc fe80::/10. > > > > Attribution d’adresse > > > > Les adresses lien-local peuvent être attribuées manuellement par un administrateur ou par des procédures automatiques du système d’exploitation. Dans les réseaux IP (Internet Protocol), ils sont attribués le plus souvent à l’aide de la configuration automatique d’adresses sans état, un processus qui utilise souvent un processus stochastique pour sélectionner la valeur des adresses lien-local, en attribuant une adresse pseudo-aléatoire différente pour chaque session. Cependant, dans IPv6, l’adresse lien-local peut être dérivée de l’adresse MAC (Media Access Control) de l’interface dans une méthode basée sur des règles, bien que cela soit obsolète pour des raisons de confidentialité et de sécurité. > > > > Dans IPv4, les adresses lien-local ne sont normalement utilisées que lorsqu’il n’existe aucun mécanisme externe de configuration d’adresse avec état, tel que le protocole DHCP (Dynamic Host Configuration Protocol), ou lorsqu’une autre méthode de configuration principale a échoué. Dans IPv6, les adresses lien-local sont toujours attribuées, ainsi que les adresses d’autres réseaux/scopes/services, et sont nécessaires au fonctionnement interne de divers composants de protocole. [De l’usage des adresses locales uniques ipv6 (ULA)](https://www.22decembre.eu/fr/2016/12/02/ula/) 🙂 ---
**Author:** ![anon36725218](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/8e8cbc/32.png) [@anon36725218](https://www.debian-fr.org/u/anon36725218)\ **Post date:** [Janvier 24, 2024, 2:36 UTC](https://www.debian-fr.org/t/quantumleap-post-quantum-strongswan-algorithms-compagnies/89398/4 "2024-01-24T14:36:41Z")
Je vous envoie mes testes de bande passante sur la connexion SWAN entre mes 2 réseaux : Sachant que j’ai connexion de 100Mbits/seconde en montant/descendant - [cf](https://www.zw3b.fr/pub/screens/orange/Screenshot%202024-01-24%20at%2014-39-11%20Speedtest%20d%e2%80%99Ookla%20%e2%80%93%20le%20test%20de%20vitesse%20de%20connexion%20global.png). Je suis donc à environ 90 Mbits/sec entre les 2 gateways et 85Mbits/secondes (bon un truc dans le genre) en rentrant des les sous-réseaux - **nikel aucune perte malgré** l’ESP en KYBER / DILITHIUM / FALCON. Le responder est le serveur dans le DATA-CENTER → `fec1::/16` L’initiateur est la machine sur mon réseau local 😉 → `fec3::/XX` ```auto root@responder:/etc/swanctl # ifconfig ens3: flags=4163 mtu 1500 ether fa:16:3e:16:c6:f3 txqueuelen 1000 (Ethernet) RX packets 203396822 bytes 90473774124 (84.2 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 215203934 bytes 43626968305 (40.6 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Boucle locale) RX packets 367 bytes 44818 (43.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 367 bytes 44818 (43.7 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vethlQV0nW: flags=4163 mtu 1500 inet6 fe80::fc16:1fff:fe91:b2e prefixlen 64 scopeid 0x20 ether fe:16:1f:91:0b:2e txqueuelen 1000 (Ethernet) RX packets 64107583 bytes 14963711553 (13.9 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 72208200 bytes 8087855888 (7.5 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vmbr0: flags=4163 mtu 1500 inet 135.125.133.51 netmask 255.255.255.0 broadcast 135.125.133.255 inet6 fe80::24b2:4ff:fea2:c384 prefixlen 64 scopeid 0x20 inet6 2001:41d0:701:1100::6530 prefixlen 128 scopeid 0x0 ether 26:b2:04:a2:c3:84 txqueuelen 1000 (Ethernet) RX packets 201481838 bytes 87488395208 (81.4 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 215203934 bytes 43626968305 (40.6 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vmbr1: flags=4163 mtu 1500 inet 10.133.0.254 netmask 255.255.255.0 broadcast 10.133.0.255 inet6 fe80::7069:deff:fe53:4683 prefixlen 64 scopeid 0x20 inet6 fec1::1 prefixlen 16 scopeid 0x40 inet6 fc00:41d0:701:1100::fffe prefixlen 64 scopeid 0x0 ether 72:69:de:53:46:83 txqueuelen 1000 (Ethernet) RX packets 64107547 bytes 14066203279 (13.1 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 59347563 bytes 7419102364 (6.9 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ``` → `vmbr1` inet6 `fec1::1` prefixlen **16** scopeid `0x40` \ - address ajoutée manuellement pour swanctl sur le responder network range : ` fec1:0000:0000:0000:0000:0000:0000:0000- fec1:ffff:ffff:ffff:ffff:ffff:ffff:ffff` ```auto root@responder.ns3:/ # ifconfig eth0: flags=4163 mtu 1500 inet 10.133.0.1 netmask 255.255.255.0 broadcast 10.133.0.255 inet6 fe80::216:3eff:fe78:442d prefixlen 64 scopeid 0x20 inet6 fc00:41d0:701:1100::1 prefixlen 64 scopeid 0x0 inet6 fec1:41d0:701:1100::1 prefixlen 16 scopeid 0x40 ether 00:16:3e:78:44:2d txqueuelen 1000 (Ethernet) RX packets 72166238 bytes 7977831957 (7.4 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 64091381 bytes 14962204096 (13.9 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ``` → `eth0` inet6 `fec1:41d0:701:1100::1` prefixlen **16** scopeid `0x40` \ - address ajoutée manuellement pour swanctl sur un container du responder (pour tester le network IPv6::/16) network range : ` fec1:0000:0000:0000:0000:0000:0000:0000- fec1:ffff:ffff:ffff:ffff:ffff:ffff:ffff` Je ne pense pas que cela soit bien/bon (une bonne façon de/à réfléchir) puisque le « container NS3 » n’est pas directement connecté à ESP. Qu’en pensez-vous !? ```auto root@responder.ns3:/ # iperf3 -s ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from fec3::1, port 35176 [5] local fec1:41d0:701:1100::1 port 5201 connected to fec3::1 port 35192 [ID] Interval Transfer Bitrate [5] 0.00-1.00 sec 8.89 MBytes 74.6 Mbits/sec [5] 1.00-2.00 sec 10.5 MBytes 88.0 Mbits/sec [5] 2.00-3.00 sec 10.5 MBytes 88.1 Mbits/sec [5] 3.00-4.00 sec 10.0 MBytes 83.8 Mbits/sec [5] 4.00-5.00 sec 10.1 MBytes 84.9 Mbits/sec [5] 5.00-6.00 sec 10.1 MBytes 84.8 Mbits/sec [5] 6.00-7.00 sec 10.5 MBytes 88.1 Mbits/sec [5] 7.00-8.00 sec 9.97 MBytes 83.6 Mbits/sec [5] 8.00-9.00 sec 9.85 MBytes 82.7 Mbits/sec [5] 9.00-10.00 sec 10.2 MBytes 85.9 Mbits/sec [5] 10.00-10.04 sec 390 KBytes 84.0 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ID] Interval Transfer Bitrate [5] 0.00-10.04 sec 101 MBytes 84.4 Mbits/sec receiver ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- ``` ```auto root@initiator:/etc/swanctl # ifconfig enp3s0: flags=4163 mtu 1500 ether c8:9c:dc:2e:2e:1c txqueuelen 1000 (Ethernet) RX packets 1164546 bytes 311865167 (297.4 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 880428 bytes 355142019 (338.6 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Boucle locale) RX packets 174 bytes 20372 (19.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 174 bytes 20372 (19.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vethQG47NH: flags=4163 mtu 1500 inet6 fe80::fc7c:11ff:fe6f:82db prefixlen 64 scopeid 0x20 ether fe:7c:11:6f:82:db txqueuelen 1000 (Ethernet) RX packets 5861 bytes 1933350 (1.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 171888 bytes 8994071 (8.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vmbr0: flags=4163 mtu 1500 inet 192.168.1.254 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 2a01:cb1d:2d4:88ff:ff:ff:ff:ff prefixlen 56 scopeid 0x0 inet6 fec3::1 prefixlen 128 scopeid 0x40 inet6 2a01:cb1d:2d4:8800::1 prefixlen 128 scopeid 0x0 inet6 fe80::e825:b5ff:feab:55cc prefixlen 64 scopeid 0x20 ether ea:25:b5:ab:55:cc txqueuelen 1000 (Ethernet) RX packets 744437 bytes 154979604 (147.8 MiB) RX errors 0 dropped 51237 overruns 0 frame 0 TX packets 708403 bytes 346196603 (330.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vmbr1: flags=4163 mtu 1500 inet 10.116.42.254 netmask 255.255.255.0 broadcast 10.116.42.255 inet6 fe80::88f5:2cff:fe38:e29a prefixlen 64 scopeid 0x20 inet6 2a01:cb1d:2d4:88ff::3:ff prefixlen 112 scopeid 0x0 ether 8a:f5:2c:38:e2:9a txqueuelen 1000 (Ethernet) RX packets 5848 bytes 1849560 (1.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 199 bytes 64371 (62.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ``` Test entre GateWay-GateWay-VLAN: ```auto root@initiator:/etc/swanctl # iperf3 -c fec1:41d0:701:1100::1 Connecting to host fec1:41d0:701:1100::1, port 5201 [5] local fec3::1 port 35192 connected to fec1:41d0:701:1100::1 port 5201 [ID] Interval Transfer Bitrate Retr Cwnd [5] 0.00-1.00 sec 10.7 MBytes 89.4 Mbits/sec 0 943 KBytes [5] 1.00-2.00 sec 10.6 MBytes 88.9 Mbits/sec 1 660 KBytes [5] 2.00-3.00 sec 10.2 MBytes 85.3 Mbits/sec 0 660 KBytes [5] 3.00-4.00 sec 10.2 MBytes 85.9 Mbits/sec 2 348 KBytes [5] 4.00-5.00 sec 9.96 MBytes 83.5 Mbits/sec 0 372 KBytes [5] 5.00-6.00 sec 10.4 MBytes 87.3 Mbits/sec 0 384 KBytes [5] 6.00-7.00 sec 10.5 MBytes 88.4 Mbits/sec 0 389 KBytes [5] 7.00-8.00 sec 10.1 MBytes 84.8 Mbits/sec 0 392 KBytes [5] 8.00-9.00 sec 9.33 MBytes 78.2 Mbits/sec 0 392 KBytes [5] 9.00-10.00 sec 10.8 MBytes 90.8 Mbits/sec 0 393 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ID] Interval Transfer Bitrate Retr [5] 0.00-10.00 sec 103 MBytes 86.3 Mbits/sec 3 sender [5] 0.00-10.04 sec 101 MBytes 84.4 Mbits/sec receiver iperf Done. ``` ```auto root@initiator:/etc/swanctl # traceroute6 -n fec1:41d0:701:1100::1 traceroute to fec1:41d0:701:1100::1 (fec1:41d0:701:1100::1), 30 hops max, 80 byte packets 1 fec1::1 24.642 ms 25.167 ms 25.153 ms 2 fec1:41d0:701:1100::1 25.207 ms 25.215 ms 25.198 ms ``` Test entre GateWay-GateWay: ```auto root@initiator:/etc/swanctl # iperf3 -c fec1::1 Connecting to host fec1::1, port 5201 [5] local fec3::1 port 33458 connected to fec1::1 port 5201 [ID] Interval Transfer Bitrate Retr Cwnd [5] 0.00-1.00 sec 10.1 MBytes 84.8 Mbits/sec 0 427 KBytes [5] 1.00-2.00 sec 10.6 MBytes 89.0 Mbits/sec 0 471 KBytes [5] 2.00-3.00 sec 10.8 MBytes 90.3 Mbits/sec 1 363 KBytes [5] 3.00-4.00 sec 9.30 MBytes 78.0 Mbits/sec 8 287 KBytes [5] 4.00-5.00 sec 9.86 MBytes 82.7 Mbits/sec 0 307 KBytes [5] 5.00-6.00 sec 7.80 MBytes 65.4 Mbits/sec 3 239 KBytes [5] 6.00-7.00 sec 8.17 MBytes 68.6 Mbits/sec 0 258 KBytes [5] 7.00-8.00 sec 9.22 MBytes 77.4 Mbits/sec 0 282 KBytes [5] 8.00-9.00 sec 9.31 MBytes 78.1 Mbits/sec 0 302 KBytes [5] 9.00-10.00 sec 9.34 MBytes 78.3 Mbits/sec 0 316 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ID] Interval Transfer Bitrate Retr [5] 0.00-10.00 sec 94.5 MBytes 79.3 Mbits/sec 12 sender [5] 0.00-10.04 sec 93.4 MBytes 78.1 Mbits/sec receiver iperf Done. ``` ```auto root@responder:/etc/swanctl # iperf3 -s ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from fec3::1, port 33454 [5] local fec1::1 port 5201 connected to fec3::1 port 33458 [ID] Interval Transfer Bitrate [5] 0.00-1.00 sec 9.05 MBytes 75.9 Mbits/sec [5] 1.00-2.00 sec 10.3 MBytes 86.7 Mbits/sec [5] 2.00-3.00 sec 10.4 MBytes 87.1 Mbits/sec [5] 3.00-4.00 sec 9.36 MBytes 78.5 Mbits/sec [5] 4.00-5.00 sec 9.95 MBytes 83.5 Mbits/sec [5] 5.00-6.00 sec 7.62 MBytes 63.9 Mbits/sec [5] 6.00-7.01 sec 8.52 MBytes 70.7 Mbits/sec [5] 7.01-8.00 sec 9.00 MBytes 76.3 Mbits/sec [5] 8.00-9.00 sec 9.34 MBytes 78.3 Mbits/sec [5] 9.00-10.00 sec 9.55 MBytes 80.1 Mbits/sec [5] 10.00-10.04 sec 307 KBytes 69.3 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ID] Interval Transfer Bitrate [5] 0.00-10.04 sec 93.4 MBytes 78.1 Mbits/sec receiver ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- ``` Romain 🙂 🤠 ---
**Author:** ![anon36725218](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/8e8cbc/32.png) [@anon36725218](https://www.debian-fr.org/u/anon36725218)\ **Post date:** [Mars 15, 2024, 4:57 UTC](https://www.debian-fr.org/t/quantumleap-post-quantum-strongswan-algorithms-compagnies/89398/5 "2024-03-15T16:57:19Z")
J’ajoute ce sujet que j’ai ouvert dernièrement → [🥳 Network IPv6 - IPSec - strongSwan - Modern Security communication](https://www.debian-fr.org/t/network-ipv6-ipsec-strongswan-modern-security-communication/89528) 😊 ---
**Author:** ![anon36725218](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/8e8cbc/32.png) [@anon36725218](https://www.debian-fr.org/u/anon36725218)\ **Post date:** [Avril 9, 2024, 2:06 UTC](https://www.debian-fr.org/t/quantumleap-post-quantum-strongswan-algorithms-compagnies/89398/6 "2024-04-09T14:06:23Z")
Bonjour, sans parler d’algorithme pour la cryptographie quantique, la technologie serait un clef stockée dans un photon… Des informations ci-dessous 😉 [La cryptographie quantique avance grâce au record de chercheurs danois](https://www.journaldugeek.com/2024/04/04/la-cryptographie-quantique-avance-grace-au-record-de-chercheurs-danois/) Je pense qu’ils utilisent le [protocole BB84](https://fr.m.wikipedia.org/wiki/Protocole_BB84) pour la techno de transmission. Et sûrement en utilisant ce type de matériels pour la [distribution de clés quantique](https://www.aureatechnology.com/fr/applications/distribution-cles-quantique.html) (QKD) - compteur de photons SPD\_A d’AUREA Technology. Bonne journée à vous. Romain