I am the author of Maxwell. Replies to some comments below. Pedro I. Sanchez <psanc...@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. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACXcFm=AXXfH670N=KSKv3zr+09WY1TzEBR_At2mVxuehn=2...@mail.gmail.com
