Re: Microsoft's CryptoAPI - thoughts?
James A. Donald writes:
A notable misfeature of the API is that it assumes that in general you will have two key pairs. One for signing and one for encrypting.
Since in the most common case you are encrypting something related to a signed message by the person you are encrypting to, this is a bad idea,
At 07:59 AM 1/27/96 -0500, Futplex wrote:
Could you elaborate ? I haven't heard of any known interaction effects between a strong encryption algorithm and a distinct strong digital signature algorithm (with or without distinct keys),
I was concerned about a different issue: Suppose you have some signed information: You wish to send some encrypted information to the person who wrote that signed information. If the signing key and the encrypting key are the same, your software can locally ensure that you encrypt with the right key, (The correct key is the same public key that you used to check the signature on the message.) If the signing key and the encrypting key are different, then in order to ensure that you are not spoofed into using the wrong public key, the whole protocol must work correctly, exposing many more points of attack, since key management is the most complex and most vulnerable area. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd@echeque.com
-----BEGIN PGP SIGNED MESSAGE----- James Donald writes:
I was concerned about a different issue:
Suppose you have some signed information: You wish to send some encrypted information to the person who wrote that signed information.
If the signing key and the encrypting key are the same, your software can locally ensure that you encrypt with the right key, (The correct key is the same public key that you used to check the signature on the message.)
If the signing key and the encrypting key are different, then in order to ensure that you are not spoofed into using the wrong public key, the whole protocol must work correctly, exposing many more points of attack, since key management is the most complex and most vulnerable area.
OK, I think I understand the concern. I was assuming a model where the signing and encrypting keys are bound together in a certificate in some fashion. Presumably the encrypting key is signed by the signing key. The certificates are distributed & managed according to some protocols and policies that are orthogonal to the number of keys in a single certificate. Things get slightly more complicated if you want to update the encrypting and signing keys independently of each other. But offhand I don't see any new thorny issues arising. Disclaimer: I haven't read enough of the MSCAPI to have any idea how it proposes to handle the purpose-specific keys. Futplex <futplex@pseudonym.com> GO COWBOYS! -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMQv1IynaAKQPVHDZAQFawwf7BySS8rC/uugXjOtgBM/GU4VlQfdXSk9p XjaGP1fJiBeFxwtiJe26MqoPmqSNrvV3Bf/iVawUiB1mU+NQgcX6mf6kf7P05c2c JMsYzFaT468VDC7/uv2pc8NT0u70bbWW8lrSqmyFGBVvMnYDmHXN7XWywdMuB3mk BIG+zrcfFRVlrHkIGvz3Xzuaog3SVRCUxujozxw1vciY4EgRN2vvizuecNAa4R0j //vVNOiEAAPqAb/ZEG29Fc/LR7ecjcIihNA+pB/Dn9e5yyuX1H6yy4HNRn0RGaSx /lDIsLXYI3KsMWuiYENaR5aNcXzn68aM7IxOCEHjp59kLEAy8KxbJQ== =o0QD -----END PGP SIGNATURE-----
participants (2)
-
futplexï¼ pseudonym.com -
James A. Donald