openssh unix dev - Jul 2003 - Fw: Problem/bug report for "bad decrypted len" error in OpenSSH

Hi,

On Wed, Jul 02, 2003 at 09:18:04PM +0300, Stefan Hadjistoytchev
wrote:
>     3. Those that use servers from SSH Data Communications do not have the
> problem. )
Sounds as if they are just not doing sanity checking on their input data.
No?

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at
greenie.muc.de
fax: +49-89-35655025                        gert.doering at
physik.tu-muenchen.de

>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).
>  
>
This number cannot be correct; neither RSA nor DSA can (easily) provide
digital signatures in 280/288 bits.
>    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;
>
SSHv2 uses sign-and-verify; SSHv1 uses encrypt-and-prove-decrypt. Both
should be compatible with crypto tokens -- "here, decrypt this" is no
different than "here, sign this".

--Dan

The number 36 may not be correct but is a fact :(

----- Original Message ----- 
From: "Dan Kaminsky" <dan at doxpara.com>
To: "Stefan Hadjistoytchev" <sth at hq.bsbg.net>
Cc: <openssh-unix-dev at mindrot.org>; <djm at mindrot.org>;
"Markus Friedl"
<markus at openbsd.org>
Sent: Wednesday, July 02, 2003 3:55 AM
Subject: Re: Fw: Problem/bug report for "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).
> >
> >
>
> This number cannot be correct; neither RSA nor DSA can (easily) provide
> digital signatures in 280/288 bits.
>
> >    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;
> >
> SSHv2 uses sign-and-verify; SSHv1 uses encrypt-and-prove-decrypt. Both
> should be compatible with crypto tokens -- "here, decrypt this"
is no
> different than "here, sign this".
>
> --Dan
>
>
>
>

They do not use Mucrosoft API, but have thier own API to communicate with
smart-cards. The problem with them is that your smart-card must be supported
by them :(

----- Original Message ----- 
From: "Gert Doering" <gert at greenie.muc.de>
To: "Stefan Hadjistoytchev" <sth at hq.bsbg.net>
Cc: <openssh-unix-dev at mindrot.org>; <djm at mindrot.org>;
"Markus Friedl"
<markus at openbsd.org>
Sent: Tuesday, July 01, 2003 10:17 PM
Subject: Re: Fw: Problem/bug report for "bad decrypted len" error in
OpenSSH

> Hi,
>
> On Wed, Jul 02, 2003 at 09:18:04PM +0300, Stefan Hadjistoytchev wrote:
> >     3. Those that use servers from SSH Data Communications do not have
the
> > problem. )
>
> Sounds as if they are just not doing sanity checking on their input data.
> No?
>
> gert
> -- 
> USENET is *not* the non-clickable part of WWW!
>
//www.muc.de/~gert/
> Gert Doering - Munich, Germany
gert at greenie.muc.de
> fax: +49-89-35655025
gert.doering at physik.tu-muenchen.de
>
>

On Tue, Jul 01, 2003 at 05:55:30PM -0700, Dan Kaminsky
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
> >(OpenSSH standard).
> >  
> >
> 
> This number cannot be correct; neither RSA nor DSA can (easily) provide
> digital signatures in 280/288 bits.
this is about something different. this is about pkcs#1

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

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

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