nur: Privacy-Preserving Threat Intelligence Through Cryptographic Commitments
Hook
What if you could prove your organization contributed to a threat intelligence aggregate without anyone—including the server—knowing what you submitted? nur treats security intelligence sharing as a zero-knowledge proof problem.
Context
Traditional threat intelligence sharing faces a fundamental paradox: organizations need collective knowledge to defend against sophisticated attackers, but sharing raw security data exposes competitive intelligence, reveals detection capabilities, and creates compliance nightmares. ISACs (Information Sharing and Analysis Centers) solve this through trust frameworks—members agree to share within closed communities. But trust is fragile. A compromised ISAC server could leak who’s vulnerable to what. A malicious participant could correlate submissions with public breaches. Regulated industries face additional constraints: healthcare organizations sharing IOCs might inadvertently reveal patient data patterns; financial institutions could expose transaction monitoring thresholds.
The existing solutions operate on a spectrum of trust versus transparency. MISP and similar platforms assume participants trust the central server and each other. Commercial platforms like Anomali add legal contracts but still require trusting the vendor. At the other extreme, fully decentralized approaches like blockchain-based sharing sacrifice query performance and operational practicality. nur attempts a middle path: cryptographically enforced privacy where individual contributions are mathematically irretrievable, but aggregates remain queryable and verifiable. It’s designed for ‘wartime’ scenarios (active incidents requiring IOC correlation) and ‘peacetime’ analysis (vendor evaluation, coverage gaps, threat modeling) where you need collective intelligence without collective trust.
Technical Insight
nur’s architecture centers on accountable compute nodes that aggregate cryptographic commitments rather than raw data. When an organization contributes threat intelligence, it never leaves their infrastructure in plaintext. Instead, the system generates Pedersen commitments—cryptographic hashes that can be aggregated homomorphically while hiding individual values. Here’s the contribution flow:
# Simplified example of how nur handles IOC contributions
import hashlib
import hmac
from collections import defaultdict
class NurContributor:
def __init__(self, org_salt):
# Each org has a private salt never shared with server
self.org_salt = org_salt
self.commitments = []
def contribute_ioc(self, ioc_value, category):
# Hash the IOC with org salt for blind matching
salted_hash = hmac.new(
self.org_salt.encode(),
f"{category}:{ioc_value}".encode(),
hashlib.sha256
).hexdigest()
# Create commitment (simplified Pedersen commitment)
commitment = {
'hash': salted_hash,
'category': category,
'timestamp': self._get_timestamp(),
'proof': self._generate_merkle_proof(salted_hash)
}
self.commitments.append(commitment)
return commitment
def verify_inclusion(self, server_response):
# Verify your contribution affected the aggregate
# without revealing which specific item was yours
local_root = self._compute_merkle_root(self.commitments)
return local_root in server_response['merkle_forest']The server never sees ioc_value in plaintext—only salted hashes and running counts. When querying for threat prevalence, nur returns aggregates like “23 organizations have observed this campaign” without revealing which 23. The critical innovation is blind category discovery: a new threat category (like a novel APT group or attack pattern) only becomes visible in the shared taxonomy after three or more organizations independently submit matching salted hashes for the same entity. This prevents single-org intelligence leakage—if you’re the only one who’s seen a threat, you’re not accidentally telling competitors you’ve been compromised.
The dual-mode operation reflects different threat intelligence use cases. Wartime mode operates under time pressure: you have IOCs from an active incident and need to know if it’s part of a broader campaign. The query returns campaign correlation scores, detection gap analysis (“4 other orgs detected this via endpoint telemetry, but you only have network signatures”), and cryptographic receipts proving the aggregate wasn’t fabricated:
# Wartime query response structure
wartime_response = {
'campaign_id': 'APT-2024-0847',
'prevalence': 23, # Number of orgs affected
'first_seen': '2024-01-15T08:23:11Z',
'detection_vectors': {
'network_signature': 18,
'endpoint_telemetry': 12,
'email_gateway': 8
},
'merkle_proof': [...], # Verify this wasn't fabricated
'commitment_root': 'a3f5...', # Anchor to verify later
'industry_breakdown': {
'finance': 12,
'healthcare': 7,
'energy': 4
}
}Peacetime mode supports strategic planning without time pressure. Organizations query for vendor coverage analysis (“how many orgs using Vendor X detected threats that Vendor Y missed?”), MITRE ATT&CK technique prevalence (“which techniques are most common in our industry vertical?”), and threat modeling (“what attack patterns target similar organizations?”). The system maintains compliance mappings—HIPAA requirements, NIST CSF controls, PCI-DSS—so queries can filter by regulatory context.
The verification mechanism deserves attention. Every response includes a cryptographic receipt—a Merkle proof linking your local commitments to the aggregate result. You can audit that your contributions influenced the numbers without the server knowing which specific items were yours. This creates accountability without attribution: the server can’t fabricate statistics because participants can verify proofs, but participants can’t identify each other’s contributions because everything operates on salted hashes. The architecture assumes rational actors who want accurate intelligence and Byzantine-tolerant aggregation where up to 33% of participants could be malicious without corrupting the system.
The platform integrates 37 live threat intelligence feeds (according to documentation), automatically normalizing IOC formats and mapping to ATT&CK techniques. Contributors can choose their privacy level: full commitment mode (maximum privacy, only hashes leave your infrastructure), aggregated mode (share category counts but not individual IOCs), or hybrid mode (share some categories openly, commit others cryptographically). This flexibility acknowledges that not all threat data requires the same privacy guarantees—commodity malware hashes might be shareable, but sophisticated APT IOCs need protection.
Gotcha
The fundamental challenge is the cold start problem: cryptographic privacy guarantees are worthless without sufficient network effects. With only one GitHub star and no evidence of production deployments, nur faces a chicken-and-egg dilemma. Collective intelligence requires a collective, and convincing the first hundred organizations to adopt a complex cryptographic platform with zero proven value is brutal. The blind category discovery mechanism requiring three independent submissions before a threat becomes visible means early adopters get almost no value—you’re contributing to a system that can’t tell you anything useful until critical mass.
The cryptographic infrastructure introduces operational complexity that many security teams aren’t equipped to handle. You’re not just integrating an API—you’re managing key material, verifying Merkle proofs, auditing commitment receipts, and trusting that the cryptographic primitives are correctly implemented. The codebase shows 575 passing tests, but cryptographic code requires expert review, and there’s no evidence of professional security audits. A subtle bug in the Pedersen commitment implementation or Merkle tree construction could leak data or allow fabricated aggregates. For organizations with limited security engineering resources, simpler trust-based ISACs with legal frameworks might be more pragmatic than trustless systems with cryptographic complexity.
Performance and scalability questions remain unanswered. Homomorphic aggregation over commitments is computationally expensive compared to counting plaintext rows in a database. How does query latency scale with contributor count? What happens when 1,000 organizations each contribute 100,000 IOCs? The repository doesn’t include benchmarks or scalability analysis. The vision of privacy-preserving collective intelligence is compelling, but without real-world deployment data, it’s unclear whether the architecture works at scale or remains an elegant proof of concept.
Verdict
Use if: you’re in a regulated industry where privacy-preserving threat intelligence sharing is legally or strategically critical, you have security engineering capacity to manage cryptographic verification workflows, you’re willing to be an early adopter contributing to network effects without immediate intelligence returns, or you’re researching privacy-preserving data collaboration architectures and want a reference implementation. Skip if: you need mature threat intelligence with proven community participation (use established ISACs or MISP instead), you want simple integration without cryptographic overhead, you’re a small team without resources for key management and proof verification, or you need production-ready tooling with security audits and scalability evidence. nur is a sophisticated answer to a real problem—privacy-preserving collective intelligence—but it’s currently a research prototype waiting for its first real community. The architecture is sound in theory; the challenge is finding the coalition of organizations willing to bootstrap the network.
