[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

Sample code for the MS crypto API calls.

Tony Toews

1/12/2012 7:31:00 AM

Folks

I'm looking for some up to date sample code for the MS crypto API
calls.

A few users have reported getting the error message. "Automation error
The profile for the user is a temporary profile" The only relevant
hit is the following which has no answer:
http://www.tek-tips.com/viewthread.cfm?q... (I find a problem
which apparently has only ever happened once before to be a scary
concept. For me to attempt to figure out.)

Unfortunately this happens to appear in a module which I use to
decrypt the license key data such as the clients name so I can't
bypass the logic. <sigh>

The module uses code such as

Private Declare Function CryptAcquireContext _
Lib "advapi32.dll" _
Alias "CryptAcquireContextA" ( _
ByRef phProv As Long, _
ByVal pszContainer As String, _
ByVal pszProvider As String, _
ByVal dwProvType As Long, _
ByVal dwFlags As Long) As Long

and

lRes = CryptAcquireContext(hProv, vbNullString, _
"Microsoft Enhanced Cryptographic Provider v1.0",
PROV_RSA_FULL, 0)

Trouble is I have no idea where I located the code and it was prior to
July 2004. So I wonder if the code has some subtle bugs or problems
in it that weren't apparent back then. I'm thinking that if I can
locate an up to date version of the code it might fix up my problem.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/ac...
Tony's Microsoft Access Blog - http://msmvps.com/blo...
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeup...
20 Answers

GS

1/12/2012 7:44:00 AM

0

Tony Toews brought next idea :
> Folks
>
> I'm looking for some up to date sample code for the MS crypto API
> calls.
>
> A few users have reported getting the error message. "Automation error
> The profile for the user is a temporary profile" The only relevant
> hit is the following which has no answer:
> http://www.tek-tips.com/viewthread.cfm?q... (I find a problem
> which apparently has only ever happened once before to be a scary
> concept. For me to attempt to figure out.)
>
> Unfortunately this happens to appear in a module which I use to
> decrypt the license key data such as the clients name so I can't
> bypass the logic. <sigh>
>
> The module uses code such as
>
> Private Declare Function CryptAcquireContext _
> Lib "advapi32.dll" _
> Alias "CryptAcquireContextA" ( _
> ByRef phProv As Long, _
> ByVal pszContainer As String, _
> ByVal pszProvider As String, _
> ByVal dwProvType As Long, _
> ByVal dwFlags As Long) As Long
>
> and
>
> lRes = CryptAcquireContext(hProv, vbNullString, _
> "Microsoft Enhanced Cryptographic Provider v1.0",
> PROV_RSA_FULL, 0)
>
> Trouble is I have no idea where I located the code and it was prior to
> July 2004. So I wonder if the code has some subtle bugs or problems
> in it that weren't apparent back then. I'm thinking that if I can
> locate an up to date version of the code it might fix up my problem.
>
> Tony

Tony,
I'd be happy to help but I forgot most of the nuances involved with
using CryptoApi since I started using a class wrapper for doing this
for app licensing. The class (by David Midkiff) is a pure VB
implementation that I include in my projects, and so is not dependent
on APIs. It uses 'Private' Key methodology rather than 'Public/Private'
keys because I don't give out the key. Let me know if you're interested
in switching up from using the MS CryptoAPIs.

--
Garry

Free usenet access at http://www.eternal-sep...
ClassicVB Users Regroup! comp.lang.basic.visual.misc

Tony Toews

1/12/2012 8:43:00 AM

0

On Thu, 12 Jan 2012 02:43:40 -0500, GS <gs@somewhere.net> wrote:

>I'd be happy to help but I forgot most of the nuances involved with
>using CryptoApi since I started using a class wrapper for doing this
>for app licensing. The class (by David Midkiff) is a pure VB
>implementation that I include in my projects, and so is not dependent
>on APIs. It uses 'Private' Key methodology rather than 'Public/Private'
>keys because I don't give out the key. Let me know if you're interested
>in switching up from using the MS CryptoAPIs.

The problem is I have many clients out there using the utility with
encrypted passwords in their INI files and an encrypted license key
file from me. I have to be able to use the same "seed", if that's the
correct terminology and the same outcome as the past versions of my
utility. So I have to continue to use the MS Crypto API so it's
transparent to the clients. Otherwise they'll be very unhappy and
I'll get many support emails.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/ac...
Tony's Microsoft Access Blog - http://msmvps.com/blo...
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeup...

ralph

1/12/2012 10:40:00 AM

0

On Thu, 12 Jan 2012 00:30:48 -0700, Tony Toews
<ttoews@telusplanet.net> wrote:

>Folks
>
>I'm looking for some up to date sample code for the MS crypto API
>calls.
>
>A few users have reported getting the error message. "Automation error
>The profile for the user is a temporary profile" The only relevant
>hit is the following which has no answer:
>http://www.tek-tips.com/viewthread.cfm?q... (I find a problem
>which apparently has only ever happened once before to be a scary
>concept. For me to attempt to figure out.)
>
>Unfortunately this happens to appear in a module which I use to
>decrypt the license key data such as the clients name so I can't
>bypass the logic. <sigh>
>
>The module uses code such as
>
>Private Declare Function CryptAcquireContext _
> Lib "advapi32.dll" _
> Alias "CryptAcquireContextA" ( _
> ByRef phProv As Long, _
> ByVal pszContainer As String, _
> ByVal pszProvider As String, _
> ByVal dwProvType As Long, _
> ByVal dwFlags As Long) As Long
>
>and
>
> lRes = CryptAcquireContext(hProv, vbNullString, _
> "Microsoft Enhanced Cryptographic Provider v1.0",
>PROV_RSA_FULL, 0)
>
>Trouble is I have no idea where I located the code and it was prior to
>July 2004. So I wonder if the code has some subtle bugs or problems
>in it that weren't apparent back then. I'm thinking that if I can
>locate an up to date version of the code it might fix up my problem.
>

Doubtful.

It isn't any particular error/bug/<whatever> in the "code" itself that
is causing the error. It is that the client is using some
configuration with his Remote (or Roaming) profile that is simply
failing with the combination of your application and the application
you are attempting to "automate". (Or the other way around, It isn't
clear which you are doing.)

[Note: It isn't that their current profile is *broken*, it likely
works just fine most of the time. It is only that it breaks for this
unique circumstance and combination, and needs tweaking.]

The real repair is for the client to reconfigure the remote profiles
to work with yours or the other application. To help with that you
need to be onsite to determine what to change, with full
administrative privileges, of course. <g>

You might play around with new code, new libraries. You never know. A
little juggling might be all that is needed. Automation can ticklish
at times. But don't waste your time looking for "bugs".

-ralph

MikeD

1/12/2012 11:53:00 AM

0



"Tony Toews" <ttoews@telusplanet.net> wrote in message
news:5j2tg7tgsfceo15esmtmji2ho21kerqk0v@4ax.com...
> Folks
>
> I'm looking for some up to date sample code for the MS crypto API
> calls.
>
> A few users have reported getting the error message. "Automation error
> The profile for the user is a temporary profile" The only relevant


Just a shot in the dark, but is it possible the user(s) is/are logged on as
"guest"? I don't even know if that could cause problems with the encryption
API, but it's certainly something that I could see causing problems.

--
Mike

GS

1/12/2012 4:11:00 PM

0

on 1/12/2012, Tony Toews supposed :
> On Thu, 12 Jan 2012 02:43:40 -0500, GS <gs@somewhere.net> wrote:
>
>> I'd be happy to help but I forgot most of the nuances involved with
>> using CryptoApi since I started using a class wrapper for doing this
>> for app licensing. The class (by David Midkiff) is a pure VB
>> implementation that I include in my projects, and so is not dependent
>> on APIs. It uses 'Private' Key methodology rather than 'Public/Private'
>> keys because I don't give out the key. Let me know if you're interested
>> in switching up from using the MS CryptoAPIs.
>
> The problem is I have many clients out there using the utility with
> encrypted passwords in their INI files and an encrypted license key
> file from me. I have to be able to use the same "seed", if that's the
> correct terminology and the same outcome as the past versions of my
> utility. So I have to continue to use the MS Crypto API so it's
> transparent to the clients. Otherwise they'll be very unhappy and
> I'll get many support emails.
>
> Tony

Yeah, I went through the same issue when I transitioned from using an
encrypted license key to an encrypted license file. I now send a
LicenseActivator.EXE instead of keys because I also write a backup
version of the license file to some obscure place in the Registry
(and/or another file on the drive the app is installed to depending if
the license has a 'Roam' profile).

In your case it wouldn't matter if you sent a key or use a license
file, so nothing will actually break if handled right. I did, though,
revise my apps to recognize older license keys/files and convert the
decrypted data to the new methodology so all previous releases were
updated without breaking (or the user even knowing it happened). This
was easy to do since the license is always checked at startup. If the
old license file existed it was opened, processed, then replaced with a
new license file. Since the old/new file names were different this was
an easy transition for me and my users!

FWIW, I use a separate license file so the app's INI file just contains
app data. Optionally, I could send a new license file to replace the
existing outdated license file. Also, my apps are licensed to the
computer and so any user can use the app.

--
Garry

Free usenet access at http://www.eternal-sep...
ClassicVB Users Regroup! comp.lang.basic.visual.misc

GS

1/12/2012 4:31:00 PM

0

Tony Toews explained on 1/12/2012 :
> On Thu, 12 Jan 2012 02:43:40 -0500, GS <gs@somewhere.net> wrote:
>
>> I'd be happy to help but I forgot most of the nuances involved with
>> using CryptoApi since I started using a class wrapper for doing this
>> for app licensing. The class (by David Midkiff) is a pure VB
>> implementation that I include in my projects, and so is not dependent
>> on APIs. It uses 'Private' Key methodology rather than 'Public/Private'
>> keys because I don't give out the key. Let me know if you're interested
>> in switching up from using the MS CryptoAPIs.
>
> The problem is I have many clients out there using the utility with
> encrypted passwords in their INI files and an encrypted license key
> file from me. I have to be able to use the same "seed", if that's the
> correct terminology and the same outcome as the past versions of my
> utility. So I have to continue to use the MS Crypto API so it's
> transparent to the clients. Otherwise they'll be very unhappy and
> I'll get many support emails.
>
> Tony

"Seed" is what I was referring to as "Private/Public" encryption keys.
I use a 256-bit string for mine, each app having its own unique
version.

--
Garry

Free usenet access at http://www.eternal-sep...
ClassicVB Users Regroup! comp.lang.basic.visual.misc

ralph

1/12/2012 7:08:00 PM

0

On Thu, 12 Jan 2012 11:11:05 -0500, GS <gs@somewhere.net> wrote:

>on 1/12/2012, Tony Toews supposed :
>> On Thu, 12 Jan 2012 02:43:40 -0500, GS <gs@somewhere.net> wrote:
>>
>>> I'd be happy to help but I forgot most of the nuances involved with
>>> using CryptoApi since I started using a class wrapper for doing this
>>> for app licensing. The class (by David Midkiff) is a pure VB
>>> implementation that I include in my projects, and so is not dependent
>>> on APIs. It uses 'Private' Key methodology rather than 'Public/Private'
>>> keys because I don't give out the key. Let me know if you're interested
>>> in switching up from using the MS CryptoAPIs.
>>
>> The problem is I have many clients out there using the utility with
>> encrypted passwords in their INI files and an encrypted license key
>> file from me. I have to be able to use the same "seed", if that's the
>> correct terminology and the same outcome as the past versions of my
>> utility. So I have to continue to use the MS Crypto API so it's
>> transparent to the clients. Otherwise they'll be very unhappy and
>> I'll get many support emails.
>>
>> Tony
>
>Yeah, I went through the same issue when I transitioned from using an
>encrypted license key to an encrypted license file. I now send a
>LicenseActivator.EXE instead of keys because I also write a backup
>version of the license file to some obscure place in the Registry
>(and/or another file on the drive the app is installed to depending if
>the license has a 'Roam' profile).
>
>In your case it wouldn't matter if you sent a key or use a license
>file, so nothing will actually break if handled right. I did, though,
>revise my apps to recognize older license keys/files and convert the
>decrypted data to the new methodology so all previous releases were
>updated without breaking (or the user even knowing it happened). This
>was easy to do since the license is always checked at startup. If the
>old license file existed it was opened, processed, then replaced with a
>new license file. Since the old/new file names were different this was
>an easy transition for me and my users!
>
>FWIW, I use a separate license file so the app's INI file just contains
>app data. Optionally, I could send a new license file to replace the
>existing outdated license file. Also, my apps are licensed to the
>computer and so any user can use the app.

Excellent advise.

-ralph

Tony Toews

1/12/2012 7:57:00 PM

0

On Thu, 12 Jan 2012 06:53:27 -0500, "MikeD" <nobody@nowhere.edu>
wrote:

>Just a shot in the dark, but is it possible the user(s) is/are logged on as
>"guest"? I don't even know if that could cause problems with the encryption
>API, but it's certainly something that I could see causing problems.

I doubt it very much but I suppose it's possible.

I'm also going to ask the client to review the event log to see if
there's anything interesting in there.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/ac...
Tony's Microsoft Access Blog - http://msmvps.com/blo...
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeup...

GS

1/12/2012 8:02:00 PM

0

Tony Toews formulated on Thursday :
> On Thu, 12 Jan 2012 06:53:27 -0500, "MikeD" <nobody@nowhere.edu>
> wrote:
>
>> Just a shot in the dark, but is it possible the user(s) is/are logged on as
>> "guest"? I don't even know if that could cause problems with the encryption
>> API, but it's certainly something that I could see causing problems.
>
> I doubt it very much but I suppose it's possible.
>
> I'm also going to ask the client to review the event log to see if
> there's anything interesting in there.
>
> Tony

<FWIW>
In the case where the user isn't likely to know what they're looking at
in event/error logs, I prefer they email me the file via the "Report a
problem" button on my help menu.

--
Garry

Free usenet access at http://www.eternal-sep...
ClassicVB Users Regroup! comp.lang.basic.visual.misc

GS

1/12/2012 8:04:00 PM

0

Thanks, Ralph! Your comment is very much appreciated!

regards,

--
Garry

Free usenet access at http://www.eternal-sep...
ClassicVB Users Regroup! comp.lang.basic.visual.misc