Pith. sign in

REVIEW 2 major objections 5 minor 86 references

Pacer: Comprehensive Network Side-Channel Mitigation in the Cloud

T0 review · 2 major / 5 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 Pacer reshapes traffic outside guest VMs so packet timing and sizes carry no secret-dependent signal, and proves it with a noninterference theorem.

desk verdict A serious systems paper with a real proof gap: the prototype's interrupt-handler timestamps violate the noninterference theorem's secrecy assumption. read the letter →

arxiv 1908.11568 v5 pith:V6J4JUI5 submitted 2019-08-30 cs.CR

Aastha Mehta , Mohamed Alzayat , Roberta de Viti , Björn B. Brandenburg , Peter Druschel , Deepak Garg This is my paper · ORCID
classification cs.CR
keywords networksidechannelstrafficshapingIaaScloudsecuritycloakedtunnelhypervisorparavirtualizationnoninterferencepacketpaddingandpacingCNNclassification
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

Pacer is, by the paper's account, the first system to eliminate network side-channel leaks in public infrastructure-as-a-service clouds end-to-end. The core idea is to move traffic shaping outside the guest: a cloaked tunnel pads every packet to a fixed MTU and transmits on schedules chosen independently of secrets, sending dummy packets when no payload is ready, so packet timing, size, and count carry no secret-dependent signal. The design splits enforcement between a performance-isolated hypervisor component that masks its own delays and a guest kernel module that supplies flow-control and congestion state. The paper proves a noninterference theorem for this design and reports that a CNN classifier that identifies videos with over 99% accuracy on unshielded traffic drops to random guessing on Pacer-shaped traffic, at moderate bandwidth, latency, and CPU costs.

What carries the argument

The load-bearing mechanism is the cloaked tunnel, a schedule-driven shaping layer that wraps each flow outside the application and makes packet timing and size secret-independent by design. The security argument turns on HyPace's masking discipline: an event handler scheduled at $t_n - \delta_{\mathrm{xmit}}$ spins until $t_n$ and then writes the NIC doorbell, so any variability in handler execution is hidden as long as the observed worst-case delay $\delta_{\mathrm{xmit}}=35\,\mu\mathrm{s}$ is a true bound; batched, epoch-based transmission amortizes the cost of this masking. GPace enforces a second bound, $\delta_{\mathrm{delay}}=20\,\mathrm{ms}$, for the guest's processing of inbound packets and timers, so that causally related network events are never observably closer than the bound. Together these mechanisms ensure that each of the paper's properties S1–S5 — schedule choice, activation, updates, deviations, and transport responses — is either secret-independent or unobservable to a network adversary.

What would settle it

Run two Pacer-protected servers that differ only in their private guest state while a co-resident adversary generates heavy DMA, bus, and PCIe traffic, and record every NIC doorbell-write delay relative to the scheduled transmission time; if any delay exceeds $\delta_{\mathrm{xmit}}=35\,\mu\mathrm{s}$, or if a classifier trained on the packet traces identifies the private state better than random guessing, Theorem 3's premise is falsified.

Watch

Extended reading notes

Core claim

The paper's central claim is that network side-channel leaks can be removed by construction rather than by adding noise. Pacer wraps a tenant's flows in a cloaked tunnel whose shaping layer decides every transmission: packets are padded to MTU size, transmission follows a schedule anchored to public events such as a request arrival or a prechosen class, and a dummy packet is sent whenever the guest has not produced payload in time. HyPace, a small hypervisor component, enforces the schedule and masks any secret-dependent delay in its own execution by spinning until the scheduled time before writing the NIC doorbell, batching packets in epochs to keep line rate. GPace, a kernel module in the guest, pads payloads, shares per-flow congestion windows and sequence numbers, and masks processing delays between causally related network events. The formal appendix proves Theorem 3: from identical public states, runs with different private guest states produce observationally identical environment states, so an adversary observing traffic shape learns nothing about guest secrets.

Load-bearing premise

Security rests on the empirical bounds $\delta_{\mathrm{xmit}}=35\,\mu\mathrm{s}$ for the delay between a scheduled transmission and the NIC doorbell write and $\delta_{\mathrm{delay}}=20\,\mathrm{ms}$ for guest processing; the paper concedes that secret-dependent bus or PCIe contention on general-purpose hardware cannot be ruled out, so an adversary who can reliably trigger such delays could break the masking assumption.

Editorial extensions

If this is right

  • A tenant who rents a dedicated CPU socket and runs Pacer can expose its outbound traffic to colocated or on-path observers without leaking secret-dependent information through packet timing, sizes, or counts.
  • Workloads can be partitioned into public classes such as video resolution or document clusters; each class may use its own efficient schedule, and only the public class membership is revealed, not the specific object.
  • Because Pacer honors congestion signals, flow-control windows, and retransmissions, it can sustain elastic bandwidth sharing and TCP-friendliness, which fixed-rate dummy traffic cannot.
  • The quantitative costs are two hypervisor cores, modest memory, and bandwidth overhead that depends on how coarsely or finely the tenant clusters its content; the paper reports roughly 4x padding on videos and 142.8% on medical pages with the tested clusters.
  • If the proof and measurements hold, a CNN classifier that would identify shielded videos in the clear at over 99% accuracy is reduced to predictions no better than random on Pacer-shaped traffic.

Reading between the lines

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

  • If NICs ever expose a hardware 'transmit at this timestamp' primitive, Pacer's $\delta_{\mathrm{xmit}}$ bound could become a hardware guarantee instead of an empirical measurement, closing the residual bus- and PCIe-contention gap the paper explicitly leaves open.
  • The same tunnel abstraction can be mirrored at the client end, which the paper notes as a trivial extension; that would hide request timing and sizes as well as responses, at the cost of client-side GPace installation.
  • Pacer's guarantee is stated for a threat model that already excludes microarchitectural channels by dedicated-socket rental; combining it with CPU-cache and memory isolation would give a stronger end-to-end confidentiality claim for the whole server, not just the network path.
  • The 99th/90th-percentile schedule synthesis in ProfPace is tuned for web-style workloads; applying Pacer to interactive protocols such as VoIP or remote procedure calls would require re-measuring those percentiles, since the latency overhead of tail-shaped schedules may dominate for short exchanges.
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 / 5 minor

Summary. The paper presents Pacer, a system aimed at eliminating network side channels (NSCs) in public IaaS clouds by shaping traffic outside the guest VM. The core abstraction is a cloaked tunnel that makes packet timing and size independent of secrets. Pacer is implemented as a paravirtualized extension: HyPace in the hypervisor handles transmission scheduling, encryption, padding, and dummy generation; GPace in the guest kernel shares network state and timestamps; ProfPace generates transmission schedules. The paper includes a formal noninterference model and proof in Appendix E, and an experimental evaluation on two web workloads showing moderate overhead and successful defense against a CNN classifier. The abstract claims that Pacer is the first system to eliminate NSC leaks end-to-end and that it provides provable security.

Significance. If the security claim holds, Pacer is a significant advance over prior NSC mitigations: it explicitly addresses host-level internal side channels (requirement R6), respects network flow control, congestion control, and loss recovery (R5), and provides a formal noninterference theorem. The formal model in Appendix E is a genuine proof with clearly stated assumptions, and the evaluation is thorough in its coverage of latency, throughput, and bandwidth overheads. The paper is also honest about several limitations, most notably the possibility of secret-dependent bus/PCIe interference. However, the significance of the contribution is conditional on closing a substantial gap between the assumptions of the formal model and the behavior of the implemented prototype, as detailed below.

major comments (2)
  1. [§4.2 and Appendix E (Figure 11, assumption (2))] The prototype violates the formal model's assumption that schedule effective times are secret-independent. GPace timestamps inbound packets in the vNIC interrupt handler, so the timestamp used to anchor a default schedule is taken after an interrupt-delivery delay d that may depend on the guest's secret-dependent computation (e.g., interrupts disabled while processing a secret). The schedule start time is thus T_arrival + d, and the first response is transmitted at T_arrival + d + δ, where δ = ε + δdelay. The request-to-response interval observed by a network adversary includes the secret-dependent component d; adding the constant δdelay after the timestamp shifts but does not cancel its variation. This violates assumption (2) of the formal model (Figure 11), which requires the effective time Tei to be secret-independent, so Theorem 3 does not apply to the implementation as described. The masking rule of §4.2 only hides guest processing that occurs after the timestamp is taken, not the delay before the timestamp, so the central claim that Pacer's prototype achieves noninterference is not supported.
  2. [§4.1 and Appendix E (assumption (7))] The claimed end-to-end guarantee is not established for the hardware transmission path. The paper states that delays between the doorbell write and the actual wire transmission caused by concurrent secret-dependent bus/PCIe transactions 'cannot be ruled out on general-purpose hardware' (§4.1). The formal model abstracts away the NIC and bus: assumption (7) concerns only Fo_H's logical output timing, not the physical time at which a packet appears on the wire. Consequently, Theorem 3 proves noninterference only up to the HyPace doorbell write, and the prototype's security on real hardware depends on the empirically measured bound δxmit = 35 µs, which the authors concede is an assumption rather than a guarantee. The abstract's unqualified claim that Pacer 'eliminates NSC leaks in public IaaS Clouds end-to-end' is therefore too strong for the current prototype; the security result is conditional on empirical delay bounds that the paper itself says may be violated by an adversary able to induce bus contention.
minor comments (5)
  1. [§4.2] The definition of δdelay as the 'empirical maximum inbound packet- and timer-processing time' is ambiguous about whether it includes the latency from packet arrival at the NIC to the entry of the vNIC interrupt handler; the paper should state precisely what was measured and whether the 20 ms bound covers that interval.
  2. [§6.3] The empirical security evaluation uses only four videos from a single cluster and reports that classifier probabilities are near 25% for each label; the paper should provide a confidence interval or error analysis and clarify that this is a sanity check rather than a validation of the noninterference guarantee.
  3. [§5] The statement that an inadequate schedule 'cannot leak secrets' should be justified for the case where an actual response exceeds the scheduled packet count, since excess payload may be dropped or deferred and could trigger secret-dependent retransmissions or connection timeouts that alter traffic shape.
  4. [Appendix E] There is a garbled line of characters immediately before Figure 8 in the provided text that appears to be a rendering artifact; the authors should ensure the final version contains no such corruption.
  5. [§2.1] The prototype assumptions state that client request traffic reveals no secrets through its shape; this is a strong assumption for the bidirectional case and should be highlighted earlier, since it limits the 'end-to-end' claim to server-side shaping only.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Pacer's noninterference theorem is a conditional compositional proof with explicit component-level assumptions, not a fitted or self-citational derivation.

full rationale

Pacer's central security claim is Theorem 3 in Appendix E, which states a noninterference property for the composed system. The proof is a standard relational invariant argument: it assumes component-level conditions (e.g., assumption (1) that the environment's observable behavior is secret-independent, assumption (2) that profile update contents and effective times are secret-independent, assumption (6) that profile updates respect their effective times, and assumption (7) that HyPace's output function Fo_H emits same packet timings given same profiles regardless of packet queue contents) and derives the system-level conclusion. These assumptions are not introduced as predictions or as outputs of the derivation; they are explicit hypotheses of the model. In particular, assumption (7) is a formal abstraction of the §4.1 masking mechanism, not a restatement of Theorem 3, because it concerns only the low-level Fo_H step and still requires the proof (Lemma 2) to show that the profiles [sigma_H'] are equal across runs before it can be applied. The empirical bounds delta_xmit and delta_delay are presented as measured estimates with explicit caveats that hardware interference 'cannot be ruled out on general-purpose hardware'; they are not fitted parameters being relabeled as predictions. The CNN evaluation is an empirical sanity check, not a derivation from fitted values. No load-bearing self-citation or imported uniqueness theorem appears. Accordingly, no step in the paper's derivation chain is circular; the main caveats are unproven hardware assumptions, which are correctness and validation concerns rather than circularity.

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

The paper introduces no new physical entities. Its novel components, HyPace and GPace, are implemented software modules rather than postulated and unverified entities. The central claim rests mainly on empirical delay bounds, on the assumption that clients and guests do not leak through timing or profile choices, and on the modeling assumption that HyPace's internal packet generation is itself secret-independent. These are the most significant assumptions beyond standard network and hypervisor behavior.

free parameters (5)
  • δxmit (transmission masking delay bound) = 35 µs
    Empirically determined maximum delay between scheduled transmission time and HyPace's NIC doorbell write; used to start the timer early so the handler can spin until the scheduled time. If the true maximum exceeds this on real hardware, the security claim fails.
  • δdelay (guest processing delay bound) = 20 ms
    Empirical maximum inbound packet and timer processing time in the guest; used to anchor schedule activation and retransmission timing. If exceeded, secret-dependent processing delays may become observable.
  • Epoch length ε = 120 µs
    Chosen from microbenchmarks to balance batch preparation and line rate; affects whether scheduled transmissions are delayed to the end of an epoch. Performance parameter that interacts with the delay bounds.
  • Max batch size B = 38 packets per HyPace handler
    Empirically chosen so a single handler can prepare B packets within an epoch; used to sustain throughput. Performance parameter, not a security parameter.
  • Schedule percentile parameters = 99th percentile initial delay, 90th percentile inter-packet spacing, 100th percentile packet count +10%
    ProfPace uses these to construct transmit schedules; the paper states the choice is relevant for performance, not security, but it determines bandwidth and latency overheads.
assumptions (6)
  • domain assumption Clients do not leak secrets through request timing or payload-visible behavior (assumption (1), Figure 10).
    The model assumes the environment function FE produces timing-independent outputs when payloads and private client state differ. The prototype assumes client request traffic reveals no secrets through shape (§2.1). If clients are adversarial or compromised, the guarantee does not hold.
  • domain assumption The guest does not leak secrets through profile update effective times, only through queueing times (assumption (2), Figure 11).
    The proof allows Tui to be secret-dependent but requires Tei to be secret-independent. The paper claims this can be ensured by bucketizing secret-dependent delays into public buckets, but this is not formally verified.
  • domain assumption Propagation delays are respected: Tui ≤ Tei for all profile updates (assumption (3)).
    The guest is assumed to anchor effective times sufficiently far in the future to cover processing delays. If this fails, updates can become effective at secret-dependent times.
  • ad hoc to paper Event handler delays are bounded by the empirically measured δxmit and guest delays by δdelay.
    This is the load-bearing empirical bound in §4.1 and §6.1. The paper admits secret-dependent bus interference cannot be ruled out on general-purpose hardware.
  • ad hoc to paper HyPace's output function Fo_H itself does not leak secrets (assumption (7), Figure 13).
    The proof assumes that given equivalent profile prefixes, Fo_H emits timing-equivalent packet outputs. This is the core security property at the HyPace level, assumed rather than derived from hardware behavior.
  • domain assumption Chosen traffic shapes (schedules) are secret-independent (S1, §3.3).
    The security argument assumes all installed schedules, including custom profiles, are chosen without dependence on secrets. Tenants must follow this contract; the paper provides guidelines but no enforcement.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Pacer: Comprehensive Network Side-Channel Mitigation in the Cloud." pith.science (2026). https://pith.science/paper/V6J4JUI5

@misc{pith2026190811568,
  author       = {Pith},
  title        = {Pith review of: Pacer: Comprehensive Network Side-Channel Mitigation in the Cloud},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/V6J4JUI5}},
  note         = {Machine review of arXiv:1908.11568}
}
read the original abstract

Network side channels (NSCs) leak secrets through packet timing and packet sizes. They are of particular concern in public IaaS Clouds, where any tenant may be able to colocate and indirectly observe a victim's traffic shape. We present Pacer, the first system that eliminates NSC leaks in public IaaS Clouds end-to-end. It builds on the principled technique of shaping guest traffic outside the guest to make the traffic shape independent of secrets by design. However, Pacer also addresses important concerns that have not been considered in prior work -- it prevents internal side-channel leaks from affecting reshaped traffic, and it respects network flow control, congestion control and loss recovery signals. Pacer is implemented as a paravirtualizing extension to the host hypervisor, requiring modest changes to the hypervisor and the guest kernel, and only optional, minimal changes to applications. We present Pacer's key abstraction of a cloaked tunnel, describe its design and implementation, prove the security of important design aspects through a formal model, and show through an experimental evaluation that Pacer imposes moderate overheads on bandwidth, client latency, and server throughput, while thwarting attacks based on state-of-the-art CNN classifiers.

Figures

Figures reproduced from arXiv: 1908.11568 by the authors.

Figure 1
Figure 1. The adversary can (a) colocate VMs with victim’s VM [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Cloaked tunnel (one endpoint) environment. Subsequently in §5, we sketch how Pacer auto￾matically generates efficient traffic shapes, thus completing Pacer’s design. 3.1. Desiderata A practical, secure cloaked tunnel must satisfy three high-level properties, mirroring requirements R1, R5 and R6 from §1. (i) Secret-independent traffic shape: Requires that transmis￾sions follow a schedule that does not depend on secre… view at source ↗
Figure 3
Figure 3. shows Pacer’s architecture. Unlike the strictly layered tunnel stack from §3, Pacer factors out a small set of functions that inherently require performance-isolation into the [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (11 more)
Figure 4
Figure 4. Figure 4: Medical service throughput vs latency subsequent segments sequentially whenever space is available in the buffer. We measure the impact of traffic shaping on (i) the initial delay until the video starts playing, (ii) the frequency and duration of any pauses (video skip…
Figure 5
Figure 5. Figure 5: CNN architecture. k denotes the number of features used. n denotes the number of elements of one time series, which is the total time of the time series divided by the window size (50ms). (ii) the victim traffic and rest of the traffic through the host. We configure th…
Figure 6
Figure 6. Figure 6: Relative padding overhead vs number of clusters [PITH_FULL_IMAGE:figures/full_fig_p017_6.png]
Figure 7
Figure 7. Figure 7: Relative padding overhead vs number of clusters [PITH_FULL_IMAGE:figures/full_fig_p017_7.png]
Figure 8
Figure 8. Figure 8: Download latency for a 10Mbps client for segments [PITH_FULL_IMAGE:figures/full_fig_p018_8.png]
Figure 9
Figure 9. Figure 9: Equivalence of states and queues Assumptions (1) QE1 ∼ QE2 and σE1 = σE2 and FE(QE1 ,σE1 ,Tg) = (QE 0 1 ,QG 00 1 ,σE 0 1 ) and FE(QE2 ,σE2 ,Tg) = (QE 0 2 ,QG 00 2 ,σE 0 2 ) ⇒ QE 0 1 ∼ QE 0 2 and QG 00 1 ∼ QG 00 2 and σE 0 1 ∼ σE 0 2 Transition FE(QE,σE,Tg) = (QE 0 ,QG …
Figure 10
Figure 10. Figure 10: Assumptions and transition of the environment [PITH_FULL_IMAGE:figures/full_fig_p019_10.png]
Figure 11
Figure 11. Figure 11: Assumptions and transition of the guest E.1.2. Guest acts The guest acts by consuming events from QG to update its internal state and to produce events in the queue QH (including both its subqueues Qu H and Q p H ). We model the environment as an abstract function FG.…
Figure 12
Figure 12. Figure 12: The functions update and update_prof that model HyPace’s profile update logic Assumptions (6) F u H (Φ,Eu,Te) = Φ0 and Te0 < Te ⇒ [Φ]Te0 = [Φ0 ]Te0 (7) s1 = s2 and F o H (Q p H1 ,s1) = (Q p H 0 1 ,QE 00 1 ) and F o H (Q p H2 ,s2) = (Q p H 0 2 ,QE 00 2 ) ⇒ QE 00 1 ∼ QE…
Figure 13
Figure 13. Figure 13: Assumptions and transition of HyPace (Non-modification of past outputs) FG should not output events in the past, i.e., Qu H 0 should only contain events with time￾stamps greater than Tg. (Non-consumption of future inputs) FG should not remove future events from its in…
Figure 14
Figure 14. Figure 14: Invariants of the transition system the system. Noninterference is usually proved by establishing invariants. We state and prove the relevant invariants of our model before stating and proving security. Our model has two kinds of relevant invariants: unary and relatio…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

86 extracted references · 77 canonical work pages

  1. [1]

    https://www.mediawiki.org/wiki/MediaWiki_1

    MediaWiki. https://www.mediawiki.org/wiki/MediaWiki_1

  2. [2]

    https://www.medicinenet.com/script/main/hp

    MedicineNet. https://www.medicinenet.com/script/main/hp. asp. Last accessed on 16 Sep 2020

    2020

  3. [3]

    https: //www.napatech.com/support/resources/data-sheets/ napatech-smartnic-feature-overview/

    NapaTech SmartNIC, Feature Overview Data Sheet. https: //www.napatech.com/support/resources/data-sheets/ napatech-smartnic-feature-overview/

  4. [4]

    https://github.com/giltene/wrk2

    wrk2: A constant throughput, correct latency recording variant of wrk. https://github.com/giltene/wrk2

  5. [5]

    https://patchwork.kernel.org/patch/ 9669405/

    Xen Null scheduler. https://patchwork.kernel.org/patch/ 9669405/

  6. [6]

    Moving in next door: Network flooding as a side channel in cloud environments

    Yatharth Agarwal, Vishnu Murale, Jason Hennessey, Kyle Hogan, and Mayank Varia. Moving in next door: Network flooding as a side channel in cloud environments. In Intl. Conf. on Cryptology and Network Security (CANS), 2016

    work page 2016

  7. [7]

    Fine grain Cross-VM Attacks on Xen and VMware are possible! In IEEE Intl

    Gorka Irazoqui Apecechea, Mehmet Sinan Inci, Thomas Eisenbarth, and Berk Sunar. Fine grain Cross-VM Attacks on Xen and VMware are possible! In IEEE Intl. Conf. on Big Data and Cloud Computing (BDCLOUD), 2014

    work page 2014

  8. [8]

    Predictive black- box mitigation of timing channels

    Aslan Askarov, Danfeng Zhang, and Andrew C Myers. Predictive black- box mitigation of timing channels. In ACM Conf. on Computer and Communications Security (CCS), 2010

    work page 2010

Show all 86 references
  1. [9]

    Mitigating network side channel leakage for stream processing systems in trusted execution environments

    Muhammad Bilal, Hassan Alsibyani, and Marco Canini. Mitigating network side channel leakage for stream processing systems in trusted execution environments. In ACM Intl. Conf. on Distributed and Event- based Systems (DEBS), 2018

    2018

  2. [10]

    Robust and effi- cient elimination of cache and timing side channels

    Benjamin A Braun, Suman Jana, and Dan Boneh. Robust and effi- cient elimination of cache and timing side channels. arXiv preprint arXiv:1506.00189, 2015

    2015 arXiv

  3. [11]

    Remote timing attacks are still practical

    Billy Bob Brumley and Nicola Tuveri. Remote timing attacks are still practical. In European Symposium on Research in Computer Security (ESORICS), 2011

    2011

  4. [12]

    Remote timing attacks are practical

    David Brumley and Dan Boneh. Remote timing attacks are practical. Computer Networks, 48(5), 2005

    2005

  5. [13]

    Cs-buflo: A conges- tion sensitive website fingerprinting defense

    Xiang Cai, Rishab Nithyanand, and Rob Johnson. Cs-buflo: A conges- tion sensitive website fingerprinting defense. In Workshop on Privacy in the Electronic Society (WPES), 2014

    2014

  6. [14]

    A systematic approach to developing and evaluating website fingerprinting defenses

    Xiang Cai, Rishab Nithyanand, Tao Wang, Rob Johnson, and Ian Gold- berg. A systematic approach to developing and evaluating website fingerprinting defenses. In ACM SIGSAC Conference on Computer and Communications Security (CCS), 2014

    2014

  7. [15]

    Touching from a distance: Website fingerprinting attacks and defenses

    Xiang Cai, Xin Cheng Zhang, Brijesh Joshi, and Rob Johnson. Touching from a distance: Website fingerprinting attacks and defenses. In ACM Conf. on Computer and Communications Security (CCS), 2012

    2012

  8. [16]

    Side- channel leaks in web applications: A reality today, a challenge tomorrow

    Shuo Chen, Rui Wang, XiaoFeng Wang, and Kehuan Zhang. Side- channel leaks in web applications: A reality today, a challenge tomorrow. In IEEE Symposium on Security and Privacy (SP), 2010

    2010

  9. [17]

    Traffic analysis of ssl encrypted web browsing, 1998

    Heyning Cheng and Ron Avnur. Traffic analysis of ssl encrypted web browsing, 1998

    1998

  10. [18]

    Howie Huang

    Ron Chi-Lung Chiang, Sundaresan Rajasekaran, Nan Zhang, and H. Howie Huang. Swiper: Exploiting virtual machine vulnerability in third-party clouds with competition for I/O resources. IEEE Trans. on Parallel and Distributed Systems (TPDS), 26(6), 2015

    2015

  11. [19]

    Obladi: Oblivious serializable transac- tions in the cloud

    Natacha Crooks, Matthew Burke, Ethan Cecchetti, Sitar Harel, Rachit Agarwal, and Lorenzo Alvisi. Obladi: Oblivious serializable transac- tions in the cloud. In USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2018

    2018

  12. [20]

    Traffic Analysis of the HTTP Protocol over TLS

    George Danezis. Traffic Analysis of the HTTP Protocol over TLS. http://www0.cs.ucl.ac.uk/staff/G.Danezis/papers/ TLSanon.pdf, 2009. 13

    2009

  13. [21]

    Peek-a-boo, I still see you: Why efficient traffic analysis coun- termeasures fail

    Kevin P Dyer, Scott E Coull, Thomas Ristenpart, and Thomas Shrimp- ton. Peek-a-boo, I still see you: Why efficient traffic analysis coun- termeasures fail. In IEEE Symposium on Security and Privacy (SP) , 2012.[22] Kevin P Dyer, Scott E Coull, Thomas Ristenpart, and Thomas Shrim...

    2012

  14. [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

  15. [24]

    Jump over ASLR: Attacking branch predictors to bypass ASLR

    Dmitry Evtyushkin, Dmitry Ponomarev, and Nael Abu-Ghazaleh. Jump over ASLR: Attacking branch predictors to bypass ASLR. InIEEE/ACM Intl. Symposium on Microarchitecture (MICRO), 2016

    2016

  16. [25]

    Suppressing the oblivious ram tim- ing channel while making information leakage and program efficiency trade-offs

    Christopher W Fletchery, Ling Ren, Xiangyao Yu, Marten Van Dijk, Omer Khan, and Srinivas Devadas. Suppressing the oblivious ram tim- ing channel while making information leakage and program efficiency trade-offs. In IEEE International Symposium on High Performance Computer Arch...

    2014

  17. [26]

    A survey of microarchitectural timing attacks and countermeasures on contemporary hardware

    Qian Ge, Yuval Yarom, David Cock, and Gernot Heiser. A survey of microarchitectural timing attacks and countermeasures on contemporary hardware. Journal of Cryptographic Engineering, 2016

    2016

  18. [27]

    Accessed 31 Aug 2020

    2020

  19. [28]

    Website detection using remote traffic analysis

    Xun Gong, Nikita Borisov, Negar Kiyavash, and Nabil Schear. Website detection using remote traffic analysis. In Privacy Enhancing Technolo- gies Symposium (PETS), 2012

    2012

  20. [29]

    Quantifying the information leakage in timing side channels in deterministic work-conserving schedulers

    Xun Gong and Negar Kiyavash. Quantifying the information leakage in timing side channels in deterministic work-conserving schedulers. IEEE/ACM Trans. on Networking (TON), 24(3), 2016

    2016

  21. [30]

    k-fingerprinting: A robust scalable website fingerprinting technique

    Jamie Hayes and George Danezis. k-fingerprinting: A robust scalable website fingerprinting technique. In USENIX Security Symposium, 2016

    2016

  22. [31]

    Fingerprinting websites using traffic analysis

    Andrew Hintz. Fingerprinting websites using traffic analysis. In Conf. on Privacy Enhancing Technologies (PETS), 2002

    2002

  23. [32]

    Seriously, get off my cloud! cross- vm rsa key recovery in a public cloud

    Mehmet Sinan Inci, Berk Gülmezoglu, Gorka Irazoqui Apecechea, Thomas Eisenbarth, and Berk Sunar. Seriously, get off my cloud! cross- vm rsa key recovery in a public cloud. IACR Cryptology ePrint Archive, 2015(1-15), 2015

    2015

  24. [33]

    Efficient, adversarial neighbor discovery using logical channels on microsoft azure

    Mehmet Sinan ˙Inci, Gorka Irazoqui, Thomas Eisenbarth, and Berk Sunar. Efficient, adversarial neighbor discovery using logical channels on microsoft azure. In Annual Conf. on Computer Security Applications (ACSAC), 2016

    2016

  25. [34]

    S$A: A Shared Cache Attack That Works across Cores and Defies VM Sandboxing–and Its Application to AES

    Gorka Irazoqui, Thomas Eisenbarth, and Berk Sunar. S$A: A Shared Cache Attack That Works across Cores and Defies VM Sandboxing–and Its Application to AES. In IEEE Symposium on Security and Privacy (SP), 2015

    2015

  26. [35]

    Silo: Predictable message latency in the cloud

    Keon Jang, Justine Sherry, Hitesh Ballani, and Toby Moncaster. Silo: Predictable message latency in the cloud. In ACM Conf. on Special Interest Group on Data Communication (SIGCOMM), 2015

    2015

  27. [36]

    Miti- gating timing side channel in shared schedulers

    Sachin Kadloor, Negar Kiyavash, and Parv Venkitasubramaniam. Miti- gating timing side channel in shared schedulers. IEEE/ACM Trans. on Networking (TON), 24(3), 2016

    2016

  28. [37]

    Adam: A Method for Stochastic Optimization

    Diederik P Kingma and Jimmy Ba. Adam: A Method for Stochastic Optimization. http://arxiv.org/abs/1412.6980, 2014

    2014 arXiv

  29. [38]

    Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems

    Paul Kocher. Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems. In Advances in Cryptology – CRYPTO, 1996.[38] Adam Langley, Alistair Riddoch, Alyssa Wilk, Antonio Vicente, Charles Krasic, Dan Zhang, Fan Yang, Fedor Kouranov, Ian Swett, Janardhan I...

    1996

  30. [39]

    Karaoke: Distributed private messaging immune to passive traffic analysis

    David Lazar, Yossi Gilad, and Nickolai Zeldovich. Karaoke: Distributed private messaging immune to passive traffic analysis. InUSENIX Sympo- sium on Operating Systems Design and Implementation (OSDI), 2018

    2018

  31. [40]

    Yodel: strong metadata security for voice calls

    David Lazar, Yossi Gilad, and Nickolai Zeldovich. Yodel: strong metadata security for voice calls. In ACM Symposium on Operating Systems Principles (SOSP), 2019

    2019

  32. [41]

    Herd: A scalable, traffic analysis resistant anonymity network for V oIP systems

    Stevens Le Blond, David Choffnes, William Caldwell, Peter Druschel, and Nicholas Merritt. Herd: A scalable, traffic analysis resistant anonymity network for V oIP systems. In ACM Conf. on Special In- terest Group on Data Communication (SIGCOMM), 2015

    2015

  33. [42]

    Stopwatch: a cloud archi- tecture for timing channel mitigation

    Peng Li, Debin Gao, and Michael K Reiter. Stopwatch: a cloud archi- tecture for timing channel mitigation. ACM Trans. on Information and System Security (TISSEC), 17(2), 2014

    2014

  34. [43]

    Measuring information leakage in website fingerprinting attacks and defenses

    Shuai Li, Huajun Guo, and Nicholas Hopper. Measuring information leakage in website fingerprinting attacks and defenses. In ACM Conf. on Computer and Communications Security (CCS), 2018

    2018

  35. [44]

    Last-level cache side-channel attacks are practical

    Fangfei Liu, Yuval Yarom, Qian Ge, Gernot Heiser, and Ruby B Lee. Last-level cache side-channel attacks are practical. In IEEE Symposium on Security and Privacy (SP), 2015

    2015

  36. [45]

    On-demand time blurring to support side-channel defense

    Weijie Liu, Debin Gao, and Michael K Reiter. On-demand time blurring to support side-channel defense. In European Symposium on Research in Computer Security (ESORICS), 2017

    2017

  37. [46]

    Shroud: Ensuring private access to large-scale data in the data center

    Jacob R Lorch, Bryan Parno, James Mickens, Mariana Raykova, and Joshua Schiffman. Shroud: Ensuring private access to large-scale data in the data center. InUSENIX Conference on File and Storage Technologies (FAST), 2013

    2013

  38. [47]

    Dynaflow: An efficient website fingerprinting defense based on dynamically- adjusting flows

    David Lu, Sanjit Bhat, Albert Kwon, and Srinivas Devadas. Dynaflow: An efficient website fingerprinting defense based on dynamically- adjusting flows. In Workshop on Privacy in the Electronic Society (WPES), 2018

    2018

  39. [48]

    HTTPOS: Sealing Information Leaks with Browser-side Obfuscation of Encrypted Flows

    Xiapu Luo, Peng Zhou, Edmond WW Chan, Wenke Lee, Rocky KC Chang, and Roberto Perdisci. HTTPOS: Sealing Information Leaks with Browser-side Obfuscation of Encrypted Flows. In Network and Distributed System Security Symposium (NDSS), volume 11, 2011

    2011

  40. [49]

    Timewarp: Rethinking timekeeping and performance monitoring mechanisms to mitigate side-channel attacks

    Robert Martin, John Demme, and Simha Sethumadhavan. Timewarp: Rethinking timekeeping and performance monitoring mechanisms to mitigate side-channel attacks. In Intl. Symposium on Computer Archi- tecture (ISCA), 2012

    2012

  41. [50]

    Skypemorph: Protocol obfuscation for tor bridges

    Hooman Mohajeri Moghaddam, Baiyu Li, Mohammad Derakhshani, and Ian Goldberg. Skypemorph: Protocol obfuscation for tor bridges. In ACM Conf. on Computer and Communications Security (CCS), 2012

    2012

  42. [51]

    Glove: A bespoke website fingerprinting defense

    Rishab Nithyanand, Xiang Cai, and Rob Johnson. Glove: A bespoke website fingerprinting defense. In Workshop on Privacy in the Electronic Society (WPES), 2014

    2014

  43. [52]

    Scheduling I/O in virtual machine monitors

    Diego Ongaro, Alan L Cox, and Scott Rixner. Scheduling I/O in virtual machine monitors. In ACM SIGPLAN/SIGOPS Intl. Conf. on Virtual Execution Environments (VEE), 2008

    2008

  44. [53]

    Website fingerprinting in onion routing based anonymization networks

    Andriy Panchenko, Lukas Niessen, Andreas Zinnen, and Thomas Engel. Website fingerprinting in onion routing based anonymization networks. In ACM Workshop on Privacy in the Electronic Society (WPES), 2011

    2011

  45. [54]

    DRAMA: Exploiting DRAM Addressing for Cross- CPU Attacks

    Peter Pessl, Daniel Gruss, Clementine Maurice, Michael Schwarz, and Stefan Mangard. DRAMA: Exploiting DRAM Addressing for Cross- CPU Attacks. In USENIX Security Symposium, 2016

    2016

  46. [55]

    Who Is Your Neighbor: Net I/O Perfor- mance Interference in Virtualized Clouds

    Xing Pu, Ling Liu, Yiduo Mei, Sankaran Sivathanu, Younggyun Koh, Calton Pu, and Yuanda Cao. Who Is Your Neighbor: Net I/O Perfor- mance Interference in Virtualized Clouds. IEEE Trans. on Services Computing, 6(3), 2013

    2013

  47. [56]

    A Hardware/Software Approach for Miti- gating Performance Interference Effects in Virtualized Environments Using SR-IOV

    Andre Richter, Christian Herber, Stefan Wallentowitz, Thomas Wild, and Andreas Herkersdorf. A Hardware/Software Approach for Miti- gating Performance Interference Effects in Virtualized Environments Using SR-IOV. In IEEE Intl. Conf. on Cloud Computing (CLOUD) , 2015

    2015

  48. [57]

    Hey, You, Get off of My Cloud: Exploring Information Leakage in Third-party Compute Clouds

    Thomas Ristenpart, Eran Tromer, Hovav Shacham, and Stefan Savage. Hey, You, Get off of My Cloud: Exploring Information Leakage in Third-party Compute Clouds. In ACM Conf. on Computer and Commu- nications Security (CCS), 2009

    2009

  49. [58]

    Devices that tell on you: Privacy trends in con- sumer ubiquitous computing

    T Scott Saponas, Jonathan Lester, Carl Hartung, Sameer Agarwal, Ta- dayoshi Kohno, et al. Devices that tell on you: Privacy trends in con- sumer ubiquitous computing. In USENIX Security Symposium, 2007

    2007

  50. [59]

    Beauty and the Burst: Remote Identification of Encrypted Video Streams

    Roei Schuster, Vitaly Shmatikov, and Eran Tromer. Beauty and the Burst: Remote Identification of Encrypted Video Streams. In USENIX Security Symposium, 2017

    2017

  51. [60]

    Net- Spectre: Read Arbitrary Memory over Network

    Michael Schwarz, Martin Schwarzl, Moritz Lipp, and Daniel Gruss. Net- Spectre: Read Arbitrary Memory over Network. CoRR, abs/1807.10535, 2018

    2018 arXiv

  52. [61]

    Principles of secure information flow analysis

    Geoffrey Smith. Principles of secure information flow analysis. In Mihai Christodorescu, Somesh Jha, Douglas Maughan, Dawn Song, and Cliff Wang, editors, Malware Detection, volume 27 of Advances in Information Security, pages 291–307. Springer, 2007

    2007

  53. [62]

    Timing anal- ysis of keystrokes and timing attacks on ssh

    Dawn Xiaodong Song, David Wagner, and Xuqing Tian. Timing anal- ysis of keystrokes and timing attacks on ssh. In USENIX Security Symposium, 2001

    2001

  54. [63]

    Simon, Yi-Min Wang, Wilf Russell, Venkata N

    Qixiang Sun, Daniel R. Simon, Yi-Min Wang, Wilf Russell, Venkata N. Padmanabhan, and Lili Qiu. Statistical identification of encrypted web browsing traffic. In IEEE Symposium on Security and Privacy (SP) , 2002

    2002

  55. [64]

    Tor: The Second-Generation Onion Router

    Paul Syverson, Roger Dingledine, and Nick Mathewson. Tor: The Second-Generation Onion Router. In Usenix Security, 2004

    2004

  56. [65]

    Vuvuzela: Scalable private messaging resistant to traffic analy- sis

    Jelle Van Den Hooff, David Lazar, Matei Zaharia, and Nickolai Zel- dovich. Vuvuzela: Scalable private messaging resistant to traffic analy- sis. In Symposium on Operating Systems Principles (SOSP), 2015

    2015

  57. [66]

    Scheduler-based defenses against cross-vm side-channels

    Venkatanathan Varadarajan, Thomas Ristenpart, and Michael M Swift. Scheduler-based defenses against cross-vm side-channels. In USENIX Security Symposium, 2014

    2014

  58. [67]

    Eliminating fine grained timers in xen

    Bhanu C Vattikonda, Sambit Das, and Hovav Shacham. Eliminating fine grained timers in xen. In ACM workshop on Cloud Computing Security Workshop, 2011

    2011

  59. [68]

    Practical TDMA for Datacenter Ethernet

    Bhanu Chandra Vattikonda, George Porter, Amin Vahdat, and Alex C Snoeren. Practical TDMA for Datacenter Ethernet. In ACM European Conference on Computer Systems (EuroSys), 2012

    2012

  60. [69]

    Loophole: Timing attacks on shared event loops in chrome

    Pepe Vila and Boris Köpf. Loophole: Timing attacks on shared event loops in chrome. In USENIX Security Symposium, 2017. 14

    2017

  61. [70]

    Effective attacks and provable defenses for website fingerprinting

    Tao Wang, Xiang Cai, Rishab Nithyanand, Rob Johnson, and Ian Gold- berg. Effective attacks and provable defenses for website fingerprinting. In USENIX Security Symposium, 2014

    2014

  62. [71]

    Walkie-talkie: An efficient defense against passive website fingerprinting attacks

    Tao Wang and Ian Goldberg. Walkie-talkie: An efficient defense against passive website fingerprinting attacks. In USENIX Security Symposium, 2017

    2017

  63. [72]

    Scramblesuit: A poly- morphic network protocol to circumvent censorship

    Philipp Winter, Tobias Pulls, and Juergen Fuss. Scramblesuit: A poly- morphic network protocol to circumvent censorship. In ACM Workshop on Privacy in the Electronic Society (WPES), 2013

    2013

  64. [73]

    Spot me if you can: Uncovering spoken phrases in encrypted V oIP conversations

    Charles V Wright, Lucas Ballard, Scott E Coull, Fabian Monrose, and Gerald M Masson. Spot me if you can: Uncovering spoken phrases in encrypted V oIP conversations. InIEEE Symposium on Security and Privacy (SP), 2008

    2008

  65. [74]

    Wright, Scott E

    Charles V . Wright, Scott E. Coull, and Fabian Monrose. Traffic morph- ing: An efficient defense against statistical traffic analysis. In Network and Distributed System Security Symposium (NDSS), 2009

    2009

  66. [75]

    On inferring application protocol behaviors in encrypted network traffic

    Charles V Wright, Fabian Monrose, and Gerald M Masson. On inferring application protocol behaviors in encrypted network traffic. Journal of Machine Learning Research (JMLR), 7, Dec 2006

    2006

  67. [76]

    Deterministically deterring timing attacks in deterland

    Weiyi Wu and Bryan Ford. Deterministically deterring timing attacks in deterland. arXiv preprint arXiv:1504.07070, 2015

    2015 arXiv

  68. [77]

    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 IEEE Symposium on Security and Privacy (SP), 2015

    2015

  69. [78]

    FLUSH+RELOAD: A High Resolu- tion, Low Noise, L3 Cache Side-Channel Attack

    Yuval Yarom and Katrina Falkner. FLUSH+RELOAD: A High Resolu- tion, Low Noise, L3 Cache Side-Channel Attack. In USENIX Security Symposium, 2014

    2014

  70. [79]

    CacheBleed: a tim- ing attack on OpenSSL constant-time RSA

    Yuval Yarom, Daniel Genkin, and Nadia Heninger. CacheBleed: a tim- ing attack on OpenSSL constant-time RSA. Journal of Cryptographic Engineering, 7(2), 2017

    2017

  71. [80]

    Predictive Mitigation of Timing Channels in Interactive Systems

    Danfeng Zhang, Aslan Askarov, and Andrew C Myers. Predictive Mitigation of Timing Channels in Interactive Systems. In ACM Conf. on Computer and Communications Security (CCS), 2011

    2011

  72. [81]

    Cross-VM side channels and their use to extract private keys

    Yinqian Zhang, Ari Juels, Michael K Reiter, and Thomas Ristenpart. Cross-VM side channels and their use to extract private keys. In ACM Conf. on Computer and Communications Security (CCS), 2012

    2012

  73. [82]

    Mitts: Memory inter-arrival time traffic shaping

    Yanqi Zhou and David Wentzlaff. Mitts: Memory inter-arrival time traffic shaping. ACM SIGARCH Computer Architecture News, 44(3), 2016. A. Network Side-Channel Attack Here, we briefly describe a proof-of-concept NSC attack. To carry out such an attack, an adversary must be able t...

    2016

  74. [83]

    Environment acts The environment acts by consuming a subset of events in the queue QE, processing them to update its internal state and adding new events to the queue QG

    and FE(QE2, σE2, Tg) = (QE′ 2, QG′′ 2, σE′ 2) ⇒ QE′ 1∼ QE′ 2 and QG′′ 1∼ QG′′ 2 and σE′ 1∼ σE′ 2 Transition FE(QE, σE, Tg) = (QE ′, QG ′′, σE ′) (σE, σG, σH, QG, QH, QE, Tg) ↝E (σE ′, σG, σH, QG∪ QG ′′, QH, QE ′, Tg) env Figure 10: Assumptions and transition of the environment...

  75. [84]

    Tui≤ Tei (4) FG(QG, Temax, Qp H, σG, Tg) = (QG′, Qu H ′′, Temax′, Qp H ′, σG′) ⇒ Iemax(Qu H ′′, Temax′) where Iemax(Qu H, Temax)≜∀(f↦→ U)∈ Qu H.∀(Tui, Eui, Tei)∈ U

    and FG(QG2, Temax2, Qp H2, σG2, Tg) = (QG′ 2, Qu H ′′ 2, Temax′ 2, Qp H ′ 2, σG′ 2) ⇒ QG′ 1∼ QG′ 2 and Qu H ′′ 1∼ Qu H ′′ 2 and σG′ 1∼ σG′ 2 (3) FG(QG, Temax, Qp H, σG, Tg) = (QG′, Qu H ′, Temax′, Qp H ′, σG′) ⇒ Idelay(Qu H ′) where Idelay(Qu H)≜∀(f↦→ U)∈ Qu H.∀(Tui, Eui, Tei)...

  76. [85]

    (Non-consumption of future inputs) FG should not remove future events from its input queue, QG

    and Fo H(Qp H2,s2) = (Qp H ′ 2, QE′′ 2) ⇒ QE′′ 1∼ QE′′ 2 Transition σH ={flowi↦→ Φi}N i=1 Qu H ={flowi↦→ Ui}N i=1 (Φ′ i, U′ i) = update_prof(Φi, Ui, Tg) σH ′←{ flowi↦→ Φ′ i}N i=1 [σH ′]Tg≜{flowi↦→ [Φ′ i]Tg}N i=1 Fo H(Qp H, [σH ′]Tg) = (Qp H ′, QE ′′) Qu H ′←{ flowi↦→ U′ i}N i=...

  77. [86]

    QE1∼ QE2 by assump- tion about the invariant holding before the transition, so we only need to prove that QE′′ 1∼ QE′′

  78. [87]

    We already know from the invariant be- fore the transition that Tg1 = Tg2 = Tg (say) and, following the definition of [σH′]Tg, we only need to show that for every i∈{ 1,

    Now, again following the rule, QE′′ i (for i = 1,2) is obtained from the function Fo H, so by assumption (7) of Figure 13, we only need to show that [σH′ 1]Tg1 = [σH′ 2]Tg2. We already know from the invariant be- fore the transition that Tg1 = Tg2 = Tg (say) and, following the...

Pith tools

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