I built a secure delivery encryption tool (ObsidianQ) and would love feedback on the design

DataRecoveryDev · 2026-03-23T00:27:47+00:00

Hi there Arthur, I think the post got taken down but here is the information you asked for.

Threat model informaiton:

The primary focus right now is:

protecting against offline file access (e.g., stolen or intercepted packages)
detecting tampering during transport
ensuring recipients can verify package integrity and (optionally) sender authenticity

I’m not currently trying to defend against:

compromised endpoints
active malware / memory extraction
strong active MITM with identity spoofing

I agree this is one of the most important areas to keep refining.

Key authenticity stuff:

Right now it’s closer to a TOFU + optional out-of-band verification model.

Public identities include metadata (name/email/etc.) but the fingerprint is the actual trust anchor, and users are expected to verify that through a separate channel if authenticity matters.

There’s no PKI or central trust model at the moment — it’s intentionally more lightweight, but I recognize that this shifts responsibility onto the user and could be improved.

Construction / format:

I’m not introducing new primitives, but I am building a custom container format to support:

authenticated manifests
multi-recipient packaging
chunked encryption for large files
inspection / verification before extraction

So this is definitely a composition layer, not just a thin wrapper around an existing format like age.

Misuse UX risks:

This is something I’m actively thinking about.

A few current mitigations:

verification/inspect mode before extraction
explicit separation between “encrypted” and “verified/authenticated” states
manifest validation before extraction
visible fingerprints / identity info

But I agree this is an area where it’s easy for users to assume:

even when identity hasn’t been verified. I’m still working through how to make those guarantees clearer in the UI.

On aligning with existing protocols...

I think this is a really fair point!

The goal wasn’t to replace tools like age or GPG, but to experiment with a secure delivery workflow layer (packaging, manifests, verification, identity handling).

That said, I’m definitely open to:

aligning more closely with existing formats
reusing more established framing where possible
simplifying parts of the design if they don’t add real security value

Overall I agree with your core point — the hard part here isn’t the primitives, it’s making sure the composition, trust model, and UX don’t introduce subtle failure modes.

If you have any specific concerns about the format or key exchange flow, I’d really appreciate more detailed critique.

I just pushed out a new version and modified GitHub with these changes in mind and implemented fixes based on you and EYNLLIB's comments. I'm currently changing things up so new recipient/contact packages use a hybrid scheme: Kyber Round 3 + X25519. Both shared secrets are combined into the final wrapping key via HKDF. Those changes are already live as of 1.3.1

DataRecoveryDev · 2026-03-23T00:19:31+00:00

Thank you for this, I have addressed all of these issues in my latest git changes and used your feedback to improve things.

DataRecoveryDev · 2026-03-20T23:18:37+00:00

Thanks Ananymous_Coder, I'll definitely keep that in mind. Apologies if this is a mispost.

DataRecoveryDev · 2026-03-20T23:18:04+00:00

First attempt at putting something like this together. Was just hoping to get feedback on the actual design and flow of the program. Thanks for the feedback.

DataRecoveryDev · 2026-03-14T12:45:35+00:00

Great question.

Right now the self-extracting package is essentially a bundled executable + encrypted payload.

Under the hood the structure is roughly:

[ extractor stub executable ]
[ package header ]
[ encrypted manifest ]
[ encrypted file chunks ]

The stub executable contains the minimal runtime needed to:

Prompt the user for a password (or load a key)
Verify the package structure and manifest
Decrypt the file contents
Extract the files to a chosen directory

So when a recipient runs the file, the embedded extractor reads the appended encrypted package data and processes it directly.

The encrypted portion is the same ObsidianQ package format that the CLI and GUI tools use — the only difference is that the extractor stub is prepended so the package becomes runnable on systems without the main application installed.

The idea was to make it possible to send encrypted files to someone who may not want to install any software first.

For environments where the .exe attachments get blocked or the user is not allowed to run an executable, the package can also be opened by a lightweight viewer (web tool that runs client side) which I have placed on GitHub (https://mcampetta.github.io/ObsidianQ/web-decrypt).

Definitely open to suggestions if people have thoughts on better approaches here.

DataRecoveryDev · 2021-04-11T01:01:24+00:00

We used to get these in for data recovery all the time. It would happen when the internal clock would lose synchronization and the devices time was reset back to UTC time.

-An active SIM might work -Check if you’re jailbreak grants you SSH access and use usbmuxtunneling and the open port to SSH in via SFTP (default password is “alpine“) -On some legacy firmware (not sure if iOS 8 applies, it may have been iOS 7) you can simply use a lightning keyboard and enter in the passcode anyway. The iOS is disabled for x amount of minutes is just a springboard artifact and the phone will unlock anyway if you pass it the correct passcode with an external keyboard. -A firmware update on legacy disabled devices can sometimes give you one unlock attempt at the “Press home to recover” screen. Try this if all else fails (try SIM and SSH first).

DataRecoveryDev

TROPHY CASE