update

README.md

@@ -32,6 +32,7 @@ In this repo, it records some paper related to storage system, including **Data
 6. *Modeling the Dropbox Client Behavior*----ICC'14 ([link]( https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6883506 )) 
 7. *A Simulation Analysis of Redundancy and Reliability in Primary Storage Deduplication*----TC'18 ([link]()) [summary](https://yzr95924.github.io/paper_summary/SimRedundancy-TC'18.html)
 8. *A Simulation Analysis of Reliability in Primary Storage Deduplication*----IISWC'16
+9. Identifying Trends in Enterprise Data Protection Systems----USENIX ATC'15 ([link](https://www.usenix.org/system/files/conference/atc15/atc15-paper-amvrosladis.pdf))
 
 ### Deduplication System Design
 
@@ -53,6 +54,7 @@ In this repo, it records some paper related to storage system, including **Data
 16. *iDedup: Latency-aware, Inline Data Deduplication for Primary Storage*----FAST'12 ([link]( https://www.usenix.org/legacy/event/fast12/tech/full_papers/Srinivasan.pdf ))
 17. *DupHunter: Flexible High-Performance Deduplication for Docker Registries*----USENIX ATC'20 ([link](https://www.usenix.org/system/files/atc20-zhao.pdf))
 18. Design Tradeoffs for Data Deduplication Performance in Backup Workloads----FAST'15 ([link](https://www.usenix.org/system/files/conference/fast15/fast15-paper-fu.pdf)) [summary](https://yzr95924.github.io/paper_summary/DedupDesignTradeoff-FAST'15.html)
+19. The Dilemma between Deduplication and Locality: Can Both be Achieved?---FAST'21 ([link](https://www.usenix.org/system/files/fast21-zou.pdf)) [summary](https://yzr95924.github.io/paper_summary/MFDedup-FAST'21.html)
 
 ### Restore Performances
 
@@ -65,6 +67,7 @@ In this repo, it records some paper related to storage system, including **Data
 7. *Improving Restore Speed for Backup Systems that Use Inline Chunk-Based Deduplication*---FAST'13 ([link](https://www.usenix.org/system/files/conference/fast13/fast13-final124.pdf)) [summary](https://yzr95924.github.io/paper_summary/ImproveRestore-FAST'13.html)
 8. *Chunk Fragmentation Level: An Effective Indicator for Read Performance Degradation in Deduplication Storage*----HPCC'11 
 9. *Improving the Restore Performance via Physical Locality Middleware for Backup Systems*----Middleware'20 ([link](https://dl.acm.org/doi/pdf/10.1145/3423211.3425691))
+10. Efficient Hybrid Inline and Out-of-Line Deduplication for Backup Storage----ToS'14 ([link](https://www.cse.cuhk.edu.hk/~pclee/www/pubs/tos14revdedup.pdf))
 
 ### Secure Deduplication
 1. *Convergent Dispersal: Toward Storage-Efficient Security in a Cloud-of-Clouds*----HotStorage'14 ([link](https://www.cse.cuhk.edu.hk/~pclee/www/pubs/hotstorage14.pdf)) [summary](https://yzr95924.github.io/paper_summary/CAONT-RS-HotStorage'14.html)
@@ -75,7 +78,7 @@ In this repo, it records some paper related to storage system, including **Data
 6. *Side Channels in Deduplication: Trade-offs between Leakage and Efficiency*----AsiaCCS'17 ([link](https://dl.acm.org/doi/abs/10.1145/3052973.3053019)) [summary](https://yzr95924.github.io/paper_summary/SideChannelTradeOffs-AsiaCCS'17.html)
 7. *On Information Leakage in Deduplication Storage Systems*----CCS Workshop'16 [summary](https://yzr95924.github.io/paper_summary/InformationLeakage-CCSW'16.html)
 8. *SecDep: A User-Aware Efficient Fine-Grained Secure Deduplication Scheme with Multi-Level Key Management*----MSST'15 ([link](https://cswxia.github.io/SecDep-final-2015.pdf))
-9. *Message-Locked Encryption and Secure Deduplication*----EuroCrypt'13
+9. *Message-Locked Encryption and Secure Deduplication*----EuroCrypt'13 [summary](https://yzr95924.github.io/paper_summary/MLE-EuroCrypto'13.html)
 10. *Proofs of Ownership in Remote Storage System*----CCS'11
 11. *Tapping the Potential: Secure Chunk-based Deduplication of Encrypted Data for Cloud Backup*----CNS'18 [summary](https://yzr95924.github.io/paper_summary/TappingPotential-CNS'18.html)
 12. *A Bandwidth-Efficient Middleware for Encrypted Deduplication*----DSC'18 [summary](https://yzr95924.github.io/paper_summary/UWare-DSC'18.html)
@@ -278,10 +281,12 @@ In this repo, it records some paper related to storage system, including **Data
 5. *Varys: Protecting SGX Enclaves From Practical Side-Channel Attacks*---USENIX ATC'18 ([link](https://www.usenix.org/system/files/conference/atc18/atc18-oleksenko.pdf))
 6. *sgx-perf: A Performance Analysis Tool for Intel SGX Enclaves*----Middleware'18 ([link](https://www.ibr.cs.tu-bs.de/users/weichbr/papers/middleware2018.pdf)) [summary]( https://yzr95924.github.io/paper_summary/SGXPerf-Middleware'18.html )
 7. *TaLoS: Secure and Transparent TLS Termination inside SGX Enclaves*----arxiv'17 ([link](https://www.doc.ic.ac.uk/~fkelbert/papers/talos17.pdf)) [summary](https://yzr95924.github.io/paper_summary/talos-arxiv'17.html)
-8. *Switchless Calls Made Practical in Intel SGX*----SysTex'18 ([link](https://dl.acm.org/doi/pdf/10.1145/3268935.3268942))
+8. *Switchless Calls Made Practical in Intel SGX*----SysTex'18 ([link](https://dl.acm.org/doi/pdf/10.1145/3268935.3268942)) 
 9. *Regaining Lost Seconds: Efficient Page Preloading for SGX Enclaves*----Middleware'20 ([link](https://dl.acm.org/doi/pdf/10.1145/3423211.3425673))
+10. *Everything You Should Know About Intel SGX Performance on Virtualized Systems*----Sigmeterics'19 ([link](https://dl.acm.org/doi/pdf/10.1145/3322205.3311076)) [summary](https://yzr95924.github.io/paper_summary/SGXPerformance-SIGMETRICS'19.html)
 
 ### SGX Storage
+
 1. *NEXUS: Practical and Secure Access Control on Untrusted Storage Platforms using Client-side SGX*----DSN'19 ([link](https://people.cs.pitt.edu/~adamlee/pubs/2019/djoko2019dsn-nexus.pdf))
 2. *Securing the Storage Data Path with SGX Enclaves*----arxiv'18 ([link](https://arxiv.org/abs/1806.10883)) [summary](https://yzr95924.github.io/paper_summary/StorageDataPathSGX-arxiv.html)
 3. *EnclaveDB: A Secure Database using SGX*----S&P'18

StoragePaperNote/Deduplication/Deduplication-System-Design/MFDedup-FAST'21.md

@@ -0,0 +1,126 @@
+---
+typora-copy-images-to: ../paper_figure
+---
+The Dilemma between Deduplication and Locality: Can Both be Achieved?
+------------------------------------------
+|           Venue            |       Category       |
+| :------------------------: | :------------------: |
+| FAST'21 | Deduplication System Design |
+[TOC]
+
+## 1. Summary
+### Motivation of this paper
+- Motivation
+  - restore and GC issues in deduplication system
+    - locality issue
+    - eliminate random I/O 
+  - most duplicate chunks in a backup are directly from its previous backup.
+    - a novel management-friendly deduplication framework 
+    - Neighbor-Duplicate-Focus indexing (NDF): perform duplicate detection against a previous backup.
+    - Across-Version-Aware Reorganization scheme (AVAR): rearrange chunks with an offline and iterative algorithm into a compact, sequential layout.
+  - GC issues
+    - includes two stages: 
+      - selecting which containers have unreferenced chunks 
+      - migrating referenced chunks into new containers, so selected containers can be freed
+
+- The main difference between previous deduplication system 
+  - previous deduplication system: **write-friendly**, mainly focus on write path, rarely manages the location and placement of chunks 
+  - this deduplication system: **management-friendly**, use **offline** method to iteratively redesign the data layout of deduplicated chunks to improve chunk locality.
+    - argue the cost of this offline approach is acceptable.
+
+### MFDedup
+
+- Main observation
+  - Fragmentation is dependent on the backup version and associated with chunks' reference relationship.
+    - can use this to reduce the fragmentation issue (classification-based data layout)
+      - change to **variable-sized** containers
+    - ![image-20210302202326671](../paper_figure/image-20210302202326671.png)
+- Main challenges 
+  - The space of classification is very large, may generate more small containers 
+    - 2^n - 1 categories, (n is the number of versions) 
+  - OPT data layout solves the read amplification problem but requires more seek operations for these very small containers, which causes poor data locality.
+- Derivation relationship of backups
+  - In backup system, the duplicate chunks of each backup are not randomly distributed but are derived from the chunks of the last backup
+    - consecutive pattern of duplicates
+    - adjacent and internal duplicate chunks account for more than 99.5% in most datasets
+  - can greatly decrease the number of categories needed for the OPT data layout.
+    - ${n \choose 1} + {n \choose 2} = n(n+1)/2$
+- Neighbor-Duplicates-Focus indexing (NDF)
+  - only removes duplicates between neighboring backup version.
+  - need to build a **local** fingerprint index 
+    - lower memory overhead compared with traditional **global** fingerprint index. 
+    - current version and previous version 
+- Across-Version-Aware reorganization (AVAR)
+  - Deduplicating stage: store unique chunks of the latest new backup version into a new **active** category.
+    - chunks in active category may be referenced by future backup versions 
+  - Arranging stage: analyze the reference relationship between chunks and backup versions.
+    - need to iteratively update the existing OPT with new unique chunks of the incoming version.
+  - Each category has two states:
+    - Active: can be further arranged after future backups. 
+    - Archived: immutable.
+    - Grouping: store the new archived categories into a **Volume** by the order of their name
+      - achieve sequential reads during the restore process
+      - ![image-20210304160351467](../paper_figure/image-20210304160351467.png)
+
+- Restore
+  - need to read the required categories on the OPT data layout, which is referenced by the to-be-restored version.
+    - Grouping: required categories are always grouped in the same volume :arrow_right_hook: sequential reads.
+- Deletion and GC
+  - delete the last category in the corresponding volume.
+
+### Implementation and Evaluation
+
+- Implementation:
+  - based on Destor, open-sourced
+  - SHA-1 as the fingerprint 
+  - FastCDC: as the chunking method
+  - Compared with:
+    - HAR: History-Aware rewriting algorithm (FAST'14)
+    - CAM: Container-Marker algorithm (TPDS'14)
+    - Capping: FAST'13
+- Evaluation
+  - Trace: sina, source code of Chromium project, ubuntu VM, SYN
+  - SSD user space + HDD store space 
+  - Actual deduplication ratio 
+    - compare with exact deduplication and other rewrite scheme
+  - Backup throughput
+    - hashing is the bottleneck 
+    - indexing overhead is better than keeping a global index
+  - Restore throughput
+    - Restore throughput
+    - Seek number
+    - Read amplification factor
+  - Arranging vs. Traditional GC
+    - compared with Perfect GC
+    - processing period (s)
+  - Size distribution of volumes/categories
+    - the size of volumes: 90MB - 1.3GB
+    - can estimate how much more can be written to the deduplication system
+      - volumes represent the difference between neighboring versions.
+
+## 2. Strength (Contributions of the paper)
+
+1. Neighbor-Duplicate-Focus (NDF) indexing: only detect duplicates of a backup version with its previous version
+2. Across-Version-Aware Reorganization (AVAR): classify and group according to the simplified reference relationship between chunks and versions.
+3. Good discussion in the limitation of current prototype.
+
+## 3. Weakness (Limitations of the paper)
+1. This paper only considers two state-of-art rewriting techniques, however, there exists many works to solve the rewriting issues (FAST'18, FAST'19)
+> capping-FAST'13
+> HAR -FAST'14
+
+
+## 4. Some Insights (Future work)
+1. Why focuses on hard-drive based deduplication 
+
+For backup storage, it remains one of the most significant use cases.
+
+2. Key insights
+
+change the container from fixed-sized containers to variable-sized containers
+
+3. the discuss of the backup size:
+
+VM backups: 100GB
+
+the majority of backups are 50-500GB in Data Domain.

StoragePaperNote/Deduplication/Secure-Dedup/MLE-EuroCrypto'13.md

@@ -0,0 +1,99 @@
+---
+typora-copy-images-to: ../paper_figure
+---
+Message-Locked Encryption and Secure Deduplication
+------------------------------------------
+|           Venue            |       Category       |
+| :------------------------: | :------------------: |
+| EuroCrypto'13 | Secure Deduplication |
+[TOC]
+
+## 1. Summary
+### Motivation of this paper
+- The formulation of MLE
+  - the key under which encryption and decryption are performed is itself derived from the message.
+  - definitions both for privacy and for a form of integrity (tag consistency).
+
+- There is an absence of a theoretical treatment for MLE in secure deduplication deployment.
+  - It is not clear what precisely is the underlying security goal and whether deployed schemes achieve it.
+
+### MLE definitions
+
+- General MLE syntax
+  - key generation algorithm: K
+  - encryption algorithm: E
+  - decryption algorithm: D
+  - tagging algorithm: T
+- For convergent encryption:
+  - K = H(M)
+  - C = E(K, M)
+  - T = H(C)
+- Privacy:
+  - No MLE scheme can achieve semantic-security-style privacy
+    - if the target message $M$ is drawn from a space of $s$
+      - given an encryption $C$ of $M$, it can recover $M$ in $O(s)$ trials.
+      - the best possible privacy: semantic security when message are **unpredictable** (have high min-entropy)
+- Tag consistency: (how to against the duplicate faking attacks)
+  - **TC**: an adversary cannot make an honest client recover an incorrect message, meaning one different from the one it uploaded. (cannot protect the message integrity)
+  - **STC**: an adversary cannot erase an honest client's message.
+  - **STC** is strictly stronger than **TC**.
+  - If an MLE scheme is deterministic, letting the tag equal the ciphertext will result in a scheme that is **STC** secure.
+    - CR-hashing the ciphertext preserves **STC**, but the performance is not good. 
+- Discussion: for upload operation
+  - the client stores $K$ securely (may store $K$ encrypted under its password on the server, but the implementation is not relevant here).
+  - the client sends the $C$ to the server.
+  - the server computes tag $T$. (the main issue)
+- Fast MLE schemes
+  - CE: convergent encryption
+  - HCE1 (Hash-and-CE 1, in TahoeFS)
+    - compute the tags during encryption by hashing the per-message key ($T = H(P, K)$), and including the result in the ciphertext.
+    - offload the work from the server to the client and reduces th	e number of passes needed to encrypt and generate a tag from three to two.
+  - HCE2
+    - include the guarded decryption
+    - recomputing the tag using the just-decrypted message.
+  - RCE
+    - randomized convergent encryption
+![image-20210223233822225](../paper_figure/image-20210223233822225.png)
+
+- Performance of each MLE scheme
+
+![image-20210223234507807](../paper_figure/image-20210223234507807.png)
+
+
+### Implementation and Evaluation
+
+## 2. Strength (Contributions of the paper)
+1. Practical contribution 
+ROM security analyses of a natural family of MLE schemes (include deployed schemes).
+
+2. Theoretical contribution
+Standard model solution, the connection with deterministic encryption, hash functions.
+> different trade-offs between assumptions made and the message distributions for which security is proven.
+
+3. Provide four MLE schemes with different trade-offs between the security and performance.
+> CE, HCE1, HCE2. RCE 
+
+
+## 3. Weakness (Limitations of the paper)
+
+## 4. Some Insights (Future work)
+1. This paper mentions the issue that how to generate the tag?
+> $CE$: $K=H(M)$, $C=SE(K, M)$, $T=H(C)$
+> $HCE1$: $K=H(M)$, $C=SE(K, M)|| H(K)$, $T=H(K)$
+
+The $HCE1$ can offer better performance for the server who can simply read the tag as the second part of the ciphertext rather than needing to compute it by hashing the possibly long ciphertext.
+
+> vulnerable to duplicate faking attacks 
+
+
+2. the length of the key 
+It insists that an MLE scheme have keys that are shorter than the message.
+
+3. Tag consistency theorem
+
+- Any deterministic scheme is **STC**-secure when tags are CR-hashes of the ciphertext.
+- If $H$ is **CR**-secure then HCE2 and REC are **TC**-secure.
+
+
+
+