Re: ssh host key generation in Red Hat Linux

From: Kent Borg (kentborgat_private)
Date: Fri Jul 25 2003 - 13:49:12 PDT

  • Next message: H D Moore: "Re: scan.sygate.com. over-scanning?"

    It has been pointed out that the Linux random driver will block if it
    computes there is no entropy available, and this is correct.
    
    However, last August there were bugs discovered in entropy accounting
    that caused it to overestimate current entropy, and the Red Hat
    2.4.20-19.9 kernel still doesn't seem to have the fix.  If one has a
    lot of faith in md5, this isn't a problem on an up-and-running machine
    with ~some~ source of entropy, but at very early points in the entropy
    pool's life, the amount does matter when something very important is
    being generating early on, such as ssh keys.  (Ironically, would
    adopting the random fix, lock up a Red Hat first boot?)
    
    Also, not everyone is comfortable with disk or network timings as
    entropy sources.  Again, on a running machine, having too many entropy
    sources, some of which might not actually have much entropy in them,
    isn't a problem, but a fresh entropy pool is different.
    
    Solution?  One approach is to delay creation of ssh keys.  (Or, as I
    did, manually create new keys after one is certain there is enough
    entropy available.)  Even if disk jitter is the only available entropy
    source, waiting for more of it to accumulate would help.
    
    And don't forget embedded Linux cases, such as routers, wireless
    access points, etc., where there might not be a mechanical disk.  It
    is not hard to imagine really getting hard up for entropy in a
    factory-fresh box.  One idea I had recently is to hash the power up
    state of a reasonable portion of RAM.  By no means are the initial
    contents of RAM completely random, but RAM *is* volatile, I am pretty
    sure it has some entropy in it.  Even if there is little entropy from
    one power up to another power up of a given DRAM chip, there must be
    some entropy between different physical chips.  A warm boot might have
    extremely little to no entropy in RAM contents, but by that point some
    entropy could have been stored from previously.  It is the really,
    really cold boot that is the problem.
    
    
    -kb, the Kent who wiggles the mouse on his basement server whenever he
    walks by, a bit like a stroking rabbit's foot.
    
    
    P.S.  A few months ago I wrote a RAM entropy grabber for embedded PPC,
    but it is too groady in how it passes it to the kernel.
    



    This archive was generated by hypermail 2b30 : Fri Jul 25 2003 - 14:59:26 PDT