Key Takeaways

Anyone handling sensitive user data lives in fear of a data breach. We know that encryption can reduce the negative consequences, but most encryption is relegated to infrastructure-level elements like TLS and VPNs rather than at the application layer. Application-layer and end-to-end encryption can be a powerful tool in our toolkit, but as developers, how can we safely add encryption to our applications without introducing bugs or reducing the utility of the data?

In this article, we discuss the pros and cons of application-layer encryption. We will cover the attack surface of application-layer encryption in the browser, how it is very different from native clients, and how WebCrypto helps.

The reputation, financial, and human impact of breaches can be extremely high. New laws that help protect end-user privacy are an important step forward, but they come with potentially ruinous fines.

Studies showthat encryption is one of the most effective technical security measures to reduce the impact and cost of a data breach. When attackers get encrypted datasets, they either have to attack a different system to get the key or have to settle with metadata and side-channel information instead of the good stuff.

Encryption is typically focused on infrastructure-layer elements, like TLS, VPNs, database encryption flags, and full-disk encryption. These are important tools in our toolbox, but they rely on assumptions about the infrastructure instead of the application code itself.

In fact, if you consider most recent data breaches, at least among established companies, they were certainly using TLS and at-rest database encryption, and yet the leaks happened anyway. For instance,Capital One was recently hackedand sensitive financial information stolen. Google Photosaccidentally gave the wrong users accessto photos and videos from other users. These mistakes could have been prevented, or at least mitigated, by application-layer or end-to-end encryption.

As developers, infrastructure isnt our strength, and sometimes its not our job, so encryption takes a back seat to features. But for those of us who do care about defense in-depth, it makes good sense to add encryption to the application itself. Application-layer encryption can insulate our systems from infrastructure-level failures, known weaknesses of TLS, and some server-side vulnerabilities.

The practice of moving more security, operations, and testing into the development process (known asshift-left) is improving software agility, reliability, and efficiency. It also means that security best practices need to be implemented as part of application developmentnot as an afterthought when things go wrong. However, the vast majority of developers are not security or cryptography experts, and at the same time, the security team has less control over the security posture of IT and development than ever before.

Application-layer encryption, or shift-left cryptography, is part of this trend. It means giving developers more control over what gets encrypted and who gets the keys for decryption. In some cases, the users themselves may be the only parties with the keys. In other cases, application-layer encryption can be an added access control layer on data management, providing defense-in-depth.

As implied by the name, application-layer encryption gets added directly to the codebase of your application, and access to key material is controlled by your application logic. As a result, you can think of the data itself as being encrypted throughout its lifecycle, rather than relying on it being on an encrypted network or disk.

The most widely-understood application-layer encryption is end-to-end encrypted chat like Signal and WhatsApp provide, so lets think through how those applications work. Its a bit over-simplified, but it basically works like this:

End-user action

Access Control Logic (Server)

App-layer Cryptographic Operation (Client)

Add a friend

Create an access control rule where users are allowed to send each-other messages

Trust the friends cryptographic key

Write the friend a message

Create an access control rule where the friend can read the message

Encrypt the message with the friends key (and sign it)

Read a message from a friend

Check for permission to download the message

Decrypt a message with end users key (and check the signature)

In this simple example, we can already see some of the power of application-layer encryption:

Note that this is an example of end-to-end encryption, but not all application-layer encryption is end-to-end. Also, applications like this still need TLS and other infrastructure-layer encryption to enforce things like authentication, prevent replay attacks, and address a host of other issues.

When we think about TLS, we picture data getting encrypted at its source and decrypted on the server. But this over-simplification hides the practical limits of TLS.

The reality of encryption in transit leaves out encryption of data at rest, which impacts the security of both ends of the transmission. It also completely ignores what happens to the data after HTTPS termination which may be further out on the edge of your network than you know; at your load balancer for instance.

So what about encryption at other points in the application? If youre doing an above-average job of crypto, youve written robust, well-tested code in your app to encrypt data at rest, youve used HTTPS and IPSec on your network, and youve enabled transparent database crypto.

Were pretty much encrypting everywhere with this approach, but as the data moves through the system, it gets decrypted and re-encrypted at each step. Each point that touches plain text data is a potential vulnerability, resulting in a large attack surface, and you have to ask yourself, why the heck do these intermediate services need the data in plain text anyway? They probably dont.

Infrastructure-layer encryption also lends itself to gaps in security because unanticipated parts of the infrastructure might get the data. For instance, your database and disk backups might not get encrypted, even if your database is. Or your health monitoring system might be logging sensitive data in plain text, and (horror of horrors) maybe even sending it to a third party. These security gaps happen because different individuals or departments are accountable for security at these various points:

Each one of these solutions uses different ciphers, libraries, and key sizes. Youre counting on a lot of people to get a lot of things right. Thats a problem.

Encryption is about communication; data is written and encrypted by one party, then received and decrypted by another party. The sender and receiver both have to have an application that knows how to do the encryption and decryption, and can be trusted to do it correctly. But that is easier said than done.

What if the encryption code is malicious? What could an attacker do? The simplest attack would be for the application to work exactly as expected, butalsosend the unencrypted messages to the bad guys. More subtle attacks are possible of course; adding hidden vulnerabilities to weaken the encryption, messing with the public keys, etc. But they all amount to the same thing: A bit of code that helps the bad guy get the secret message.

So lets talk about code delivery. For two people communicating using apps on their mobile phones, the trust chain goes something like this: A good programmer writes good encryption code, compiles it into an app, signs the app with a digital signature, and uploads it to an app store via TLS. The user downloads an app over TLS, the operating system checks whether the digital signature is trusted, and the user runs the app to have their encrypted communication. Note that this protocol is itself an application-layer cryptographic data exchange. Systems like Debian Linux have similar protocols for installing and upgrading the server and desktop applications.

There are a number of things that can go wrong with the trusted app download: The user could download a malicious version of the app. The OS vendor could undermine the check of the digital signature on the app. An attacker could trick the user into installing an old and vulnerable version of the app (or not upgrading it). Any of these types of attacks would make the end-to-end encrypted communication suspect. But for the most part, this works well.

Application-level cryptography is typically implemented in native code running on mobile, laptops, or servers, and can use a protocol like this to deliver trustworthy code. But modern applications very often have a major browser-based component, even for critically sensitive information.

The code delivery model on the web looks quite different from an app. When users decide that they want to have a secure conversation, they visit a web page. The browser downloads some JavaScript over TLS on-demand. Beyond warning the user about bad TLS connections, thats the end of the standard protocol for code delivery. It relies completely on TLS. The JavaScript that gets delivered needs to perform the application-layer encryption and tonothave any malicious code that just sends the unencrypted text to the bad guys.

Why is this a problem? Lets say for instance that our security claim is that the data gets encrypted in one browser, decrypted in another browser, and the webserver in between cannot see the data without warning flags and fireworks going off. To undermine this claim, the server simply needs to deliver malicious JavaScript at the application start time. So an attacker that can control the server that delivers code or various aspects of DNS and TLS could pull off this attack without breaking any crypto. The bad code can be sent only to a specific target, making it hard to detect for security researchers.

In fact, with the speed of application updates and continuous integration, similar attacks are possible against mobile apps and desktops. Many modern apps use dynamic code techniques to deliver at least some code to an app in real-time; many desktop apps update their own code at will. This gives attackers the ability to hijack code updates at various points but also gives security teams the ability to patch quickly. That said, the browser-based attacks are a lot better understood.

Some people in the security and cryptography community point to this issue to say that you shouldnt do browser-based encryption, or if you do, you cant claim that its end-to-end secure. Or at the very least, that it creates a false sense of security. We disagree. There are indeed weaknesses, but as developers, we should be doing it anyway, because simply put, people use the web for security-critical purposes.

Despite the code delivery problem, doing application-layer encryption in the browser significantly improves the overall security of any system. The reason for this is that security isnt all-or-nothing. Very rarely in modern server infrastructure is a single browser talking only to a single web server that performs every task; modern systems are just more complex than that.

For instance, lets say your web application uses HTTPS and does browser-based end-to-end encryption, but that it has an SQL injection vulnerability. The nature of this vulnerability is that the attacker tricks the application into tricking the database into dumping out sensitive data (over HTTPS, ironically). But in our example, the data is end-to-end encrypted, so the database only contains encrypted messages. Without application-layer encryption, the bad guy would get something much more sensitive: the plain text messages. Note that with this vulnerability alone, the attacker cannot change the code to inject malicious JavaScript; the browser-based encryption code is still sound.

On the other hand, if the attacker has a remote code execution exploit on the API server, and can modify the JavaScript or inject malicious code into it on the fly, theycanundermine the end-to-end encryption, again by simply adding code that sends the plain text data to themselves.

These are only two examples, one where application-layer encryption can be undermined and one where it cannot, but there are innumerable other attacks that can be prevented with end-to-end encryption: Perhaps you have a too-nosey employee who is looking for the private information on celebrities, but who doesnt have access to the code. Perhaps you backed up your Postgres database to an S3 bucket and accidentally left it open on the web. Perhaps an attacker can undermine TLS, but they only act passively; they can eavesdrop but they cannot do code injection.

As we can see, application-layer encryption in the browser provides defense-in-depth, even though there are challenges to code delivery. In the next section, we will talk about approaches that mitigate those challenges.

There are a number of ways to improve the security of application-layer encryption in the browser. The first line of defense is to use good, trusted code. Modern application development is much faster because we reuse a lot of code we find on the web, but if any of the code that runs in the users browser is malicious or vulnerable, it undermines the encryption significantly.

Protecting the server that delivers the code is also vital. Use the principle of least privilege when assigning access control rights on that server. Use multi-party control for administration and code deployment. This will significantly reduce the risk of insider attacks.

There are also under-used code-delivery settings that instruct the browser to take extra precautions. These arent the default because they somewhat reduce the flexibility of the development and integration process, but the security they provide is worth the work, whether your application does encryption or not:

In addition, there is a relatively new browser API that helps with efficient and secure delivery of cryptographic primitives. The WebCrypto API provides low-level ciphers, hashes, and other encryption components. This helps because you dont have to include those ciphers in your JavaScript. The browser implements them directly and can take advantage of local native execution and even hardware acceleration. It doesnt prevent certain attacks, like just sending an unencrypted copy of the data to the bad guys, but WebCrypto does make browser-based encryption more standard and accessible.

Secure code delivery isnt the only challenge for implementing application-layer encryption. The biggest problem is that most encryption libraries are relatively hard to use securely and difficult to implement consistently in different programming languages and platforms. When you encrypt something in a browser and decrypt it on an app, you probably need three different implementations in different languages (Android, iOS, and JavaScript) that all use the exact same ciphers and modes.

The secure operation of these modes is not very easy to understand. For instance, the well-beloved cipher AES is secure, but pairing it with an insecure mode like ECB (the default mode in Java) is insecure. Pairing AES with GCM is considered a best practice, but even GCM has its flaws; if you encrypt too much data with the same key, or make a mistake with the initialization vector/nonce, you could actually leak key material, which is a flaw that some other modes do not have.

One mistake can make your encrypted data unrecoverable, or even worse, recoverable by a bad guy.

Another challenge is that if you put encrypted data in your database, its no longer as searchable. You have to plan ahead for what kinds of queries and downselects you want the database to do or that you want your application to do. If you encrypt a users home address, for instance, you cant simply SELECT * for all the rows with the string Oregon. If downselecting by state is part of your application workflow, you can instead encrypt the users entire address, but add an unencrypted metadata field with their state so that you can still perform this query. From there, you can potentially use application-layer logic to decrypt the record and perform the rest of the search, but the database wont be of much help.

People I talk to are often concerned about performance for application-layer encryption, but this isnt a significant concern. Encryption is fast, and often hardware accelerated these days. After all, we use HTTPS for streaming entire social networks with photos and videos and dont really notice much of a performance hit. Its similar at the application layer, and you are simply unlikely to find encryption to be a bottleneck.

To be sure, there are still attacks against application-layer encryption. Various governments have made it illegal or legally impractical to operate an encryption service or install an encrypted app. Users selecting weak or reused passwords can completely undermine encryption. Users forgetting passwords is a challenge to address as well; what should happen in that case? Should the user be able to recover their data via a password reset email? That itself weakens the end-to-end encryption argument.

And of course, once the data is decrypted, attackers can attack the end device itself. This happened to WhatsApp in 2019, causing some to wonder if end-to-end encryption is worthwhile or important. But the fact that attackers had to target specific individuals with zero-day attacks against WhatsApp is proof enough to me that end-to-end encryption helps.

When implementing encryption in your application, you will need to consider your specific security goals, any compliance rules you might have to follow, and who you need to have the key material. Cryptography is very specific to your application. A trained cryptographer can help you understand the strengths and weaknesses of your approach, and no magazine article can tell you whats right or wrong. There are, however, a few choices you can make that will get you closer to good cryptography, and you can often safely use them.

First a bit of brief background on the three major cryptographic systemssymmetric, asymmetric, and hashing. Symmetric (shared key) is fast and efficient, these algorithms are usually your baseline for encrypting data. AES is usually what you want. Symmetric encryption suffers from challenges with key management. You need a way to get the shared key to both parties, which is why you need asymmetric encryption. Symmetric multi-block modes vary in their confidentiality and integrity properties, and some work better with different types of data or different system constraints (such as a lack of a random number generator): ECB, GCM, CBC, SIV, etc.

Asymmetric (public/private key) cryptography is slower and more complex than symmetric encryption, these algorithms are typically used for exchanging symmetric keys. RSA is the classic choice here; ECC is more modern and efficient, and almost as widely supported. Roughly speaking, public keys are used for encrypting data and verifying signatures. Private keys are used for decrypting data and generating signatures.

Hashing, cryptographic signatures, and message authentication codes (MACs) provide integrity. Hashing generates a short string that proves the data was either unchanged or in the case of message authentication codes, proves that the person holding a secret key signed the data. Many people think that encryption implies integrity, but it does not. For instance, AES doesnt provide integrity by default. Algorithms like SHA2, Poly1305, and GCM help.

Managing keys is a very big topic in itself, but a few important things to consider:

Beyond key material, there are other elements of randomness or uniqueness that are associated with encrypted messages. Initialization Vector, salt, and nonces fall in this category. These need to be communicated to the decrypting party as well, so they need to be stored or transmitted. Typically, its safe to transmit these unencrypted along with the ciphertext, but you should be careful not to let the attacker modify them.

You also need to pad, encode, serialize, and sign your messages. Believe it or not, even bad padding can undermine the confidentiality of the encrypted message. For signing of structured data like a JSON object or HTTP headers, you need an identical way for both sides to serialize and deserialize the data, or the signatures wont match.

If youve done all of this right, you now have an encrypted and signed message. Its likely at this point that youll want to send this message to another party, who will check the signature and decrypt the message. That means you need to communicate all of your choices: key id, size, cipher, mode, IV, hashing algorithm, etc. This communication itself is a fraught weakness in many cryptography systems. For instance, attackers have been able to trick some symmetric systems into behaving like asymmetric systems and sending their shared key directly to the attacker. Oops.

A few recommendations we have, particularly if you need to or want to stick with the NIST/FIPS-140 ciphers that are sometimes required for compliance in government work or banking:

Encryption is an exceptionally effective way to protect data, but most encryption deployed today is part of the IT infrastructure, and not part of applications. As developers, we have a unique opportunity to improve privacy and security of our users by making application-layer encryption a part of our toolbox. There are challenges to be sure; encrypted data can be harder to manage, and most encryption libraries are very hard to use for untrained developers, but the benefit to our users is worth it!

The following are not the formal definition of these terms, but color commentary to help you understand how these terms and technologies fit into application-layer encryption.

Isaac Potoczny-Jones is the founder and CEO of Tozny, LLC, a privacy and security company specializing in identity management and encryption. Isaacs work in cybersecurity spans open source, the public sector, and commercial companies. His projects have included end-to-end encryption for privacy in human subject research, secure cross-domain collaboration, identity management, anonymous authorization, mobile password-free authentication, anti-forgery in hardware devices, and privacy-preserving authentication. He has worked with agencies including DARPA, the Navy, Air Force Research Laboratory, the Department of Homeland Security, the National Institute of Standards and Technologies, and other elements of the DoD and intelligence communities. Isaac is an active open source developer in the areas of cryptography and programming languages. Education: B.S. in computer science, M.S. in Cybersecurity.

Read more from the original source:
How to Use Encryption for Defense in Depth in Native and Browser Apps - InfoQ.com

The cloud encryption software market is expected to grow by USD 2.82 billion during 2020-2024. The report also provides the market impact and new opportunities created due to the COVID-19 pandemic. The impact can be expected to be significant in the first quarter but gradually lessen in subsequent quarters with a limited impact on the full-year economic growth according to the latest market research report by Technavio.

This press release features multimedia. View the full release here: https://www.businesswire.com/news/home/20200512005716/en/

Technavio has announced its latest market research report titled Global Cloud Encryption Software Market 2020-2024 (Graphic: Businesswire)

Request for Technavio's latest reports on directly and indirectly impacted markets

Market estimates include pre- and post-COVID-19 impact on the cloud encryption software market

Download free sample report

The increasing use of in-built cloud encryption solutions is expected to drive the growth of the market. Location-independent tasks and cloud hosting requires cloud encryption software for data and business security along with the adoption of the software as a service method. Cloud encryption software delivers data security by masking important data and information through encryption. Various organizations are adopting in-built cloud encryption software to mitigate the possibility of data breaches. In addition, the increasing use of mobile devices is creating a need to protect personal information, which will drive the demand for in-built cloud encryption during the forecast period.

To learn more about the global trends impacting the future of market research, download a free sample: https://www.technavio.com/talk-to-us?report=IRTNTR43409

The global outbreak of COVID-19 is expected to have a neutral impact on the growth of the global cloud encryption software market. The global market is not expected to see any major impact of COVID-19 spread. One of the key factors for the market to sustain is the increased efforts of companies to provide work from home facilities to their employees due to lockdown across various countries. This increases the chances of data breaches and cyber thefts, thereby driving the demand for cloud encryption solution.

As per Technavio, the growing adoption of biometric encryption will have a positive impact on the market and contribute to its growth significantly over the forecast period. This research report also analyzes other significant trends and market drivers that will influence market growth over 2020-2024.

Cloud Encryption Software Market: Growing Adoption of Biometric Encryption

The growing adoption of biometric encryption is one of the key emerging trends in the global cloud encryption software market. Biometric verification allows access to a system by recognizing distinctive biological traits such as fingerprint, voice, iris, or facial lineaments. A fingerprint scan to access office premises is one such example. Biometric devices also store sensitive information. Thus, players in the market are offering biometric encryption systems to end-user industries to deal with the increasing security threats. The demand for biometric encryption, is hence, expected to increase from SMEs as the solution is affordable.

Story continues

"The rising digitization will have a significant impact on the growth of the cloud encryption software market value during the forecast period," says a senior analyst at Technavio.

Register for a free trial today and gain instant access to 17,000+ market research reports

Technavio's SUBSCRIPTION platform

Cloud Encryption Software Market: Segmentation Analysis

This market research report segments the cloud encryption software market by end-user (BFSI, manufacturing, professional services, healthcare, and others) and geography (North America, Europe, APAC, South America, and MEA).

The North American region led the cloud encryption software market share in 2019, followed by Europe, APAC, South America, and MEA respectively. During the forecast period, the North American region is expected to register the highest incremental growth due to factors such as the rising demand for security solutions from a majority of data centers, and growing adoption of biometric encryption.

Technavios sample reports are free of charge and contain multiple sections of the report, such as the market size and forecast, drivers, challenges, trends, and more. Request a free sample report

Some of the key topics covered in the report include:

Market Drivers

Market Challenges

Market Trends

Vendor Landscape

About Technavio

Technavio is a leading global technology research and advisory company. Their research and analysis focus on emerging market trends and provides actionable insights to help businesses identify market opportunities and develop effective strategies to optimize their market positions.

With over 500 specialized analysts, Technavios report library consists of more than 17,000 reports and counting, covering 800 technologies, spanning across 50 countries. Their client base consists of enterprises of all sizes, including more than 100 Fortune 500 companies. This growing client base relies on Technavios comprehensive coverage, extensive research, and actionable market insights to identify opportunities in existing and potential markets and assess their competitive positions within changing market scenarios.

View source version on businesswire.com: https://www.businesswire.com/news/home/20200512005716/en/

Contacts

Technavio ResearchJesse MaidaMedia & Marketing ExecutiveUS: +1 844 364 1100UK: +44 203 893 3200Email:media@technavio.com Website:www.technavio.com/

Read the rest here:
Analysis on Impact of COVID-19-Global Cloud Encryption Software Market 2020-2024| Increasing Use of In-built Cloud Encryption Solutions to Boost...

Tauria is the only solution that offers full end-to-end, no knowledge encryption to protect businesses communication and work

WATERLOO, ON , May 12, 2020 /CNW/ -Tauria, a Waterloo -based software encryption company, is excited to announce that today it is launching its secure video conferencing and business suite. This will protect businesses confidential information by providing end-to-end encryption, at a time where other video conferencing solutions have had massive security breaches and have sold sensitive user information with third parties. Tauria has the capability to support up to 50 people on video conference calls, while also allowing users to send messages, organize schedules, share files and much more, all fully encrypted. This makes Tauria the only end-to-end encrypted video conferencing solution for groups.

Tauria, a Waterloo-based software encryption company, is excited to announce the launch of its secure video conferencing and business suite. (CNW Group/Tauria)

The timely launch of Tauria coincides with a dramatic increase in the number of companies resorting to online webinar formats, video conferencing tools and digital communication platforms to manage business operations in the wake of the coronavirus outbreak. As use of these tools and platforms has skyrocketed, so too have the number of incidents regarding their lack of privacy and numerous security vulnerabilities.

"It is incredibly important for us to create a product that is fully end-to-end, no knowledge encrypted to protect businesses. Encryption is the foundation of everything we do," said Tauria CEO Jesse Th.

No-knowledge encryption ensures that not even Tauria staff have access to the information that is shared on the platform or through the video conferencing feature. This is a fundamental distinction between Tauria and companies like Zoom, Microsoft, Google and Slack, all of whom can access users' private information and whose substandard security features have been publicly exposed. Tauria's safe guarding against even its own employees guarantees the highest level of privacy and security in the market.

As public institutions and companies with proprietary or personal client information migrate to cloud-based solutions to facilitate communication during this pandemic, safeguarding private information has become increasingly challenging. Hospitals, law offices, municipalities, school boards and accounting firms require the level of protection offered with end-to-end, no knowledge user encryption as per corporate governance policies, but have struggled with finding a platform that offers this level of protection.

"We are setting a new standard for both the private and public sector to secure private information while facilitating digital connectivity," said Th. "This communication tool has the power to transform service delivery for a multitude of industries."

During COVID-19 Tauria has discounted its services to ensure that secure and encrypted communications for businesses is more accessible.

With companies relying on business collaboration tools to facilitate remote work during the coronavirus outbreak, Tauria is offering its platform free for one month. By enhancing digital communication through Tauria's secure platform, companies will be able to execute day-to-day business operations while protecting sensitive information.

For more information on Tauria, please visitwww.tauria.com.

Story continues

More here:
Move over Zoom, this encryption company just released the first fully end to end encrypted conferencing solution - Yahoo Finance

Data integrity holds the most delicate aspect of any organization. It provides the reliability and security of data details over its lifecycle. However, day after day the number of data violations and data-tampering incidents is increasing rapidly. Such an issue commonly takes place as cybercriminals always keep trying in finding new sensitive strategies to victimize internet users. To counter such a problem, there is an encryption technique that protects digital data secretly by converting plaintext to ciphertext. In such a way, only authorized individuals could get access to your message or data and those people who are not authorized, cannot.

For example, you want to send a letter to your buddy stating you miss him but you dont want anybody else to open and read the message. In this guide, Im going to explain two different types of encryption in an easy way i.e. Symmetric and Asymmetric encryption.

As it is cleared out that the Symmetric encryption and Asymmetric encryption both are forms of the encryption process. But, the basic difference between these two techniques is that the symmetric encryption uses a single secret key while asymmetric encryption makes use of two different separate keys.

Another point is that asymmetric encryption is relatively slower in the execution process. Since the symmetric encryption is less complicated and executes faster, it infers a better way to transfer data having in large quantities.

As said earlier, symmetric encryption is a form of encryption that uses only one private key to cipher and decipher the data. Such a way of encrypting messages had been widely used in earlier times to have a secret conversation between administrations and armies. It mainly uses a private key that can either be a number, a letter, a symbol, or a sequence of arbitrary characters such as BK5, RU-8. These words are combined with the plain text of a message so that it could change the content in a particular way. Due to having a less complex algorithm, it executes the process faster.

Although it is well said that everything has both aspects, right and wrong. In the same way, symmetric encryption has also a disadvantage of using. And that is, the encrypted data can only be deciphered using the same secret key which the sender has been used to encrypt. In simple language, the sender uses a secret key to encode data before sending the information, right? Now, the receiver should also have the same secret key to decode the enciphered message. Because of having such a simplistic nature, both the operations can be carried out quite fastly.

Let us look at the example I used above. If you have used the symmetric encryption to secure the message you are sending to your buddy, then obviously the same key will be used to encrypt and decrypt the data. But your friend doesnt have the private key to decrypt the message or data. In this case, you must have to transfer the key through a secure channel.

Asymmetric encryption is an encryption model that requires a pair of two different key i.e. public key and private key. Since it uses two separate keys, it is also known as the public key cryptography and thats why it is considered to be more secure as compared to the symmetric encryption.

But here you may think Why does it need two keys? Well, the asymmetric encryption uses one key to encode the data and that is called the public key. And this public key is available to everyone. Whereas the asymmetric encryption uses the private key to decode the encoded data and that must be kept secret.

For example, you send greetings to your beloved one and encrypt the message using a public key then your friend could only decrypt it using the private key which has to you. However, if you encode the message using a private key, your friend will need to have your public key to decode it.

This cryptographic technique is comparatively a new method and it provides higher security. It is because the asymmetric encryption uses two separate keys for the encoding and decoding process. However, one major shortcoming of the asymmetric encryption is that it takes more time than the process associated with the symmetric encryption.

The private key is although used with an algorithm to encode and decode data. But the primary need of this key is to decipher any information that is ciphered using the public key.

In data encryption, this private key is also known as a secret key and it must need to be kept confidential. It means, this secret key never needs to be transferred and thus there is no reason that it can be required by the third party.

As the name infers, this key is available publically. It doesnt require any security and is mainly used to encode information not to decode.

In this tutorial, I have explained the symmetric encryption and asymmetric encryption along with the examples in a very simple and transparent way.

Thats it.

See the original post here:
What is the difference between Symmetric and Asymmetric Encryption? - TWCN Tech News