[19345] in bugtraq
Re: SSH1 key recovery patch
daemon@ATHENA.MIT.EDU (Markus Friedl)
Thu Feb 22 21:50:57 2001
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-Id: <20010222215940.E8831@folly>
Date: Thu, 22 Feb 2001 21:59:40 +0100
Reply-To: Markus Friedl <markus.friedl@INFORMATIK.UNI-ERLANGEN.DE>
From: Markus Friedl <markus.friedl@INFORMATIK.UNI-ERLANGEN.DE>
X-To: Dan Astoorian <djast@cs.toronto.edu>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <01Feb22.114950edt.453135-20742@jane.cs.toronto.edu>; from
djast@cs.toronto.edu on Thu, Feb 22, 2001 at 11:49:45AM -0500
On Thu, Feb 22, 2001 at 11:49:45AM -0500, Dan Astoorian wrote:
> On Wed, 21 Feb 2001 15:37:45 EST, Markus Friedl writes:
> >
> > OpenSSH checks whether the two calls to rsa_private_decrypt()
> > success and the resulting session keys has the correct size.
> >
> > Otherwise it just uses a 'random' session key. Now the attacker no
> > longer can tell whether the RSA operations failed and the
> > oracle is (almost) closed. [...]
>
> As much as I hate to point out possible problems without proposing
> solutions to them:
>
> Has anyone performed any sort of analysis as to whether there are any
> significant timing differences between the cases where the RSA
> operations succeeded and where they failed--whether due to differences
> in the amount of time taken by rsa_private_decrypt() (etc.) in the two
> cases, or the time taken to prepare the 'random' session key?
(1) the padding check is _after_ the expensive mod_exp-operation
in rsa_private_decrypt(), so there is no significant timing
difference in rsa_private_decrypt().
(2) the 'random' session key is generated by 'md5' operations and
time (md5) << time (2*rsa_private_decrypt).
so, in this case, the timing difference is not an issue.
-markus
