Hi,

Based on both your statements and your questions, I believe you might
want to rethink your approach to the problem you're trying to solve.

> I have a doubt concerning the way that PKI encryption is handling
> PKCS#7.
>
For background, make sure you're clear on the distinction between
"Public Key Cryptography" and "Public Key Infrastructure." Public key
cryptography is the math that lets you have one key that you can make
public and one that you keep private, and use that keypair to sign and
encrypt data. Even that sentence is a gross oversimplification. For
example, when I say that I encrypt a message using your public key, I
don't usually mean that at all. For most messages and public key
algorithms, that would certainly be inefficient and hard to do
securely. A still-simplified explanation of what I really mean is that
I generate key material for some symmetric algorithm and use that to
encrypt the message. I then use your public key to encrypt the (small)
symmetric key I just used to encrypt the data. I transmit the
encrypted symmetric key along with the encrypted message to you. In
order to retrieve the plaintext message, you must first decrypt the
key I used to encrypt the message, then decrypt the message using
that. An analogous but different relationship exists between keypairs
and message digest algorithms when you use them for digital
signatures.

To understand the theory behind all this, the best free resource I can
think of is the Handbook of Applied Cryptography:
http://www.cacr.math.uwaterloo.ca/hac/

Roughly, Public Key Infrastructure (PKI) is a collection of protocols,
formats and algorithms you use to associate key(pairs) with entities.
It gives us ways to answer questions like "I want to encrypt a message
for [email protected]. What keypair should I use?" "I want to send
my creditcard information to a server claiming to be www.amazon.com.
Does the public key sent to me by 207.171.166.252 really belong to
amazon?" "This key signed a message ordering me to spend $1M of my
company's money. Does it belong to someone who's authorized to do so?"

crypto++ implements the low level cryptographic operations that are
necessary to use this infrastructure and make it work, but there's a
lot more to the infrastructure than just the cryptography. Most of it
is outside the scope of what crypto++ attempts to address


> What I am doing in cryptopp is simply
>
> StringSource pubFile(public_key, true, new Base64Decoder);
>        RSAES_PKCS1v15_Encryptor pub(pubFile);
>
>        RandomPool randPool;
>        randPool.IncorporateEntropy((byte *)"123", strlen("123"));
>
>        StringSource(message, true, new PK_EncryptorFilter(randPool,
> pub, new HexEncoder(new StringSink(ciphertext))));
>
> and decoding is simply the inverse...

That's not very similar to what Chilkat is doing :-). The "PKCS#7
blob" includes information telling you which public key was used to
encrypt the symmetric key, what algorithm was used for symmetric
encryption, what parameters you might need for that, etc. So at a high
level, you need to parse the message, figure out which keypair you
need to use to decrypt the symmetric key, figure out what the
symmetric algorithm is, use the decrypted symmetric key and parameters
to instantiate an appropriate crypto++ object, and use that to decrypt
your message.

> For instance, in here I don't even say what's the size of the key.
> Does cryptopp infers it?
>
The public key you read from the file is actually a DER-encoded
PublicKeyInfo structure. It has that information.


> 1. Where do I fit PKCS#7 in here?
>
PKCS#7 is a large and very flexible (and therefore rather complex)
standard defining a set of message formats. The original standard
published by RSA can be found here:

http://www.rsa.com/rsalabs/node.asp?id=2129

That's currently maintained in the IETF and has been refined in RFC 5652:

http://tools.ietf.org/html/rfc5652

The CMS provides a format for conveying the other bits of information
you need to have in order to make decryption and verification work
securely :-). It's a lot of work to implement it and get it right,
though. While crypto++ provides all the crypto you need to implement
CMS, you've got a lot left to do (depending on what you need to
interoperate with). Unless you've got some overriding special
consideration, it's probably worthwhile to look at the various
libraries that implement it. Whichever path you go down, though, start
with EnvelopedData and KeyTransRecipientInfo structure if you're
trafficking in messages encrypted for recipients with RSA keys.

> 2. What is the difference between encrypting/decrypting with a
> certificate or just setting the public/privet keys from a string?
>
A certificate associates a key with some entity (maybe an individual,
a server, etc.). Generally, you're encrypting something because you
want to be sure it's kept secret, so you want to take care that only
the intended recipient can decrypt it. With a certificate, there's
standardized infrastructure for deciding whether you should trust the
key-to-identity binding asserted in the certificate. Look at RFC 5280
to see the algorithm you should use to validate a certificate:

http://tools.ietf.org/html/rfc5280

If you've just got a bare public key, then presumably you've already
performed this validation (maybe in some other way). The crypto's the
same. The certificate is extra data to help you make sure you're using
the crypto the way you intend to.

Sorry for the overly long message (and the pointers to much longer
reading...) but I hope it helps you get pointed in the right
direction.

Good luck,

Geoff

-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.

Reply via email to