Sorry, but that's not entirely true. As I mentioned before, the weakest link in cryptography is not the algorithm, or the protocol but the implementation. The devil is always in the details

The RSA algorithm as designed by Rivest, Shamir and Adleman is:

1. Find two large random primes p and q of approximately equal size such that their product n = pq is of the required bit length, e.g. 1024 bits.

2. Compute n = pq and phi = (p-1)(q-1).

3.

**Select** a random integer e, 1 < e < phi, such that

**gcd(e, phi) = 1**
4. Use the extended Euclidean algorithm to compute the unique integer d, 1 < d < phi, such that ed is congruent 1 (mod phi).

5. <n,e> becomes the public key and <n,d> the private.

Encryption is achieved by c = m^e mod n and decryption by m = c^d mod n thus the relationship between e and d, in this context, is better defined as bijective rather than symmetrical: ((x^e)^d) is congruent x mod n

Choosing e is not something you approach lightly. Yes, you want a small enough number so computations are performed fast but above all things (this is about security after all) e

**must not** divide neither (p-1) nor (q-1) otherwise your private key can be derived.

e and d shouldn't be used interchangeably because after you derive d you don't know if gcd(d,phi) = 1

As a general rule, always follow the designer's algorithm until the variation you want to implement has been reviewed and approved by the crypto community. Even a small, insignificant, deviation may have undesired interactions that can weaken the system.

I'm sure you (dELTA) are familiar with this paper but for the people following this thread that are not, D. Boneh wrote an interesting paper titled "Twenty years of attacks on the RSA cryptosystem" http://crypto.stanford.edu/~dabo/papers/RSA-survey.pdf