Re: CryptoAPI and private key /not public/ encryption with CryptEncrypt - can not use CryptHash* functions
From: Alun Jones [MSFT] (alunj_at_online.microsoft.com)
Date: 12/29/04
- Previous message: Valery Pryamikov: "Ann: New version of RunAsAdmin"
- In reply to: Valery Pryamikov: "Re: CryptoAPI and private key /not public/ encryption with CryptEncrypt - can not use CryptHash* functions"
- Next in thread: Valery Pryamikov: "Re: CryptoAPI and private key /not public/ encryption with CryptEncrypt - can not use CryptHash* functions"
- Reply: Valery Pryamikov: "Re: CryptoAPI and private key /not public/ encryption with CryptEncrypt - can not use CryptHash* functions"
- Reply: Przemek Wasylko: "Re: CryptoAPI and private key /not public/ encryption with CryptEncrypt - can not use CryptHash* functions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 29 Dec 2004 08:50:25 -0800
"Valery Pryamikov" <Valery@nospam.harper.no> wrote in message
news:%23$V9kzb7EHA.3376@TK2MSFTNGP12.phx.gbl...
>> decrypting with public key. I guess by that it is not possible with
>> cryptoapi ?
> It is possible with CAPI, but not possible with any of standard Microsoft
> cryptography providers (not current version at least). But nothing stops
> you from developing your own cryptography provider, signing it (by
> Microsoft) and using it from your programs.
>
> BTW: This question is probably one of the most often asked in this and
> microsoft.public.security.crypto groups. If you just search google
> groups - you'll find a lots of answers to it (with at least dozen of
> related threads during last couple of months).
I would guess that the most frequent answer would be "why would you do
that?"
Encrypting with the private key is equivalent to signing. The document
produced can be decrypted by anyone with access to your public key (and
since it /is/ your public key, that equates to "anyone"), and the only
benefit of the encryption is to indicate that only the owner of the private
key could have produced the encrypted document. That can be achieved better
with signing the document. If your document is shorter than the hash that's
used in the signature process, encrypting it results in the likelihood that
you will include some entropy that allows for attack on your key; if your
document is longer than the hash, you're spending a lot of time to encrypt
the document, and asking the recipient to spend a lot of time decrypting the
document.
If there is a reason to encrypt the whole document with a private key,
rather than simply using the more common routines for signing a document,
I'd be interested to hear it.
Alun.
~~~~
-- Software Design Engineer, Internet Information Server (FTP) This posting is provided "AS IS" with no warranties, and confers no rights.
- Previous message: Valery Pryamikov: "Ann: New version of RunAsAdmin"
- In reply to: Valery Pryamikov: "Re: CryptoAPI and private key /not public/ encryption with CryptEncrypt - can not use CryptHash* functions"
- Next in thread: Valery Pryamikov: "Re: CryptoAPI and private key /not public/ encryption with CryptEncrypt - can not use CryptHash* functions"
- Reply: Valery Pryamikov: "Re: CryptoAPI and private key /not public/ encryption with CryptEncrypt - can not use CryptHash* functions"
- Reply: Przemek Wasylko: "Re: CryptoAPI and private key /not public/ encryption with CryptEncrypt - can not use CryptHash* functions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|