Traditional encryption algorithms are often referred to as symmetric, because you use the same key, or password, for both encryption and decryption.
Julius Caesar’s eponymous cipher, for example, now about 2000 years old, worked by shifting every letter back three places in the alphabet, so the encryption/decryption key was the fixed number 3, with encryption sliding the letters to the left and decryption sliding them back the same amount to the right:
Plaintext: DEFEND THE FORT
<--move by 3--<
Encrypted: ABCBKA QEB CLOQ
>--move by 3-->
Decrypted: DEFEND THE FORT
You can generalize the Caesar cipher to 25 different shift distances (in the modern English alphabet of 26 letters), which means it’s extremely weak because it’s trivial to try all 25 possibilities until you hit the right answer.
But a similar operational principle applies even in today’s symmetric algorithms.
The widely-used Advanced Encryption Standard (AES), for instance, uses keys that are 16, 24 or 32 bytes long (128, 192 or 256 bits), so that guessing the right one, or trying all the possibilities, is considered computationally infeasible, a phrase that can be translated in real life into the word “impossible.”
Caesar cipher (English alphabet): 25 possible keys AES cipher (16-byte key variant): 2128 possible keys (2128 = 340,282,366,920,938,463,463,374,607,431,768,211,456)
But both systems face the same troublesome problem when you want to use them to share data securely with someone else, rather than just to lock up your own data for later.
The problem is that before the recipient can decrypt the data correctly, you first need to share the key with them.
And if your communication medium is insecure enough to make it worth encrypting the data you send over it, it’s not safe to use it to share the key directly.
You’ll need a key to scramble the key to the data, and for that, you’ll a key to scramble to key to scramble the key, and so ad infinitum.
The only reliable way around this conundrum, if all you have is symmetric encryption, is to meet up first, and to exchange one or more secret keys in person.
That approach that doesn’t lend itself to internet-style and internet-scale online interactions.
The solution to this key-exchange problem, as we explained in our Keeping secrets with people you’ve never met article series, is a system generally known as public-key cryptography, also known as asymmetric encryption.
The word “asymmetric” comes from the fact, loosely speaking, that this algorithm family uses one key to encrypt (or to create a digital signature of) a chunk of data, but a different key to decrypt it (or verify its signature).
By convention, and for rather obvious reasons, one key is called the public key, because you can share it with anyone you like, and the other is the private key, because you keep it to yourself.
If I want to send you a secret, I encrypt it with your public key, after which neither I nor anyone else can then decrypt it…
…except for you, because you’re the only person with the private key to reverse the encryption and recover the original content.
Likewise, if you want to authenticate something digitally, you sign it with your private key, after which I (or indeed anyone else) can verify the signature using your public key.
With asymmetric encryption there is no secret key that we need to exchange first, so there is no need for us to meet face-to-face up front to agree on a shared encryption/decryption secret such as a Caesar shift of 3 or an AES key of 7329D355AF23D0C97232D4863668DAA8.
The important foundations of a working public-key cryptographic algorithm are:
Additionally, and perhaps rather obviously, you need to keep your private key to yourself, just as you need to keep a symmetric key or password to yourself, because anyone who gets hold of a copy of that private key can undetectably pretend to be you.
Usefully, asymmetric cryptography also provides a really neat way of password-protecting access to a remote server, without ever agreeing on and sharing a fixed password first, as we need to do when setting up a conventional username-plus-password logon.
That means we never need to send a symmetric password across the internet from a client computer to a server, which means that there is no risk that the server might leak that shared secret, whether accidentally or otherwise.
Servers aren’t supposed to keep a copy of any password submitted in the course of logging on. Instead, they should store a cryptographic hash, or “one-way digital fingerprint,” which is enough to check that the right password was presented. Servers are expected to purge any submitted passwords from memory as soon the logon process is complete, which reduces the risk of passwords lying around in memory, or being written to a logfile by mistake.
So-called public-key authentication uses a public-private keypair instead of a plain password, like this:
Additionally, you may choose to use symmetric encryption to password-protect your private key locally on your own computer, so that the file in which your private key is stored useless on its own, thus providing an extra step of protection if the raw file containing your private key is stolen.
Alternatively, a so-called security token (e.g. a YubiKey) that can be plugged into a USB port or accessed wirelessly can be used to generate and store your private key.
These tokens are designed so that they can generate a public-private keypair internally, and will then:
What you absolutely must remember, if you’re a server vendor setting up and configuring a server for public-key authentication, is that:
Annoyingly, given that network and security vendors should know and adhere to these rules as table stakes for any software or service, a major vendor has just been caught out violating both of these principles in two different products, in bugs now tagged CVE-2025-44954 and CVE-2025-6243.
These bugs apply to the Ruckus Networks products Virtual SmartZone and Network Director respectively (the former helps customers manage multiple network access points and clients, while the latter manages a collection of SmartZones).
Simply put, the affected products:
Simply put, the servers not only ship with an all-powerful backdoor user that is available to the vendor, but also include the private key needed for any attacker to access this account, not just the vendor.
Worse still, as far as we can tell, in the CVE-2025-44954 variant of the bug, every server comes with the same keypair, so extracting the private key from one server would give an attacker root-level remote access to every server.
Ruckus Networks has acknowledged these bugs, along with several other critical vulnerabilities, but at the time of writing [2025-07-17T19:00:00Z] says that it is “actively investigating,” and will “provide updates as new information becomes available.”
Remember that every zero-day vulnerability ever exploited represents a case in which cybercriminals got there first, and decided to abuse the bug, instead of reporting it so that it could be fixed proactively.
Learn more about our mobile security solution that goes beyond traditional MDM (mobile device management) software, and offers active on-device protection that’s more like the EDR (endpoint detection and response) tools you are used to on laptops, desktops and servers:
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
Featured image of funky door by Claudio Schwarz via Unsplash.
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
