# RSA vs DSA working methodolgy?

I have looked for various answers but I am being confused on how does RSA can be used for both Digital Signatures and Encryption/Decryption like in "TLS_DHE_RSA_..." or "TLS_RSA_.." cipher suite whereas DSA is only used like in "TLS_DHE_DSS_.." only for certificate signing, and not for encryption/decryption.

It would be better if someone could explain the mathematical functions/how they work with an example each for these two standards.

Edit : Also if DSA and RSA are only used for Digital Signatures how does there public keys are provided to client because the public key is needed to verify privately signed certificate, do certificates are exchanged twice and what are the parameters that are encrypted in the digitally signed certificate ?

How can RSA be used for digital signing and encrypting and DSA only for encrypting?

To understand this one has to dig into the definitions of RSA and DSA.

RSA by itself was designed to be a public-key encryption scheme and later converted to a digital signature scheme. RSA does encrypt data by rasing them to an exponent e modulo a composite number n. You can invert this process if you know the factorization of n, you can calculate the exponent d that turns the encrypted message into the original message. Now you should see how it can be used for PK-encryption. Note that m^e^d=m^(e*d)=m. Now you want to sign something. So calculate the hash of this message (H(M)) and "decrypt" this so everyone knowing e and n can "encrypt" it to get H(M) back and then verify this belongs to the message M. (Wikipedia Article)

Now DSA does things a little differently. You can only sign data with DSA because it's defined to be used with a hash-function. The result of the hash-function is used to do the signing math and hence a verifier can only check that certain values match, to believe your signature but they can't reconstruct the hash itself as it is possible with RSA. Wikipedia Article

Now to your second question concerning the certificates.

In TLS a server presents the client with his certificate to prove the public key belongs to him. How is that verified? The server also provides you with what is called a "certificate chain". The whole idea of the certificate-system is that some institutions (CAs) believe you that you are who you claim to be. So your browser (or your OS) has a list of public keys of CAs it's trusting to do their job right. Now the server presents you with his certificate. The server also provides you also with an intermediate certificate. You check if the signature on the server's certificate can be verified using the intermediate certificate's public key. The you verfiy the intermediate ceritificate's signature using the next one... until you reach a point where the certificate is stored in your browser / OS then you'll trust that chain. Now you know that the public key belongs to the server. The certificate contains by itself some data that gives you information about who owns the private key, about the algorithms used, about the validility period, about the CA who issued the certificate and about the signature. (Wikipedia Article about standard X.509 certificates)