human: Given a node-centered hypergraph: <hypergraph>, where nodes represent papers and hyperedges represent sets of papers co-cited by a source paper.

Details of the hypergraph:
Center node: "block oriented programming automating data only attacks"
  Abstract: With the widespread deployment of Control-Flow Integrity (CFI), control-flow hijacking attacks, and consequently code reuse attacks, are significantly more difficult. CFI limits control flow to well-known locations, severely restricting arbitrary code execution. Assessing the remaining attack surface of an application under advanced control-flow hijack defenses such as CFI and shadow stacks remains an open problem. We introduce BOPC, a mechanism to automatically assess whether an attacker can execute arbitrary code on a binary hardened with CFI/shadow stack defenses. BOPC computes exploits for a target program from payload specifications written in a Turing-complete, high-level language called SPL that abstracts away architecture and program-specific details. SPL payloads are compiled into a program trace that executes the desired behavior on top of the target binary. The input for BOPC is an SPL payload, a starting point (e.g., from a fuzzer crash) and an arbitrary memory write primitive that allows application state corruption. To map SPL payloads to a program trace, BOPC introduces Block Oriented Programming (BOP), a new code reuse technique that utilizes entire basic blocks as gadgets along valid execution paths in the program, i.e., without violating CFI or shadow stack policies. We find that the problem of mapping payloads to program traces is NP-hard, so BOPC first reduces the search space by pruning infeasible paths and then uses heuristics to guide the search to probable paths. BOPC encodes the BOP payload as a set of memory writes. We execute 13 SPL payloads applied to 10 popular applications. BOPC successfully finds payloads and complex execution traces -- which would likely not have been found through manual analysis -- while following the target's Control-Flow Graph under an ideal CFI policy in 81% of the cases.

Connected through hyperedge HE-1 (induced by source paper "methodologies for quantifying re randomization security and timing under jit rop"):
  with members:
    - "is less really more towards better metrics for measuring security improvements realized through software debloating"
    - "on the effectiveness of type based control flow integrity"
    - "automatic heap layout manipulation for exploitation"
    - "control flow integrity precision security and performance"

Connected through hyperedge HE-2 (induced by source paper "using name confusion to enhance security"):
  with members:
    - "pac it up towards pointer integrity using arm pointer authentication"
    - "cfi care hardware supported call and return enforcement for commercial microcontrollers"
    - "control flow integrity precision security and performance"

Connected through hyperedge HE-3 (induced by source paper "exploitation techniques and defenses for data oriented attacks"):
  with members:
    - "oei operation execution integrity for embedded devices"
    - "sok sanitizing for security"
    - "hardscope thwarting dop with hardware assisted run time scope enforcement"
    - "control flow integrity precision security and performance"

Connected through hyperedge HE-4 (induced by source paper "dmon a distributed heterogeneous n variant system"):
  with members:
    - "sok sanitizing for security"
    - "inferring fine grained control flow inside sgx enclaves with branch shadowing"
    - "rowhammer js a remote software induced fault attack in javascript"
    - "drama exploiting dram addressing for cross cpu attacks"

Connected through hyperedge HE-5 (induced by source paper "measuring attack surface reduction in the presence of code re randomization"):
  with members:
    - "automatic heap layout manipulation for exploitation"

Connected through hyperedge HE-6 (induced by source paper "analyzing control flow integrity with llvm cfi"):
  with members:
    - "control flow integrity precision security and performance"

Connected through hyperedge HE-7 (induced by source paper "shining light on shadow stacks"):
  with members:
    - "a leak resilient dual stack scheme for backward edge control flow integrity"
    - "erim secure and efficient in process isolation with memory protection keys"
    - "control flow integrity precision security and performance"

Question: Please tell me which class the center node belongs to. The 40 classes are: cs.NA(Numerical Analysis), cs.MM(Multimedia), cs.LO(Logic in Computer Science), cs.CY(Computers and Society), cs.CR(Cryptography and Security), cs.DC(Distributed, Parallel, and Cluster Computing), cs.HC(Human-Computer Interaction), cs.CE(Computational Engineering, Finance, and Science), cs.NI(Networking and Internet Architecture), cs.CC(Computational Complexity), cs.AI(Artificial Intelligence), cs.MA(Multiagent Systems), cs.GL(General Literature), cs.NE(Neural and Evolutionary Computing), cs.SC(Symbolic Computation), cs.AR(Hardware Architecture), cs.CV(Computer Vision and Pattern Recognition), cs.GR(Graphics), cs.ET(Emerging Technologies), cs.SY(Systems and Control), cs.CG(Computational Geometry), cs.OH(Other Computer Science), cs.PL(Programming Languages), cs.SE(Software Engineering), cs.LG(Machine Learning), cs.SD(Sound), cs.SI(Social and Information Networks), cs.RO(Robotics), cs.IT(Information Theory), cs.PF(Performance), cs.CL(Computation and Language), cs.IR(Information Retrieval), cs.MS(Mathematical Software), cs.FL(Formal Languages and Automata Theory), cs.DS(Data Structures and Algorithms), cs.OS(Operating Systems), cs.GT(Computer Science and Game Theory), cs.DB(Databases), cs.DL(Digital Libraries), cs.DM(Discrete Mathematics). Directly output the class name.

gpt: cs.CR(Cryptography and Security)