Pith. sign in

REVIEW 2 major objections 4 minor 52 references

A Tale of Two Trees: One Writes, and Other Reads. Optimized Oblivious Accesses to Large-Scale Blockchains

T0 review · 2 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A two-tree ORAM design lets Bitcoin SPV clients query a full node without revealing their addresses.

desk verdict Useful two-tree ORAM/TEE system for Bitcoin SPV, but the read-once privacy proof is a one-sentence assertion that fails on collisions; worth reviewing, not citable as-is. read the letter →

arxiv 1909.01531 v2 pith:SA4QONOS submitted 2019-09-04 cs.CR

Duc V. Le , Lizzy Tengana Hurtado , Adil Ahmad , Mohsen Minaei , Byoungyoung Lee , Aniket Kate This is my paper · ORCID
classification cs.CR
keywords obliviousRAMtwo-treeORAMBitcoinSPVclientUTXOsettrustedexecutionenvironmentaccess-patternprivacyconcurrentIntelSGX
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper proposes T3, a server-side system that lets lightweight Bitcoin clients find their unspent transaction outputs without revealing to the server which addresses they care about. The system runs a trusted execution environment on the server and wraps the Bitcoin UTXO database in an oblivious RAM (ORAM) construction, so even an adversary who watches every memory access cannot tell which block was queried. The central design move is to split a standard ORAM access into its two halves and run them on two trees: a read-once tree serves client queries with only the read-path step, while a writing tree performs the eviction and update steps that keep positions randomized. Under the paper's natural assumption that a rational client asks about a given address at most once per Bitcoin block interval, the split preserves ORAM privacy while letting reads proceed concurrently, and the paper reports millisecond-level latencies and thousands of requests per minute on the real Bitcoin UTXO set. If the construction is correct, it makes private lightweight blockchain queries practical at a scale that Bloom-filter SPV or classic private information retrieval could not reach.

What carries the argument

The load-bearing mechanism is the two-tree ORAM: instead of one encrypted binary tree of buckets with a position map and stash, the system keeps two copies—a read-once tree that executes only the ReadPath step for each client query, and an original tree where the writing enclave performs the Evict step and the interval's writes. The privacy argument rides on the block-interval resynchronization: within one interval, every path in the read-once tree is accessed by at most one read, and when a new Bitcoin block arrives the read-once tree is thrown away and both trees are rebuilt from the updated writing tree, shuffling all positions before the next interval begins. Around this core, the design uses a keyed hash to map Bitcoin addresses to ORAM block identifiers, recursive ORAM to shrink the position map so it fits in the enclave's limited trusted memory, and oblivious conditional-move operations so that enclave-internal memory access patterns reveal nothing.

What would settle it

Compute the keyed address-to-block mapping for every active Bitcoin address in a real UTXO snapshot, simulate one interval in which each client queries each of its addresses once, and count how many paths are visited by more than one distinct address; if that count is not negligible, the server can distinguish a colliding client's query from background traffic and Claim 2's read-once-per-path premise is violated. A negative version of the same test—collision rate near zero under realistic block sizes—would support the practical security of the read-once tree.

Watch

Extended reading notes

Core claim

The paper's claim is that the two halves of a tree-based ORAM access—reading a path into a stash, and evicting blocks back into the tree to randomize their positions—can be split across two trees without sacrificing the access-pattern privacy guarantee, as long as each path is read at most once before the trees are resynchronized. In T3, the read-once ORAM tree handles client queries using only the read-path operation; the original ORAM tree absorbs the eviction operations and the batch of writes from newly verified Bitcoin blocks, performed sequentially by a writing enclave. After every block creation interval the reading tree is discarded and both copies are replaced by fresh copies of the updated writing tree, so the server never observes a path being read twice within one interval. The paper additionally claims that even a client who repeats a query within an interval loses privacy only for that short interval, because the resynchronization re-randomizes all block positions. On the Bitcoin UTXO snapshot used in the evaluation, the read-once accesses complete in a few milliseconds and scale with thread count, supporting the claim that the system handles bursty concurrent requests where a standard single-tree ORAM would serialize.

Load-bearing premise

The load-bearing premise is that within one ten-minute block interval no storage path is ever read twice; the paper's stated assumption only forbids a single client from asking about the same address twice, so two clients whose addresses land in the same ORAM block can both read that path and reveal a link the proof does not account for.

Editorial extensions

If this is right

  • A Bitcoin SPV client can privately query its balance against a full node with millisecond-level server latency, something Bloom-filter-based SPV does not offer because the filter leaks addresses.
  • Read-side throughput scales with the number of threads, because read-once accesses do not wait on eviction; the evaluation reports roughly linear speed-up up to four threads.
  • The two-tree split applies to any tree-based ORAM and any blockchain whose state updates arrive in batches, not only Bitcoin.
  • Repeated queries by an irrational client leak information only for about one block interval (ten minutes), after which the tree resynchronization re-randomizes positions.
  • A deployment serving many SPV clients can absorb thousands of queries per minute on the real UTXO set, because concurrent reads are no longer blocked by the serial eviction step.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Inference: the paper's per-client assumption does not cover collisions: two different addresses mapped to the same ORAM block by the keyed hash will both read the same path in one interval, letting the server link those two clients' queries; the security of Claim 2 actually requires that no path be read twice for any reason.
  • Inference: an attacker could test the real-world severity of this gap by simulating honest queries on the actual UTXO set and measuring how often a second address lands in an already-read block; if that collision rate is negligible, the practical privacy loss may be small, but the formal indistinguishability guarantee needs a collision bound.
  • Inference: the read-once-per-epoch structure is not Bitcoin-specific; any stateful service with natural epoch semantics, such as fetching new messages or monitoring a certificate log, could adopt the same two-tree split to get concurrent private reads.
  • Inference: a direct fix would be to make the address-to-block map collision-free for active addresses, or to have the reading enclave add dummy reads when a requested block was already touched, restoring the once-per-path premise even under multi-client traffic.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 4 minor

Summary. The manuscript presents T3, a system that combines Intel SGX with a two-tree ORAM design to give Bitcoin SPV clients oblivious access to the UTXO set. The server maintains a read-once ORAM tree to serve client read requests without eviction, and a separate original ORAM tree on which evictions and block updates are performed; the two trees are synchronized once per Bitcoin block-creation interval. The paper's central claim is that, under the assumption that each SPV client queries a given public key hash at most once per block interval, this split enables concurrent client requests with millisecond-level latency while preserving the ORAM indistinguishability guarantee. The authors implement recursive Path-ORAM and Circuit-ORAM variants, evaluate on a snapshot of roughly 58 million UTXOs, and compare the throughput and communication cost against Bloom-filter-based SPV and the BITE system.

Significance. If the security claim were correct, T3 would be a substantial step toward practical private SPV clients: the reported throughput (sub-millisecond to few-millisecond access times with multiple threads) and the concrete use of recursive ORAM under SGX memory constraints are useful engineering contributions, and the comparison with BITE is informative. However, the core privacy proof for the read-once tree is not established, and the collision issue described below affects the central claim: the system as described does not satisfy Definition 1 for the read-once tree. The prototype and evaluation are real and the systems-engineering effort is commendable, but they cannot compensate for the unsupported security guarantee.

major comments (2)
  1. [VI-A, Claim 2 (with II-D and IV-A1)] The security of the read-once tree rests on the assertion that 'each path corresponding to a UTXO can only be accessed once during a read interval.' This premise does not follow from the threat model in Section II-D. The rationality assumption only constrains a single client from requesting the same public key hash more than once; it does not prevent two different clients from querying two distinct public key hashes that map to the same ORAM block, nor does it prevent one client from querying two distinct addresses that collide under OBlockMap(·,·). Section IV-A1's Claim 1 shows that such collisions are expected, bounding the load by e·m/N, which is roughly 9 addresses per block for the paper's parameters. When a second read of the same block occurs within the same interval, the server observes the same path being read again because the read-once tree does not re-randomize or write back the path. This makes the physical access patterns of two request sequences that differ only in whether a logical block is repeated distinguishable, violating Definition 1 in Section III-B. The one-sentence justification of Claim 2 is therefore not a security derivation; at the claimed scale of about 10,000 requests per interval and N=2^24, the expected number of colliding request pairs is c^2/(2N)≈3, so this is not a negligible corner case.
  2. [II-C and IV-B3] The paper states that if an SPV client behaves irrationally by requesting the same transaction multiple times, the client's privacy is 'only compromised for a short period of time (i.e., 10 minutes)' because the trees are synchronized before the next interval. This is not correct: the adversary observes the duplicate path read at the moment it occurs, and the later synchronization does not erase or obscure that observation. The adversary has already linked the repeated sessions and learned that the same logical block was accessed; re-synchronization at the next block interval does not restore the indistinguishability guarantee. This undercuts the paper's attempt to downplay violations of the rationality assumption and further confirms that Claim 2's path-uniqueness premise is load-bearing rather than a minor proof gap.
minor comments (4)
  1. [IV-A1 and VI-A] The claim numbering is confusing: Section IV-A1 already contains Claim 1 (Addresses per ORAM block) and Claim 2 (UTXO per ORAM block), but Section VI-A reuses the same numbers for unrelated security claims about the managing enclave and the read-once tree. This makes cross-referencing difficult and should be fixed in any revision.
  2. [II-D] The sentence 'before during the block creation interval' is ungrammatical; it should be 'during the block creation interval.'
  3. [VI-B] There is a typo in the first sentence: 'pratical' should be 'practical.'
  4. [V-A] The main performance results in Tables I and II are obtained from SGX simulation mode because the primary test machine is not SGX-enabled; the claim that hardware mode would show 'no noticeable difference' is supported only by a smaller-tree comparison, so the abstract's phrasing that the system 'is feasible to be deployed in practice' should be tempered or the hardware-mode evidence should be presented more prominently.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the two-tree ORAM construction and its performance claims are self-contained; Claim 2's read-once privacy premise is an unsupported assumption (a correctness gap), not a circular reduction, and the self-citations are not load-bearing.

full rationale

I find no step in which a claimed result is equivalent by construction to an input. The central two-tree optimization separates the ReadPath and Evict phases of standard tree ORAM (Sec. II-C, IV-B2) and is evaluated on the real Bitcoin UTXO set (Sec. V-B); no fitted parameter is later renamed as a prediction. The load-bearing assumption in Sec. II-D ('SPV clients are honest and rational which means that ... a SPV client should not request the server for transaction outputs of a same public key hash more than once') is a domain premise, not a restatement of the privacy conclusion. The closest candidate is Claim 2 (Sec. VI-A): 'this is secure since each path corresponding to a UTXO can only be accessed once during a read interval and will be shuffled before the next interval.' That sentence asserts privacy directly from the read-once property, but the property does not follow from the stated threat model when distinct addresses collide under OBlockMap (Claim 1 of Sec. IV-A1 bounds collisions by e·m/N); this is an unproven premise and a security gap, not a definitional equivalence, because the protocol does not define 'read-once' in terms of the indistinguishability goal and no equation equates the assumption with the conclusion. The paper's self-citations, chiefly to OBLIVIATE [10] (co-authored by T3 authors Ahmad and Lee) and ZEROTRACE [42] for cmov-based side-channel defenses (Sec. III-A, Claim 6), support a secondary hardening claim; the core two-tree concurrency and efficiency claims do not reduce to those libraries, so at most a minor, non-load-bearing self-citation. Score 1 reflects essentially no circularity with that small self-citation note.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

The system rests on standard ORAM security (Path ORAM, Circuit ORAM), on the SGX trust model, and on the rationality axiom. No constants are fitted to data to produce a prediction; the free parameters are design choices for the evaluation. No new physical or cryptographic entities are postulated; the two-tree layout is a system architecture, not an invented primitive.

free parameters (3)
  • Maximum UTXOs per address (delta) = 2
    Chosen by hand from the UTXO distribution so that T3 covers about 92% of addresses; this is a design trade-off, not a fitted constant.
  • ORAM tree size N (evaluation) = 2^20 to 2^24, headline at 2^24
    Selected to explore the trade-off; the 544-byte block size at N=2^24 follows from the e*m/N load bound in Claim 1.
  • Number of threads = 1 to 4
    Concurrency evaluation only goes to 4 threads, so the scaling claim cannot be extrapolated beyond that.
assumptions (5)
  • domain assumption Intel SGX provides the assumed confidentiality, integrity, and attestation; enclaves do not leak secrets via side channels when used with oblivious operations.
    Section III-A states SGX limitations and then assumes oblivious operations mitigate them; no proof is given that the software countermeasures fully close all side channels.
  • standard math Path ORAM and Circuit ORAM are secure and correct as defined in the cited works [44], [49].
    Section III-B imports tree-based ORAM security and uses it as a black box.
  • domain assumption The keyed block mapping OBlockMap behaves as a truly random function.
    Claims 1 and 2 (Section IV-A) rely on random mapping for the max-load bounds on addresses per block.
  • ad hoc to paper Each SPV client queries a given public key hash at most once per block creation interval (rational client).
    Section II-D threat model; this is the load-bearing assumption behind Claim 2's one-path-per-interval argument, and it is not sufficient to prevent cross-client block collisions.
  • domain assumption The adversary cannot mine a Bitcoin block within a block creation interval.
    Section III-D; used for the validity of block verification in the update protocol.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Tale of Two Trees: One Writes, and Other Reads. Optimized Oblivious Accesses to Large-Scale Blockchains." pith.science (2026). https://pith.science/paper/SA4QONOS

@misc{pith2026190901531,
  author       = {Pith},
  title        = {Pith review of: A Tale of Two Trees: One Writes, and Other Reads. Optimized Oblivious Accesses to Large-Scale Blockchains},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SA4QONOS}},
  note         = {Machine review of arXiv:1909.01531}
}
abstract

The Bitcoin network has offered a new way of securely performing financial transactions over the insecure network. Nevertheless, this ability comes with the cost of storing a large (distributed) ledger, which has become unsuitable for personal devices of any kind. Although the simplified payment verification (SPV) clients can address this storage issue, a Bitcoin SPV client has to rely on other Bitcoin nodes to obtain its transaction history and the current approaches offer no privacy guarantees to the SPV clients. This work presents $T^3$, a trusted hardware-secured Bitcoin full client that supports efficient oblivious search/update for Bitcoin SPV clients without sacrificing the privacy of the clients. In this design, we leverage the trusted execution and attestation capabilities of a trusted execution environment (TEE) and the ability to hide access patterns of oblivious random access memory (ORAM) to protect SPV clients' requests from a potentially malicious server. The key novelty of $T^3$ lies in the optimizations introduced to conventional ORAM, tailored for expected SPV client usages. In particular, by making a natural assumption about the access patterns of SPV clients, we are able to propose a two-tree ORAM construction that overcomes the concurrency limitation associated with traditional ORAMs. We have implemented and tested our system using the current Bitcoin Unspent Transaction Output database. Our experiment shows that the system is feasible to be deployed in practice while providing strong privacy and security guarantees to Bitcoin SPV clients.

Figures

Figures reproduced from arXiv: 1909.01531 by the authors.

Figure 1
Figure 1. An overview of T 3 workflow. The encrypted ORAM databases are stored in server untrusted memory region. Steps 1 - 6 describe the flow of the request sent from SPV clients. Steps 1 - 8 describe the flow of the update procedure when T 3 receives new Bitcoin block In this work, we design T 3 to overcome the limitations of efficiency and concurrency plaguing existing systems. Our design is motivated by the following obs… view at source ↗
Figure 2
Figure 2. a standard tree-based ORAM read/write access resides on. Finally, the client needs to have a stash to store a path retrieved from the server. We follow the same generalization of a tree-based ORAM access described in [28]. Each access in both ORAM schemes requires two operations: a ReadPath operation and an Evict operation. Intuitively, ReadPath takes as input the ORAM block identifier, bid, accesses the position ma… view at source ↗
Figure 3
Figure 3. Single address into Single ORAM block Single address into Many ORAM blocks. Mapping a single address into a single ORAM block incurs less work on the server as it requires a single ORAM access for an address. However, if we want to allow each address to have more than one output, using the first approach implies that the storage overhead increase linearly because the first approach distribute unspent outputs based o… view at source ↗
Figures from the paper (6 more)
Figure 5
Figure 5. Figure 5: The read protocol. Steps 1 - 5 describes how T 3 receives and responds to the client, and for each request, the writing enclave performs the Eviction procedure of ORAM on the original ORAM tree during step 6 . request procedure calls (RPC) to obtain Bitcoin blocks. Upo…
Figure 4
Figure 4. Figure 4: offers an overview of the both approaches. Enclave pkh kb OBlockMap() ORAM bid δ = 2 ORAM bid pkh Enclave kb OBlockMap() ORAM bid ORAM bid max = 3 δ = 2 [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 6
Figure 6. Figure 6: Oblivious write protocol. During steps 1 - 5 , the managing enclave receives and responds to SPV client request as usual. During steps 6 - 8 , read requests from clients are queued up, and the managing enclave resume these requests after updating the read-once ORAM tre…
Figure 7
Figure 7. Figure 7: Number of transactions per wallet ID. By allowing each [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: gives us the overall performance of three existing solutions. The performance of T 3 outperforms the SPV with Bloom filter solution. The reason is that in T 3 , the system relies on the TEE to handle the integrity checking of the Bitcoin block before updating the ORAM …
Figure 9
Figure 9. Figure 9: Communication cost of T 3 and the current SPV solution. Since both systems return the information of unspent outputs to the client, the communication overhead of BITE will be equal to the communication overhead of T 3 . UTXOs (e.g., ≈ 3 − 4× for CIRCUIT-ORAM, 6 − 8× fo…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

52 extracted references · 47 canonical work pages

  1. [1]

    https://bitcoin.org/en/bitcoin-core/

    Bitcoin core. https://bitcoin.org/en/bitcoin-core/. Accessed in Nov 2018

    work page 2018

  2. [2]

    https://bitcoin.org/en/ \developer-reference

    Bitcoin Developer Reference. https://bitcoin.org/en/ \developer-reference. Accessed in Nov 2018

    work page 2018

  3. [3]

    https://bitcoinwisdom.com/ bitcoin/difficulty

    Bitcoin difficulty and network hash rate. https://bitcoinwisdom.com/ bitcoin/difficulty

    work page

  4. [4]

    https://bitcoinj.github.io/

    Bitcoinj. https://bitcoinj.github.io/. Accessed in Oct 2018

    work page 2018

  5. [5]

    https://electrum.org/

    Electrum Bitcoin Wallet. https://electrum.org/. Accessed in Oct 2018

    work page 2018

  6. [6]

    https://github.com/cinemast/libjson-rpc-cpp

    json-roc-cpp. https://github.com/cinemast/libjson-rpc-cpp. Accessed in Oct 2018

    work page 2018

  7. [7]

    https://keystone-enclave.org/

    Key stone project. https://keystone-enclave.org/. Accessed in Oct 2018

    work page 2018

  8. [8]

    https://github.com/petertodd/python-bitcoinlib

    python-bitcoinlib. https://github.com/petertodd/python-bitcoinlib. Ac- cessed in April 2019

    work page 2019

Show all 52 references
  1. [9]

    In 28th USENIX Security Symposium (USENIX Security 19) , Santa Clara, CA, 2019

    BITE: Bitcoin lightweight client privacy using trusted execution. In 28th USENIX Security Symposium (USENIX Security 19) , Santa Clara, CA, 2019. USENIX Association

    2019

  2. [10]

    OBLIVIATE: A data oblivious filesystem for intel SGX

    Adil Ahmad, Kyungtae Kim, Muhammad Ihsanulhaq Sarfaraz, and Byoungyoung Lee. OBLIVIATE: A data oblivious filesystem for intel SGX. In NDSS. The Internet Society, 2018

    2018

  3. [11]

    Stillwell, David Goltzsche, Dave Eyers, R ¨udiger Kapitza, Peter Pietzuch, and Christof Fetzer

    Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, Andre Martin, Christian Priebe, Joshua Lind, Divya Muthukumaran, Dan O’Keeffe, Mark L. Stillwell, David Goltzsche, Dave Eyers, R ¨udiger Kapitza, Peter Pietzuch, and Christof Fetzer. SCONE: Secure linux containers wit...

    2016

  4. [12]

    Shielding applica- tions from an untrusted cloud with haven

    Andrew Baumann, Marcus Peinado, and Galen Hunt. Shielding applica- tions from an untrusted cloud with haven. In 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14) , pages 267–283, Broomfield, CO, 2014. USENIX Association. 13

    2014

  5. [13]

    Software grand exposure: SGX cache attacks are practical

    Ferdinand Brasser, Urs M ¨uller, Alexandra Dmitrienko, Kari Kostiainen, Srdjan Capkun, and Ahmad-Reza Sadeghi. Software grand exposure: SGX cache attacks are practical. In 11th USENIX Workshop on Offensive Technologies (WOOT 17) , Vancouver, BC, 2017. USENIX Association

    2017

  6. [14]

    Concuroram: High-throughput stateless parallel multi-client ORAM

    Anrin Chakraborti and Radu Sion. Concuroram: High-throughput stateless parallel multi-client ORAM. In 26th Annual Network and Distributed System Security Symposium, NDSS 2019, San Diego, Cali- fornia, USA, February 24-27, 2019 , 2019

    2019

  7. [15]

    Porter, and Mona Vij

    Chia che Tsai, Donald E. Porter, and Mona Vij. Graphene-sgx: A practical library OS for unmodified applications on SGX. In 2017 USENIX Annual Technical Conference (USENIX ATC 17) , pages 645– 658, Santa Clara, CA, 2017. USENIX Association

    2017

  8. [16]

    Iago attacks: Why the system call api is a bad untrusted rpc interface

    Stephen Checkoway and Hovav Shacham. Iago attacks: Why the system call api is a bad untrusted rpc interface. SIGARCH Comput. Archit. News, 41(1):253–264, March 2013

    2013

  9. [17]

    Johnson, Ari Juels, Andrew Miller, and Dawn Song

    Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah M. Johnson, Ari Juels, Andrew Miller, and Dawn Song. Ekiden: A platform for confidentiality-preserving, trustworthy, and performant smart contract execution. CoRR, abs/1804.05141, 2018

    2018 arXiv

  10. [18]

    Intel sgx explained

    Victor Costan and Srinivas Devadas. Intel sgx explained. Cryptology ePrint Archive, Report 2016/086, 2016. https://eprint.iacr.org/2016/086

    2016

  11. [19]

    Sanctum: Minimal hardware extensions for strong software isolation

    Victor Costan, Ilia Lebedev, and Srinivas Devadas. Sanctum: Minimal hardware extensions for strong software isolation. In 25th USENIX Security Symposium (USENIX Security 16), pages 857–874, Austin, TX,

  12. [20]

    Lecture notes on approximation and random- ized algorithms

    Artur Czumaj. Lecture notes on approximation and random- ized algorithms. http://www.ic.unicamp.br/ ∼celio/peer2peer\/math/ czumaj-balls-into-bins.pdf

  13. [21]

    Analysis of the bitcoin utxo set

    Sergi Delgado-Segura, Cristina P ´erez-Sol`a, Guillermo Navarro-Arribas, and Jordi Herrera-Joancomart ´ı. Analysis of the bitcoin utxo set. Cryptology ePrint Archive, Report 2017/1095, 2017. https://eprint.iacr. org/2017/1095

    2017

  14. [22]

    Diffie and M

    W. Diffie and M. Hellman. New directions in cryptography. IEEE Trans. Inf. Theor., 22(6):644–654, September 2006

    2006

  15. [23]

    An oblivious general-purpose SQL database for the cloud

    Saba Eskandarian and Matei Zaharia. An oblivious general-purpose SQL database for the cloud. CoRR, abs/1710.00458, 2017

    2017 arXiv

  16. [24]

    Andersen, Michael Kaminsky, and Michael D

    Bin Fan, Dave G. Andersen, Michael Kaminsky, and Michael D. Mitzenmacher. Cuckoo filter: Practically better than bloom. In Proceedings of the 10th ACM International on Conference on Emerging Networking Experiments and Technologies, CoNEXT ’14, pages 75–88, New York, NY , USA, 2014. ACM

    2014

  17. [25]

    Karame, and Damian Gruber

    Arthur Gervais, Srdjan Capkun, Ghassan O. Karame, and Damian Gruber. On the privacy provisions of bloom filters in lightweight bitcoin clients. In Proceedings of the 30th Annual Computer Security Applications Conference, ACSAC ’14, pages 326–335, New York, NY , USA, 2014. ACM

    2014

  18. [26]

    Goldreich

    O. Goldreich. Towards a theory of software protection and simulation by oblivious rams. In Proceedings of the Nineteenth Annual ACM Symposium on Theory of Computing , STOC ’87, pages 182–194, New York, NY , USA, 1987. ACM

    1987

  19. [27]

    Danny Harnik, Eliad Tsfadia, Doron Chen, and Ronen I. Kat. Securing the storage data path with SGX enclaves. CoRR, abs/1806.10883, 2018

    2018 arXiv

  20. [28]

    Thang Hoang, Muslum Ozgur Ozmen, Yeongjin Jang, and Attila A. Yavuz. Hardware-Supported ORAM in Effect: Practical Oblivious Search and Update on Very Large Dataset (to appear). InIn Proceedings on Privacy Enhancing Technologies Symposium (PoPETs) , 2019

    2019

  21. [29]

    Ryoan: A distributed sandbox for untrusted computation on secret data

    Tyler Hunt, Zhiting Zhu, Yuanzhong Xu, Simon Peter, and Emmett Witchel. Ryoan: A distributed sandbox for untrusted computation on secret data. In 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16) , pages 533–549, Savannah, GA, 2016. USENIX Association

    2016

  22. [30]

    Short paper: Industrial feasibility of private information retrieval

    Angela J ¨aschke, Bj ¨orn Grohmann, Frederik Armknecht, and Andreas Schaad. Short paper: Industrial feasibility of private information retrieval. In SECRYPT, pages 395–400, 2017

    2017

  23. [31]

    Hacking in darkness: Return-oriented programming against se- cure enclaves

    Jaehyuk Lee, Jinsoo Jang, Yeongjin Jang, Nohyun Kwak, Yeseul Choi, Changho Choi, Taesoo Kim, Marcus Peinado, and Brent ByungHoon Kang. Hacking in darkness: Return-oriented programming against se- cure enclaves. In 26th USENIX Security Symposium (USENIX Security 17), pages 523–...

    2017

  24. [32]

    Inferring fine-grained control flow inside SGX enclaves with branch shadowing

    Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim, Hyesoon Kim, and Marcus Peinado. Inferring fine-grained control flow inside SGX enclaves with branch shadowing. In 26th USENIX Security Symposium (USENIX Security 17), pages 557–574, Vancouver, BC, 2017. USENIX Association

    2017

  25. [33]

    Pietzuch, and Emin G ¨un Sirer

    Joshua Lind, Ittay Eyal, Peter R. Pietzuch, and Emin G ¨un Sirer. Teechan: Payment channels using trusted execution environments. CoRR, abs/1612.07766, 2016

    2016 arXiv

  26. [34]

    Connection bloom filtering, 2012

    Matt Corallo Mike Hearn. Connection bloom filtering, 2012

    2012

  27. [35]

    R3c3: Cryptographically secure censorship resistant rendezvous using cryp- tocurrencies

    Mohsen Minaei, Pedro Moreno-Sanchez, and Aniket Kate. R3c3: Cryptographically secure censorship resistant rendezvous using cryp- tocurrencies. Cryptology ePrint Archive, Report 2018/454, 2018. https://eprint.iacr.org/2018/454

    2018

  28. [36]

    Bitcoin: A peer-to-peer electronic cash system,” http://bitcoin.org/bitcoin.pdf

    Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system,” http://bitcoin.org/bitcoin.pdf

  29. [37]

    Oblivious multi- party machine learning on trusted processors

    Olga Ohrimenko, Felix Schuster, Cedric Fournet, Aastha Mehta, Se- bastian Nowozin, Kapil Vaswani, and Manuel Costa. Oblivious multi- party machine learning on trusted processors. In 25th USENIX Security Symposium (USENIX Security 16) , pages 619–636, Austin, TX, 2016. USENIX A...

    2016

  30. [38]

    Eleos: Exitless os services for sgx enclaves

    Meni Orenbach, Pavel Lifshits, Marina Minkin, and Mark Silberstein. Eleos: Exitless os services for sgx enclaves. In Proceedings of the Twelfth European Conference on Computer Systems, EuroSys ’17, pages 238–253, New York, NY , USA, 2017. ACM

    2017

  31. [39]

    Client side block filtering

    Olaoluwa Osuntokun, Alex Akselrod, and Jim Posen. Client side block filtering

  32. [40]

    Raccoon: Closing digital side-channels through obfuscated execution

    Ashay Rane, Calvin Lin, and Mohit Tiwari. Raccoon: Closing digital side-channels through obfuscated execution. In 24th USENIX Security Symposium (USENIX Security 15) , pages 431–446, Washington, D.C.,

  33. [41]

    Taostore: Overcoming asynchronicity in oblivious data storage

    Cetin Sahin, Victor Zakhary, Amr El Abbadi, Huijia Lin, and Stefano Tessaro. Taostore: Overcoming asynchronicity in oblivious data storage. In IEEE Symposium on Security and Privacy, SP 2016, San Jose, CA, USA, May 22-26, 2016 , pages 198–217, 2016

    2016

  34. [42]

    Fletcher

    Sajin Sasy, Sergey Gorbunov, and Christopher W. Fletcher. Zerotrace : Oblivious memory primitives from intel SGX. In 25th Annual Network and Distributed System Security Symposium, NDSS 2018, San Diego, California, USA, February 18-21, 2018 , 2018

    2018

  35. [43]

    Elaine Shi, T. H. Hubert Chan, Emil Stefanov, and Mingfei Li. Obliv- ious ram with o((logn)3) worst-case cost. In Dong Hoon Lee and Xiaoyun Wang, editors, Advances in Cryptology – ASIACRYPT 2011 , pages 197–214, Berlin, Heidelberg, 2011. Springer Berlin Heidelberg

    2011

  36. [44]

    Path oram: An extremely simple oblivious ram protocol

    Emil Stefanov, Marten van Dijk, Elaine Shi, Christopher Fletcher, Ling Ren, Xiangyao Yu, and Srinivas Devadas. Path oram: An extremely simple oblivious ram protocol. In Proceedings of the 2013 ACM SIGSAC Conference on Computer; Communications Security, CCS ’13, pages 299–310, ...

    2013

  37. [45]

    Slalom: Fast, verifiable and private execution of neural networks in trusted hardware

    Florian Tramer and Dan Boneh. Slalom: Fast, verifiable and private execution of neural networks in trusted hardware. In International Conference on Learning Representations , 2019

    2019

  38. [46]

    Obscuro: A bitcoin mixer using trusted execution environments

    Muoi Tran, Loi Luu, Min Suk Kang, Iddo Bentov, and Prateek Saxena. Obscuro: A bitcoin mixer using trusted execution environments. In Proceedings of the 34th Annual Computer Security Applications Con- ference, ACSAC ’18, pages 692–701, New York, NY , USA, 2018. ACM

    2018

  39. [47]

    Kalodner, Vrushali Kulkarni, Daniela Oliveira, and Donald E

    Chia-Che Tsai, Kumar Saurabh Arora, Nehal Bandi, Bhushan Jain, William Jannen, Jitin John, Harry A. Kalodner, Vrushali Kulkarni, Daniela Oliveira, and Donald E. Porter. Cooperation and security isolation of library oses for multi-process applications. In Proceedings of the Nin...

    2014

  40. [48]

    Wenhao Wang, Guoxing Chen, Xiaorui Pan, Yinqian Zhang, XiaoFeng Wang, Vincent Bindschaedler, Haixu Tang, and Carl A. Gunter. Leaky cauldron on the dark land: Understanding memory side-channel hazards in SGX. CoRR, abs/1705.07289, 2017

    2017

  41. [49]

    Circuit oram: On tightness of the goldreich-ostrovsky lower bound

    Xiao Wang, Hubert Chan, and Elaine Shi. Circuit oram: On tightness of the goldreich-ostrovsky lower bound. In Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security , CCS ’15, pages 850–861, New York, NY , USA, 2015. ACM

    2015

  42. [50]

    Zlite: Lightweight clients for shielded zcash 14 transactions using trusted execution

    Karl W ¨ust, Sinisa Matetic, Moritz Schneider, Ian Miers, Kari Kosti- ainen, and Srdjan Capkun. Zlite: Lightweight clients for shielded zcash 14 transactions using trusted execution. Cryptology ePrint Archive, Report 2018/1024, 2018. https://eprint.iacr.org/2018/1024

    2018

  43. [51]

    Controlled-Channel attacks: Deterministic side channels for untrusted operating systems

    Yuanzhong Xu, Weidong Cui, and Marcus Peinado. Controlled-Channel attacks: Deterministic side channels for untrusted operating systems. In S&P (Oakland), 2015

    2015

  44. [52]

    Town crier: An authenticated data feed for smart contracts

    Fan Zhang, Ethan Cecchetti, Kyle Croman, Ari Juels, and Elaine Shi. Town crier: An authenticated data feed for smart contracts. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security , CCS ’16, pages 270–282, New York, NY , USA, 2016. ACM. 15

    2016

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.