[Cryptography] where shall we put the random-seed?

Tom Mitchell mitch at niftyegg.com
Wed Dec 28 21:06:11 EST 2016


On Wed, Dec 28, 2016 at 1:31 PM, Ron Garret <ron at flownet.com> wrote:
>
> On Dec 27, 2016, at 4:18 PM, Theodore Ts'o <tytso at mit.edu> wrote:
> > On Tue, Dec 27, 2016 at 03:32:16PM -0700, John Denker wrote:
> >>
> >> The kernel image is already a fancy thing with internal structural
>
.....

> >> To refresh the seed, read the System.map to see where it sits.
>
.....

> >
> > It's a lot more complicated than that.
>
....

>
> What about putting it in the bootloader configuration and passing it to
> the kernel as a boot-time argument?
>

Yes that can help as can a read with a timeout (pause but not block).
'read -t 1 line < /dev/pty' or something asking for jiberish input and
timing
events.

All installation media has a common problem, the same problem PRNGs have.
They all do the same thing when unattended.

Lacking keyboard or mouse input the install might continue and then after a
reboot DHCP
might then continue and results can be used to some  advantage.   DHCP is
often local and not
visible to the NSA.   A DHCP server can return site  specific data that can
help this issue at a site
(factory, company, IT department).    The longer the device can postpone
the use of random
bits and postpone connecting to the  network the better.

Generating long lasting keys too early and connecting to the world too early
seems to be the nut of a problem here.

Also, we should not ignore the system attributes for files on modern file
systems.
They imply a lot...    From the XATTR man page on macOS.
    Extended attributes are arbitrary metadata stored with a file, but
separate from the
    filesystem attributes (such as modification time or file size).  The
metadata is often a
    null-terminated UTF-8 string, but can also be arbitrary binary data.
A reason to not ignore this is a trusted set of processes can control this
random data
problem and exclude root (UID=0) processes.  The simple owner/group/other
model is too
simple when loading the OS.   Lacing MAC etc.. The UID of the installer
process is the only bit
that needs to be attacked.   Once the OS is installed the MAC (SELinux) and
stricter environments
including capability based systems can be adjusted so the system is
configured to the purpose
intended.

arc4random() should be mentioned. There is a perl package.  Apple notes
this in the random man page:
   "Applications requiring cryptographic quality randomness should use
arc4random(3)"
...
from the arc4random man page"
DESCRIPTION
     These functions use a cryptographic pseudo-random number generator to
generate high quality random
     bytes very quickly.  One data pool is used for all consumers in a
process, so that consumption under program
     flow can act as additional stirring.  The subsystem is re-seeded from
the kernel random number subsystem on
     a regular basis, and also upon fork(2).

     This family of functions provides higher quality random data than
those described in rand(3), random(3), andrand48(3).           They can be
called in almost environments, including chroot(2) and their use is
encouraged over all other standard
     library functions for random numbers.


-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161228/320f4862/attachment.html>


More information about the cryptography mailing list