'Re: CPSETHASHPARAM usage'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-cryptoapi
Subject:    Re: CPSETHASHPARAM usage
From:       Laszlo Elteto <lelteto () RAINBOW ! COM>
Date:       2002-09-10 15:44:20
[Download RAW message or body]


I think for this particular case (ie. SSL mutual authentication) the =
answer
will be NO. The reason is that you have to SIGN an arbitrary value (no, =
it's
really not even a hash, it's just a random challenge) to prove that you =
have
the private key for your client-side certificate.
You are correct that signing hash values (of text, eg. contract) =
provided to
you by a third party is a security no-no. (It's similar to if somebody =
asks
you to sign with a pen a paper you are not allowed to read first - =
would you
do that? I hope not.) Fortunately, the 36-byte SSL "hash" signing is =
not
used anywhere else (ie. it is not considered a valid signing of any =
text) so
I don't think there is any legal risk doing so. Your CSP may reject any
OTHER CPSetHashParam request.
An alternative would be to completely redesign the SSL mutual =
authentication
process (eg. the server would send it's part of the pre-master key =
encrypted
with the client's public key; the client decrypts it then both client =
and
server would combine the two parts eg. XORing to come up with the key). =
It
is unlikely SSL (or TLS) would be changed that radically. Moreover, =
many of
the client certs which does signing could become invalid - if they can =
only
be used to sign, not to decrypt.
Again, SSL's 36-byte special value (not really hash value, just a =
random
challenge) is not used outside of SSL so I don't think it's a security =
risk.

Laszlo Elteto
Fellow Scientist
Rainbow Technologies, Inc.

-----Original Message-----
From: Frederic Huygens [mailto:fhuygens2002@YAHOO.FR]
Sent: Tuesday, September 10, 2002 2:09 AM
To: CryptoAPI@DISCUSS.MICROSOFT.COM
Subject: Re: CPSETHASHPARAM usage


Hi John,

thanks for your answer, it allows me not to search for
something that doesn't exist. ((-:

This leaves me with the following questions.

In the CPsethashparam doc there is the following text:

"This parameter gives application to sign hash values,
without having access to the base data. Because the
application and the user have no idea of what is being
signed, this operation is intrisically risky. It is
envisioned that most CSP will not support this
parameter."

I took a deeper look at it and I read somewhere that
having the hash created by third party application and
give it to a function performing only "pad+RSA encrypt
with private key" can give rise to several
cryptographic attacks (f.e.: "Further results and
considerations on side channel attacks on RSA-Vladimir
Klima and Tomas Rosa").

- If I do not implement an algid that is not
CALG_SSL3_SHAMD5, against which kind of attack am I
protected against ? I do not really understand how
this work, could you elaborate on it ?

- Is there somewhere in the microsoft planning a
release of Cryptoapi combined with a release of IE
that would allow to avoid having to implement
CPSetHashParam in the CSP, while being in position to
use mutual SSL with the CSP? If the answer would be
yes, could you indicate to me when this is planned to
be released ? This would, I suppose, enhance the
global security of the signature/encryption scheme
while allowing PKI to remain simple (one key, both for
signature and encryption).

Thanks again for the time you would take to answer my
questions.

regards,

Fred.

--- John Banes <jbanes@WINDOWS.MICROSOFT.COM> a
=E9crit : > You are correct, and there is no way around
this
> requirement.
>
> SSL and TLS client authentication require the client
> to sign a 36 byte value that consists of both an MD5
> hash and an SHA hash. Creating such a hash is not
> supported by CryptoAPI, and so the only way to
> perform the signature is to pass in the hash via
> CryptSetHashParam(HP_HASHVAL). The algid for this
> operation is CALG_SSL3_SHAMD5.
>
> I'm not sure what your requirements are, but your
> CSP can possibly get away without implementing any
> other algid with CPSetHashParam....
>
> Regards,
> John
>
> -----Original Message-----
> From: Frederic Huygens
> [mailto:fhuygens2002@YAHOO.FR]
> Sent: Monday, September 09, 2002 5:33 AM
> To: CryptoAPI@DISCUSS.MICROSOFT.COM
> Subject: CPSETHASHPARAM usage
>
>
> Dear all,
>
> According to the information I could collect from
> Internet explorer 5.5. and Internet explorer 6
> behavior with regards to CSPs usage, it seems that
> the CPSETHASHPARAM function with HP_HASHVAL
> parameter must be implemented in any CSP wishing to
> allow the browser to perform the required operations
> needed to obtain a mutual SSL session authentication
> (client and server authenticates to each other).
>
> Is this affirmation correct ?
>
> is there a way to avoid implementing in a CSP
> CPSETHASHPARAM with HP_HASHVAL while allowing IE
> (5.5.
> and/or 6) to perform a mutual SSL session with that
> csp ?
>
> Any information in that matter will be welcome.
>
> Frederic.
>
>
___________________________________________________________
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et
> en fran=E7ais ! Yahoo! Mail : http://fr.mail.yahoo.com
>
>
----------------------------------------------------------------
> Users Guide
> http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the
> archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe,
>
mailto:CryptoAPI-signoff-request@DISCUSS.MICROSOFT.COM
>
>
----------------------------------------------------------------
> Users Guide
> http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the
> archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe,
mailto:CryptoAPI-signoff-request@DISCUSS.MICROSOFT.COM

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran=E7ais !
Yahoo! Mail : http://fr.mail.yahoo.com

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:CryptoAPI-signoff-request@DISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:CryptoAPI-signoff-request@DISCUSS.MICROSOFT.COM

[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic