freebsd security - Sep 2003 - [Fwd: Re: FreeBSD Security Advisory FreeBSD-SA-03:12.openssh]

Roger Marquis wrote:
> [snip]
>
>It takes all of 2 seconds to generate a ssh 2 new session on a
>500Mhz cpu (causing less than 20% utilization).  Considering that
>99% of even the most heavily loaded servers have more than enough
>cpu for this task I don't really see it as an issue.
>
>Also, by generating a different key for each session you get better
>entropy, which makes for better encryption, especially when you
>consider that the keys for one session are useless when attempting
>to decrypt other sessions.  For this reason alone it's better to
>run sshd out of inetd.
>
>  
>
>>I think running sshd out of inetd is a very bad idea indeed, unless
>>Mr Marquis is willing to stay in my datacenter and hammer the keys like
>>a monkey all day, but even then that might be a poor source of entropy.
>>    
>>
>
>I've been using inetd+ssh since 1995, in dozens of data centers,
>across hundreds of hosts, and millions of sessions without a single
>problem.  I wonder what Bruce Schneier would think of Mr. Simpson's
>understanding of cryptography?
>
If I'm not mistaken, /dev/random is a pseudo-random generator, which 
means it has a certain period before it begins to repeat numbers (along 
with that it just isn't truly random). So, please correct me if I'm 
wrong, but doesn't this mean that when reading from /dev/random, you're 
'losing' randomness/entropy/whatever you're calling it?

On a related note, the manpage entry for sshd states:
    -i      Specifies that sshd is being run from inetd.  sshd is normally
            not run from inetd because it needs to generate the server key
            before it can respond to the client, and this may take tens of
            seconds.  Clients would have to wait too long if the key was re-
            generated every time.  However, with small key sizes (e.g., 512)
            using sshd from inetd may be feasible.

This is apparently the 'official' reason for not using it within inetd. 
What are current times on servers running at 1GHz or whatever's standard 
for 1Us these days. What are feasible key sizes at the moment? I do not 
run sshd from inetd and have thus never had said speed issues.

But really, please lose the sarcasm.

--Devon

Devon H. O'Dell just mooed:
>
> If I'm not mistaken, /dev/random is a pseudo-random generator, which 
> means it has a certain period before it begins to repeat numbers (along 
> with that it just isn't truly random). So, please correct me if I'm
> wrong, but doesn't this mean that when reading from /dev/random,
you're
> 'losing' randomness/entropy/whatever you're calling it?
   You're mistaken.  /dev/random stops feeding you random bits
when it doesn't have enough.  /dev/urandom depletes the entropy
pool, but when it starts to run out, it falls back to hashing
to generate pseudo-random sequences from the random bits that
it can obtain.

  -Dave

-- 
work: dga@lcs.mit.edu                          me:  dga@pobox.com
      MIT Laboratory for Computer Science           http://www.angio.net/
      I do not accept unsolicited commercial email.  Do not spam me.

"Devon H. O'Dell" writes:
> If I'm not mistaken, /dev/random is a pseudo-random generator, which 
> means it has a certain period before it begins to repeat numbers (along 
> with that it just isn't truly random). So, please correct me if I'm
> wrong, but doesn't this mean that when reading from /dev/random,
you're
> 'losing' randomness/entropy/whatever you're calling it?
You are very mistaken indeed :-).

In FreeBSD-4-*, /dev/random is an "entropy distiller", albeit not a
very
good one as it is not very conservative. On that system, /dev/urandom is
a very complex PRNG, with the added feature of being perturbed by actual
entropy.

In FreeBSD-5-* there is no separate /dev/urandom, and /dev/random is 
driven by Yarrow (http://www.counterpane.com/yarrow/). This is a
PRNG+entropy-harvester, and it it _very_ conservative. As long as
_some_ entropy is being harvested, it is unlikely that either generator
wil produce a repeating sequence _ever_.

M
--
Mark Murray
iumop ap!sdn w,I idlaH