|
Ordinarily, this equation alone would be asymmetric and we'd have an infinite number of values for D that satisfy this equation; fortunately, we've also stipulated that we're only interested in the value that is less than N and there will be only one of those. A programmatic approach to determining this value for D might be
<?php
function find_D($E, $N, $phi) {
for($x = 1; $x < $N; $x++) {
if (0 == ((($x * $phi) + 1) % $E)) {
return (($x * $phi) + 1)/$E;
}
}
}
?>
This loop could easily be sped up to require far fewer iterations, but it should cover the basics. Now that we have our values for E, D, and N, we can toss out P, Q, and F, confident that we'll never need them again. In fact, we need to be sure to get rid of them because any one of those values, paired with our public key pair (E, N), would allow someone to determine our value for D using the exact methods we used to generate it in the first place.
Because E and N by themselves are not enough to calculate D, we can give out a copy of our public key to anyone who wants it. In fact, we can publish it on the Internet, write it on our business card, and rattle it off on our home answering machine. Given a public key, all anyone can really do with it is encrypt new data that can be decrypted only with our private key or decrypt data that happens to have been encrypted using our private key. As we'll cover in the next section, these are both activities that are not only acceptable, they're actually exactly what we want to happen.
|
Publishing your public key is where the importance of a large keysize comes into play. Because P and Q are the only factors of N, an attacker could potentially derive these from your public key and use them to deduce the value of D, given sufficient time and computing resources. 1,024 bits is currently considered "secure enough," although many new implementations are favoring 2,048-, 4,096-, or even 8,192-bit keysizes. |
|
