crypto_key.format.txt

                                  ┏━━━━━━━━━━━━━━━━┓
                                  ┃   CRYPTO_KEY   ┃
                                  ┗━━━━━━━━━━━━━━━━┛

Différents types :
  - password avec caractères graphiques
  - passphrase
  - passcode (uniquement des chiffres)
  - clef binaire
  - "méthode" (ex : route cipher)
  - clef biométrique (conversion analogue->digital->hash ?)

Données biométriques :
  - ex :
    - rétine
    - empreinte digitale
  - usurpation :
    - stade analogue :
      - relever empreinte digitale
  - problème de révocation si usurpation

Password/passphrase : 
  - plus mémorisable, mais susceptible à dictionary attack
  - password psychology : étude de la rétention des passwords

Stockage :
  - mémoire d'un individu 
    - problème de rétention 
  - support physique : bout de papier, etc.
    - évite problème de rétention, mais induit problème de lecture du support physique
    - keyfile : fichier informatique 
  - données biométriques

Clef privée/secrète aléatoire vs non-aléatoire :
  - aléatoire : 
      - moins mémorisable
  - non-aléatoire :
      - réduit K, donc brute-force plus rapide
      - ex de password/passphrase :
        - cause de réduction de K :
          - utilisation de caractères/digrammes/etc. plus souvent que d'autres (frequency analysis) 
              - Contrer cela : 
                  - hash function pour augmenter diffusion
          - utilisation de mots existants (attaque par dictionnaire)
              - réduit grandement K -> clef privée/secrète devrait donc toujours être aléatoire
              - Contrer cela : pas possible
                  - hash function ne résout pas le problème, car attaquant peut utiliser un hash de chaque mot du dictionnaire
          - taille variable du password (souvent plus courte que maximum)
              - Contrer cela : 
                  - augmenter imposer taille minimum pour composer réduction de K

Asym. vs sym. :
  - asymétrique :
    - clef privées, crées localement
    - clef publiques, distribuées sans confidentialité
    - besoin d'une seule paire par entité
  - symétrique :
    - pre-shared key (PSK) / secret key, distribuées confidentiellement
    - besoin d'une clef par paire d'entité, soit n(n - 1) / 2 clef, où n est nombre d'entités
    - recommander d'en changer régulièrement (clefs de session)

Key management possible pour algo sym. :
  - Principe :
    - Trent et Alice échange sur un channel secure la clef k₁
    - Trent et Bob échange sur un channel secure la clef k₂
    - Lorsqu'Alice veut communiquer avec Bob :
        - Trent envoie une clef de session kₓ chiffrée avec k₁ à Alice, et chiffrée avec k₂ à Bob
        - Alice et Bob communique avec kₓ
        - clef de session est mise à jour à intervals réguliers
    - Avantages :
        - sur un réseau de n entités, besoin que d'une clef par entité, et non n clefs
            - ajout d'une nouvelle entité ne crée qu'une nouvelle clef, et non n clefs pour cette entité + une nouvelle pour
              chaque autre entité
            - problème de distribution de clef seulement une fois par entité, et non pour chaque communication avec nouvelle
              entité
            - pas de problème de distribution de clef pour création nouvelle clef de session
    - Désavantages :
        - implique Trent :
            - problème de confiance, car Trent a toutes les clefs secrètes, et peut donc lire et modifier
            - tous problèmes liés à système centralisé
                - notamment fait de Trent un single point of failure

Key length :
  - nombre de bits de la clef
  - implique le nombre de permutation possibles de la clef (par exemple pour une clef de n bits, 2^n).
  - variable (ex: AES) vs fixe (ex : DES)
  - limité à l'export à 64 bits aux USA (mais peut obtenir autorisation)

Bits of security :
  - nombre de permutations _maximale_ pour attaquer un algo, avec la meilleure attaque (=> moyenne est /2)
  - bits of security n'est pas forcément == key length :
    - si algo est breaked
    - pour asymetric crypto, hash function, etc.
  - si pas de break :
    - symetric algo : souvent key length == bits of security
    - asymétric algo : bits of security bien < key length (mais related) => key + grande requise
  - aujourd'hui :
    - 128 bits of security est encore secure pour plusieurs années, 256 est vraiment secure

IV :
  - input d'une fonction E, comme e pour Eₑ. Cependant, pas besoin d'être confidentiel, mais doit :
    - ou :
      - ne pas forcément être unique : peut être une fixed value
      - cryptographic nonce ("stateful scheme") : être "unique", ne pas se répéter
        - si répétition, provoque mêmes problèmes que mode of operation ECB
        - ex : CTR mode of operation
      - ("randomized scheme") être "unique" + "unpredictible", aléatoire ou pseudo-aléatoire
        - ex : autres modes of operations
        - doit éviter collisions et birthday attacks
    - dans tous les cas pas confidentielle : doit être communiquée au destinataire
      - si randomized scheme, doit être générée par émetteur, sinon, peut être prédéfini
  - différent donc d'une clef, qui doit être "unique" + "unpredictible" + confidentielle
  - pour block cipher, en général taille == block size du block cipher
    - idéalement >= size length, si randomized algo, pour contrer time-memory-data trade-off attacks

Salt :
  - IV utilisé par une hash function
  - le salt est présent de manière non-chiffré concaténé à l'output du hash
  - but est :
    - contrer les precomputed lookup table attacks (dont rainbow tables) :
      - précalcul doit être effectué pour chaque salt possible
      - doit donc utiliser 2ⁿ plus de mémoire, et de temps de précalcul
    - (plus rare) si digest visibles, éviter qu'un attaquant devine que m₁ == m₂, car d₁ == d₂
      - ex : sans salt, cracker un hash de password, cracke tous les passwords avec le même digest (sauf si c'est à cause
        d'une collision, ce qui devrait être peu fréquent)
  - équivaut donc conceptuellement à :
      - un MAC dont la clef n'est pas confidentielle
  - souvent utilise key stretching en plus du salt, pour éviter precomputed lookup table + diminuer risque de bruteforce : 
    F(k, salt, nb_iterations)

Key management :
  - comprend :
    - key establisment/exchange :
      - key generation :
          - création de clef(s)
          - souvent génération cherche à donner à clef une parfaite diffusion
          - sous-type :
            - key agreement :
              - lorsque clef est générée de manière commune par Alice et Bob
              - pour éviter MitM attack, souvent algo asym.
      - dont key transport :
          - communication de la clef
    - key storage
    - key maintenance :
        - mise à jour des clefs par un nouvel key establisment

TTP (Trusted Third Party) / Trent :
  - peut être :
      - unconditionnaly trusted :
          - possède les clefs secrètes ou privées du système
          - ou est chargé de l'association des clefs privées avec les clefs publiques
      - functionnaly trusted :
          - est seulement chargé de l'identification des clefs publiques
          - ne possède donc que les clef publiques

Key derivation function (KDF) :
  - function créant une seconde clef ("derived key") à partir d'une première clef ("master key") en input
  - utilisation :
    - key stretching
    - key scheduling
    - key diversification
    - key generation, avec comme but d'éviter une weak key (weakness dépend de l'algo)
  - souvent désirable de produire clef pseudo-aléatoire
  - peut utiliser une hash function (souvent MAC) ou PRNG
  - ex : PBKDF2, bcrypt, scrypt

Key scheduling :
  - création de round keys/subkeys à partir d'une master key dans un block cipher
  - peut utiliser de la key stretching
  - peut chercher à éviter les weak keys
  - ex (du moins bien au mieux) :
    - simple split de la master key
    - simple split, puis transformation à chaque round (par exemple rotation)
    - utilise une ou plusieurs one-way functions sur la master key :
      - one-way function peut parfois être le cipher lui-même, avec comme clef une constante
  - susceptible aux related-key attacks et slide attacks

Key stretching :
  - diminue temps moyen d'un break par brute-force, non en augmentant bits de la clef, mais en augmentant temps requis par
    essai du brute-force
  - souvent utilisé pour permettre à des clefs à faible key length, dont passwords, à être quand même utilisé de manière secure
  - en général, temps additionnel n'est pas pénible pour l'utilisateur légitime (par ex. 1 seconde), mais augmente grandement
    temps requis pour brute-force (si 1 seconde au lieu de 0.001 secondes -> 1000 fois plus long)
  - méthodes pour augmenter temps :
      - si algo de vérification est black box (par exemple authentication via password sur internet (pas accès au serveur) en
        local (privilèges moindres)), l'algo peut ajouter un temps fixe
      - utiliser un KDF
        - en général une succession d'une hash function, ou un block cipher utilisé comme tel
        - key strengthening : 
          - utilise un salt lors de la première computation, mais ne l'inclue pas dans le digest. 
          - Ainsi, toute personne (dont légitime) souhaitant vérifier qu'un plaintext et un digest concorde doit faire un
            bruteforce du salt, ce bruteforce ayant pour but d'augmenter temps (key stretching)
        - peut faire partie de la key schedule d'un block cipher
      - rajouter algo soluble seulement par un humain
        - ex : captcha
  
Key diversification :
  - production de plusieurs clefs de session à partir d'une master key :
    - doit être one-way function
  - but : si adversaire obtient clef de session, n'obtient pas master key et donc clefs de session suivantes

Content-encryption key (CEK) :
  - clef chiffrée par une seconde clef, une key encryption key (KEK)
  - cette clef peut donc être distribuée de manière confidentielle
  - elle est renouvelée ensuite fréquemment
  - la KEK est souvent une clef privée asym.
  - but : 
    - limiter :
      - timeframe possible d'une attaque
      - datas possibles d'une CPA, KPA ou CCA
    - utiliser algo plus rapide avec la CEK que celui de la KEK : en général KEK est clef privée asym. (lent) et CEK utilise
      un algo sym., plus rapide
    - ne pas pouvoir deviner KEK si compromission de la CEK
  - deux types :
    - Traffic-encryption key (TEK) / session key / multicast key / Message encryption key (MEK) :
      - clef utilisée dans un algo sym. (PSK)
    - Transmission security key (TSK) :
      - clef utilisée dans un PRNG (seed)
  - problème : si key generation problématique (notamment mauvaise diffusion), attaques possibles
  - Perfect Forward Secrecy (PFS) :
    - fait que la compromission de la KEK ne compremet pas les CEK produites, et que compromission d'une CEK ne compremet pas
      les autres CEK
    - possible que si KEK est une paire de clef privée/publique asym.
    - pour ce faire, notamment les CEK ne doivent pas être utilisées comme KEK

Pre-placed key : 
  - grand nombre de clefs mises dans un tamper-resistant crypto hardware pour lui fournir des clefs pour une période donnée

RED key :
  - clef pouvant être facilement copiée : 
    - paper key, sur papier
    - unencrypted electronic key
  - opposé : encrypted electronic key ("benign key / black key")

Weak key :
  - clef ayant des effets indésirables sur un cipher donné
  - cipher doivent chercher à ne pas en avoir :
    - peuvent utiliser KDF pour cela
    - un cipher sans weak keys a un flat/linear keyspace
  - ex :
    - crypto classique : mixed alphabet avec alphabet mal mélangé comme clef -> chiffre moins bien
    - DES :
      - si clef est 0x0101... ou 0xfefe..., alors :
        - les round keys sont 0x00..., 0x11... ou 0x0101...
        - chiffrer deux fois revient au départ
  - il y a aussi des weak IV
  - si cipher a weak keys, contre-mesures :
    - identifier weak keys et détecter si clef == une des weak keys, auquel cas, modifier
    - choisir clef at random pour réduire odds
  - peut être problématique dans les keyed hash function ou hash compression function, où un attaquant peut utiliser une weak
    key choisie pour obtenir des collisions

Diceware :
  - méthode pour créer une passphrase aléatoire :
    - jeter cinq fois un dé représentant les 5 chiffres d'un nombre
    - choisir le mot numéro nombre dans une wordlist
    - chaque mot a une entropie de log₂(6^5) == 13 bits