asymetric_crypto.theory.txt

                                  ┏━━━━━━━━━━━━━━━━━━━━━━┓
                                  ┃   ASYMETRIC_CRYPTO   ┃
                                  ┗━━━━━━━━━━━━━━━━━━━━━━┛

Par rapport à algo sym. :
  - désavantages :
    - clef plus longues
    - bien moins efficient
    - ne peut pas être utilisé comme primitive pour des hashs fonction, PRNG (pourquoi ???), et utilise elle-même un algo sym.
      comme primitive
  - avantages :
    - key distribution dans un channel pas nécessairement secure
        - par conséquent, pas besoin de modifier la clef fréquemment

Algo asymétrique :
  - basé sur trapdoor function asymétrique :
    - connaissant e mais ignorant d, tout le monde peut faire Eₑ (chiffrer), mais seule Alice (ayant d) peut faire Dᵈ (déchiffrer)
    - d (trapdoor info) est private key
    - e est publique key
      - publique => peut être distribuée de manière non-secure (mais a toujours besoin d'etre authenticated, via key
        authentication)
  - confidentialité :
    - Eₑ : M -> C, tout le monde peut chiffrer car e est public
    - Dᵈ : C -> M, seule Alice peut déchiffrer
  - digital signature :
    - comme il s'agit d'une permutation, Dᵈ(Eₑ(m)) == x, mais aussi Eₑ(Dᵈ(m))
    - on peut donc inverser rôle de D et E pour chiffrer/déchiffrer
    - donc :
      - Dᵈ : M -> C, seule Alice peut chiffrer
        - Dᵈ est appelé aussi S₁, signing fonction
        - C est appelé aussi S, signature space, avec des signatures {s₁,...,sₙ}
      - Eₑ  : S -> M, tout le monde peut déchiffrer car e est public
        - ( Eₑ(s) == m ), et non Eₑ, est aussi appelé V₁, verification fonction
      - d et e sont alors appelés les signature keys
    - donc si e est prouvé être clef publique d'Alice (trust model), seule Alice a pu produire ciphertext (si forgery
      impossible) => message chiffré ainsi a entity authentication + message authentication
    - si D propage erreur de transmission (quasiment toujours le cas), donne aussi intégrité (contre corruption involontaire)
      => donc non-répudiation.
    - Pourrait aussi utiliser aussi checksum pour cela :
      - mais le fait que D propage erreur suffit théoriquement
      - Cependant, checksum est signé au lieu du message entier :
        - pour des raisons de performance, en utilisant algo sym. pour la transmission du message
        - aussi semble protéger parfois contre des CCA, qui pourrait retrouver le ciphertext, et ici retrouverait que le hash

Digital signature, 3 éléments :
  - key generation : création de d et e
  - signature scheme : paire Dᵈ;Eₑ
  - trust model : vérification que e appartient à Alice

Key authentication :
  - clef publique peut être distribuée sur un channel insecure, mais toujours risque d'attaque man-in-the-middle
      => besoin de key authentication (fait de rattacher une clef à une entity)
  - vérifier que Trent distribuant clef publique de Alice :
    - il s'agit bien de clef publique d'Alice :
      - Trent a fait les checks nécessaires ("trust")
      - ne l'a pas modifié
        - peut mener notamment à vérifier qu'il s'agisse bien de Trent
  - si Trent == Alice (self-signed certificate) : on a soit même fait les checks nécessaires

Certificate :
  - tous les certificates sont contenus dans un repositery/public file
  - key authentication document, i.e. confirming link between Bob entity information and Bob public key
     - first a CSR, i.e. plaintext entity info + signature by Bob private key of entity info + Bob public key
        - among entity info:
           - Common Name (CN): hostname, e.g. www.google.fr. Can use wilcard * from subdomains: *.google.fr
           - Alternative names: can use for other hostnames, using IP instead of DNS name, etc.
           - Email address: often must be same as email found on whois HOST. Can be checked by CA.
           - Other info
     - Trent takes CSR as input and issued a certificate:
        - structure:
           - CSR + signature by Trent private key of CSR + Trent public key + Trent certificate
           - Can also include:
              - Validity period, to limit certificate steal impact in time
              - Some extensions fields
        - Trent can be Bob, in which case it is a self-signed certificate
           - Since Trent certificate must be verified itself against another Trent, at some points the chain stops to
             a self-signed certificate, i.e. "root Trent"
        - Trent certificate is contained inside Bob certificate, so verification can be done locally.
           - root Trent: only need to store locally known root Trent certificates to verify any chain of trust they verify,
             through other Trents
     - CRL (Certificate Revocation List):
        - List of certificates revoked by CA. Reasons: private key compromised, CSR was not coming from Bob, etc.
        - Can also be hold, i.e. temporarily revoked
        - Should always be checked
        - Issued periodically (e.g. everyday) by CA. Are signed by CA. Are stored locally by client.
        - .crl format is a list of SHA1 checksum of certificates???, includes revokation reason
        - Alternative: OCSP (Online Certificate Staus Protocol):
            - protocol to get revokation status of a specific certificate
            - Is being preferred over CRL now. Is faster and better than fetching URL periodically.
            - OCSP server usually owned by CA
            - Problem: client disclose identity of server it wants to check (privacy concert).
              OCSP stapling can be used to counter this.
     - those files can come in different container formats:
        - PEM (.pem), often used in open source software. Use base64 encoding on a certificate in DER format (binary).
           - raw DER format (.crt, .cer, .der): not often used
        - PKCS#7 (.p7c, .p7b)
        - PKCS#12 (.p12, .pfx): contains both certificate and private key
           - predecessor was PFX (.pfx)
  - relies on two points:
     - ability of Trent to verify CSR comes from Bob
     - trust of Bob in root Trent (i.e. in locally stored root Trent certificates).
  - Those two points depend on trust models:
     - PKI (Public Key Infrastructure):
        - Trent are CA. Non-root CA are intermediate CA.
        - root CA are determined by client application, e.g. web browsers (but end-user can add its own ones)
        - CA verification that CSR comes from Bob depends on CA:
           - some free ones don't check
           - paid ones check better
           - a premium fee is charged for Extended Validation (EV), which will be shown in web browser with a green bar in the
             omnibox
     - Web of Trust:
        - Trent are "endorsers", determined by client.
          Client also choose whether to trust root CA/self-signed certificate itself.
        - Trent verification can be anything, e.g. meeting the person in real life.
  - cas où identité d'Alice peut se résumer à un id, peu importe personne réelle attaché à l'id :
    - ex: personne utilisant pseudonymes/id précis et ne voulant être identifié que par lui
    - alors pas de problème de trust

"Message recovery" :
  - si certificate a une certaine structure, alors Dᵈ: M' -> S et Eₑ: S -> M', où M' restreint M vers les messages de cette
    structure précise ("redundancy")
  - M' doit être propre à d et e, et donc infeasible à atteindre via forgery
  - deux intérêts :
      - V₁ peut être non ( Eₑ(s) == m ) mais ( Eₑ(s)∈ M' ) :
        - L'algo doit proposer une manière de deviner pour tout s si Eₑ(c)∈ M', pour un le bon M' (verification fonction)
        - permettant de marcher pour tout m, et pas un cas précis
        - donc pas besoin de transmettre m, mais seulement e
      - rend plus difficile qu'une forgery soit non-suspecte.
        En fait, ( Eₑ(s) == m ) pouvant être vu comme une autre manière de voir ( Eₑ(s)∈ M' ), que Eₑ(s) appartienne à un set
        restreint de M est nécessaire (que la signature ait une apparence donnée), car sinon (si signature ressemblant à
        du garbarge) toute s validerait V₁ rendant toute forgery possible
        Le défi est dans le fait de :
          - avoir confusion entre e et M', sinon on peut forger un e' avec le même M'

Attaque :
  - man-in-the-middle attack :
    - Mallory se fait passer pour Trent et donne à Alice non la clef publique de Bob, mais la sienne
    - il intercepte message d'Alice, déchiffre avec sa clef publique, modifie ou seulement prend connaissance du message,
      chiffre avec clef publique de Bob, et renvoie à Bob
    - peut le faire pour Bob aussi
  - autres attacks :
    - toujours attaques plus rapides que brute-force (comme factoring attack sur RSA) sur tout algo asym. (un peu comme brithday attack sur collision-resistant hash function) => clef plus longue requise (1024 bits asym. ≃ 128 bits sym. ???)

Signature digitale :
  - pour que non-répudiation :
      - algo avec forgery infeasible
      - e appartient bien à Alice (trust model), et E a été utilisé
      - d est resté secure
        - problème si Alice prétend que d a été volé
        - Alice doit donc prendre responsabilité de d jusqu'à révocation (comme une carte bancaire)