Skip to main content
banner image
venafi logo

The Evolution of 256-Bit Encryption and Security Certificates

The Evolution of 256-Bit Encryption and Security Certificates

encryption key management, encryption management, encryption key management, website security certificate
September 8, 2017 | David Bisson


With the advent of e-commerce came an important question: how can users verify that an entity on the other end of a web connection is who it says it is? The answer wasn't immediately clear in the Internet's early days. But in subsequent years, a suitable method slowly entered into focus.


Public Key Infrastructure to the Rescue!

The solution came in the form of public key infrastructure (PKI), a set of requirements which detail the implementation of public key cryptography for authenticating parties involved in a web transaction. At the heart of public key infrastructure are two keys: a public key, which is widely available, and a private key, which is known only to its owner. The keys work together in that an entity can use a public key to verify that someone holding the private key indeed sent a message. On the flip side, the public key infrastructure also supports asymmetric encryption by restricting the decryption of a message encrypted with a public key to someone holding the corresponding private key.


How well are you protecting your machine identities? Download our Dummies' Guide.
 

Public and private keys meet in what are known as digital signatures. These coded messages abide by public key infrastructure which enables signers to use their private keys to create the digital signature. The mathematical algorithm underlying the private key creates a hash and encrypts the data, thereby producing a digital signature.

Electronic signature technology provider Docusign provides an example of how digital signatures can help authenticate an individual involved in a transaction:

"… Jane signs an agreement to sell a timeshare using her private key. The buyer receives the document. The buyer who receives the document also receives a copy of Jane’s public key. If the public key can’t decrypt the signature (via the cipher from which the keys were created), it means the signature isn’t Jane’s, or has been changed since it was signed. The signature is then considered invalid."

It's imperative that parties can ensure the integrity of a digital signature. As a result, public key infrastructure frequently requires the sender of a document and the recipient to agree on using reputable Certificate Authorities (CAs) for creating, conducting, and saving their asymmetric keys. A type of service provider, CAs are third-party organizations that help ensure key security. They're responsible for issuing security certificates, electronic documents which contain a digital signature's public key and the identity associated with that key. Security certificates therefore help confirm the owner of a public key and are essential to creating a digital signature.

Security certificates don't last forever; CAs issue them for a specified period of time and then require owners to renew them. Once issued, these certificates appear in security certificate management systems and tie into the central directory, a repository of stored and indexed keys maintained by the public key infrastructure. If a CA has any reason to revoke a security certificate before it reaches its expiration, that document likely ends up in a certificate revocation list (CRLs). Browsers can use this list to not trust revoked security certificates, thereby protecting web users against bad actors who might seek to abuse expired/revoked security certificates.


The Evolution of Security Certificates

Security certificates come in many different forms. Most commonly, an organization purchases a security certificate and installs it on a web server. Doing so authenticates the identity of the website for web browsers and visitors as well as encrypts data transmitted between the website and the visitor.

To establish these secure communication channels, domain owners often obtain Secure Sockets Layer (SSL) security certificates. Netscape Communications originally developed SSL in 1994, which means it's most likely the first cryptographic protocol developed for the Internet. Today, SSL helps secure emails sent using the Simple Mail Transfer Protocol (SMTP), phone calls placed via the Voice over Internet Protocol (VoIP), files exchanged over the File Transfer Protocol (FTP), and processes that make use of other protocols. Of course, it also works with the Hypertext Transfer Protocol (HTTP) to produce Hypertext Transfer Protocol Secure (HTTPS), which establishes encrypted communications on the web.

The most recent version of Secure Sockets Layer is SSL 3.0. In January 1999, Internet Engineering Task Force adopted an enhanced version of SSL 3.0 called Transport Layer Security (TLS). This successor protocol's latest version is TLS 1.2.


AES: Its Role and Key Sizes

Underlying the actual data transmission of SSL and TLS is the Advanced Encryption Standard (AES). A successor of the Data Encryption Standard (DES), AES is an encryption standard technique used by many cryptographic libraries. Organizations traditionally use AES for symmetric key cryptography, or use of the same key to encrypt and decrypt messages.

AES candidates support a fixed block length of 126 bits. But the standard supports three key lengths: 128 bits, 192 bits, and 256 bits. Most organizations require their employees use AES 256-bit encryption because of the 2256 possible key combinations that a brute force attacker would need to try in order to guess the key.

To put things into perspective, it would take one billion billion years to crack 128-bit key. This is already older than the age of the universe (13.82 billion years) and is therefore considered uncrackable. 256-bit encryption keys, by comparison, require 2128 times the computational power needed to break a 128-bit key. This size considerably raises the stakes of cracking a 256-bit encryption key. Using a hypothetical scenario provided by Wikipedia, say 50 super computers have the ability to try one billion billion key combinations each second. It would still take them 3×1051 years to exhaust the key space under 256-bit encryption.

Gain visibility into your encryption environment today.


Digital Certificates, Keys, and Machine Identities

Security certificates and 256-bit encryption keys managed by the public key infrastructure all constitute machine identities. These capabilities enable authentication and encryption for security protocols like SSL and TLS. But if not adequately protected, digital attackers could abuse them to target an organization's IT infrastructure. Indeed, attackers could abuse access to machine identities to steal trusted credentials and thereby bypass other security controls. Attackers could then steal private (including 256-bit encryption) keys, forge security certificates, compromise Certificate Authorities (CAs), leverage encrypted tunnels, and exploit machine identities to steal data and/or conduct digital espionage.

Machine identities are high-value targets for digital attackers and malicious insiders. Acknowledging this risk, organizations need to strengthen their machine identity protection infrastructure. This effort begins with gaining global visibility into all certificates and keys used in internal and external infrastructures, the cloud, and other environments.


Learn more about machine identity protection. Explore now. 
 

Like this blog? We think you will love this.
Intelligent robot looking into the future
Featured Blog

Blockchain May Be Leading Us Toward More Secure Human Authentication. But What About Machines?

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection
Industry Research

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection

Machine Identity Protection for Dummies
eBook

Machine Identity Protection for Dummies

About the author

David Bisson
David Bisson

David is a Contributing Editor at IBM Security Intelligence.David Bisson is a security journalist who works as Contributing Editor for IBM's Security Intelligence, Associate Editor for Tripwire and Contributing Writer for Gemalto, Venafi, Zix, Bora Design and others.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat