[RFQ] dm-steg : a deniable encryption module

[RFQ] dm-steg : a deniable encryption module

[Leo Samulis]

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

Re: [RFQ] dm-steg : a deniable encryption module

[Bryn M. Reeves]

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.

Re: [RFQ] dm-steg : a deniable encryption module

[Leo Samulis]

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

Re: [RFQ] dm-steg : a deniable encryption module

[Mikulas Patocka]

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

Re: [RFQ] dm-steg : a deniable encryption module

[Leo Samulis]

On 1/7/26 11:26 PM, Mikulas Patocka wrote:
>
> 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
>
Hi Mikulas,

Thanks very much for your reply!

Lack of formal verification for cryptography is both a blessing and a 
curse. I'll KISS.

Re: Milan Broz, I'm not sure how much traffic you guys like to see on 
dm-devel, so I'll drop him a private email. I agree that cryptsetup 
integration is the ideal, and I see no reason why it's not possible.

Re: SSDs - I already thought of this. See Section 4.7 Transparent 
Aspects @ https://dmsteg.sourceforge.net/Steg.pdf

Thanks,

- Leo