Bug#662736: Some concerns about adding maxwell to Debian
I am the author of Maxwell. Replies to some comments
below.
Pedro I. Sanchez <psanchez@fosstel.com> wrote:
> On 12-07-20 10:11 AM, Henrique de Moraes Holschuh wrote:
>>
>> I am somewhat worried about this package being added to Debian.
>>
>> The kernel itself is responsible for collecting randomness from interrupts
>> when it is deemed safe enough, this is NOT a task well suited to
>> userspace.
>> Userspace should gather entropy from external sources (like audio noise,
>> USB
>> HRNGs, or an entropy data feed over the network).
Valid concerns. Certainly where a hardware RNG or audio device
is available, that should be used in preference to Maxwell. In
particular, I would say supporting Turbid (discussed in the
Maxwell paper and, last I looked, also on the Debian list of
requested programs) is more important than Maxwell.
> Labeling the algorithm as "good" or "bad" is going to be context sensitive.
> Small embedded systems with no network activity, such us monitors or
> autonomous process controllers, might benefit from a timer-based entropy
> generator for example.
The target I was thinking of in designing the program was Freedom Box.
> In any case, I don't believe that it is up to the
> Debian distribution to determine in advance whether a package is good or bad
> for a system; as with any other package, this decision ultimately belongs to
> the system designer or administrator who knows what he wants to achieve. We
> have to provide the package in the first place, ensure that it is run with
> safe default values, and that it is properly documented so that some one
> else can make a final educated decision on the program's fit for a
> particular application.
>> I recommend it to be restricted to archs where it was tested, which is
>> x86-64 right now ...
Yes
>> It would also be advisable to ship it configured by default in
>> Debian to credit at most 50%-70% of entropy, so as to account
>> for unexpected behaviour ...
Arguably, that is built in. I cite research showing about one
bit of entropy per sample and run tests that show somewhat
more. The program's default is 48 samples per 32-bit output.
The user interface lets the admin increase the number of
samples per output, but not lower it.
The 48 above is 16 times a #define compile-time constant.
If a particular environment needs more, changing that
constant is easy.
>> I'd also recommend that it be tested first in a VM environment, ...
Good idea.
>> Initial entropy at very early boot, before Debian seeds the kernel, is a
>> task that can only be done properly by the kernel itself, and is being
>> addressed there at this time (patches have already been proposed). The
>> proper fix for better initial entropy at boot is to backport these changes
>> to the Debian kernel. I do not consider maxwell relevant for this
>> scenario.
Where can I get info on those patches? I am on the linux-crypto list
and have not noticed them there.
>> For other entropy gathering needs, there are safer choices. This should
>> be reflected on the package description.
>
> Agree, as I mentioned before, work on documentation is needed to ensure that
> we provide enough information for the system designer/administrator to make
> informed decision about how to use or not to use maxwell.
I thought I'd dealt with that in the man page & PDF.
>> Another concern is that maxwell looks like an academic work from upstream,
>> it would be best to talk to upstream ...
>
> I do share this concern as well. I invite the upstream maintainer to let us
> know about his plans and what we can expect as support from him in the short
> and long terms.
I've been using various Unix or Unix-like systems for several decades and
working on crypto & security for quite a while too. I hope to be around
and active in those areas indefinitely. Subject to assorted constraints,
I'm willing to assist in any way you need.
That said, I think of Maxwell as a finished project, and have no plans
for a version 2.0 or other changes.
Reply to: