Cryptography: RSA and Factoring; Digital Signatures; Ssh Greg Plaxton Theory in Programming Practice, Spring 2005 Department of Computer Science University of Texas at Austin
The Hardness of Breaking RSA One approach to breaking RSA is to try to compute the private key (d, n) from the public key (e, n), i.e., to compute d from e and n No one has proven that this is the only way to break RSA, but many experts believe that this is the case In what follows we will argue that the problem of computing d from e and n is essentially equivalent in difficulty to the problem of factoring n Given the prime factors p and q of n, it is possible to compute d efficiently Given d such that de is congruent to 1 modulo φ(n), it is possible to factor n efficiently
Computation of d from e, p, and q Note the symmetry of RSA with respect to d and e We can switch the public/private roles of the keys (d, n) and (e, n), and the scheme still works This property will come in handy again later when we discuss digital signatures So we can compute d from e, p, and q in the same way that we previously computed e from d, p, and q Use the extended Euclid algorithm
Computation of p and q from d, e, and n We know that de 1 is a multiple of φ(n), so we can easily compute a multiple of φ(n) It can be shown that given such a multiple of φ(n), n can be factored efficiently The proof is somewhat technical, so we content ourselves with proving a weaker result, namely, that given n and φ(n) we can compute p and q efficiently Given n = pq and φ(n) = (p 1)(q 1) = n (p + q) + 1, we can easily compute p + q = n φ(n) + 1 Given n = pq and p + q we can compute p q since p q = (p q) 2 = (p + q) 2 4pq Given p q and p + q we can easily solve for p and q
Digital Signatures Desirable properties of a document intended for Bob that is electronically signed by Alice: Only Bob can decrypt the message, and he is convinced that it was sent by Alice Alice cannot deny signing the document No one can modify the document without invalidating Alice s signature RSA is widely used for such digital signatures Let s see how this can be done
Digital Signatures via RSA Suppose Alice wants to sign a document and send it to Bob She encrypts the document x with her private key fa 1, and then encrypts the result with Bob s public key f b, i.e., she sends Bob f b (fa 1 (x)) Bob decrypts by applying his private key f 1 b, yielding fa 1 (x), followed by Alice s public key f a, yielding x In cases where Bob might not be sure who is sending him the document, Alice can send f b (y) where y is the concatenation of Alice s name (in plaintext) and fa 1 (x) Note that Bob is not fooled if someone else s name is included instead If Carol s name is concatenated to fa 1 (x), Bob obtains gibberish when he computes f c (fa 1 (x))
Alice Cannot Deny Sending the Message An impartial judge can determine that Alice signed the document, since the only way to get anything sensible out of fa 1 (x) (which can be supplied by Bob) is to apply Alice s public key f a This assumes that Alice is the only person who knows her private key Safeguarding private keys is critical
No One Can Modify Alice s Signed Document Suppose Bob changes one or more bits of the encrypted document (x) f 1 a Application of Alice s public key f a then yields gibberish
Ensuring Security of Communication with a Trusted Third Party In an RSA cryptosystem, we often need to retrieve the public key of another party Such keys may be obtained from a trusted third party, David, who maintains a database of public keys We need to be wary of an attacker Eve who might intercept a request to David and respond with the wrong public key Solution: David signs any public keys that he sends out Eve can no longer pose as David
Another Application of Public Key Cryptography: Ssh Provides a secure version of telnet We will give a brief overview of ssh and some related tools The ssh environment consists of a network of hosts (machines) Each host has a unique public/private key pair Each host runs a daemon process sshd Users of these hosts set up certain files containing public and private keys in a manner to be described Users run ssh to connect from one host to another
Ssh: Basic User Configuration Within a user account (in the.ssh subdirectory), the following basic files are created/maintained Public/private key pairs are created using ssh-keygen Private key files should not be readable by other users; for added security, private key files are often encrypted using a passphrase An authorized keys file, maintained by the user, that contains a list of public keys such that the holder of any associated private key is authorized to connect to this account A known hosts file, maintained by ssh (but editable), that contains the verified public keys of the hosts to which this user has previously connected
Using Ssh: The Basics To (attempt to) connect to another account, run ssh user@host If no private key is specified on the command line, a default private key file is assumed; if the private key is passphrase-protected, the user is prompted for the passphrase If the public key of the target host does not appear in the known hosts file, then the public key of the target host is displayed, and the user is asked whether to accept it If the public key of the remote host is accepted, it is added to the known hosts file In high-security environments, a user might telephone someone to decide whether to accept a given host public key The attempt to connect succeeds if the associated public key resides in the authorized keys file of the target account If not, the user is prompted for the account password
Ssh: The scp Command The scp command is like the unix cp command, but it can be used to copy files between remote hosts The syntax is similar to cp, but the source and destination filenames may be prefixed with an account name followed by a colon (for example, user@host:file) The source and destination files can both be remote Before the copy operation is performed, the user is prompted for the necessary passphrases and/or passwords to access the relevant remote accounts As with ssh, this may result in the known hosts file being updated, et cetera
Ssh: Agents A shortcoming of ssh as thus far described is that the security-conscious user with passphrase-protected private keys is constantly being asked to enter passphrases An elegant solution to this problem is provided by the ssh-agent utility, which the user invokes to initiate an agent process The agent may be abstractly viewed as a container of private keys for which the user has already provided the associated passphrase The ssh-add utility is used to add a (local) private key to the agent; if the private key being added is passphrase-protected, the user is prompted for the passphrase When an agent process is running, it interacts with the remote ssh daemon whenever the user attempts to access a remote account (e.g., via ssh or scp) If one of the private keys held by the agent is sufficient to gain access, the user is not prompted for a passphrase
Ssh: Agent Forwarding The ssh daemon running on a given host can be configured to enable or disable agent forwarding If agent forwarding is enabled on host B, then a user running an agent on host A can ssh into an account on B, and then ssh from B to C The private keys contained in the agent running on host A can be used to gain access to C If agent forwarding is enabled on host C, the user can ssh from C to D using the agent on A, et cetera