Advanced SSL Topics - Implementing SSL/TLS Using Cryptography and PKI - page 454

block type is slightly different; rather than padding with random bytes, the
padding section contains all 1's.
Why is this? Well, imagine that the same RSA key was used to decrypt private
data as well as to sign messages. To keep the example small and simple, use
small values — the mini-key pair e = 79, d = 1019, and n = 3337 from Chapter
3 works nicely. Now, let's say you encrypted your secret number, 42, using the
public key e and n , which works out to 2,973. So far, so good; an eavesdropper
without access to d can't recover your secret number 42. All he saw was 2,973,
which is useless to him.
However, he can trick the private key holder into revealing it. He can ask the
private key holder to please sign his credit card number, which happens to be
2,973. Now, the private key holder computes 2973 d % n, which is your secret
number 42. Oops.
To guard against this, PKCS #1 mandates that signatures and encryptions
be padded differently. It's the responsibility of the signer to add this padding
before signing anything.
It's easy to refactor the rsa_encrypt routing from Listing 3-17 to support
signing and encrypting correctly. Extract everything except the padding into a
separate routing called rsa_process that takes a block_type as an argument,
and call it from rsa_encrypt and rsa_sign as shown in Listing 8-31.
Listing 8-31: “rsa.c” rsa_encrypt and rsa_sign
int rsa_ process ( unsigned char *input,
unsigned int len,
unsigned char **output,
rsa_key *public_key ,
unsigned char block_type )
{
…
memcpy( padded_block + ( modulus_length - block_size ), input, block_size );
// set block type
padded_block[ 1 ] = block_type ;
for ( i = 2; i < ( modulus_length - block_size - 1 ); i++ )
{
if ( block_type == 0x02 )
{
// TODO make these random
padded_block[ i ] = i;
}
else
{
padded_block[ i ] = 0xFF;
}
}