Re: Decrypting on different platforms

From: Frank Perry (FrankPerry_at_discussions.microsoft.com)
Date: 05/27/05 

Date: Thu, 26 May 2005 18:59:37 -0700

Howdy,

Doesn't the call
> > if (!CryptGenKey (hProv, CALG_RC2, CRYPT_EXPORTABLE, &hKey))
create an asysmmetric key?

I've tried both paths through the sample. The top path is with out a
password and it uses CryptGenKey. That is where the CryptGetUserKey fails.
The other pass is with a password. That works to encrypt and decrypt but
only on the same platform.

I have looked further into the problem in the with password path. I had
tried to force the hash in the decrypt on the W2K machine to the hash I found
on the CE machine. What I found is the function CryptSetHashParam fails
telling me the hash is not in the correct state. I wasn't able to persue
that further today.

I'll pound on it tomorrow. 

-- 
Frank Perry
LavaLeaf Software
"Ryan Menezes [MSFT]" wrote:
> CryptGetUserKey failure is expected since you never created an asymmetric 
> key using CryptGenKey in the first place.
> When creating the RC2 key, also look into specifying the KP_EFFECTIVE_KEYLEN 
> flag using CryptSetKeyParam().
> 
> 
> Thanks,
> Ryan Menezes [MSFT]
> 
> -- 
> This posting is provided "AS IS" with no warranties, and confers no rights. 
> "Use of included script samples are subject to the terms specified at 
> http://www.microsoft.com/info/cpyright.htm"
> 
> 
> 
> "Frank Perry" <FrankPerry@discussions.microsoft.com> wrote in message 
> news:06E49322-EE75-4623-B548-42555EE61558@microsoft.com...
> > Howdy,
> >
> > I am using the built in CSP.
> >
> > The code is lifted from the eMbedded Visual C++ help for encrypting and
> > decrypting data.  Here are the sections that give me trouble.
> >
> > // Get the handle to the default provider.
> >  if (!CryptAcquireContext (&hProv, NULL, NULL, PROV_RSA_FULL, 0))
> >  {
> >    wprintf (TEXT("Error %x during CryptAcquireContext!\n"),
> >             GetLastError ());
> >    goto exit;
> >  }
> >
> >  if (lpszPassword == NULL)
> >  {
> >    // Encrypt the file with a random session key.
> >
> >    // Create a random session key.
> >    if (!CryptGenKey (hProv, CALG_RC2, CRYPT_EXPORTABLE, &hKey))
> >    {
> >      wprintf (TEXT("Error %x during CryptGenKey!\n"),
> >               GetLastError ());
> >      goto exit;
> >    }
> >
> >    // Get the handle to the key exchange public key.
> >    if (!CryptGetUserKey (hProv, AT_KEYEXCHANGE, &hXchgKey))
> >    {
> >      wprintf (TEXT("Error %x during CryptGetUserKey!\n"),
> >               GetLastError ());
> >      goto exit;
> >    }
> > This is the path with no password.  Here it should be giving me a key that 
> > I
> > can export to a blob and then save someplace.  At this point, it always 
> > fails
> > saying there is no key.
> >  ***
> >  }
> >  else
> >  {
> >    // Encrypt the file with a session key derived from a password.
> >
> >    // Create a hash object.
> >    if (!CryptCreateHash (hProv, CALG_MD5, 0, 0, &hHash))
> >    {
> >      wprintf (TEXT("Error %x during CryptCreateHash!\n"),
> >               GetLastError ());
> >      goto exit;
> >    }
> >
> >    // Hash in the password data.
> >    if (!CryptHashData (hHash, (PBYTE)lpszPassword,
> >                        wcslen (lpszPassword), 0))
> >    {
> >      wprintf (TEXT("Error %x during CryptHashData!\n"),
> >               GetLastError ());
> >      goto exit;
> >    }
> >
> >    // Derive a session key from the hash object.
> >    if (!CryptDeriveKey (hProv, CALG_RC2, hHash, 0, &hKey))
> >    {
> >      wprintf (TEXT("Error %x during CryptDeriveKey!\n"),
> >               GetLastError ());
> >      goto exit;
> >    }
> >  }
> >
> > If I give it a pass word, this section works fine but the same pass word 
> > on
> > the CE machine does not work on the W2K machine.  It does work on a 
> > different
> > CE machine.  (I have converted both to bytes so the CE machine is not
> > encrypting Unicode.)
> >
> > For the first example, I have tried running it on both the systems and get
> > the same failure.  My current thinking is that the is a security setting 
> > at
> > the OS level that is preventing me from exporting a key.  If so, the 
> > sample
> > code should say something about it, but doesn't.
> >
> > For the second, I have looked at the hash and found the hash was different
> > between the machines.  I took the hash from one machine and force the hash 
> > in
> > the other machine to the same value.  But that didn't help.  I would force
> > the key but I can't get an exportable key.
> >
> > Any ideas?  As I said, I'm looking at the security settings to see if 
> > there
> > is something that could block me from making an exportable key.
> > -- 
> > Frank Perry
> > LavaLeaf Software
> >
> >
> > "Ryan Menezes [MSFT]" wrote:
> >
> >> Which encryption algorithm are you using and what are the default CSPs on
> >> those machines ?
> >>
> >> Would definetely help if you can post some sample code.
> >>
> >> Thanks,
> >> Ryan Menezes [MSFT]
> >>
> >> -
> >> This posting is provided "AS IS" with no warranties, and confers no 
> >> rights.
> >> "Use of included script samples are subject to the terms specified at
> >> http://www.microsoft.com/info/cpyright.htm"
> >>
> >>
> >>
> >> "Frank Perry" <FrankPerry@discussions.microsoft.com> wrote in message
> >> news:03189DBD-7470-4C7A-97D3-50F68764BCED@microsoft.com...
> >> > Howdy,
> >> >
> >> > I forgot to mention that I have both machines using 40 bit key lengths.
> >> >
> >> > -- 
> >> > Frank Perry
> >> > LavaLeaf Software
> >> >
> >> >
> >> > "Frank Perry" wrote:
> >> >
> >> >> Howdy,
> >> >>
> >> >> I have been using the sample code for encrypting and decrypting files. 
> >> >> I
> >> >> have no trouble using the password version to encrypt a file and 
> >> >> decrypt
> >> >> it
> >> >> on the same machine.  But when I move the file to a different machine
> >> >> with a
> >> >> different OS, it fails.  The two OSs are W2K and CE.
> >> >>
> >> >> So far, I have found the the hash created from the same password is
> >> >> different on the two machines.  I have tried forcing the same hash on
> >> >> both
> >> >> machines but that doesn't get me anywhere either.  I haven't seen the 
> >> >> CE
> >> >> side, but the KP_IV of the W2K side is all 0's.
> >> >>
> >> >> I would try transfering the key itself, but on a different problem, I
> >> >> can't
> >> >> get CryptGetUserKey to return a key.  I am using the code from the
> >> >> example
> >> >> but nothing comes back.  I get the error that there is no key.
> >> >>
> >> >> Are there any ideas about either of these problems?
> >> >>
> >> >> Thanks in advance.
> >> >> -- 
> >> >> Frank Perry
> >> >> LavaLeaf Software
> >>
> >>
> >> 
> 
> 
>

Relevant Pages

  • Re: Decrypting on different platforms
    ... > tried to force the hash in the decrypt on the W2K machine to the hash I ... >> "Use of included script samples are subject to the terms specified at ... >>> goto exit; ... >>> // Encrypt the file with a random session key. ...
    (microsoft.public.platformsdk.security)
  • RE: Can Kerberos be cracked??
    ... Subject: Can Kerberos be cracked?? ... If you were able to decrypt the timestamp ... As for your assumption about the hash being as good as the password, ... > encrypt the timestamp) still be susceptible to brute-force> using dictionary ...
    (Focus-Microsoft)
  • RE: Can Kerberos be cracked??
    ... If you were able to decrypt the timestamp ... As for your assumption about the hash being as good as the password, ... > encrypt the timestamp) still be susceptible to brute-force> using dictionary ... The server doesn't actually know what the user's>>password is, ...
    (Focus-Microsoft)
  • Re: Can Kerberos be cracked??
    ... encrypt the timestamp) still be susceptible to brute-force using dictionary ... Secondly, even without the actual password known, wouldn't juz the hash (let ... The server doesn't actually know what the user's ...
    (Focus-Microsoft)
  • Re: Can Kerberos be cracked??
    ... > against the encrypted timestamp. ... > As for your assumption about the hash being as good as the password, ... >> encrypt the timestamp) still be susceptible to brute-force ... The server doesn't actually know what the user's ...
    (Focus-Microsoft)