QuantumLeap + Post Quantum StrongSwan : Algorithms & compagnies

Tags: #<Tag:0x00007fc9f23129f0> #<Tag:0x00007fc9f2312180>

Bonjour,

Je vous souhaites une bonne année 2024 :partying_face:, en vous souhaitant des meilleurs vœux.

Avant tout, je souhaite vous partager cette information (j’ai « copié », pour celles et ceux qui ne sont pas encore abonné·e·s, l’article de Science & Vie – Groupe 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 :wink:

Sinon, je vous invite à voir/lire cette page : PostQuantum StrongSwan v6.x + la documentation.

#PQStrongSwan #StrongSwan #VPN #Security

Ci-dessous quelques Algorithmes de cryptage (authentification et encryption) :

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
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
  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 :

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
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.

:globe_with_meridians: :sparkles: :rainbow:

#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 :confused:

J’ajoute ces sites web pour Post Archives :wink:

CRYSTALShttps://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

À 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 ».

:slight_smile:

Bonne journée.

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/

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 :

:wink:

Bonne journée à toutes et à tous.


J’ai commencé à configurer « StrongSwan » v6 (avec la librairie OQS) 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)v2, l’IPv4, l’IPv6 - TPM (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) :

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 :

# 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

# 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 :
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
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 pour savoir quel algorithme encode le trafic.

Quelqu’un aurait un Dump ?

C’est vraiment bon, çà change.

:heart_eyes: :yum: :grin:


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 :

vmbr1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  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<link>
        inet6 fec1::1  prefixlen 120  scopeid 0x40<site>
        inet6 fc00:41d0:701:1100::fffe  prefixlen 104  scopeid 0x0<global>
        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 :wink:

Par exemple IP address :

fec1::1/120

Network range :

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

Unique_local_address

Unique local address - Wikipedia
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
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)

:slight_smile:

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.

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 :wink:fec3::/XX

root@responder:/etc/swanctl # ifconfig
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  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<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        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<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fc16:1fff:fe91:b2e  prefixlen 64  scopeid 0x20<link>
        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<UP,BROADCAST,RUNNING,MULTICAST>  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<link>
        inet6 2001:41d0:701:1100::6530  prefixlen 128  scopeid 0x0<global>
        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<UP,BROADCAST,RUNNING,MULTICAST>  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<link>
        inet6 fec1::1  prefixlen 16  scopeid 0x40<site>
        inet6 fc00:41d0:701:1100::fffe  prefixlen 64  scopeid 0x0<global>
        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<site>
\
- 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

root@responder.ns3:/ # ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  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<link>
        inet6 fc00:41d0:701:1100::1  prefixlen 64  scopeid 0x0<global>
        inet6 fec1:41d0:701:1100::1  prefixlen 16  scopeid 0x40<site>
        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<site>
\
- 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 !?

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
-----------------------------------------------------------
root@initiator:/etc/swanctl # ifconfig
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  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<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        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<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fc7c:11ff:fe6f:82db  prefixlen 64  scopeid 0x20<link>
        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<UP,BROADCAST,RUNNING,MULTICAST>  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<global>
        inet6 fec3::1  prefixlen 128  scopeid 0x40<site>
        inet6 2a01:cb1d:2d4:8800::1  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::e825:b5ff:feab:55cc  prefixlen 64  scopeid 0x20<link>
        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<UP,BROADCAST,RUNNING,MULTICAST>  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<link>
        inet6 2a01:cb1d:2d4:88ff::3:ff  prefixlen 112  scopeid 0x0<global>
        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:

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.
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:

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.
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 :slight_smile:

:cowboy_hat_face:

J’ajoute ce sujet que j’ai ouvert dernièrement → :partying_face: Network IPv6 - IPSec - strongSwan - Modern Security communication

:blush:

Bonjour, sans parler d’algorithme pour la cryptographie quantique, la technologie serait un clef stockée dans un photon…

Des informations ci-dessous :wink:

La cryptographie quantique avance grâce au record de chercheurs danois

Je pense qu’ils utilisent le protocole BB84 pour la techno de transmission.

Et sûrement en utilisant ce type de matériels pour la distribution de clés quantique (QKD) - compteur de photons SPD_A d’AUREA Technology.

Bonne journée à vous.

Romain