SFDS: Selective File Disclosure System
Source: arXiv:2607.09370 · Published 2026-07-10 · By Aditya Mitra, Quazi Fariha Tasnim, Hristina Mihajloska Trpcheska
TL;DR
The paper addresses the challenges of access control and verifiable authenticity for read-only files shared over networks, especially when these files are large and in legacy formats lacking built-in digital signature mechanisms. Traditional IAM systems introduce complexity and security risks, while existing verifiable credential standards mainly handle smaller claims rather than large binary files. To overcome this, the authors propose the Selective File Disclosure System (SFDS), which extends the Selective Disclosure JSON Web Token (SD-JWT) standard to support verifiable sharing of arbitrarily large files by embedding cryptographic signatures and integrity protection directly into the shared resource in a privacy-preserving way.
SFDS encrypts individual files using AES-GCM with independent keys, appends the ciphertexts into a large binary blob, and issues a signed JWT containing hashes and metadata for selective disclosure of files. Authorized holders receive SD-JWT presentations allowing them to decrypt and verify only the files they are entitled to access. This eliminates the need for complex IAM infrastructure, user databases, and individual file-level signing, simplifying secure deployment. The implementation presented supports interoperability with W3C Verifiable Credentials, scalability to large binary files, and flexible presentation formats such as PDFs or scanned images. The system was demonstrated on a Python implementation sharing multiple file types across distinct issuer, holder, and verifier machines, confirming authenticity and integrity of selectively disclosed files.
Key findings
- SFDS enables selective disclosure of multiple encrypted files bundled into a single binary large object, referenced by a signed SD-JWT containing hashes, encryption keys, offsets, and lengths for each file.
- Each file is encrypted with a unique random symmetric key using AES-GCM with 256-bit keys, providing both confidentiality and ciphertext integrity.
- Disclosures are hashed with random salts and aggregated in the JWT, enabling verifiable selective disclosure without revealing non-disclosed file metadata.
- The system supports human-readable formats like PDF and scanned images for verifiable file sharing, addressing limitations of current SD-JWTs which handle mostly string or numeric claims.
- Revocation can be enforced by replacing encrypted file segments in the blob with random data, effectively making the file unrecoverable without affecting others.
- A prototype Python implementation successfully shared folders containing multimedia, text, and executable files, allowing holders to selectively disclose and verifiers to reconstruct and validate file integrity and authenticity.
- Random padding and decoy disclosures mitigate inference attacks based on blob size or number of disclosed files.
- The SD-JWT and verifiable presentation structures in the implementation are compliant with RFC 9901 and W3C Verifiable Credential Data Model v2.0.
Threat model
The adversary is an unauthorized entity who can access the blob storage hosting encrypted file bundles but does not have the required cryptographic disclosures (keys and metadata) to decrypt. The adversary may attempt inference attacks by analyzing blob size and structure but cannot distinguish files due to random padding and decoy disclosures. The adversary cannot forge the issuer's JWT signatures or disclosures without access to the issuer's private key, and cannot decrypt or tamper with files without breaking integrity checks.
Methodology — deep read
Threat Model & Assumptions: The adversary can access the blob storage hosting the encrypted files without authorization but cannot decrypt files lacking valid disclosures. The adversary may attempt inference attacks based on metadata or blob size, mitigated by random padding and decoy disclosures. The cryptographic keys are kept secret within disclosures only accessible to authorized holders. The adversary cannot forge issuer signatures or disclosures without the private key.
Data: The system operates over collections of arbitrary files of any format (e.g., text, PDFs, JPEGs, executables) in any directory structure. In the prototype, a sample folder with diverse file types was used. Files are read as binary blobs, hashed with SHA-256, and encrypted individually.
Architecture / Algorithm: The issuer processes all files, generating a random AES-GCM-256 key and nonce per file, encrypting the file and appending the ciphertext segments to a contiguous binary blob. Offsets and lengths within the blob are recorded. For each file, a disclosure containing file name, offset, length, encryption key, and hash is created and salted. The hash of all disclosures form a selective disclosure list included in the JWT payload, which is signed by the issuer's ECDSA private key to produce a JWS. Holders receive the signed JWT, disclosures, and access the blob URI.
Training / Generation Regime: Not applicable as this is a cryptographic protocol and system design. The experimental setup used Python implementations for issuer, presenter, and verifier on three separate machines.
Evaluation Protocol: Verification requires the verifier to check the issuer's JWT signature, verify that each disclosure hash is listed in the JWT payload, fetch only the relevant byte ranges of the blob (using HTTP Range headers if web-hosted), decrypt with the disclosed key and nonce, and confirm the plaintext file hash matches the claimed hash. This provides cryptographic guarantees on confidentiality, integrity, and authenticity. Interoperability with the SD-JWT and W3C VC data model was ensured. No formal performance or adversarial attack benchmarks were reported.
Reproducibility: The authors provide Python-based implementation and test vectors at a cited repository [18]. Detailed cryptographic parameters, keys, sample files, and encoded JWTs are shown in listings, allowing reproduction of the issuer-to-verifier flow and validation of correctness.
Concrete example: Issuer reads three sample files, encrypts each with fresh AES keys using AES-GCM-256, appends the encrypted blobs into a combined blob. For each file, metadata containing offset, length, SHA-256 hash of the plaintext, and encryption key are salted and hashed to form disclosures. The disclosures are sealed into an SD-JWT signed using ES256 (ECDSA over P-256 curve). The holder selectively chooses files to disclose, builds a verifiable presentation containing associated disclosures. The verifier verifies the JWT signature, confirms disclosures against JWT hashes, fetches partial blob segments by offsets, decrypts them using disclosed keys and nonces, checks file hashes, then reconstructs original files with provenance guaranteed by issuer signatures.
Technical innovations
- Extension of SD-JWT selective disclosure model to efficiently handle large binary files via encrypted binary blobs with per-file offsets and lengths.
- Use of random padding and decoy disclosures to mitigate inference attacks on blob storage metadata while maintaining selective disclosure.
- Support for verifiable presentation of arbitrarily large files in legacy or human-readable formats (e.g., scanned exam scripts, medical images), beyond simple string or numeric claims.
- A revocation mechanism that replaces encrypted file segments in the blob with random data without affecting integrity of other files.
- A combined cryptographic architecture embedding authenticity and integrity proofs directly into shared files, avoiding complex IAM infrastructure.
Datasets
- Custom dataset of multiple multimedia, text, and executable files used in prototype implementation (size and detailed provenance not specified).
Baselines vs proposed
- Traditional IAM with separate authentication and digital signature infrastructure: complex, requires user databases and per-file signing vs SFDS: simplified deployment with no centralized user management or per-file signing and direct verifiability.
- Standard SD-JWT for small claims only: supports privacy-preserving claims vs SFDS: extends to large files with selective disclosure and integrity guarantees.
Figures from the paper
Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2607.09370.
Fig 2: JWT generated by implementation
Fig 3: Disclosures
Limitations
- No formal performance evaluation or benchmarks reported; system performance depends on implementation and network conditions.
- Security evaluation focuses on cryptographic integrity and confidentiality but lacks empirical adversarial testing or penetration testing outcomes.
- The threat model assumes secure private key management by issuer; compromise of keys is not addressed.
- The approach assumes availability and reliability of blob storage URIs; denial-of-service or network attacks on blob retrieval are not fully explored.
- No compatibility or integration testing with existing IAM or enterprise access control systems.
- The prototype deals with encrypted blobs and disclosures but does not address long-term key management or secure revocation distribution beyond naive data replacement.
Open questions / follow-ons
- How does SFDS scale with extremely large files or many thousands of files in terms of performance and bandwidth efficiency?
- What are the impacts of network latency and partial availability of blob storage on user experience and file retrieval?
- How could SFDS integrate with enterprise-scale IAM systems or federated identity providers for hybrid deployments?
- Can the revocation mechanism be improved to support dynamic, real-time access revocation without blob replacement?
Why it matters for bot defense
Bot defense and CAPTCHA engineers typically concern themselves with authenticating human users and preventing automated abuse. The SFDS system offers a decentralized mechanism to securely and verifiably share sensitive read-only documents without the complexity and attack surface of traditional IAM systems. From a bot defense perspective, SFDS reduces reliance on server-side identity verification infrastructures that can be targets of automated attacks, instead embedding integrity and access control directly in the distributed resource. CAPTCHA practitioners may find concepts from SFDS useful to design decentralized proof-of-possession or selective disclosure protocols where access tokens prove document authenticity without server authentication calls.
Furthermore, SFDS's approach to selective disclosure of large files while preserving privacy could inspire novel challenge-response or proof-of-access mechanisms in CAPTCHA workflows dealing with file-based credentials or verifiable data disclosures. The architecture emphasizes cryptographic soundness and minimal privileged infrastructure, aligning with security best practices valued in bot-defense design.
Cite
@article{arxiv2607_09370,
title={ SFDS: Selective File Disclosure System },
author={ Aditya Mitra and Quazi Fariha Tasnim and Hristina Mihajloska Trpcheska },
journal={arXiv preprint arXiv:2607.09370},
year={ 2026 },
url={https://arxiv.org/abs/2607.09370}
}