Problem - Kevin Tafuro

solution to this problem is to concatenate the recipient’s public key with the message,
and sign that. The recipient can then easily determine that he or she was indeed
the intended recipient.
One issue with this solution is how to represent the public key. The important thing
is to be consistent. If your public keys are stored as X.509 certificates (see Chapter 10
for more on these), you can include the entire certificate when you sign. Otherwise,
you can simply represent the public modulus and exponent as a single binary string
(the DER-encoding of the X.509 certificate) and include that string when you sign.
The other issue is that RSA operations such as encryption tend to work on small
messages. A digital signature of a message will often be too large to encrypt using
public key encryption. Plus, you will need to encrypt your actual message as well!
One way to solve this problem is to perform multiple public key encryptions. For
example, let’s say you have a 2,048-bit modulus, and the recipient has a 1,024-bit
modulus. You will be encrypting a 16-byte secret and your signature, where that signature
will be 256 bytes, for a total of 272 bytes. The output of encryption to the
1,024-bit modulus is 128 bytes, but the input can only be 86 bytes, because of the
need for padding. Therefore, we’d need four encryption operations to encrypt the
entire 272 bytes.
In many client-server architectures where the client initiates a connection,
the client won’t have the server’s public key in advance. In such a
case, the server will often send a copy of its public key at its first
opportunity (or a digital certificate containing the public key). In this
case, the client can’t assume that public key is valid; there’s nothing to
distinguish it from an attacker’s public key! Therefore, the key needs
to be validated using a trusted third party before the client trusts that
the party on the other end is really the intended server. See Recipe 7.1.
Here is an example of generating, signing, and encrypting a 16-byte secret in a secure
manner using OpenSSL, given a private key for signing and a public key for the recipient.
The secret is placed in the buffer pointed to by the final argument, which must
be 16 bytes. The encrypted result is placed in the third argument, which must be big
enough to hold the modulus for the public key.
Note that we represent the public key of the recipient as the binary representation of
the modulus concatenated with the binary representation of the exponent. If you are
using any sort of high-level key storage format such as an X.509 certificate, it makes
sense to use the canonical representation of that format instead. See Recipes 7.16
and 7.17 for information on converting common formats to a binary string.
#include
#include
#include
#include
#include
344 | Chapter 7: Public Key Cryptography
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.