Skip to content

.wiff2 is encrypted; key/scheme unresolved #24

Description

@Nathan-D-R

`.wiff2` (the newer, self-contained SCIEX format) uses proprietary encryption. Clean-room analysis has confirmed a real SQLCipher-style plaintext/ciphertext boundary and ruled out every well-known open-source SQLite encryption scheme as a direct match, but the cipher mode, KDF parameters, and key remain unresolved and are not recoverable from ciphertext alone.

Full writeup, including everything confirmed, every theory tried, and the open questions: `docs/format/03-wiff2-container.md`.

`.wiff`/`.wiff.scan` (the legacy format) is unaffected and fully supported; this only blocks `.wiff2`.

Status: unsolved, not under active work. This project only uses clean-room methods - analysis of our own lawfully-obtained files, no vendor software, no NDA'd or leaked material - and that constraint holds regardless of what would technically unblock this faster.

If you have something that helps within that constraint (a vendor statement, a permissively-licensed public SDK artifact, a citation to a published non-confidential source), a comment or PR is welcome. Please don't post extracted keys, decrypted output, or anything sourced from vendor software or its disassembly - that won't be accepted regardless of where it came from.

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is neededquestionFurther information is requested

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions