On 1/5/26 4:56 PM, Bryn M. Reeves wrote:
On Tue, Dec 23, 2025 at 01:35:38AM +0800, Leo Samulis wrote:
I'm Leo, the author of dm-steg ( https://dmsteg.sourceforge.net/Steg.pdf ),
a deniable encryption module for device mapper. It was working nicely in
2011 but I got caught up in life and never updated it.
What would need to be done for it to be accepted into mainline device
mapper?
Short answer, it will need updating if there are changes to any of the
kernel or device-mapper APIs it uses (which is likely after that length
of time). I've had a look at the code in the git repo and it seems
fairly reasonable from a quick scan.
Things like DMWARN("u wot m8?") definitely need cleaning up before it
would be acceptable upstream.
The docs should be reformatted as RST in the style of the existing DM
docs under Documentation/admin-guide/device-mapper.
Would I simply need to update the code, get it working reliably, and then
submit a patch? Or would the specification and use of crypto primitives also
need to pass a separate cryptography exam?
That should be enough to at least start an RFC thread. There may well be
questions about the crypto and where it belongs (the module is on the
larger side for a DM target, but still smaller than crypt/thin, and
sxts.c will probably raise some questions), userspace interface, docs,
tooling etc. but if you're willing to put the time in to modernise it
that should be enough to get a discussion going.
Regards,
Bryn.
Hi Bryn,
Don't worry, I am expecting quite a lot of changes after 14 years :-D
Noted about docs reformatting.
Re: sxtc.c : it's a cryptographically valid optimization, but I agree it
would be more acceptable to use AES-XTS.
Thanks for skimming the code - yeah, I'll definitely get it polished
before I submit. At the moment, I'm just feeling out how difficult it's
going to be to get it accepted into mainstream and whether it's an easy
thing to do without getting bogged down in politics.
Thanks,
- Leo
