DSA (Digital Signature Algorithm) is an Asymmetric encryption algorithm that is known for being fast at cryptographically signing but slow at verifying. Slow at encrypting but fast at decrypting.
RSA (named after its published creators Rivest, Shamir and Adleman) and is also an Asymmetric encryption algorithm.
To define the difference between Asymmetric and Symmetric encryption: Symmetric relies on a single private key mixed with secret input - you can use block or stream ciphers. Asymmetric uses a combination of a public and private keys and require fixed bit lengths such as 1024, 2048 etc. The public key is allowed to be distributed so long as the private key remains secure. The private key is used for digitally signing where the public key can be used to verify the integrity of that.
The encryption is done through the intended recipients public key and the creators private key, then the combination of the recipients private key and senders public key can decrypt it.
DSA is based on a discrete logarithmic problem. RSA is based on the difficulty in the factorization of large integers.
RSA is far more common and commercially accepted. While it is possible for DSA to be over 1024 bits, many applications limit it to this. As such 2048 RSA algorithms are widely accepted as the minimum security standard to be cryptographically secure.
Showing posts with label Asymmetric. Show all posts
Showing posts with label Asymmetric. Show all posts
Saturday, 23 June 2012
Thursday, 21 June 2012
Overview of the SSL or TLS handshake
Secure Sockets Layer and its successor Transport Layer Security are cryptographic protocols that provide security over the internet.
They encrypt the segments of network connections at the Application Layer for the Transport Layer using Asymmetric Encryption for key exchange and Symmetric Encryption for confidentially and integrity.
Most protocols can be used in conjunction with TLS. Often this is done by specifying a different port, 443 for HTTPS. Another way of achieving the TLS connection is by the client requesting that the server switch to TLS. This is usually done by a protocol specific mechanism.
Once an agreement between A and B has been made to use TLS, a stateful connection is established by using a handshake procedure. During this handshake various parameters are passed between each other to establish the connections security.
Both client and server have now established that they trust who each other is and are both aware of the pre-master secret. With this they both perform a series of steps to establish the master secret.
Both parties now use the master secret to generate session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity.
The client now sends the server a message to state that future messages will be encrypted with the session key along with an encrypted message to state that it has finished it's own portion of the handshake.
The server performs the same action.
Now that the connection is established, the data shared between them is encrypted and decrypted. It's worth noting that at any time either side may renegotiate the connection and the whole process is repeated.
TLS has also been implemented on datagram oriented transport protocols such as UDP (User Datagram Protocol) and DCCP (Data Congestion Control Protocol). This usage has been standardised as DTLS (Datagram Transport Layer Security).
TLS can also be used to tunnel an entire network stack to create a VPN (Virtual Private Network), as is the case with OpenVPN.
TLS is also a standard method to protect SIP (Session Initiation Protocol) application signaling. TLS can be used to provide authentication and encryption of the SIP signaling associated with VoIP and other SIP based applications.
They encrypt the segments of network connections at the Application Layer for the Transport Layer using Asymmetric Encryption for key exchange and Symmetric Encryption for confidentially and integrity.
Most protocols can be used in conjunction with TLS. Often this is done by specifying a different port, 443 for HTTPS. Another way of achieving the TLS connection is by the client requesting that the server switch to TLS. This is usually done by a protocol specific mechanism.
Once an agreement between A and B has been made to use TLS, a stateful connection is established by using a handshake procedure. During this handshake various parameters are passed between each other to establish the connections security.
- The client sends the server the clients SSL version number, cipher settings and other details it needs to establish a connection
- The server does the same back however it also sends it's own certificate (The certificate contains the servers public key) and if the client is asking for a resource that requires authentication, the server asks for the clients certificate
- The client uses what it has been provided to authenticate the server. If the server can't be authenticated then the user is warned that the secure encryption connection can not be established.
- Using all the data generated in the handshake thus far, the client creates the pre-master secret for the session and encrypts it with the servers public key. It sends the encrypted pre-master secret to the server
- If the server has requested client authentication, the server attempts to authenticate the client. If the client can not be authenticated the session ends. If the client can be authenticated, it uses its private key to decrypt the pre-master secret.
Both client and server have now established that they trust who each other is and are both aware of the pre-master secret. With this they both perform a series of steps to establish the master secret.
Both parties now use the master secret to generate session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity.
The client now sends the server a message to state that future messages will be encrypted with the session key along with an encrypted message to state that it has finished it's own portion of the handshake.
The server performs the same action.
Now that the connection is established, the data shared between them is encrypted and decrypted. It's worth noting that at any time either side may renegotiate the connection and the whole process is repeated.
Applications
In application design, TLS is usually implemented on top of the transport layer protocols. Encapsulating the application specific protocols such as HTTP, FTP, SMTP, NNTP and XMPP.TLS has also been implemented on datagram oriented transport protocols such as UDP (User Datagram Protocol) and DCCP (Data Congestion Control Protocol). This usage has been standardised as DTLS (Datagram Transport Layer Security).
TLS can also be used to tunnel an entire network stack to create a VPN (Virtual Private Network), as is the case with OpenVPN.
TLS is also a standard method to protect SIP (Session Initiation Protocol) application signaling. TLS can be used to provide authentication and encryption of the SIP signaling associated with VoIP and other SIP based applications.
Related Resources
- SSL Tutorial
- OWASP Transport Layer Protection Cheat Sheet
- Layman Guide to SSL/TLS
- CISCO foundation of web security
Related Wikipedia Reading
Subscribe to:
Posts (Atom)