Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Jun 2012 17:03:53 +1000
From:      "Dewayne Geraghty" <dewayne.geraghty@heuristicsystems.com.au>
To:        "'Robert Simmons'" <rsimmons0@gmail.com>
Cc:        freebsd-security@freebsd.org
Subject:   RE: Hardware potential to duplicate existing host keys... RSA DSA ECDSA was Add rc.conf variables...
Message-ID:  <8F192950D203416CA6E24E2BC89B24A5@white>
In-Reply-To: <CA%2BQLa9B8P7-xKT882cMLrtrw%2B%2BgsUxxVy=FTSSss1d_Cpod%2BLg@mail.gmail.com>
References:  <CA%2BQLa9A4gdgPEn3YBpExTG05e4mqbgxr2kJ16BQ27OSozVmmwQ@mail.gmail.com><op.wge77quh34t2sn@skeletor.feld.me> <CA%2BQLa9B8P7-xKT882cMLrtrw%2B%2BgsUxxVy=FTSSss1d_Cpod%2BLg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> And as a flip side to the argument, is there a reason not to 
> raise the default to 4096?  Certainly the same advances in 
> processors makes this size key quite usable.  I've seen no 
> noticeable slowness with 4096 bit RSA or 521 bit ECDSA.

Robert, A good question and it's good to check underlying assumptions from
time to time.

Identifying a host using keys of greater than 2048 bits (RSA) adds little
to the objective of ensuring that the host that you are intending to talk
to, is who it purports to be. 

Taking a loose analogue, most secure websites use a certificate of 2048
bits, but these have the dual purpose of identifying the server, and
negotiating a symmetric cipher.  This isn't the case for an ssh host key,
which only identifies the host before commencing the next asymmetric
(account key) handshake.  

According to http://www.secg.org/download/aid-780/sec1-v2.pdf ECC 256 is
roughly equivalent to RSA 3072 bits; the current bit sizes (RSA 2048) are
supposed to be good until at least 2030. Though I don't know if this takes
into account the US Air Forces recent SGI machine with 73,728 Xeon
processors and 1.47 petabytes of memory. :)

Its arguable that the ecdsa key size should be 224 bits, base on the
previous pdf reference, but I digress :)

When the server that you're connecting to is previously unknown to you, the
next best piece of information is a DNS sshfp resource record (ssh public
key fingerprint) as a source of verification.  And this is only 16 bytes.

Regards, Dewayne 







Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8F192950D203416CA6E24E2BC89B24A5>