On Mon, May 25, 2020 at 08:02:54AM +0200, Petr wrote in
<20200525060254.ga3...@album.bayer.uni.cx>:
Software distributors are not happy seeing various software carrying its own
cryptographic code. Could you please keep using the system-provided functions
if available?
Hi Petr,
Thank you for your comment. While I concur with the sentiment of your
comment that in general you do not want your package to include its
own implementation of code for which good libraries are available
(such as zlib, handling png files, etc.) for reasons of
maintainability and security, I am not sure this applies here. The
proposed PRNG algorithm is very small and actually replaces a mismash
of different PRNG functions that often (dependant on the PRNG function
used and platform it is implemented on) has considerable weaknesses of
their own.
Furthermore, this code is only to be used in cases where we want a
"random enough" looking number, it doesn't have to withstand years of
crypto analysis by a skilled attacker. The code which would be
affected by this approach is currently being used for:
#1) Generation of tmp filenames. The current implementation uses two
31 bit values, with this patch this is replaced by two 32 bit values.
#2a) Generation of a boundary for MIME-attachments. The code would use
the new random function instead of the existing one. This boundary
just has to be "unique enough" so that one doesn't type it by accident
when composing an email.
#2b) One of my other patches proposes to use 96 bits of randomness
directly (=3 calls to the random function) for generating this
boundary instead of generating 16 random numbers (=16 calls to the
random function) and taking the modulo to come up with a Base64
character.
#3) Finally, I also propose to use a random number as part of the
Message ID which is currently not done. This is either a 64 bit or a
96 bit random value. An attacker would not only have to know what
random value will be generated, but also when it will be generated to
generate a colliding Message-ID. This will be much harder to do with
the inclusion of the random part than in its current implementation
where no part of the Message ID is random.
In conclusion, I feel that applying my patches will result in stronger
random numbers being used by mutt for these applications only. It is
my understanding that the chosen implementation does not leak any
information that could be used by an attacker to find out the state of
the PRNG, something which might be possible with the current
implementation(s).
One area of concern is that I haven't been able to find a lot of
credible critiques of the chosen algorithm. While I take comfort from
the fact that the algorithm is not new by any means and is developed
by an expert in the field, and I feel quite confident in the fact that
the produced numbers satisfy the need of appearing random, I would
like to have a little more comfort on the difficulty of brute forcing
it and being able to find the seeds used or the current internal state
of the algorithm.
Kind regards,
Remco
