Speedbumps: Rejection Attacks on Speculative Decoding

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: Today's paper: "Speedbumps: Rejection Attacks on Speculative Decoding".

Elias: The gist Speculative Rejection Attacks (SRAs) are a novel class of attacks that cause draft and target models to disagree more often,

Nadia: First, who's behind it and why it matters.

Title and authors: Nadia: Let's talk about who did this. The paper is titled "Speedbumps: Rejection Attacks on Speculative Decoding," and it’s written by Adam Y. J. Jones, Yu Yuan, and Sergio Maffeis from Imperial College London.

Elias: They are researchers in AI security and cryptography, so they're looking at how these models work under attack or exploitation. What's important here is that the authors are focusing on how to actually exploit the mechanics of speculative decoding rather than just making generic noise.

Priya: As a privacy researcher, I’m curious if this means we need to worry about these attacks when we use speculative decoding for sensitive tasks, or if it’s mostly an issue for general speedup.

Nadia: It's not just general speedup anymore; the paper shows that even when people are using techniques like speculative decoding, there’s a vulnerability that can be exploited to increase the cost per token beyond what you would pay for standard autoregressive decoding without it.

Elias: They characterize these SRAs by saying they exploit the way draft and target models interact, specifically by causing them to disagree more frequently about the proposed tokens.

The paper's summary: Nadia: So, what exactly is the core mechanism of Speedbumps? It’s about appending a specific adversarial suffix to content controlled by an attacker, and this suffix is designed to degrade speculative decoding on a victim's prompt.

Elias: The attack optimizes the expected length of the accepted prefix by using two different proxies. One proxy, Speedbump-P, only looks at the drafted tokens themselves, while the other one, Speedbump-D, looks at both distributions—the draft and the target model’s distribution.

Priya: That sounds like they are trying to figure out if it’s better to mess with what the drafter proposes or what the target model expects overall. What do those proxies actually measure?

Nadia: Speedbump-P uses a Proposal Mass Proxy, which measures how much support the target model gives to each proposal presented for verification. Speedbump-D uses a Draft-Target Overlap Proxy, which looks at the minimum of the target probability and the overlap between the draft and target distributions.

Elias: The objective function they are optimizing is defined as JSpeedbump(x) = −one/Cx Σ c Xmc i Σ j=one αc j, which basically captures how reachable a prefix is by reducing acceptance at an early depth lowers the probability of reaching every subsequent depth.

The paper's improvements: Nadia: The authors show that Speedbump outperforms other approaches they compared it to, like Mistletoe and ADSD objectives on every single decoder they tested. They also found that weighting earlier output positions with a decay makes the Speedbump objective substantially stronger for certain models.

Elias: That suggests that focusing the attack on the beginning of the generated sequence is key to maximizing the slowdown effect, which makes sense because accepting tokens early affects all subsequent steps in generating a token.

Priya: If this is true, it means an attacker doesn't need to change a whole paragraph; they just need to mess with the very first few words of the prompt to start slowing down the process.

Nadia: Precisely. And they also looked at transferability, finding that Speedbump-P transfers strongly across different drafters on GSM8K, reducing performance by about one point two zero on average for other decoders compared to native suffixes which only reduce it by zero point seven three.

Elias: But the paper flags a limitation here too; Speedbump-D doesn't transfer well because it changes the drafter’s output, whereas Speedbump-P is more transferable across different drafters.

Conclusion: Nadia: So to wrap up, the main point of "Speedbumps: Rejection Attacks on Speculative Decoding" is that speculative decoding isn't safe under adversarial input because these SRAs can inflate per-token costs past what you would expect from a standard autoregressive process.

Elias: The authors show that this happens by appending an adversarial suffix to the input, and they give us two specific proxies, Speedbump-P and Speedbump-D, to understand how effective those attacks are.

Priya: From a measurement side, it’s clear that these attacks don't even need to alter the final response quality significantly for the attacker; they only need the cost increase. That means we have to be careful about relying on speculative savings when dealing with untrusted inputs in any application.

Nadia: Right. The paper concludes that LLM application operators shouldn't assume that speculative savings hold for untrusted input and should consider defenses against these Speculative Rejection Attacks.

Elias: They suggest countermeasures like detecting an attack by looking at the perplexity of the prompt, or by monitoring response perplexity or a drop in quality. And they also tested changing the target model itself as a way to defend against it.

Priya: It’s interesting that they found that switching the target model could actually reduce the effect of this cost inflation, which means model choice is part of the defense strategy.

Nadia: That’s what we're hearing about "Speedbumps: Rejection Attacks on Speculative Decoding." We've covered how these suffix attacks work, what they measure with those proxies, and why this matters for anyone using speculative decoding in a production environment.