How do I make the CryptoAPI private key access dialog box modal?

[Mathew]

Hi

re: How do I make the CryptoAPI private key access dialog boxes modal?

I have a password request dialog being displayed by CryptoAPI when I sign a
hash, which is intended and all good. My problem is that it's not modal, so
messages are pumped for the app and users can interact with the application
during my CryptoAPI CryptSignHash call. The best answer I can think of is
making the password dialog modal, can I make the high security dialog modal?

Regards
Mathew

[Rhett Gong [MSFT]]

Hi Mathew,
I am glad to be of your assistant but it seems hard for me to get what happens in your side.

What do you mean by "I have a password request dialog being displayed by CryptoAPI"? Could you post your code for this CryptoAPI?

Thanks for your patience. I am looking forward to hearing from you.

Best regards,
Rhett Gong [MSFT]
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to newsgroups only. Thanks.

[Mathew]

Hi

The CryptoAPI call is very simple, it's just:

::CryptSignHash( hash, dwKeySpec, szDescription, dwFlags, pbSignature,
pdwSigLen );
The dialog boxes are only shown when you import private keys using the high
security options. You can programatically force some of the options by
using:

PFXImportCertStore( &blob, password.c_str(), CRYPT_USER_PROTECTED |
CRYPT_USER_KEYSET );

The dialog that is displayed is from CrypoAPI and is labelled 'Signing data
with your private exhange key', and has the prompt 'An application is
requesting access to a Protected item.' Under details the description is
'CryptoAPI Private Key'.

Does that help you identify the dialog I'm talking about? Let me know if
you would like me to email you screenshots of the dialog.

Regards
Mathew

Post by Rhett Gong [MSFT]
Hi Mathew,
I am glad to be of your assistant but it seems hard for me to get what happens in your side.
What do you mean by "I have a password request dialog being displayed by

CryptoAPI"? Could you post your code for this CryptoAPI?

Post by Rhett Gong [MSFT]
Thanks for your patience. I am looking forward to hearing from you.
Best regards,
Rhett Gong [MSFT]
Microsoft Online Partner Support

[Rhett Gong [MSFT]]

Hi Mathew,
Thanks for your feedback.

Since this dialog is brought out by System when you are using the high security options (CRYPT_USER_PROTECTED The user is to be notified through a dialog
box.), I believe there is no way to turn it to modal. Specially, it is hard to turn a modal dialog which is created by ourselves to modeless either.

If you would like to have a modal dialog to prevent users from interacting with the application during CryptSignHash call, I suggest you create a WaitCursor
(hourglass cursor) before CryptSignHash and set the cursor back when CryptSignHash is finished.
For more information on waitcursor, you can reference CWinApp::DoWaitCursor from MFC source code.
//------------------------code snippet from mfc----------------------------------------------------
void CWinApp::DoWaitCursor(int nCode)
{
// 0 => restore, 1=> begin, -1=> end
ASSERT(nCode == 0 || nCode == 1 || nCode == -1);
ASSERT(afxData.hcurWait != NULL);
AfxLockGlobals(CRIT_WAITCURSOR);
m_nWaitCursorCount += nCode;
if (m_nWaitCursorCount > 0)
{
HCURSOR hcurPrev = ::SetCursor(afxData.hcurWait);
if (nCode > 0 && m_nWaitCursorCount == 1)
m_hcurWaitCursorRestore = hcurPrev;
}
else
{
// turn everything off
m_nWaitCursorCount = 0; // prevent underflow
::SetCursor(m_hcurWaitCursorRestore);
}
AfxUnlockGlobals(CRIT_WAITCURSOR);
}
//--------------------------------------------------------------------------------------------

Hope this helps!

Have a nice day!
Rhett Gong [MSFT]
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to newsgroups only. Thanks.

[Mathew]

Hi

How does a wait cursor stop people interacting with an application?

Regards
Mathew

Post by Rhett Gong [MSFT]
Hi Mathew,
Thanks for your feedback.
Since this dialog is brought out by System when you are using the high

security options (CRYPT_USER_PROTECTED The user is to be notified through a
dialog

Post by Rhett Gong [MSFT]
box.), I believe there is no way to turn it to modal. Specially, it is

hard to turn a modal dialog which is created by ourselves to modeless
either.

Post by Rhett Gong [MSFT]
If you would like to have a modal dialog to prevent users from interacting

with the application during CryptSignHash call, I suggest you create a
WaitCursor

Post by Rhett Gong [MSFT]
(hourglass cursor) before CryptSignHash and set the cursor back when

CryptSignHash is finished.

Post by Rhett Gong [MSFT]
For more information on waitcursor, you can reference

CWinApp::DoWaitCursor from MFC source code.

Post by Rhett Gong [MSFT]
//------------------------code snippet from

mfc----------------------------------------------------

Post by Rhett Gong [MSFT]
void CWinApp::DoWaitCursor(int nCode)
{
// 0 => restore, 1=> begin, -1=> end
ASSERT(nCode == 0 || nCode == 1 || nCode == -1);
ASSERT(afxData.hcurWait != NULL);
AfxLockGlobals(CRIT_WAITCURSOR);
m_nWaitCursorCount += nCode;
if (m_nWaitCursorCount > 0)
{
HCURSOR hcurPrev = ::SetCursor(afxData.hcurWait);
if (nCode > 0 && m_nWaitCursorCount == 1)
m_hcurWaitCursorRestore = hcurPrev;
}
else
{
// turn everything off
m_nWaitCursorCount = 0; // prevent underflow
::SetCursor(m_hcurWaitCursorRestore);
}
AfxUnlockGlobals(CRIT_WAITCURSOR);
}

//--------------------------------------------------------------------------
------------------

Post by Rhett Gong [MSFT]
Hope this helps!
Have a nice day!
Rhett Gong [MSFT]
Microsoft Online Partner Support

[Rhett Gong [MSFT]]

In some scenario, it may stop the user from interacting with the ap
through the mouse.(When setting CWinApp::DoWaitCursor in mfc
application, it will stop user from clicking the mouse to interact with
app if user want to do subsequent actions on the User interface.)

As I said before, there is no way to set the dlg to modal during
CryptSignHash call since the dlg is brought out by system when
forcing the high security option.

thanks,
Rhett Gong [MSFT]
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no
rights.
Please reply to newsgroups only. Thanks.

[Mathew]

By 'may stop' do you mean that I should just hope the user won't press
anything because they see a wait cursor? If so, that's a terrible answer!
If not, how exactly does DoWaitCursor block user interaction ? The MFC code
you posted appears to just change the cursor.

Post by Rhett Gong [MSFT]
In some scenario, it may stop the user from interacting with the ap
through the mouse.(When setting CWinApp::DoWaitCursor in mfc
application, it will stop user from clicking the mouse to interact with
app if user want to do subsequent actions on the User interface.)

[Rhett Gong [MSFT]]

Post by Mathew
By 'may stop' do you mean that I should just hope the user won't
press anything because they see a wait cursor?

No. I mean it depends on the scenario you came across.

For example, I ever met a problem that I need to control a device on remote. There are many buttons in the panel to send control commands to the device. I
must wait a reply from device when I want to send next command. But actually, users could click other buttons to send command before the previous reply come
back. In this scenario, I used DoWaitCursor to stop user from clicking the other command buttons before the reply arrived.

Since I don't know how you used CryptSignHash in your code, I suggest you using it if you come into the similar scenario as I said above. If not, it can not help
anything.

thanks,
Rhett Gong [MSFT]
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to newsgroups only. Thanks.

[Mathew]

Hi

Maybe we're getting the crux of the matter. I understand from your example
why changing the cursor communicates to the user something is going on. I
already do that, although I'm not using MFC so I don't call DoWaitCursor,
but I do change the cursor just like DoWaitCursor does using SetCursor.

The problem I'm having is the CrypoAPI Dialog pumps messages to my
application (which is midway through an API call), so the user can press
buttons and I get re-enterancy problems. The problem is specific to the
nature of the CryptoAPI dialogs, not just that there is a long operation
occuring.

Do you understand why calling SetCursor doesn't solve the problem?

Regards
Mathew

Post by Rhett Gong [MSFT]

Post by Mathew
By 'may stop' do you mean that I should just hope the user won't
press anything because they see a wait cursor?

No. I mean it depends on the scenario you came across.
For example, I ever met a problem that I need to control a device on

remote. There are many buttons in the panel to send control commands to the
device. I

Post by Rhett Gong [MSFT]
must wait a reply from device when I want to send next command. But

actually, users could click other buttons to send command before the
previous reply come

Post by Rhett Gong [MSFT]
back. In this scenario, I used DoWaitCursor to stop user from clicking the

other command buttons before the reply arrived.

Post by Rhett Gong [MSFT]
Since I don't know how you used CryptSignHash in your code, I suggest you

using it if you come into the similar scenario as I said above. If not, it
can not help

Post by Rhett Gong [MSFT]
anything.
thanks,
Rhett Gong [MSFT]
Microsoft Online Partner Support

[Rhett Gong [MSFT]]

Hi,
Thanks for your feedback!

I get it. But now, I believe there is no way to achieve your goal since
this dialog is brought out by the underlying Crypto API due to the
strong private key protection.

Thanks,
Rhett Gong [MSFT]
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no
rights.
Please reply to newsgroups only. Thanks.

[Mathew]

Thank you! That is greatly appreciated.

Regards
Mathew

We ran into the same issue in our application.
The way we worked around it is by creating a new thread and calling

CryptSignHash from that new thread. This way, your application's UI thread
remains blocked, won't handle any pending Windows pump messages, and you
avoid the re-entrancy issue.