Re: CryptoAPI and private key /not public/ encryption with CryptEncrypt - can not use CryptHash* functions

From: Valery Pryamikov (Valery_at_nospam.harper.no)
Date: 12/29/04

  • Next message: Michel Gallant: "Re: CAPICOM and ASP.NET" 
    Date: Wed, 29 Dec 2004 19:08:20 +0100

    "Alun Jones [MSFT]" <alunj@online.microsoft.com> wrote in message
    news:OLJMTfc7EHA.3504@TK2MSFTNGP12.phx.gbl...
    > "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.

    Even so original poster has no good reason for asking that question, however
    it could be many good reasons for that, varying from support of some
    standards (including standard from European committee for banking standard
    or joint standards by euro card, MasterCard and visa - see EMVCv4 signature
    spec for example + many, many more).

    Using strong hash in RSA signature scheme is preferable because in random
    oracle mode it allows non-tight reduction to RSA solution problem with
    regard to chosen message attack by an existential forger. But

    - tight reduction could be only achieved only with further modification of
    RSA signature (as in Katz-Wang signature).

    - replacing random oracle with any (even by strong collision resistant hash
    function like SHA1) invalidates security prove.

    - adding hash in case of sufficient message redundancy means inevitable
    message expansion.

    - makes more difficult to switching to different message integrity schemes,
    f.e. appending division remainder on primitive polynomial in Galois filed
    (like in GCM mode of operation);

    - makes more difficult to switch to different hashing schemes in cases of
    discovering weaknesses in existing hash schemes (ex. Crypto-2004 conference,
    Wang/Feng/Lay/Yu work on collisions in MD4/MD5/RIPEMD).

    - more.

    -Valery.
    http://www.harper.no/valery

  • Next message: Michel Gallant: "Re: CAPICOM and ASP.NET"

    Relevant Pages

    • Re: rsa implementation question
      ... > There is a notion of blocks in many public-key ciphers, ... It's not about decrypting to sign, encrypting to ... as it would mean that you'd have to find hash collisions. ... I generate a signature for a string "some string" with SHA. ...
      (comp.lang.python)
    • Re: Curve25519-based EC-KCDSA
      ... signing just the hash of the message, using a standard hash function. ... those signature schemes aren't widely used. ... If the attacker aims at forgery, then an API accepting the hash doesn't ...
      (sci.crypt)
    • Re: Reverse usage of public/private RSA encryption keys for licensing?
      ... However I would not transfer the hash twice (once ... Use VerifyData to verify signature using your data. ... I generate a RSA private and public key via: ... >>>> encrypting the hash bytes? ...
      (microsoft.public.dotnet.security)
    • Re: Reverse usage of public/private RSA encryption keys for licensing?
      ... However I would not transfer the hash twice (once ... Use VerifyData to verify signature using your data. ... I generate a RSA private and public key via: ... >>>> encrypting the hash bytes? ...
      (microsoft.public.dotnet.framework)
    • Re: what happened to hash-tables
      ... >> You already need hashtables anyway internally for implementing Common ... Many of the people on the committee had much more experience ... The ANSI standard is about memorializing the "Common" practice ... Suppose that the winning extensible hash table protocol is based ...
      (comp.lang.lisp)
    • Quantcast