On Tue, 23 Dec 2025, Leo Samulis wrote:
> Hello,
>
> 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?
>
> 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?
>
> Thanks in advance,
>
> - Leo
Hi
If it doesn't interfere with other kernel code (i.e. if it's just one or a
few files with no changes elsewhere), it should be quite easy to get it
in. There is no formal verification of cryptography required.
Milan Broz is developing the userspace cryptsetup package, so you can
discuss with him how to integrate it with the existing tools.
I think that (if possible) it would be better to integrate it with
cryptsetup.
Just one big warning - it doesn't work on SSDs!
If the attacker unsolders the flash chips from the SSD and reads them
directly, he can read the mapping table for the blocks. From the mapping
table, he can infer which blocks were written recently.
I.e. if you recently wrote to the hidden area that is supposed to contain
random data, the attacker would know that you wrote there and know how
much data did you write there - he just wouldn't be able to decrypt actual
data.
So, I suggest to either disable it completely on SSDs or print a big
warning that it is not as secure as it is supposed to be.
Mikulas
