Technisches Resümee: Fair ASR: Neubewertung von Black-Box-Jailbreaks unter geteilten Zielaufruf-Budgets

1. Problemstellung

Die aktuellen Evaluierungen von Jailbreak-Angriffen auf Large Language Models (LLMs) verlassen sich primär auf die Attack Success Rate (ASR), versäumen es jedoch häufig, das für diesen Erfolg erforderliche Angriffsbudget zu berücksichtigen. Bestehende Studien berichten oft über terminale ASR-Werte, die unter ungleichen Ressourcenbeschränkungen ermittelt wurden, was zu unfairen Vergleichen führt, bei denen die Effektivität einer Methode mit der Menge des genutzten Zielzugriffs verwechselt wird.

Obwohl jüngste „compute-aware“ Evaluierungen versuchen, Budgets durch Aggregation von Ressourcen in einen einheitlichen Skalar (z. B. FLOPs) zu normalisieren, weist dieser Ansatz erhebliche Einschränkungen für Black-Box-Szenarien auf:

1. Unsichtbarkeit: Die Inferenz-FLOPs für geschlossene Modelle sind im Allgemeinen nicht verfügbar und müssen geschätzt werden.
2. Nicht-Austauschbarkeit: FLOPs kollabieren unterschiedliche Ressourcenbeschränkungen (z. B. API-Ratenbegrenzungen vs. Rechenkosten) zu einem einzigen Metrikwert, wodurch die operativen Realitäten verschleiert werden, in denen der Zugriff auf das Zielmodell aufgrund von Ratenbegrenzungen und Missbrauchserkennung der primäre Engpass ist.

Folglich mangelt es an einer vergleichbaren, beobachtbaren Basis für die Evaluierung heterogener Black-Box-Jailbreak-Angriffe.

2. Methodik: Fair-ASR-Protokoll

Um diese Probleme anzugehen, führen die Autoren Fair-ASR ein Evaluierungsprotokoll ein, das Vergleiche unter geteilten Zielaufruf-Budgets ($B$) standardisiert.

Kernprinzipien

• Primäres Budget ($B$): Das Protokoll verwendet die Anzahl der Zielaufrufe (Abfragen an das Opfermodell) als primäres Budget. Dies wurde gewählt, weil:
  • Es universell für alle Black-Box-Angriffe ist (jeder Angriff muss das Ziel abfragen).
  • Es operative Beschränkungen widerspiegelt (Ratenbegrenzungen, Kontosperrungen).
  • Es direkt beobachtbar ist, im Gegensatz zu FLOPs für geschlossene APIs.
• Sekundäre Metrik: Angreifer-Aufrufe (Abfragen an ein Angreifer-LLM oder einen Hilfs-Judge) werden separat verfolgt, um Effizienz-Trade-offs zu analysieren, anstatt sie in das primäre Budget zu kollabieren.
• Evaluierungsmetriken:
  • ASR@B: Der Anteil der erfolgreichen Angriffe auf schädliche Anfragen innerhalb von höchstens $B$ Zielaufrufen.
  • ASR-Budget-Kurve: Der Verlauf der ASR bei steigendem $B$, der Wachstumsraten und Sättigungspunkte aufzeigt.
  • Durchschnittliche Zielaufrufe (ATC): Die durchschnittliche Anzahl der pro erfolgreichem Angriff verbrauchten Zielaufrufe.
  • Schädlichkeits-Score (HS): Eine Qualitätsmetrik (unter Verwendung der StrongREJECT-Rubrik), welche die Schwere und Überzeugungskraft der schädlichen Antwort bewertet.

Experimenteller Umfang

Die Autoren haben 11 repräsentative Angriffe aus drei Kategorien neu evaluiert:

1. Handgefertigte Templates: CodeAttack, DeepInception, CipherChat.
2. Stochastische wiederholte Stichproben: Best-of-N (BoN).
3. LLM-gesteuerte automatisierte Angriffe: PAIR, TAP, ReNeLLM, AutoDAN, GPTFuzzer, AutoDAN-Turbo, Rainbow Teaming.

Die Experimente wurden auf diversen Zielmodellen (Llama-3.1, gpt-oss, GPT-4o, GPT-5, Gemini-3.1-Pro, Claude-Sonnet-4.6) unter Verwendung von Standard-Datensätzen (HarmBench, JailbreakBench) durchgeführt.

3. Zentrale Erkenntnisse der Neubewertung

Die Anwendung von Fair-ASR offenbarte drei kritische Erkenntnisse:

1. Budget-abhängige Rangfolgen: Die Rankings der Angriffe reagieren hochsensibel auf das Zielaufruf-Budget. Methoden, die unter großen Budgets überlegen erscheinen, können unter engen Budgets von einfacheren Methoden übertroffen werden. Beispielsweise führt TAP auf Llama-3.1-8B bei $B=5$ vor BoN, aber BoN überholt TAP bei $B=100$.
2. Wettbewerbsfähigkeit einfacher Primitiven: Einfache Angriffs-Primitive bleiben unter gleichem Zielzugriff äußerst wettbewerbsfähig.
   • Stochastische Perturbation: BoN verbessert sich kontinuierlich mit zusätzlichen Zielaufrufen und erreicht eine hohe ASR ohne jegliche Angreifer-Modell-Aufrufe.
   • Handgefertigte Templates: Strukturierte Templates (z. B. CodeAttack) erzielen hohe Erfolgsraten mit sehr wenigen Zielaufrufen (z. B. 62 % ASR bei $B=1$) und übertreffen oft komplexe LLM-gesteuerte Methoden in Low-Budget-Regimen.
3. Effizienz-Trade-offs: Keine der evaluierten LLM-gesteuerten Methoden ist sowohl bei Ziel- als auch bei Angreifer-Aufrufen einheitlich effizient.
   • ReNeLLM erreicht eine hohe Zielaufruf-Effizienz (niedriger ATC), verursacht jedoch hohe Angreifer-Aufruf-Kosten aufgrund iterativer Umschreibungen und Prompt-only-Schädlichkeits-Gates.
   • Andere Methoden (z. B. PAIR, TAP) nutzen möglicherweise weniger Angreifer-Aufrufe, benötigen aber signifikant mehr Zielaufrufe, um ähnliche Erfolgs-Schwellenwerte zu erreichen.

4. Vorgeschlagene Lösung: ReCode

Motiviert durch die identifizierte „zweidimensionale Effizienzlücke“, schlagen die Autoren ReCode vor, einen kompositorischen Angriff, der darauf ausgelegt ist, die ASR zu maximieren und gleichzeitig sowohl die Ziel- als als auch die Angreifer-Aufrufe zu minimieren.

Design-Architektur

ReCode kombelt drei Komponenten in einer Single-Pass-Pipeline:

1. Gate-freie Desensibilisierungs-Umschreibung: Im Gegensatz zu ReNeLLM, das ein Prompt-only-Schädlichkeits-Gate zur Filterung von Umschreibungen nutzt (was kostspielige Retries auslöst), führt ReCode eine Single-Pass-Umschreibung mittels Desensibilisierungsstrategien (z. B. literarische Umschreibung, objektive Substitution) durch, ohne eine Hilfs-Judge-Schleife.
2. Angreifer-freie stochastische Perturbation: Der umgeschriebene Prompt durchläuft zeichenbasierte Perturbationen (z. B. Groß-/Kleinschreibung-Inversion, ASCII-Einfügung) ähnlich wie BoN, was null zusätzliche Angreifer-Aufrufe erfordert.
3. Strukturierte Code-Stil-Verschachtelung: Der perturbierte Prompt wird in ein strukturiertes Code-Stil-Template eingebettet (z. B. Python-Klassendefinitionen), was die Absicht weiter verschleiert, ohne eine Verfeinerung durch das Angreifer-Modell zu erfordern.

Ergebnisse

Evaluiert unter einem Budget von $B=20$ Zielaufrufen:

• Performance: ReCode erreichte eine durchschnittliche ASR von 81,0 % über fünf Zielmodelle (einschließlich gpt-oss Varianten) und 70,3 % über die drei Frontier-Closed-Source-Modelle (GPT-5, Gemini-3.1-Pro, Claude-Sonnet-4.6).
• Effizienz: Es benötigte im Durchschnitt nur 7,00 Angreifer-Aufrufe pro Anfrage (AAC), was signifikant niedriger ist als bei ReNeLLM (18,69) und TAP (49,56).
• Spezifische Gewinne: Auf GPT-5 verbesserte ReCode die ASR von 31 % (ReNeLLM) auf 85 %, während die Angreifer-Aufrufe von 26,02 auf 7,19 reduziert wurden.
• Schädlichkeit: ReCode erreichte zudem den höchsten durchschnittlichen Harmfulness Score (HS) von 0,662, was darauf hindeutet, dass höhere Erfolgsraten mit qualitativ hochwertigeren schädlichen Antworten korrelierten.

5. Bedeutung und Behauptungen

Das Paper behauptet, dass Fair-ASR eine notwendige, beobachtbare Baseline für den Vergleich von Black-Box-Jailbreaks bietet und irreführende Schlussfolgerungen aus ungleichen Budget-Vergleichen korrigiert. Es demonstriert, dass algorithmische Komplexität keine Garantie für Effizienz ist und dass einfache, kostengünstige Primitive oft untergenutzt bleiben.

Die Einführung von ReCode dient als Proof-of-Concept dafür, dass das Schließen der Effizienzlücke möglich ist, indem man Desensibilisierungs-Umschreibung mit Angreifer-freien Obfuskations-Techniken kombiniert. Die Autoren kommen zu dem Schluss, dass zukünftige Evaluierungen über den terminalen ASR-Wert hinausgehen müssen, um die gemeinsame Ressourcen-Effizienz (Ziel- und Angreifer-Aufrufe) zu berücksichtigen, um die Sicherheitslandschaft von LLMs korrekt zu bewerten.

Anmerkungen zu Limitationen:

• Das Protokoll konzentriert sich derzeit auf Single-Turn-Angriffe und deckt noch keine Multi-Turn-Settings ab.
• Zielaufrufe erfassen nicht den Token-Verbrauch, die API-Preise oder die manuellen Kosten der Template-Entwicklung.
• Die Studie räumt ein, dass obwohl ReCode effizient ist, spezifische Modell-Verhaltensweisen (z. B. die Sensitivität von Claude gegenüber Code-Verschachtelungen) variieren können, was weitere Untersuchungen erfordert.