Fw: Problem/bug report for "bad decrypted len" error in OpenSSH

[Markus Friedl]

On Wed, Jul 02, 2003 at 09:18:04PM +0300, Stefan Hadjistoytchev wrote:
> Markus and Damien,
> 
> here is a more detailed explanation about BUG report at
> "http://bugzilla.mindrot.org/show_bug.cgi?id=592" concerning
> "bad decrypted len" error in OpenSSH:
> 
> If anyone wants to do a private key sign, and the key is located in a device
> or the Microsoft certificate store in which the private key cannot be
> accessed directly ( you cannot access the private key directly for
> encryption or decryption ) he must use Microsoft Crypto API. That exact
> Microsoft Crypto API method always returns 36 bytes instead of the 35 bytes
> (OpenSSH standard).
> 
> A private key sign is the method by which both SSL and SSH uses to do
> authentication. What this really means is the host sends an authentication
> challenge to the host which is signed by the workstation (private key
> encrypt) and is then decrypted with the public key by the host.  Since only
> the owner of the private key can encrypt data which can be decrypted by the
> public key held by the host, the host feels he can trust the connection.
> 
> The method used within the crypto API is:
> 
> (1) Obtain the context for the private key using the public key contained
> within the
> certificate.
> (2) Create a hash of the challenge using the CALG_SSL3_SHAMD5 method.

hm, i think that's wrong. this is a 'ssl signature', not the signature
used by ssh.  openssl calls this:

	/* Size of an SSL signature: MD5+SHA1 */
	#define SSL_SIG_LENGTH  36

and it's used for NID_md5_sha1, while ssh uses NID_sha1 (or
NID_md5 for older implementations).

> (3) Sign the hash
> (4) return to host
> 
> (Notes:
>     1. This all pertains only to SSH-2.  SSH-1 uses another method, and in
> fact cannot be done using private keys that cannot be accessed directly;
>     2. This only pertains to certificate based private/public keys.  If you
> use normal OpenSSH keys, then you do not have the problem since the private
> key can be
> accessed directly
>     3. Those that use servers from SSH Data Communications do not have the
> problem. )
> 
> 
> 
> Best regards
>     Stefan
> 
>