asymetric encryption with private key

what are you trying to achieve? are you signing something? what platform are
you using? and what error do you see?

"Eyup Gurel" <egl@linkbilgisayar.com.tr> wrote:
>
>I could not achieve asymetric encryption with a private key There are tons
>of samples about symetric encryption with a session key but virtually no
>samples related to asymetric encryption with a private key.
>
>CryptAcquireContext(&hProv,NULL,MS_DEF_DSS_PROV,PROV_DSS,0); succeeds
>
>CryptGenKey(hProv,CALG_DSS_SIGN,CRYPT_EXPORTABLE,&hPrivKey)
>succeeds
>
>but
>CryptEncrypt(hPrivKey,0,TRUE,0,NULL,&dwRawDataLen,128)
>fails
>
>
>Have you ever tried it. I have read every bit of MSDN but could not find
>any clue. I have tried every possible provider. In samples a hash is signed
>with a private key that is extracted from a certificate or a session key
>is encrypted with a private key. All of these happens in the bowels of API
>functions. I could not spot any CryptEncrypt call with a private key. If
>you help me you will sava a life.

You cannot encrypt with a public or private key, only with a symmetric key.
You can only sign or verify a signature with the public/private key.

btw, you should use a cert not a plain public key - otherwise, i could sign
an app with any old private key - give you the package and say, "here's the
public key, trust me it belongs to Eyup Gurel!"

"Eyup Gurel" <egl@linkbilgisayar.com.tr> wrote:
>
>Dear Micheal;
>
>What I am trying to achieve is very very simple in theory. I am using public
>key encryption architecture. I am trying to
>sign some arbitrary byte stream(which includes our software's configuration
>data and license ) with my own private key. Once this is achieved I will
>distribute my public key and this private-key encrypted data to my clients
>so that they will be able to decrypt it with my public key and use it. But
>they will never be able to play with it. In other words this data will be
>read only.
>
>
>My platform is Windows 2000 Advanced Server. I am using Microsoft's CryptoAPI.
>
>After successfully acquiring a context with CryptAcquireContext I am generating
>a private key with CryptGenKey giving to it AT_SIGNATURE. When I try to
encrypt
>data with this derived key it returns an Error NTE_BAD_KEY with Microsoft's
>Base Provider MS_DEF_PROV, with other providers it returns NTE_BAD_ALGID
>I am using the Microsoft recommended ALG_ID 's for each provider.
>
>I could not see any samples anywhere which shows an encryption with a private
>key. In CryptoAPI private keys are used behind the scenes to sign a hash
>in CryptSignHash and in a number of API's. I want to use the private key
>directly. Are we implicitly barred doing that by the Crypto API ?
>Thanks alot for your precious effort in advance.
>
>
>
>"Michael Howard" <mikehow@microsoft.com> wrote:
>>
>>what are you trying to achieve? are you signing something? what platform
>are
>>you using? and what error do you see?
>>
>>"Eyup Gurel" <egl@linkbilgisayar.com.tr> wrote:
>>>
>>>I could not achieve asymetric encryption with a private key There are
tons
>>>of samples about symetric encryption with a session key but virtually
no
>>>samples related to asymetric encryption with a private key.
>>>
>>>CryptAcquireContext(&hProv,NULL,MS_DEF_DSS_PROV,PROV_DSS,0); succeeds
>>>
>>>CryptGenKey(hProv,CALG_DSS_SIGN,CRYPT_EXPORTABLE,&hPrivKey)
>>>succeeds
>>>
>>>but
>>>CryptEncrypt(hPrivKey,0,TRUE,0,NULL,&dwRawDataLen,128)
>>>fails
>>>
>>>
>>>Have you ever tried it. I have read every bit of MSDN but could not find
>>>any clue. I have tried every possible provider. In samples a hash is signed
>>>with a private key that is extracted from a certificate or a session key
>>>is encrypted with a private key. All of these happens in the bowels of
>API
>>>functions. I could not spot any CryptEncrypt call with a private key.
If
>>>you help me you will sava a life.
>>
>

>>Re: Encrypting with a private/public key.

Yes, i mean that in CAPI you can only encrypt with a session key. but you
can encrypt the session key as part of a signed message.

>>Re: You may not need a cert if you force the public key to be verified
by getting it off the web server. But then you still have the man in the
middle attack.

Exactly, that's why you use a cert - because the public key in the cert can
be verified, assuming you trust the issuer.

"Eli Allen" <eallen@bcpl.net> wrote:
>You better just be talking about CryptoAPI. I mean a session key is usually
>a symmetric key and its a little hard to encrypt it using some other method
>then with the public key.
>
>You may not need a cert if you force the public key to be verified by
>getting it off the web server. But then you still have the man in the
>middle attack.
>--
>Eli Allen
>eallen@bcpl.net
>
>"Michael Howard" <mikehow@microsoft.com> wrote in message
>news:3a5ce3c9$3@news.dev-archive.com...
>>
>> You cannot encrypt with a public or private key, only with a symmetric
>key.
>> You can only sign or verify a signature with the public/private key.
>>
>> btw, you should use a cert not a plain public key - otherwise, i could
>sign
>> an app with any old private key - give you the package and say, "here's
>the
>> public key, trust me it belongs to Eyup Gurel!"
>>
>> "Eyup Gurel" <egl@linkbilgisayar.com.tr> wrote:
>> >
>> >Dear Micheal;
>> >
>> >What I am trying to achieve is very very simple in theory. I am using
>public
>> >key encryption architecture. I am trying to
>> >sign some arbitrary byte stream(which includes our software's
>configuration
>> >data and license ) with my own private key. Once this is achieved I will
>> >distribute my public key and this private-key encrypted data to my
>clients
>> >so that they will be able to decrypt it with my public key and use it.
>But
>> >they will never be able to play with it. In other words this data will
be
>> >read only.
>> >
>> >
>> >My platform is Windows 2000 Advanced Server. I am using Microsoft's
>CryptoAPI.
>> >
>> >After successfully acquiring a context with CryptAcquireContext I am
>generating
>> >a private key with CryptGenKey giving to it AT_SIGNATURE. When I try
to
>> encrypt
>> >data with this derived key it returns an Error NTE_BAD_KEY with
>Microsoft's
>> >Base Provider MS_DEF_PROV, with other providers it returns NTE_BAD_ALGID
>> >I am using the Microsoft recommended ALG_ID 's for each provider.
>> >
>> >I could not see any samples anywhere which shows an encryption with a
>private
>> >key. In CryptoAPI private keys are used behind the scenes to sign a hash
>> >in CryptSignHash and in a number of API's. I want to use the private
key
>> >directly. Are we implicitly barred doing that by the Crypto API ?
>> >Thanks alot for your precious effort in advance.
>> >
>> >
>> >
>> >"Michael Howard" <mikehow@microsoft.com> wrote:
>> >>
>> >>what are you trying to achieve? are you signing something? what platform
>> >are
>> >>you using? and what error do you see?
>> >>
>> >>"Eyup Gurel" <egl@linkbilgisayar.com.tr> wrote:
>> >>>
>> >>>I could not achieve asymetric encryption with a private key There are
>> tons
>> >>>of samples about symetric encryption with a session key but virtually
>> no
>> >>>samples related to asymetric encryption with a private key.
>> >>>
>> >>>CryptAcquireContext(&hProv,NULL,MS_DEF_DSS_PROV,PROV_DSS,0); succeeds
>> >>>
>> >>>CryptGenKey(hProv,CALG_DSS_SIGN,CRYPT_EXPORTABLE,&hPrivKey)
>> >>>succeeds
>> >>>
>> >>>but
>> >>>CryptEncrypt(hPrivKey,0,TRUE,0,NULL,&dwRawDataLen,128)
>> >>>fails
>> >>>
>> >>>
>> >>>Have you ever tried it. I have read every bit of MSDN but could not
>find
>> >>>any clue. I have tried every possible provider. In samples a hash is
>signed
>> >>>with a private key that is extracted from a certificate or a session
>key
>> >>>is encrypted with a private key. All of these happens in the bowels
of
>> >API
>> >>>functions. I could not spot any CryptEncrypt call with a private key.
>> If
>> >>>you help me you will sava a life.
>> >>
>> >
>>
>
>

i wish it were as simple as you point out!! first, if you can sign an object
using a key that has the name of a company i trust, then i need to trust
the issuer also. of course, if i can get you to trust my root then that's
just the start of your problem. while the pgp model seems elegant in this
instance, it simply doesn't scale.

"Eli Allen" <eallen@bcpl.net> wrote:
>Thats why I like the PGP method of verfying a public key. The way a cert
>works you have to completly trust one issuer and assume the issuer issued
it
>correctly. So if I registered for one that looked like another company's
>cert fooling a person then I just got around the security.
>
>But with the PGP method its more a web of trust and not a tree. So the
>public key should have many more signers which make the verification more
>secure. For example if I was an admin of a company I could sign MS's public
>key so all the employee's would know they could trust it because I signed
>it.
>
>Another example has more to do with e-mail. Say I got an e-mail with a
>certificate signing it from Personal Freemail. How does it prove anything
>about the message? Sure it shows that the message wasn't changed from the
>time it was signed but it proves very little else. Someone could have just
>filled out the form on the web site with another person's name making it
>easy for me to assume the identy of someone else for sending a message.
But
>with PGP their public key could be signed by others so it would take much
>more of an effort to create a false key.
>
>(I'm just using PGP here as an example of that type of key signing and not
>PGP itself)
>--
>Eli Allen
>eallen@bcpl.net
>
>"Michael Howard" <mikehow@microsoft.com> wrote in message
>news:3a5f57a9$1@news.dev-archive.com...
>> >>Re: You may not need a cert if you force the public key to be verified
>> by getting it off the web server. But then you still have the man in
the
>> middle attack.
>>
>> Exactly, that's why you use a cert - because the public key in the cert
>can
>> be verified, assuming you trust the issuer.
>>
>
>

>Thanks for your kind replies. Instead of encrypting I will just sign the
>data and get it encrypted with a session key. I can use CryptSignAndEncryptMessage
>API for it . I think it will do.

another thing you can do is use an hmac rather than a signature. if all you
need to do is determine that two or more parties could have created the data,
and the data is not long lived (ie; persisted to disk forever) then an hmac
may be a good solution. SSL/TLS uses hmac's not digsigs. you can use CALG_HMAC
with cryptoapi to create a has like this: H( K XOR OuterString, H( K XOR
InnerString, text ))

http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/crypto/aboutcrypto_79cz.htm
has more info.