A concise look at what you'll learn in this blog:
If you heard “asymmetric” in art class, your teacher rarely praised your painting skills. The sun was tilted, Dad’s arm too short and rabbits shouldn’t have Hovercraft paws.
That’s why we rarely associate asymmetry with something good, but we’d love to show you an exception that can help you protect your sensitive data: Asymmetric encryption.
A little history lesson on symmetric encryption
For context, before we talk about asymmetric encryption, let’s first discuss symmetric encryption, which has been more prevalent in the past. Maybe you’ve used it yourself as a kid to sneak secret messages past your teacher. We know we have.
In case you’re not familiar yet, let’s walk through a famous historical example of symmetric encryption – the Caesar Cipher, named after – you guessed it – good old Julius.
To encrypt your secret message, you’d replace letters one by one, shifting up or down the alphabet by a fixed number of places. Let’s say you wanted to encrypt the message, “The secret code is open sesame”, and you decided on a shift of 5.
That would turn your original line into “Ymj xjhwjy htij nx tujs xjxfrj.”
While that works for Tommy from the second row, you can tell it’s not a complicated system. If someone intercepts your message, all they need to do is count up or down the alphabet until a group of letters makes sense, and that’s checkmate. Even more complex systems building on top of this principle were vulnerable in the same spot.
Your only way to outsmart an opponent trying to crack the code is to frequently change what was the number 5 in our example, or what later became a chain of rotor and plugboard settings. Still, once they know your secret key, your message is out in the open, which is why the success of this strategy depended on separately communicating the key, somewhat similar to out-of-band authentication.
Asymmetric encryption comes to the rescue, with a small catch
Despite these blatant vulnerabilities, symmetric encryption stayed around for a long time. But in 1976, Ronald Rivest, Adi Shamir and Leonard Adleman thought to themselves, “What if we went for asymmetric encryption?”
All they needed was a catchy name, so they picked RSA (Rivest-Shamir-Adleman). OK, maybe not so catchy, but the idea was revolutionary. Instead of relying on one secret key, they built their system on two mathematically related secrets.
Let’s say Alice and Bob want to encrypt their exchanges. Both generate a public and a private key. What they share is the modulus – the factor defining the key length – and the public key exponent. Basically, they tell each other one of a million ways to compute their shared keys through math. But they only share the most necessary part of the equation.
They both keep another exponent private. Now Alice can use a combination of Bob’s public and her private key and run messages through that equation. Bob uses his private and Alice’s public key to decrypt it. They no longer have to share a shift number, therefore they don’t need to keep it secret.
However, a few caveats remain. Even though Bob and Alice were smart enough not to rely on “shift 5,” they can’t calculate mathematical equations with exponents in their heads. So they still need a directory to store and allocate the public keys to guarantee that their system works. They have to rely on external hardware, which makes their solution terribly slow compared to symmetric encryption.
That dependency on a directory can also turn revoking certificates into a pain, and it increases the risk of breaches because both are more likely to stick with the key they’ve chosen.
How symmetric and asymmetric encryption combined solve today's security issues
OK, symmetric encryption is faster at computing but easier to crack and asymmetric encryption slower at computing but next to un-breachable. What do we do? We combine the best of symmetric and asymmetric encryption, which we’re already doing with Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. While both are cryptographic authentication and encryption protocols, TLS can be seen as the updated and more secure variant of SSL.
If Alice wants to benefit from those, she first sends a “client hello” message, which tells the server about her supported cryptographic algorithms, so it can select the strongest one. The server wraps the agreed-upon preferences in a unique session ID. Now for the asymmetric encryption part. The server sends its public key to Alice’s browser, which verifies it through a trusted authority and generates a secret code.
Both the browser and server then use that code to independently calculate a shared secret key to use for faster symmetric encryption afterward.
How IBE builds on top of asymmetric encryption to add more security
Now, we’ll get into the big leagues, because one of those smart fellows didn’t rest on his laurels. In 1984, Adi Shamir came up with what we now know as identity-based encryption.
Instead of relying on a key you need to maintain in a directory, it only uses information tied to your identity, such as your phone number. This changes the entire procedure.
Think about it. If Alice knows Bob, she probably has his phone number or email. For the first time, users know their opposite’s key without depending on a storage solution. They just feed that information into a private key generator, which spits out a one-time code.
You also eliminate the security gaps we mentioned. Now, your private keys can change for every single exchange. No need to reuse them across applications. One private key for all purposes turns into hundreds of generated keys.
The public key, which required elaborate storage before, is now easy to memorize.
Even if someone were to gain access to your device, the private keys they stole would be useless. You would already have generated new ones for the next login session, so you wouldn’t need to revoke access tediously.
How does the login process with Almefy work?
That was a lot of encryption theory. We feel like you’ve earned a treat. How about a safer way to log in? As it happens, we’ve designed just that, based on the so-called Challenge-Response Pattern. Here’s how it works.
You scan a QR code that contains a short-living challenge generated by our authentication service. Once the app scans it, it extracts and signs that challenge using Almefy’s IBE methodology. Then, the app sends back the challenge with the generated signature to have the authentication service validate if it’s correct and if the IBE secret used is still valid.
If they match, we know you are who you say you are and you can carry on. And we mean carry on, because once we’ve verified your identity, you can safely log in to all your accounts in one step, without ever entering your username and password.
How does that sound? Good? Then give it a try!
Contact
Demo Login