All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bryn M. Reeves" <bmr@redhat.com>
To: Leo Samulis <anagon@gmail.com>
Cc: dm-devel@lists.linux.dev, "Alasdair Kergon" <agk@redhat.com>,
	"Mike Snitzer" <snitzer@kernel.org>,
	"Mikulas Patocka" <mpatocka@redhat.com>,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Subject: Re: [RFQ] dm-steg : a deniable encryption module
Date: Mon, 5 Jan 2026 14:56:44 +0000	[thread overview]
Message-ID: <aVvRLOlL4YF9sN0R@redhat.com> (raw)
In-Reply-To: <022d700d-d3d8-4ef9-8d7b-505f7df89354@gmail.com>

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.


  reply	other threads:[~2026-01-05 14:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-22 17:35 [RFQ] dm-steg : a deniable encryption module Leo Samulis
2026-01-05 14:56 ` Bryn M. Reeves [this message]
2026-01-11 18:22   ` Leo Samulis
2026-01-07 21:26 ` Mikulas Patocka
2026-01-11 17:59   ` Leo Samulis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aVvRLOlL4YF9sN0R@redhat.com \
    --to=bmr@redhat.com \
    --cc=agk@redhat.com \
    --cc=anagon@gmail.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=marmarek@invisiblethingslab.com \
    --cc=mpatocka@redhat.com \
    --cc=snitzer@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.