It's time for those 2048-, 3072-, and 4096-bit keys?
Colin Percival
(http://cr.yp.to/papers.html#nfscircuit) on integer factorization circuits,
along with subsequent analysis which suggests that such attacks might be
practical, is it time to change the default key sizes in OpenSSH?
While the practicality of the cracking machine proposed is still a
matter of debate, it seems that the risk is sufficient, and the cost of
increasing key sizes is sufficiently small, that there is little
justfication for not switching to a larger default key size. While a
couple years ago it might have been argued that the initial cost of
generating longer keys would be excessive, I can now generate a 4096-bit in
about 30 seconds on a rather low-end box, so I don't think key generation
time is particularly relevant any more.
Is there any other reason for not changing the default key size?
Colin Percival
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Mike Silbersack
On Tue, 26 Mar 2002, Colin Percival wrote:
> Is there any other reason for not changing the default key size?
>
> Colin Percival
Versions of ssh which use RSAREF (those compiled before the patent ended,
basically) can't handle keys over 1024 bits in length, IIRC. Hence, you'd
have to be very careful when bumping up the size of sshv1 keys on a system
which may have old clients connection.
However, I think it _would_ be safe to bump up the sshv1 session key from
768 to the largest possible key < 1024 bits in the default options. (I
would say 1024 bits, but I believe that there's also some stipulation that
host key length != session key length.)
Mike "Silby" Silbersack
Jason Stone
Hash: SHA1
> However, I think it _would_ be safe to bump up the sshv1 session key
> from 768 to the largest possible key < 1024 bits in the default
> options. (I would say 1024 bits, but I believe that there's also some
> stipulation that host key length != session key length.)
This is correct - a 1024-bit hostkey causes sessions keys to be 1152-bits
which will break rsaref-based clients. An 896-bit hostkey yields the
desired 1024-bit session keys.
Of course rsaref is old, buggy, copyright-encumbered, and ought not be
used anymore under any circumstances.
-Jason
-----------------------------------------------------------------------
I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry
that 10 or 15 years from now, she will come to me and say "Daddy, where
were you when they took freedom of the press away from the Internet?"
-- Mike Godwin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg
iD8DBQE8oFIjswXMWWtptckRAmnWAKDyY2LJeg04Ufj6sOSTuOibPzK2qQCfTu00
dMf+5M+dGdwOqp8SbhtyZS4=
=b/im
-----END PGP SIGNATURE-----
Dan Lowe
>
> Yes, upgrading clients to v2 would be best. However, I don't think that
> locking out v1 users would be the best way to achieve that. The most
> likely result of doing so would be people falling back to telnet.
On a system where security is of any concern whatsoever, why would telnet
be available in the first place?
--
Beware! To touch these wires is instant death. Anyone found doing so
will be prosecuted. -Sign at a railroad station
Garrett Wollman
> Some systems (like the SparcStation 5 that serves DNS, DHCP and NTP
> requests from my home network) are too slow for the algorithms used by
> ssh2.
It's perfectly acceptable on our IPX. The session takes a few seconds
to start, and the keys took a long time to generate, but once
authenticated there does not seem to be much difference to me. (In
fact, `cat /etc/termcap' takes consistently twice as long using v1 as
v2.)
-GAWollman
Dag-Erling Smorgrav
> What's not clear about it?
Well, for one, the fact that you can't copy from one remote host to
another.
DES
--
Dag-Erling Smorgrav - d...@ofug.org
Karsten W. Rohrbach
> <<On 31 Mar 2002 01:49:54 +0100, Dag-Erling Smorgrav <d...@ofug.org> said:
>
> > Some systems (like the SparcStation 5 that serves DNS, DHCP and NTP
> > requests from my home network) are too slow for the algorithms used by
> > ssh2.
>
> It's perfectly acceptable on our IPX. The session takes a few seconds
> to start, and the keys took a long time to generate, but once
> authenticated there does not seem to be much difference to me. (In
> fact, `cat /etc/termcap' takes consistently twice as long using v1 as
> v2.)
interresting. i observe a similar behaviour on my router (intel pentium
60, 4.4-stable 12/6/2001, ssh 2.0 20011202, protocol v2).
generation of the server key takes ages (~3+ minutes)...
regards,
/k
--
> The idea that Bill Gates has appeared like a knight in shining armour
> to lead all customers out of a mire of technological chaos neatly ignores
> the fact that it was he who, by peddling second-rate technology, led them
> into it in the first place. --Douglas Adams in Guardian, August 25, 1995
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 10x
Zvezdan Petkovic
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> > > another.
> >
> > scp man page says in the second paragraph of DESCRIPTION:
> >
> > Any file name may contain a host and user specification to indicate that
> > the file is to be copied to/from that host. Copies between two remote
> > hosts are permitted.
> >
> > scp my.office.machine:file.pdf my.home.machine:
>
> Yes, but it's not what you think - when you did this, what actually
> happened was that the client on the machine you started from did:
> ssh my.office.machine "scp file.pdf my.home.machine:"
> That is to say, you really just copied the file from office to home
> without it ever touching the machine in the middle. So if the two end
> machines can't see each other, this won't work. And if you can't arrange
> to get the password/key/passphrase for the home machine from the middle
> machine to the office machine, this won't work.
>
>
> -Jason
>
Correct. Remember though that the original post was that scp man page is
not clear enough. I just tried to show that it is quite clear and
correct. Setting the keys correctly is another matter, but my opinion is
that it is quite clear too for people who read documentation carefully.
Also, the first person in the quote above doesn't claim that copy has
to be over the middle machine. But again, you pointed correctly that if
these two machines do not allow direct connection to each other then the
copying wouldn't work. I don't think scp man page wanted to imply that
it would.
--
Zvezdan Petkovic <zve...@cs.wm.edu>
http://www.cs.wm.edu/~zvezdan/