linux-ext4 - Re: algorithm for half-md4 used in htree directories

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YWnk5K5+h/Ddd4Rr@mit.edu>
Date:   Fri, 15 Oct 2021 16:30:28 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Avi Deitcher <avi@...tcher.net>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: algorithm for half-md4 used in htree directories

On Fri, Oct 15, 2021 at 12:43:33PM -0700, Avi Deitcher wrote:
> Thanks, Ted, I will try yours and step through it to figure out what is off.
> 
> You ask a fair question: other than madness, why would someone want to
> recreate the exact algorithm?
> 
> I have had a number of cases where I have needed to manipulate disks,
> filesystems, partition tables, etc. from within a non-C-source
> program. The options have been: fork/exec to some external program;
> run a VM where I can mount the fs and manipulate content as needed.
> Those both work, but have had issues in various environments.
> 
> I made the mistake of saying, "well, all of this is just manipulating
> bytes on a disk image or block device; how hard could it be?" :-)
> So understanding the algorithm actually becomes important.

I think once you take a look at all of the "byte manipulation" that is
needed for any kind of non-trivial file system operation, you're
probably better off trying to figure out how to link the library in.

> I probably could link the library in if I am working on languages that
> support it (go, rust), but not all do, and there are reasons that is
> more difficult for the target use case.

Have you looked at SWIG?  SWIG suppotrs a *lot* of lanaguages,
including Tcl, Python, Perl, Guile, Java, Ruby, Mzscheme, PHP, OCaml,
C#, Lua, R, Octave, Go, D, Javascript, Scilab, etc.  If you end up
writing the equivalent of libext2fs for one language, it's really not
going to help you all that much for another language.

I also note you've not really been specific about "the target use
case".  Is that something you'd be willing to say more about?

In any case, if you're interested in implementing SWIG bindings for
libext2fs, that is certainly something we could discuss integrating
into e2fsprogs, so that other people could also benefit from that
work.  Let me know if you're interested!

						- Ted