Problem - Kevin Tafuro

compute d. Without those two primes, it’s believed that the most practical way to
decrypt messages is by factoring n to get p and q.
RSA is mathematically simple and elegant. Unfortunately, a straightforward implementation
of RSA based directly on the math will usually fall prey to a number of
attacks. RSA itself is secure, but only if it is deployed correctly, and that can be quite
a challenge. Therefore, if you’re going to use RSA (and not something high-level), we
strongly recommend sticking to preexisting standards. In particular, you should use
a preexisting API or, at the very worst, follow PKCS#1 recommendations for deployment.
It’s important to note that using RSA properly is predicated on your
having received a known-to-be-valid public key over a secure channel
(otherwise, man-in-the-middle attacks are possible; see Recipe 7.1 for
a discussion of this problem). Generally, secure public key distribution
is done with a PKI (see Recipe 10.1 for an introduction to PKI).
From the average API’s point of view, RSA encryption is similar to standard symmetric
encryption, except that there are practical limitations imposed on RSA mainly due
to the fact that RSA is brutally slow compared to symmetric encryption. As a result,
many libraries have two APIs for RSA encryption: one performs “raw” RSA encryption,
and the other uses RSA to encrypt a temporary key, then uses that temporary
key to encrypt the data you actually wanted to encrypt. Such an interface is sometimes
called an enveloping interface.
As with symmetric encryption, you need to pass in relevant key material, the input
buffer, and the output buffer. There will be a length associated with the input buffer,
but you are probably expected to know the size of the output in advance. With
OpenSSL, if you have a pointer to an RSA object x, you can call RSA_size(x) to determine
the output size of an RSA encryption, measured in bytes.
When performing raw RSA encryption, you should expect there to be a small maximum
message length. Generally, the maximum message length is dependent on the
type of padding that you’re using.
While RSA is believed to be secure if used properly, it is very easy not
to use properly. Secure padding schemes are an incredibly important
part of securely deploying RSA. Note that there’s no good reason to
invent your own padding format (you strongly risk messing something
up, too). Instead, we recommend EME-OAEP padding (specified
in PKCS #1 v2.0 or later).
There are primarily two types of padding: PKCS #1 v1.5 padding and EME-OAEP
padding. The latter is specified in Version 2.0 and later of PKCS #1, and is recommended
for all new applications. Use PKCS #1 v1.5 padding only for legacy systems.
Do not mix padding types in a single application.
Performing Raw Encryption with an RSA Public Key | 333
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.