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

Nils Larsch larsch at trustcenter.de
Wed Jul 2 19:11:07 EST 2003


Stefan Hadjistoytchev wrote:
....
> 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

The length of the PKCS#1 DigestInfo should depend of the hash alg
and if you select CALG_SHA it should be 35.

> (OpenSSH standard).

That's not a OpenSSH issue, the format of the signature is specified in
PKCS#1.

> 
> 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.

As far as I know OpenSSH (v2) uses the CALG_SHA method (note: the
length of the CALG_SSL3_SHAMD5 method is indeed 36, but that's not
what we want here, but with this I don't really understand why it
worked without the length check).

> (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;

Using OpenSC I can use smartcards and ssh-1 :-)

Nils




More information about the openssh-unix-dev mailing list