Three Types of Encryption

Different software products operate with encryption in different ways. Three basic types
of encryption may be considered: manual, semi-transparent and transparent.

Manual encryption is completely provided by the user (via the relevant software, of
course): he has to manually select the objects for encryption (usually files or folders) and
then run some special command/ menu item to encrypt or decrypt these objects. Thus,
manual encryption systems demand the user's active participation, and he must strictly
remember to encrypt his private data before he leaves this data outside of his personal
control. This is risky from a security point of view - risking human error (forgetfulness).
Nevertheless, manual (file) encryption, from a technical point of view, has a potential
advantage: it can operate easily and reliably - more reliably than any other type of
encryption software.

Transparent encryption is almost a complete contrast to Manual encryption. In this case,

decryption/ encryption is performed at a low level, permanently, during ALL read/write
operations, so that encrypted data of any type (including executable programs) is always
stored on the disk in encrypted form. The theft or loss of a notebook/ disk/ floppy disk, a
sudden power/ software/ hardware failure/ breakdown does not threaten loss of data - it is
always stored on the transparently encrypted volumes in encrypted form. From the point
of general security principles, complete low-level transparent encryption is the most
secure type imaginable, being easiest - imperceptible - for the user to manage, but it has a
couple of disadvantages: it can't be "mobile" - i.e. can not transport encrypted data from
computer to computer, (except via encrypted diskettes); it is very difficult to implement
(engineer) correctly; and it generally doesn't fit into system architectures based on multi-
user sharing of resources, as in networks. Nevertheless, when properly engineered, it is
unbeatable for the protection of data on local work stations and stand-alone or mobile
(laptop) machines.

Semi-Transparent, or "On-the-fly", encryption operates not permanently, but before/after

access is made to confidential objects or during some read/write operations. The most
widespread example is ciphering during Copy/Move to a "secret" volume/folder;
deciphering a file before opening it via standard Windows applications (Word, Excel, etc)
and enciphering it after the application is finished; and deciphering specified folders/files
at startup of the computer and enciphering them again at shutdown. Semi-Transparent
encryption graduates from manual/file encryption. The typical great weakness of many of
these encryption products is that they can cause degradation of the computer systems
efficiency and a sudden/ emergency loss of data when the amounts to be encrypted are
too great. The problem of developers is to find an optimal trade off between simplicity,
security, effectiveness and reliability, and most developers get into a mess here. By the
way, the semi-transparent features of F-Cryprite are based not on any doubtful
programming tricks, but on the encryption speed of the SVC algorithm (which is
essentially higher than any "open" operation in Windows): thus F-Cryprite's efficiency is
absolutely uninfluenced by the total amount of data to be encrypted!
D-Cryprite produces completely Transparent encryption. F-Cryprite and C-Subway
operate between Manual and Semi-transparent encryption (i.e. have features of both).
Introduction

Often there has been a need to protect information from 'prying eyes'. In the electronic
age, information that could otherwise benefit or educate a group or individual can also be
used against such groups or individuals. Industrial espionage among highly competitive
businesses often requires that extensive security measures be put into place. And, those
who wish to exercise their personal freedom, outside of the oppressive nature of
governments, may also wish to encrypt certain information to avoid suffering the
penalties of going against the wishes of those who attempt to control.

Still, the methods of data encryption and decryption are relatively straightforward, and
easily mastered. I have been doing data encryption since my college days, when I used an
encryption algorithm to store game programs and system information files on the
university mini-computer, safe from 'prying eyes'. These were files that raised eyebrows
amongst those who did not approve of such things, but were harmless [we were always
careful NOT to run our games while people were trying to get work done on the
machine]. I was occasionally asked what this "rather large file" contained, and I once
demonstrated the program that accessed it, but you needed a password to get to 'certain
files' nonetheless. And, some files needed a separate encryption program to decipher
them.

Fortunately, my efforts back then have paid off now, in the business world. I became
rather good at keeping information away from 'prying eyes', by making it very difficult to
decipher. Our S.F.T. Setup Gizmo application has an encrypted 'authorization code'
scheme, allowing companies to evaluate a fully-featured version of the actual software
before purchasing it, and (when licensed) a similar scheme authorizes a maximum
number of users based on the license purchased by the customer. Each of these features
requires some type of encrypted data to ensure that the 'lockout' works correctly, and
cannot be bypassed, protecting both our interests and preserving the 'full-featured demo'
capability for our customers.

Methods of Encrypting Data

Traditionally, several methods can be used to encrypt data streams, all of which can easily
be implemented through software, but not so easily decrypted when either the original or
its encrypted data stream are unavailable. (When both source and encrypted data are
available, code-breaking becomes much simpler, though it is not necessarily easy). The
best encryption methods have little effect on system performance, and may contain other
benefits (such as data compression) built in. The well-known 'PKZIP®' utility offers both
compression AND data encryption in this manner. Also DBMS packages have often
included some kind of encryption scheme so that a standard 'file copy' cannot be used to
read sensitive information that might otherwise require some kind of password to access.
They also need 'high performance' methods to encode and decode the data.

Fortunately, the simplest of all of the methods, the 'translation table', meets this need very
well. Each 'chunk' of data (usually 1 byte) is used as an offset within a 'translation table',
and the resulting 'translated' value from within the table is then written into the output
stream. The encryption and decryption programs would each use a table that translates to
and from the encrypted data. In fact, the 80x86 CPU's even have an instruction 'XLAT'
that lends itself to this purpose at the hardware level. While this method is very simple
and fast, the down side is that once the translation table is known, the code is broken.
Further, such a method is relatively straightforward for code breakers to decipher - such
code methods have been used for years, even before the advent of the computer. Still, for
general "unreadability" of encoded data, without adverse effects on performance, the
'translation table' method lends itself well.

A modification to the 'translation table' uses 2 or more tables, based on the position of the
bytes within the data stream, or on the data stream itself. Decoding becomes more
complex, since you have to reverse the same process reliably. But, by the use of more
than one translation table, especially when implemented in a 'pseudo-random' order, this
adaptation makes code breaking relatively difficult. An example of this method might use
translation table 'A' on all of the 'even' bytes, and translation table 'B' on all of the 'odd'
bytes. Unless a potential code breaker knows that there are exactly 2 tables, even with
both source and encrypted data available the deciphering process is relatively difficult.

Similar to using a translation table, 'data repositioning' lends itself to use by a computer,
but takes considerably more time to accomplish. A buffer of data is read from the input,
then the order of the bytes (or other 'chunk' size) is rearranged, and written 'out of order'.
The decryption program then reads this back in, and puts them back 'in order'. Often such
a method is best used in combination with one or more of the other encryption methods
mentioned here, making it even more difficult for code breakers to determine how to
decipher your encrypted data. As an example, consider an anagram. The letters are all
there, but the order has been changed. Some anagrams are easier than others to decipher,
but a well written anagram is a brain teaser nonetheless, especially if it's intentionally
misleading.

My favorite methods, however, involve something that only computers can do: word/byte
rotation and XOR bit masking. If you rotate the words or bytes within a data stream,
using multiple and variable direction and duration of rotation, in an easily reproducable
pattern, you can quickly encode a stream of data with a method that is nearly impossible
to break. Further, if you use an 'XOR mask' in combination with this ('flipping' the bits in
certain positions from 1 to 0, or 0 to 1) you end up making the code breaking process
even more difficult. The best combination would also use 'pseudo random' effects, the
easiest of which would involve a simple sequence like Fibbonaci numbers. The sequence
'1,1,2,3,5,...' is easily generated by adding the previous 2 numbers in the sequence to get
the next. Doing modular arithmetic on the result (i.e. Fib. sequence mod 3 to get rotation
factor) and operating on multiple byte sequences (using a prime number of bytes for
rotation is usually a good guideline) will make the code breaker's job even more difficult,
adding the 'pseudo-random' effect that is easily reproduced by your decryption program.

In some cases, you may want to detect whether data has been tampered with, and encrypt
some kind of 'checksum' into the data stream itself. This is useful not only for
authorization codes but for programs themselves. A virus that infects such a 'protected'
program would no doubt neglect the encryption algorithm and authorization/checksum
signature. The program could then check itself each time it loads, and thus detect the
presence of file corruption. Naturally, such a method would have to be kept VERY secret,
as virus programmers represent the worst of the code breakers: those who willfully use
information to do damage to others. As such, the use of encryption is mandatory for any
decent anti-virus protection scheme.

A cyclic redundancy check is one typically used checksum method. It uses bit rotation
and an XOR mask to generate a 16-bit or 32-bit value for a data stream, such that one
missing bit or 2 interchanged bits are more or less guaranteed to cause a 'checksum error'.
This method has been used for file transfers for a long time, such as with XMODEM-
CRC. The method is somewhat well documented, and standard. But, a deviation from the
standard CRC method might be useful for the purpose of detecting a problem in an
encrypted data stream, or within a program file that checks itself for viruses.

Key-Based Encryption Algorithms

One very important feature of a good encryption scheme is the ability to specify a 'key' or
'password' of some kind, and have the encryption method alter itself such that each 'key'
or 'password' produces a different encrypted output, which requires a unique 'key' or
'password' to decrypt. This can either be a 'symmetrical' key (both encrypt and decrypt
use the same key) or 'asymmetrical' (encrypt and decrypt keys are different). The popular
'PGP' public key encryption, and the 'RSA' encryption that it's based on, uses an
'asymmetrical' key. The encryption key, the 'public key', is significantly different from the
decryption key, the 'private key', such that attempting to derive the private key from the
public key involves many many hours of computing time, making it impractical at best.

There are few operations in mathematics that are truly 'irreversible'. In nearly all cases, if
an operation is performed on 'a', resulting in 'b', you can perform an equivalent operation
on 'b' to get 'a'. In some cases you may get the absolute value (such as a square root), or
the operation may be undefined (such as dividing by zero). However, in the case of
'undefined' operations, it may be possible to base a key on an algorithm such that an
operation like division by zero would PREVENT a public key from being translated into
a private key. As such, only 'trial and error' would remain, which would require a
significant amount of processing time to create the private key from the public key.

In the case of the RSA encryption algorithm, it uses very large prime numbers to generate
the public key and the private key. Although it would be possible to factor out the public
key to get the private key (a trivial matter once the 2 prime factors are known), the
numbers are so large as to make it very impractical to do so. The encryption algorithm
itself is ALSO very slow, which makes it impractical to use RSA to encrypt large data
sets. What PGP does (and most other RSA-based encryption schemes do) is encrypt a
symmetrical key using the public key, then the remainder of the data is encrypted with a
faster algorithm using the symmetrical key. The symmetrical itself key is randomly
generated, so that the only way to get it would be by using the private key to decrypt the
RSA-encrypted symmetrical key.

Example: Suppose you want to encrypt data (let's say this web page) with a key of
12345. Using your public key, you RSA-encrypt the 12345, and put that at the front of
the data stream (possibly followed by a marker or preceded by a data length to
distinguish it from the rest of the data). THEN, you follow the 'encrypted key' data with
the encrypted web page text, encrypted using your favorite method and the key '12345'.
Upon receipt, the decrypt program looks for (and finds) the encrypted key, uses the
'private key' to decrypt it, and gets back the '12345'. It then locates the beginning of the
encrypted data stream, and applies the key '12345' to decrypt the data. The result: a very
well protected data stream that is reliably and efficiently encrypted, transmitted, and
decrypted.

Source files for a simple RSA-based encryption algorithm can be found HERE:
ftp://ftp.funet.fi/pub/crypt/cryptography/asymmetric/rsa

It is somewhat difficult to write a front-end to get this code to work (I have done so
myself), but for the sake of illustration, the method actually DOES work and by studying
the code you can understand the processes involved in RSA encryption. RSA,
incidentally, is reportedly patented through the year 2000, and may be extended beyond
that, so commercial use of RSA requires royalty payments to the patent holder
(www.rsa.com). But studying the methods and experimenting with it is free, and with
source code being published in print (PGP) and outside the U.S., it's a good way to learn
how it works, and maybe to help you write a better algorithm yourself.

A brand new 'multi-phase' method (invented by ME)

I have (somewhat) recently developed and tested an encryption method that is (in my
opinion) nearly uncrackable. The reasons why will be pretty obvious when you take a
look at the method itself. I shall explain it in prose, primarily to avoid any chance of
prosecution by those 'GUMMINT' authorities who think that they oughta be able to snoop
on anyone they wish, having a 'back door' to any encryption scheme, etc. etc. etc.. Well, if
I make the METHOD public, they should have the same chance as ANYONE ELSE for
decrypting things that use this method.
(Subsequent note: according to THIS web site, it could be described as an asynchronous
stream cipher with a symmetrical key)
So, here goes (description of method first made public on June 1, 1998):

• Using a set of numbers (let's say a 128-bit key, or 256-bit key if you use 64-bit
integers), generate a repeatable but highly randomized pseudo-random number
sequence (see below for an example of a pseudo-random number generator).
• 256 entries at a time, use the random number sequence to generate arrays of
"cipher translation tables" as follows:
o fill an array of integers with 256 random numbers (see below)
 o sort the numbers using a method (like pointers) that lets you know the
original position of the corresponding number
o using the original positions of the now-sorted integers, generate a table of
randomly sorted numbers between 0 and 255. If you can't figure out how
to make this work, you could give up now... but on a kinder note, I've
supplied some source below to show how this might be done - generically,
of course.
• Now, generate a specific number of 256-byte tables. Let the random number
generator continue "in sequence" for all of these tables, so that each table is
different.
• Next, use a "shotgun technique" to generate "de-crypt" cipher tables. Basically, if
a maps to b, then b must map to a. So, b[a[n]] = n. get it? ('n' is a value between 0
and 255). Assign these values in a loop, with a set of 256-byte 'decrypt' tables that
correspond to the 256-byte 'encrypt' tables you generated in the preceding step.

NOTE: I first tried this on a P5 133Mhz machine, and it took 1 second to generate
the 2 256x256 tables (128kb total). With this method, I inserted additional
randomized 'table order', so that the order in which I created the 256-byte tables
were part of a 2nd pseudo-random sequence, fed by 2 additional 16-bit keys.

• Now that you have the translation tables, the basic cipher works like this: the
previous byte's encrypted value is the index of the 256-byte translation table.
Alternately, for improved encryption, you can use more than one byte, and either
use a 'checksum' or a CRC algorithm to generate the index byte. You can then
'mod' it with the # of tables if you use less than 256 256-byte tables. Assuming the
table is a 256x256 array, it would look like this:

crypto1 = a[crypto0][value]

where 'crypto1' is the encrypted byte, and 'crypto0' is the previous byte's
encrypted value (or a function of several previous values). Naturally, the 1st byte
will need a "seed", which must be known. This may increase the total cipher size
by an additional 8 bits if you use 256x256 tables. Or, you can use the key you
generated the random list with, perhaps taking the CRC of it, or using it as a "lead
in" encrypted byte stream. Incidentally, I have tested this method using 16
'preceding' bytes to generate the table index, starting with the 128-bit key as the
initial seed of '16 previous bytes'. I was then able to encrypt about 100kbytes per
second with this algorithm, after the initial time delay in creating the table.
• On the decrypt, you do the same thing. Just make sure you use 'encrypted' values
as your table index both times. Or, use 'decrypted' values if you'd rather. They
must, of course, match.

The pseudo-random sequence can be designed by YOU to be ANYTHING that YOU

want. Without details on the sequence, the cipher key itself is worthless. PLUS, a block
of 'e' ascii characters will translate into random garbage, each byte depending upon the
encrypted value of the preceding byte (which is why I use the ENCRYPTED value, not
the actual value, as the table index). You'll get a random set of permutations for any
single character, permuations that are of random length, that effectively hide the true size
of the cipher.

However, if you're at a loss for a random sequence consider a FIBBONACCI sequence,

using 2 DWORD's (like from your encryption key) as "seed" numbers, and possibly a 3rd
DWORD as an 'XOR' mask. An algorithm for generating a random sequence of numbers,
not necessarily connected with
This article is about an algorithm for public-key encryption. For the U.S. encryption and
network security company, see RSA Security. For the Republic of South Africa, see
South Africa. For other uses, see RSA (disambiguation).

In cryptography, RSA is an algorithm for public-key cryptography. It is the first

algorithm known to be suitable for signing as well as encryption, and one of the first
great advances in public key cryptography. RSA is widely used in electronic commerce
protocols, and is believed to be secure given sufficiently long keys and the use of up-to-
date implementations.

Contents
[hide]

• 1 History
• 2 Operation
o 2.1 Key generation
o 2.2 Encryption
o 2.3 Decryption
o 2.4 A working example
o 2.5 Padding schemes
o 2.6 Signing messages
• 3 Security and practical considerations
o 3.1 Integer factorization and RSA problem
o 3.2 Key generation
o 3.3 Speed
o 3.4 Key distribution
o 3.5 Timing attacks
o 3.6 Adaptive chosen ciphertext attacks
o 3.7 Branch prediction analysis attacks
• 4 See also
• 5 Notes
• 6 References

• 7 External links

History
The algorithm was publicly described in 1977 by Ron Rivest, Adi Shamir, and Leonard
Adleman at MIT; the letters RSA are the initials of their surnames, listed in the same
order as on the paper.[1]

Clifford Cocks, a British mathematician working for the UK intelligence agency GCHQ,
described an equivalent system in an internal document in 1973, but given the relatively
expensive computers needed to implement it at the time, it was mostly considered a
curiosity and, as far as is publicly known, was never deployed. His discovery, however,
was not revealed until 1997 due to its top-secret classification, and Rivest, Shamir, and
Adleman devised RSA independently of Cocks' work.

MIT was granted U.S. Patent 4,405,829 for a "Cryptographic communications system
and method" that used the algorithm in 1983. The patent would have expired in 2003, but
was released to the public domain by RSA Security on 21 September 2000. Since a paper
describing the algorithm had been published in August 1977,[1] prior to the December
1977 filing date of the patent application, regulations in much of the rest of the world
precluded patents elsewhere and only the US patent was granted. Had Cocks' work been
publicly known, a patent in the US might not have been possible either.

Operation
The RSA algorithm involves three steps: key generation, encryption and decryption.

Key generation

RSA involves a public key and a private key. The public key can be known to everyone
and is used for encrypting messages. Messages encrypted with the public key can only be
decrypted using the private key. The keys for the RSA algorithm are generated the
following way:

1. Choose two distinct prime numbers p and q

2. Compute n = pq
o n is used as the modulus for both the public and private keys
3. Compute the totient: .
4. Choose an integer e such that , and e and share no factors
other than 1 (i.e. e and are coprime)
o e is released as the public key exponent
5. Determine d (using modular arithmetic) which satisfies the congruence relation
;
o Stated differently, ed − 1 can be evenly divided by the totient (p − 1)(q −
1)
o This is often computed using the Extended Euclidean Algorithm
o d is kept as the private key exponent
Notes on the above steps:

• Step 1: For security purposes, the integers p and q should be chosen uniformly at
random and should be of similar bit-length. Prime integers can be efficiently
found using a Primality test.
• Step 3: PKCS#1 v2.0 and PKCS#1 v2.1 specifies using
, where lcm is the least common multiple instead
of .
• Step 4: Choosing e with a small hamming weight results in more efficient
encryption. Small public exponents (such as e=3) could potentially lead to greater
security risks.[2]

The public key consists of the modulus n and the public (or encryption) exponent e. The
private key consists of the modulus n and the private (or decryption) exponent d which
must be kept secret.

• For efficiency the following values may be precomputed and stored as part of the
private key:
o p and q: the primes from the key generation,
o and ,
o .

Encryption

Alice transmits her public key (n,e) to Bob and keeps the private key secret. Bob then
wishes to send message M to Alice.

He first turns M into an integer 0 < m < n by using an agreed-upon reversible protocol
known as a padding scheme. He then computes the ciphertext c corresponding to:

This can be done quickly using the method of exponentiation by squaring. Bob then
transmits c to Alice.

Decryption

Alice can recover m from c by using her private key exponent d by the following
computation:

Given m, she can recover the original message M by reversing the padding scheme.
The above decryption procedure works because:

Now, since ,

The last congruence directly follows from Euler's theorem when m is relatively prime to
n. By using the Chinese remainder theorem it can be shown that the equations holds for
all m.

This shows that we get the original message back:

[edit] A working example

Here is an example of RSA encryption and decryption. The parameters used here are
artificially small, but one can also use OpenSSL to generate and examine a real keypair.

1. Choose two prime numbers

p = 61 and q = 53

2. Compute n = pq

3. Compute the totient

4. Choose e > 1 coprime to 3120

e = 17

5. Compute d such that e.g., by computing the modular

multiplicative inverse of e modulo :

d = 2753
since 17 · 2753 = 46801 = 1 + 15 · 3120.
The public key is (n = 3233, e = 17). For a padded message m the encryption function is:

The private key is (n = 3233, d = 2753). The decryption function is:

For example, to encrypt m = 123, we calculate

To decrypt c = 855, we calculate

Both of these calculations can be computed efficiently using the square-and-multiply

algorithm for modular exponentiation. In real life situations the primes selected would be
much larger, however in our example it would be relatively trivial to factor n, 3233,
obtained from the freely available public key back to the primes p and q. Given e, also
from the public key, we could then compute d and so acquire the private key.

[edit] Padding schemes

When used in practice, RSA is generally combined with some padding scheme. The goal
of the padding scheme is to prevent a number of attacks that potentially work against
RSA without padding:

• When encrypting with low encryption exponents (e.g., e = 3) and small values of
the m, (i.e. m < n1 / e) the result of me is strictly less than the modulus n. In this
case, ciphertexts can be easily decrypted by taking the eth root of the ciphertext
over the integers.
• If the same clear text message is sent to e or more recipients in an encrypted way,
and the receivers share the same exponent e, but different p, q, and n, then it is
easy to decrypt the original clear text message via the Chinese remainder theorem.
Johan Håstad noticed that this attack is possible even if the cleartexts are not
equal, but the attacker knows a linear relation between them.[3] This attack was
later improved by Don Coppersmith.[4]
• Because RSA encryption is a deterministic encryption algorithm – i.e., has no
random component – an attacker can successfully launch a chosen plaintext attack
against the cryptosystem, by encrypting likely plaintexts under the public key and
test if they are equal to the ciphertext. A cryptosystem is called semantically
secure if an attacker cannot distinguish two encryptions from each other even if
 the attacker knows (or has chosen) the corresponding plaintexts. As described
above, RSA without padding is not semantically secure.
• RSA has the property that the product of two ciphertexts is equal to the encryption
of the product of the respective plaintexts. That is
Because of this multiplicative property a
chosen-ciphertext attack is possible. E.g. an attacker, who wants to know the
decryption of a ciphertext c = memod n may ask the holder of the private key to
decrypt an unsuspicious-looking ciphertext c' = cremod n for some value r chosen
by the attacker. Because of the multiplicative property c' is the encryption of
mrmod n. Hence, if the attacker is successful with the attack, he will learn mrmod
n from which he can derive the message m by multiplying mr with the modular
inverse of r modulo n.

To avoid these problems, practical RSA implementations typically embed some form of
structured, randomized padding into the value m before encrypting it. This padding
ensures that m does not fall into the range of insecure plaintexts, and that a given
message, once padded, will encrypt to one of a large number of different possible
ciphertexts.

Standards such as PKCS#1 have been carefully designed to securely pad messages prior
to RSA encryption. Because these schemes pad the plaintext m with some number of
additional bits, the size of the un-padded message M must be somewhat smaller. RSA
padding schemes must be carefully designed so as to prevent sophisticated attacks which
may be facilitated by a predictable message structure. Early versions of the PKCS#1
standard (up to version 1.5) used a construction that turned RSA into a semantically
secure encryption scheme. This version was later found vulnerable to a practical adaptive
chosen ciphertext attack. Later versions of the standard include Optimal Asymmetric
Encryption Padding (OAEP), which prevents these attacks. The PKCS#1 standard also
incorporates processing schemes designed to provide additional security for RSA
signatures, e.g., the Probabilistic Signature Scheme for RSA (RSA-PSS).

[edit] Signing messages

Suppose Alice uses Bob's public key to send him an encrypted message. In the message,
she can claim to be Alice but Bob has no way of verifying that the message was actually
from Alice since anyone can use Bob's public key to send him encrypted messages. So, in
order to verify the origin of a message, RSA can also be used to sign a message.

Suppose Alice wishes to send a signed message to Bob. She can use her own private key
to do so. She produces a hash value of the message, raises it to the power of dmod n (as
she does when decrypting a message), and attaches it as a "signature" to the message.
When Bob receives the signed message, he uses the same hash algorithm in conjunction
with Alice's public key. He raises the signature to the power of emod n (as he does when
encrypting a message), and compares the resulting hash value with the message's actual
hash value. If the two agree, he knows that the author of the message was in possession
of Alice's private key, and that the message has not been tampered with since.
Note that secure padding schemes such as RSA-PSS are as essential for the security of
message signing as they are for message encryption, and that the same key should never
be used for both encryption and signing purposes.

[edit] Security and practical considerations

[edit] Integer factorization and RSA problem
See also: RSA Factoring Challenge and Integer factorization records

The security of the RSA cryptosystem is based on two mathematical problems: the
problem of factoring large numbers and the RSA problem. Full decryption of an RSA
ciphertext is thought to be infeasible on the assumption that both of these problems are
hard, i.e., no efficient algorithm exists for solving them. Providing security against
partial decryption may require the addition of a secure padding scheme.[citation needed]

The RSA problem is defined as the task of taking eth roots modulo a composite n:
recovering a value m such that c = memod n, where (n,e) is an RSA public key and c is an
RSA ciphertext. Currently the most promising approach to solving the RSA problem is to
factor the modulus n. With the ability to recover prime factors, an attacker can compute
the secret exponent d from a public key (n,e), then decrypt c using the standard
procedure. To accomplish this, an attacker factors n into p and q, and computes (p − 1)(q
− 1) which allows the determination of d from e. No polynomial-time method for
factoring large integers on a classical computer has yet been found, but it has not been
proven that none exists. See integer factorization for a discussion of this problem.

As of 2008, the largest (known) number factored by a general-purpose factoring

algorithm was 663 bits long (see RSA-200), using a state-of-the-art distributed
implementation. The next record is probably going to be a 768 bits modulus[5]. RSA keys
are typically 1024–2048 bits long. Some experts believe that 1024-bit keys may become
breakable in the near term (though this is disputed); few see any way that 4096-bit keys
could be broken in the foreseeable future. Therefore, it is generally presumed that RSA is
secure if n is sufficiently large. If n is 300 bits or shorter, it can be factored in a few hours
on a personal computer, using software already freely available. Keys of 512 bits have
been shown to be practically breakable in 1999 when RSA-155 was factored by using
several hundred computers and are now factored in a few weeks using common
hardware.[6] A theoretical hardware device named TWIRL and described by Shamir and
Tromer in 2003 called into question the security of 1024 bit keys. It is currently
recommended that n be at least 2048 bits long.[citation needed]

In 1994, Peter Shor showed that a quantum computer could factor in polynomial time,
breaking RSA. However, only small scale quantum computers have been realized.[citation
needed]
[edit] Key generation

Finding the large primes p and q is usually done by testing random numbers of the right
size with probabilistic primality tests which quickly eliminate virtually all non-primes.

Numbers p and q should not be 'too close', lest the Fermat factorization for n be
successful, if p − q, for instance is less than 2n1 / 4 (which for even small 1024-bit values
of n is 3×1077) solving for p and q is trivial. Furthermore, if either p − 1 or q − 1 has only
small prime factors, n can be factored quickly by Pollard's p − 1 algorithm, and these
values of p or q should therefore be discarded as well.

It is important that the private key d be large enough. Michael J. Wiener showed[7] that if
p is between q and 2q (which is quite typical) and d < n1 / 4 / 3, then d can be computed
efficiently from n and e. There is no known attack against small public exponents such as
e = 3, provided that proper padding is used. However, when no padding is used or when
the padding is improperly implemented then small public exponents have a greater risk of
leading to an attack, such as for example the unpadded plaintext vulnerability listed
above. 65537 is a commonly used value for e. This value can be regarded as a
compromise between avoiding potential small exponent attacks and still allowing
efficient encryptions (or signature verification). The NIST Special Publication on
Computer Security (SP 800-78 Rev 1 of August 2007) does not allow public exponents e
smaller than 65537, but does not state a reason for this restriction.

[edit] Speed

RSA is much slower than DES and other symmetric cryptosystems. In practice, Bob
typically encrypts a secret message with a symmetric algorithm, encrypts the
(comparatively short) symmetric key with RSA, and transmits both the RSA-encrypted
symmetric key and the symmetrically-encrypted message to Alice.

This procedure raises additional security issues. For instance, it is of utmost importance
to use a strong random number generator for the symmetric key, because otherwise Eve
(an eavesdropper wanting to see what was sent) could bypass RSA by guessing the
symmetric key.

[edit] Key distribution

As with all ciphers, how RSA public keys are distributed is important to security. Key
distribution must be secured against a man-in-the-middle attack. Suppose Eve has some
way to give Bob arbitrary keys and make him believe they belong to Alice. Suppose
further that Eve can intercept transmissions between Alice and Bob. Eve sends Bob her
own public key, which Bob believes to be Alice's. Eve can then intercept any ciphertext
sent by Bob, decrypt it with her own private key, keep a copy of the message, encrypt the
message with Alice's public key, and send the new ciphertext to Alice. In principle,
neither Alice nor Bob would be able to detect Eve's presence. Defenses against such
attacks are often based on digital certificates or other components of a public key
infrastructure.

[edit] Timing attacks

Kocher described a new attack on RSA in 1995: if the attacker Eve knows Alice's
hardware in sufficient detail and is able to measure the decryption times for several
known ciphertexts, she can deduce the decryption key d quickly. This attack can also be
applied against the RSA signature scheme. In 2003, Boneh and Brumley demonstrated a
more practical attack capable of recovering RSA factorizations over a network
connection (e.g., from a Secure Socket Layer (SSL)-enabled webserver). This attack
takes advantage of information leaked by the Chinese remainder theorem optimization
used by many RSA implementations.

One way to thwart these attacks is to ensure that the decryption operation takes a constant
amount of time for every ciphertext. However, this approach can significantly reduce
performance. Instead, most RSA implementations use an alternate technique known as
cryptographic blinding. RSA blinding makes use of the multiplicative property of RSA.
Instead of computing cdmod n, Alice first chooses a secret random value r and computes
(rec)dmod n. The result of this computation is rmmod n and so the effect of r can be
removed by multiplying by its inverse. A new value of r is chosen for each ciphertext.
With blinding applied, the decryption time is no longer correlated to the value of the
input ciphertext and so the timing attack fails.

[edit] Adaptive chosen ciphertext attacks

In 1998, Daniel Bleichenbacher described the first practical adaptive chosen ciphertext
attack, against RSA-encrypted messages using the PKCS #1 v1 padding scheme (a
padding scheme randomizes and adds structure to an RSA-encrypted message, so it is
possible to determine whether a decrypted message is valid.) Due to flaws with the PKCS
#1 scheme, Bleichenbacher was able to mount a practical attack against RSA
implementations of the Secure Socket Layer protocol, and to recover session keys. As a
result of this work, cryptographers now recommend the use of provably secure padding
schemes such as Optimal Asymmetric Encryption Padding, and RSA Laboratories has
released new versions of PKCS #1 that are not vulnerable to these attacks.

[edit] Branch prediction analysis attacks

Branch prediction analysis is also called BPA. Many processors use a branch predictor to
determine whether a conditional branch in the instruction flow of a program is likely to
be taken or not. Usually these processors also implement simultaneous multithreading
(SMT). Branch prediction analysis attacks use a spy process to discover (statistically) the
private key when processed with these processors.

Simple Branch Prediction Analysis (SBPA) claims to improve BPA in a non-statistical

way. In their paper, "On the Power of Simple Branch Prediction Analysis", the authors of
SBPA (Onur Aciicmez and Cetin Kaya Koc) claim to have discovered 508 out of 512 bits
of an RSA key in 10 iterations.