quelques notes de lectures (pas très beau, histoire de l'avoir sur le git)

recherches/vanDerLindeLeitaoPreguica.md

@@ -2,6 +2,41 @@
 
 ## Authors: van der Linde, Leitao, Preguica
 
+## Résumé:
+
+Le papier spécifie une amélioration de la cohérence causale, rajoutant des propriétés en renforçant la sécurité. Ils comparent ensuite différentes implémentations de leurs solutions en axant sur le besoin d'une faible latence pour privilégier l'interactivité.
+
+## Plan:
+
+1. Présente les attaques possibles sur la cohérence causale. $3
+2. Définissent les propriétés d'une cohérence causale sécurisée répondant aux attaques. $4
+3. Définit de nouvelles classes de cohérence étendant la cohérence causale. $5
+4. Définit des algorithmes pour implémenter ces classes de cohérence. $5
+5. Présente des résultats de performance de ces algorithmes. $6
+
+## Détails du document
+
+### Types d'attaques
+
+- Tempering: un nœud soumet une opération pour anticiper une opération en attente qui n'a pas encore été exécutée par le système.
+- Omitting dependencies: un nœud n'utilise qu'un sous-ensemble des opérations dans la dépendance. Il sera en mesure de soumettre une tâche concurrente au système.
+- Unseen dependencies (également appelé add): un nœud soumet une opération qui dépend d'une opération qu'il n'a pas vue. Il permet à l'attaquant d'anticiper une opération. (C'est différent du tempering car dans ce cas l'opération n'existe pas encore).
+- Combining omitting and unseen: un nœud peut omettre une dépendance et soumettre une opération qui dépend d'une opération qu'il n'a pas vue.
+- Sibbling generation: créer deux opérations différentes avec le même id. L'attaquant pourrait créer une divergence permanente entre les nœuds.
+
+### Propriétés d'une cohérence causale sécurisée
+
+- **Immutable History**: Chaque opération est envoyée avec son passé causal à chaque nœud valide. (Contrecarre le tempering)
+- **No Future Dependencies**: Chaque opération est envoyée avec son état de connaissance de l'état des nœuds du système. (Contrecarre l'unseen dependencies puisque l'opération sera considérée par l'ensemble du système comme "en retard" et sera donc ignorée)
+- **Causal Execution**: Toute opération $o_i$ appartenant au passé causal d'une opération $o$ doit être sérialisable t.q. : $o_i < o$. (Force une sorte de synchronisation entre les nœuds)
+- **Eventual Sibling Detection**: Chaque opération doit être considérée comme une faute éventuelle et doit donc avoir la possibilité d'être révoqué. La révocation ne peut se produire qu'après l'exécution de l'opération. (Assure que si deux opérations sont créées avec un même identifiant et crée une divergence, alors les nœuds auront toujours un moyen de retourner à un état convergent. Contrecarre **en partie** le sibling generation)
+- **Limitted Omission**: 
+
+<!-- OLD
+# Practical Client-side Replication: Weak Consistency Semantics for Insecure Settings
+
+## Authors: van der Linde, Leitao, Preguica
+
 ## Definition
 
 causal consistency: model enforcing clients to observe a state that respects the causal order of operations. (this is the case for decentralized and peer to peer systems)
@@ -36,4 +71,4 @@ The algorithms they propose used the following solutions for each property:
 
 The Secure Strict Causas Consistency is a variant of the Secure Causal Consistency who is using a trusted service. Such as the enclave in Intel SGX. Thus the usage of a hash of the dependencies is unnecessary.
 An issue of this solution is the cost of the connection to the trusted service. A possible attack would be to connect and disconnect a lot of time of the trusted service to make the system slow.
-This sollution was not explored in the paper due to this issue.
+This sollution was not explored in the paper due to this issue. -->