Subject: issues

From: Niels Provos <[email-masked]>
Date: Mon, 19 Mar 2001 11:24:08 -0500

Hi,

there are a couple of small issues that should be noted:

1. traffic analysis can determine the length of passwords that have
   been typed in for authentication or at the command line.

   a security advisory has been posted at
     
      http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt

   and should appear on the free version of the bugtraq mailing list soon.

2. the choice of private exponents for the diffie-hellman should depend
   on the size of key material for the negotiated ciphers, i.e.
   256-bit AES requires longer exponents than 128-bit AES.

   this applies to both the transport and the diffie-hellman group
   exchange draft.

These problems do not require any change in the protocol, and we will
provide short implementation notes to address the problems, i.e.
a description on how to alleviate them.

-- 
Niels Provos <[email-masked]> finger [email-masked] for pgp info
	"Gravity is the soul of weight." - Anonymous.

---

From: Mika Kojo <[email-masked]>
Date: Mon, 19 Mar 2001 21:17:22 +0200

>    this applies to both the transport and the diffie-hellman group

If you let the 256-bit AES to mandate the used Diffie-Hellman group
then you will end up with a group with p > 2^13547 (say). This is
something that seems quite unreasonable from the performance
viewpoint. Changing the exponent size is not enough.

(The usual 1024-bit Diffie-Hellman group gives security level similar
to a 80-bit block cipher. Here exponent must be more than
160-bits---increasing it would not give any more security, but
decreasing it would indeed decrease security.)
 
Perhaps a better solution is to give the user some indication of the
security level achieved in a particular session. Of course, it is
difficult to measure security exactly, but this is only required to be
a rough approximation (say, `very secure` > 2^128, `secure' > 2^80,
`broken' <= 2^80, when measured in elementary operations).

Best regards, 
Mika Kojo
SSH Communications Security Corp

---

From: Darren J Moffat <[email-masked]>
Date: Mon, 19 Mar 2001 12:01:52 -0800

> `broken' <= 2^80, when measured in elementary operations).

I see it as an implmentation issue, unless you are requesting
that some definition of security quality is added to the protocol.

Personally I'd be very wary of using definitions like the above and
displaying them to a user, they seem very strong.  What I would be
happy with is displaying a warning to the user (generated either by
the client or server) if a known weak combinaition is used, but then
we shouldn't be allowing known weak combinations in the definition of
the protocol so...

--
Darren J Moffat

---

From: Mika Kojo <[email-masked]>
Date: Mon, 19 Mar 2001 23:05:22 +0200

> that some definition of security quality is added to the protocol.

You are right, it is an implementation issue. It is possible to give
some formulas for computing the "security level", but ultimately such
formulas would only have informational value.

Best regards,
Mika Kojo

---

From: [email-masked] (Niels M�ller)
Date: 19 Mar 2001 22:12:16 +0100

> >    256-bit AES requires longer exponents than 128-bit AES.

I have seen reasoning like this before, and I don't think I understand
it. If you want a security level of 2^150, say (I'm not going to try
to define security level precisely, and this particular level is just
an example), then the important thing is that each component
(public-key operations, hashes, bulk ciphers, etc) is at least
2^150-secure.

Now, say you happen to choose a cipher with 2^256-security, because
that's the only thing you've got that's better than 2^128 (if we count
3des as 2^112). When choosing the other components, it's *still* the
2^150 level that matters. They don't have to *match* the cipher.

The important thing is that *each* components is strong enough, not
that they all have equal strength. One component being significantly
stronger than the others doesn't increase security beyond the weakest
part, of course, but it doesn't hurt either.

Is there anything I'm missing?

> decreasing it would indeed decrease security.)

If these figures are right, then the conclusion must be that we should
offer some bigger groups. Either by adding some
diffie-hellam-group2-sha1 key exchange method, or making the
group-exchange mechanism mandatory.

/Niels

---

From: Mika Kojo <[email-masked]>
Date: Tue, 20 Mar 2001 00:24:18 +0200

Niels Möller writes:
[...]
> group-exchange mechanism mandatory.

It is an easy matter to use the complexity estimates for GNFS to see
that (say) RSA of 1024-bits gives about 80-bits of security when
measured in elementary bit operations. There is a paper by Lenstra and
Verheul on this if you want to see some interesting
tabulations. Recall that complexity estimates for discrete log and
factorization are pretty much equal (except for some minor bias in the
favour of discrete logs).

IPsec's IKE groups could be directly taken by SSH2, but even they
don't get yet close the 256-bit limit (which requires the mentioned
13K-bit primes).

Best regards, 
Mika Kojo

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Mar 2001 22:46:49 +0200 (EET)

> don't get yet close the 256-bit limit (which requires the mentioned

The current ssh prime is alreadu the ike-prime-2, thus the wg can
easily take the other groups from the
draft-ietf-ipsec-ike-modp-groups-01.txt if they want so.

I will not do anything to this issue, as I have completely lost
interest about the secure shell protocol because of the wg meeting
yesterday. I have already unsubscribed this mailing list. 
-- 
[email-masked]                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/