Encryption Explained: From AES to Post-Quantum Cryptography and End-to-End Messaging

Every message you send, every payment you make, and every password you type relies on encryption. It is the invisible layer that keeps digital life private — and it is built into virtually every application your business depends on. This article explains how different types of encryption protect real-world applications, why emerging technologies like elliptic curves and post-quantum algorithms matter for your products, and what Instagram's recent decision to drop end-to-end encryption tells us about the tension between privacy and regulation.

What encryption actually does

Encryption transforms readable data (plaintext) into an unreadable form (ciphertext) using a secret value called a key. Only someone who possesses the correct key can reverse the process and recover the original data.

Two properties matter most:

• Confidentiality — an attacker who intercepts the ciphertext learns nothing about the plaintext.
• Integrity — modern encryption schemes also detect if the ciphertext was tampered with in transit.

All practical encryption falls into one of two families: symmetric and asymmetric. Real-world systems use them together, and understanding why helps you make informed decisions about the applications you build or use.

Symmetric encryption: the workhorse of data protection

In symmetric encryption, the same key is used to encrypt and decrypt. Think of it as a safe with a single combination: anyone who knows the combination can open it, and keeping that combination secret is what keeps the contents secure.

Where you encounter it every day

AES (Advanced Encryption Standard) is the most widely used symmetric cipher in the world. Adopted by NIST in 2001, it supports key lengths of 128, 192, or 256 bits and is backed by hardware acceleration in virtually every modern processor.

Here is where AES protects your data in practice:

• Cloud storage. When you upload files to AWS S3, Google Cloud Storage, or Azure Blob Storage, they are encrypted at rest using AES-256. Even if someone gains physical access to the storage hardware, the data is unreadable without the key.
• Database encryption. PostgreSQL, MongoDB, and MySQL all offer AES-based encryption to protect data on disk. This means a stolen database backup is useless without the encryption keys.
• HTTPS / TLS. Every time your browser shows a padlock icon, AES is doing the heavy lifting. TLS 1.3 uses AES-GCM (Galois/Counter Mode) as its primary cipher — it encrypts data and verifies its integrity simultaneously, protecting everything from login credentials to API calls.
• Mobile applications. Both Android's file-based encryption and Apple's Data Protection use AES-256 to encrypt data on the device. When a user locks their phone, the encryption keys are evicted from memory, making the stored data inaccessible.
• Payment processing. PCI DSS — the security standard for handling credit card data — requires AES encryption for cardholder data both in transit and at rest.

ChaCha20-Poly1305 is another symmetric cipher gaining adoption. It is faster than AES on devices without hardware AES acceleration — particularly older smartphones and IoT devices. Google chose it for TLS connections on Android, and it is the default cipher in WireGuard VPN.

Try it yourself: AES encryption in your terminal

You do not need any special software — OpenSSL is pre-installed on macOS, Linux, and most server environments. Open a terminal and try these commands.

Encrypt a message with AES-256:

echo "I want to secure my app with AES" | openssl enc -aes-256-cbc -a -salt -pass pass:nerdy_pro

The output will be a block of random-looking Base64 text — your encrypted ciphertext. To decrypt it, take that output and run:

echo "U2FsdGVkX181dnX8SWIhZTumWK0Uc7Kh947omVSNpH8lujB43L5OjlubfkGa3Y1dyxj5cfzyPZjhWiyGzIWdPw==" | openssl enc -aes-256-cbc -a -d -salt -pass pass:nerdy_pro

You will get your original message back. OpenSSL may show a warning: *** WARNING : deprecated key derivation used. — this is expected. It means OpenSSL defaults to an older key derivation method when using -pass pass:. In production, you would use -pbkdf2 for stronger key derivation, but for this demonstration the default works fine.

Now try changing a single character in the password and decrypting again — it will fail. This demonstrates the core property of symmetric encryption: without the exact key, the data is unrecoverable.

You can also encrypt entire files:

# Encrypt
openssl enc -aes-256-cbc -salt -in report.pdf -out report.pdf.enc -pass pass:nerdy_pro

# Decrypt
openssl enc -aes-256-cbc -d -in report.pdf.enc -out report-decrypted.pdf -pass pass:nerdy_pro

The key distribution problem

Symmetric encryption is fast and efficient, but both parties must share the same secret key before they can communicate. If your application serves a million users, you cannot pre-share a million different keys securely. This is the problem that asymmetric cryptography solves.

Asymmetric encryption: enabling trust between strangers

Asymmetric encryption uses a pair of keys: a public key that can be shared openly, and a private key that must remain secret. Data encrypted with the public key can only be decrypted with the corresponding private key.

RSA: the foundation of internet security

RSA, published in 1977, was the first practical public-key cryptosystem. Its security rests on the difficulty of factoring the product of two very large prime numbers — a problem that is easy to set up but virtually impossible to reverse with current technology.

Here is how RSA powers real applications:

• SSL/TLS certificates. When you visit a website over HTTPS, the server presents a certificate signed with RSA (or ECC). Your browser verifies this signature to confirm you are talking to the real server and not an imposter. Certificate authorities like Let's Encrypt issue millions of RSA-signed certificates.
• Code signing. When you download an app from the Apple App Store or install a Windows application with a digital signature, RSA signatures verify that the code has not been tampered with since the developer published it.
• Email encryption. PGP/GPG and S/MIME use RSA to encrypt emails and sign them, ensuring both privacy and sender authenticity.
• SSH access. System administrators use RSA key pairs to securely access servers without passwords — ssh-keygen -t rsa is one of the most common commands in any DevOps workflow.

Try it yourself: RSA encryption in your terminal

Generate an RSA key pair:

# Generate a 2048-bit private key
openssl genrsa -out private.pem 2048

# Extract the public key
openssl rsa -in private.pem -pubout -out public.pem

Now encrypt a message with the public key and decrypt it with the private key:

# Encrypt — anyone with your public key can do this
echo "I want to secure my app with RSA" | openssl pkeyutl -encrypt -pubin -inkey public.pem -out message.enc

# Decrypt — only the private key holder can do this
openssl pkeyutl -decrypt -inkey private.pem -in message.enc

This is the core idea: your business partner encrypts data with your public key, sends the ciphertext over any channel (even email), and only you can read it. Without the private key, the encrypted file is useless.

The hybrid approach

In practice, asymmetric encryption is too slow for encrypting large amounts of data. Instead, real systems use a hybrid approach: RSA (or ECC) securely exchanges a one-time symmetric key, and then AES handles the bulk data encryption at high speed. This is exactly how TLS, SSH, and PGP work under the hood.

Elliptic curve cryptography: stronger security, smaller keys

Elliptic Curve Cryptography (ECC) achieves the same security level as RSA with dramatically smaller keys. This translates directly into faster connections, smaller certificates, lower bandwidth, and better performance on mobile and IoT devices.

The practical difference

A 256-bit ECC key provides the same protection as a 3072-bit RSA key — that is a 12x reduction in key size. For applications that handle thousands of connections per second or run on battery-powered devices, this difference is significant.

Where ECC is used today

• TLS 1.3. The latest version of TLS exclusively uses ECC-based key exchange (ECDHE). RSA key exchange has been removed entirely. Every modern HTTPS connection you make uses elliptic curves.
• Signal and WhatsApp. The Signal Protocol uses Curve25519 — a specific elliptic curve designed for high performance and resistance to implementation errors — for its key exchange. This is the same protocol that protects messages for over two billion WhatsApp users.
• WireGuard VPN. WireGuard uses Curve25519 for all key exchanges, contributing to its reputation as a simpler and faster VPN compared to OpenVPN or IPsec.
• SSH keys. Ed25519 — an elliptic curve signature scheme — has become the recommended key type for SSH. It produces shorter keys and faster signatures than RSA: ssh-keygen -t ed25519 generates a key that is both more secure and more convenient than the older RSA default.
• Cryptocurrency. Bitcoin and Ethereum use the secp256k1 elliptic curve to sign every transaction. When you send cryptocurrency, an ECC signature proves you own the wallet without revealing your private key.
• Apple and Google sign-in. Sign in with Apple uses ECC (P-256) for its identity tokens. Google's Cloud KMS supports ECC keys for signing and verification.

Try it yourself: ECC keys in your terminal

Generate an elliptic curve key pair and compare it with RSA:

# Generate an ECC private key (Curve P-256)
openssl ecparam -genkey -name prime256v1 -noout -out ec-private.pem

# Extract the public key
openssl ec -in ec-private.pem -pubout -out ec-public.pem

# Compare file sizes — ECC keys are dramatically smaller
wc -c private.pem ec-private.pem

You will see the ECC private key is roughly 4-5x smaller than the RSA one, while providing equivalent security. On a server handling thousands of TLS handshakes per second, this difference adds up fast.

Digital signatures and checksums: proving authenticity and integrity

Encryption keeps data secret, but two equally important questions remain: who sent this data? and was it modified in transit? Digital signatures and checksums answer these questions — and they are just as fundamental to application security as encryption itself.

Checksums and CRCs: detecting accidental corruption

A checksum is a short value computed from a block of data. If even one bit of the data changes, the checksum changes too. The simplest form is the CRC (Cyclic Redundancy Check) — a fast algorithm designed to catch accidental errors during data transfer or storage.

You use CRCs more often than you might think:

• File downloads. When you download a Linux ISO or a software package, the website often lists an SHA-256 or MD5 checksum. You compute the checksum of your downloaded file and compare it — if they match, the file arrived intact.
• Network protocols. Ethernet frames, TCP packets, and ZIP files all include CRC checksums to detect corruption during transmission.
• Database replication. Systems like PostgreSQL use checksums to detect data corruption on disk before it propagates to replicas.
• Git. Every commit, file, and tree in a Git repository is identified by a SHA-1 hash. This is why Git can detect any modification to the repository history.

Try it in your terminal:

# Create a file and compute its SHA-256 checksum
echo "I want to secure my app with checksums" > document.txt
shasum -a 256 document.txt

# Modify even one character and the checksum changes completely
echo "I want to secure my app with Checksums" > document.txt
shasum -a 256 document.txt

The two checksums will be entirely different — not just slightly different, but completely unrecognizable from each other. This property is called the avalanche effect, and it is what makes checksums reliable for detecting changes.

Important distinction: CRCs and simple checksums detect accidental corruption — they do not protect against intentional tampering. An attacker who modifies a file can simply recompute the checksum. To defend against deliberate modification, you need cryptographic signatures.

Digital signatures: proving who sent the data

A digital signature uses asymmetric cryptography in reverse: instead of encrypting with the public key and decrypting with the private key, the sender signs a message with their private key, and anyone with the public key can verify the signature.

This gives you two guarantees:

• Authentication — the message was created by the holder of the private key and nobody else.
• Integrity — the message was not altered after signing.

Digital signatures are everywhere in production systems:

• Software updates. When your phone installs an iOS or Android update, the OS verifies Apple's or Google's digital signature before applying it. A modified update without a valid signature is rejected — this is the primary defense against malicious firmware.
• API authentication. JWTs (JSON Web Tokens) used for API auth are digitally signed. When your backend receives a JWT, it verifies the signature to confirm the token was issued by your auth server and has not been tampered with.
• Package managers. npm, PyPI, Docker Hub, and APT all use signatures to verify that packages were published by their claimed authors. Supply chain attacks — like the infamous event-stream incident — exploit gaps in this verification.
• Blockchain transactions. Every Bitcoin or Ethereum transaction is signed with the sender's private key. The network verifies the signature before accepting the transaction — this is how cryptocurrency works without a central authority.
• Document signing. PDF documents, contracts, and invoices can carry digital signatures that prove authorship and detect modifications — recognized as legally binding in most jurisdictions under eIDAS (EU) and ESIGN (US) regulations.

Try signing and verifying a message yourself:

# Create a document
echo "I want to secure my app with digital signatures" > message.txt

# Sign it with your RSA private key (from the earlier example)
openssl dgst -sha256 -sign private.pem -out message.sig message.txt

# Verify the signature with the public key
openssl dgst -sha256 -verify public.pem -signature message.sig message.txt
# Output: Verified OK

# Now tamper with the file and verify again
echo "I want to secure my app with Digital Signatures" > message.txt
openssl dgst -sha256 -verify public.pem -signature message.sig message.txt
# Output: Verification Failure

The tampered message fails verification — the signature proves both who created the document and that it has not been modified. This is the same mechanism that protects every HTTPS certificate, every signed Git commit, and every app you install from an app store.

HMAC: signatures for symmetric systems

When both parties share a secret key (as in many API integrations), HMAC (Hash-based Message Authentication Code) provides integrity and authentication without the overhead of public-key cryptography. Stripe, AWS, and GitHub all use HMAC to sign webhook payloads so your server can verify they are genuine:

# Compute an HMAC-SHA256 of a message
echo -n "I want to secure my app with HMAC" | openssl dgst -sha256 -hmac "nerdy_pro"

Your server computes the same HMAC using its copy of the shared secret and compares it to the signature in the request header. If they match, the webhook is authentic.

JWTs: signatures in practice

JSON Web Tokens (JWTs) are one of the most common real-world applications of digital signatures. If your application has user authentication, there is a good chance JWTs are involved. A JWT is a compact, URL-safe token with three parts separated by dots: a header, a payload, and a signature.

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0Miwicm9sZSI6Im5lcmR5X2FkbWluIn0.oAi5ALawUM_KpWDkiJcfA8504oQ_Yjx7OhEM8nZxlIc

The header specifies the signing algorithm. The payload carries the actual data — user ID, role, expiration time. The signature ensures neither has been tampered with. Your server verifies the signature on every request and trusts the payload only if verification passes.

Try decoding this token yourself — paste it into jwt.io and see what is inside. You will notice you can read the payload without knowing the secret. That is by design: JWTs are signed, not encrypted. The signature only proves the token has not been tampered with — it does not hide the contents.

Signing algorithms determine the security model:

• HS256 (HMAC-SHA256) — symmetric. The same secret key signs and verifies the token. Simple to set up, but every service that needs to verify tokens must have the secret — which becomes a risk as your architecture grows.
• RS256 (RSA-SHA256) — asymmetric. The auth server signs with a private key, and any service verifies with the public key. The public key can be distributed freely without compromising security.
• ES256 (ECDSA-P256) — asymmetric, using elliptic curves. Same trust model as RS256, but with smaller keys and faster signatures. Increasingly the recommended choice for new applications.

Advantages of JWTs:

• Stateless authentication. The server does not need to query a database or session store on every request — the token itself contains all the information needed to authorize the user. This simplifies scaling horizontally across multiple servers.
• Cross-service trust. In microservice architectures, the auth service signs the token once, and every downstream service can verify it independently using the public key. No shared database or network call required.
• Standard and portable. JWTs are an open standard (RFC 7519) supported by libraries in every major programming language. Tokens can be passed in HTTP headers, URL parameters, or cookies.

Pitfalls to watch for:

• Tokens cannot be revoked. Once a JWT is signed, it is valid until it expires. If a user's account is compromised, you cannot invalidate their existing tokens without adding a server-side blocklist — which partially defeats the stateless benefit. Short expiration times (15 minutes) combined with refresh tokens mitigate this.
• Payload is not encrypted. The Base64-encoded payload is signed but not encrypted — anyone who intercepts the token can read its contents. Never put sensitive data (passwords, personal information, API keys) in a JWT payload. If you need an encrypted token, use JWE (JSON Web Encryption), though this adds complexity.
• Algorithm confusion attacks. If the server accepts multiple algorithms and does not strictly validate the alg header, an attacker can forge tokens — for example, by switching from RS256 to HS256 and signing with the public key as the HMAC secret. Always enforce the expected algorithm on the server side.
• Oversized tokens. Developers sometimes put too much data in the payload — entire user profiles, permission lists, session state. JWTs are sent with every request, usually in an HTTP header. Large tokens increase bandwidth, may exceed header size limits, and slow down every API call. Keep payloads minimal: user ID, role, expiration.

For most applications, JWTs with ES256 signing and short expiration times provide a good balance of security, performance, and simplicity. If you need token revocation, pair them with a lightweight server-side check against a revocation list or use opaque refresh tokens that can be invalidated independently.

The quantum threat: a real risk that demands preparation now

Quantum computers use fundamentally different physics — qubits that can exist in multiple states simultaneously — to solve certain problems exponentially faster than any classical computer. For encryption, this has specific and well-understood consequences.

What quantum computers will break

In 1994, Peter Shor published a quantum algorithm proving that a sufficiently powerful quantum computer could break RSA, ECC, and Diffie-Hellman — essentially every asymmetric algorithm in use today. This is not theoretical speculation: it is a proven mathematical result. The only open question is when quantum hardware will be powerful enough to execute it at scale.

Symmetric ciphers like AES are affected less severely. Grover's algorithm effectively halves the security of symmetric keys — making AES-128 inadequate but leaving AES-256 with a comfortable 128-bit security margin.

"Harvest now, decrypt later"

This is the threat that makes quantum computing an urgent concern today, not in some distant future. Intelligence agencies and sophisticated attackers are already intercepting and storing encrypted traffic, planning to decrypt it once quantum hardware matures. This strategy is well-documented in NSA's post-quantum cybersecurity guidance.

For any application that handles data with a long confidentiality lifespan — medical records, financial data, legal communications, intellectual property — this is a present risk, not a hypothetical one.

Post-quantum cryptography: the industry response

In 2024, NIST finalized its first post-quantum cryptographic standards:

• ML-KEM (CRYSTALS-Kyber) — a key exchange mechanism that replaces ECDH. Already deployed in production: Chrome and Cloudflare use a hybrid X25519 + ML-KEM key exchange by default.
• ML-DSA (CRYSTALS-Dilithium) — a digital signature scheme that replaces RSA and ECDSA signatures.
• SLH-DSA (SPHINCS+) — a backup signature scheme based on hash functions, providing algorithmic diversity in case lattice-based schemes are found vulnerable.

What this means for your applications

If you are building or maintaining applications today, here is what matters:

1. Upgrade to AES-256. This is the simplest step and provides quantum-resistant symmetric encryption at virtually no performance cost.
2. Enable hybrid key exchange. Modern TLS libraries (OpenSSL 3.x, BoringSSL) already support X25519 + ML-KEM. Enabling it protects connections against both classical and quantum attacks.
3. Audit your cryptographic dependencies. Know where RSA and ECC are used in your stack — these are the components that will eventually need migration.
4. Plan for larger keys and signatures. Post-quantum algorithms produce larger keys than ECC. Test that your protocols, certificates, and storage can accommodate them.

End-to-end encryption: the gold standard for private messaging

End-to-end encryption (E2EE) means that messages are encrypted on the sender's device and can only be decrypted on the recipient's device. The service provider — whether it is a messaging app, email platform, or cloud storage — cannot read the content, even if compelled by a court order or compromised by an attacker.

How modern E2EE works in practice

The Signal Protocol, used by Signal and WhatsApp, combines multiple encryption techniques into a layered system:

1. Elliptic curve key exchange (Curve25519) — two devices establish a shared secret without ever transmitting it over the network.
2. The Double Ratchet algorithm — generates a new encryption key for every single message. If an attacker somehow obtains one key, they cannot decrypt past or future messages. This property is called forward secrecy.
3. AES-256 or ChaCha20 — encrypts the actual message content at high speed.
4. HMAC authentication — ensures messages cannot be tampered with in transit.

The result is that every message has a unique key, keys are never reused, and compromise of any single key is contained. This is why security researchers consistently recommend the Signal Protocol as the state of the art in messaging security.

The group messaging challenge

E2EE in one-on-one conversations is a solved problem. Group chats are significantly harder. When a group has 50, 200, or 1000 members, the protocol must handle several additional complexities:

• Key distribution at scale. Every message must be encrypted so that all current group members — and only current members — can read it. The Signal Protocol uses a mechanism called Sender Keys: each participant shares a symmetric key with the group, and messages are encrypted once rather than once per recipient. This keeps group messaging performant even at large sizes.
• Member changes. When someone joins or leaves a group, the encryption keys must be rotated so that the new member cannot read past messages and the departed member cannot read future ones. WhatsApp and Signal handle this automatically, but it adds latency and overhead — particularly in large groups with frequent membership changes.
• Multi-device support. If a user has a phone, a tablet, and a desktop client, each device has its own encryption keys. The protocol must ensure all devices can decrypt group messages while keeping forward secrecy intact. Apple's iMessage protocol and Signal's multi-device architecture take different approaches to this trade-off.

For businesses building group collaboration features — team chats, project channels, shared workspaces — these are not theoretical concerns. The architecture choices made early in development determine whether E2EE is feasible at the scale the product will eventually need.

Instagram's E2EE reversal: a cautionary tale

In December 2023, Meta rolled out default E2EE for Messenger and began extending it to Instagram Direct Messages. The engineering effort was massive — Meta's team described the multi-year infrastructure overhaul required to rebuild features like search, link previews, and spam detection without server-side access to message content.

Then, in March 2026, Meta reversed course. The company announced that Instagram will remove E2EE from Direct Messages on May 8, 2026. Unlike WhatsApp, where E2EE is the default for all users, Instagram's encrypted messaging was only available as an opt-in feature in select regions — and Meta cited low adoption as the reason for shutting it down.

This reversal is significant for several reasons:

Privacy as a feature, not a guarantee. Instagram's E2EE was never truly "default" — users had to opt in on a per-chat basis, and it was only available in certain countries. This stands in stark contrast to WhatsApp, where every message has been end-to-end encrypted since 2016 with no user action required. The lesson: if encryption is not on by default, adoption will remain low, and that low adoption becomes the justification for removing it.

Regulatory pressure wins. Governments in the US, UK, EU, and Australia have pushed back hard against E2EE in messaging, arguing it hampers investigations into child exploitation and terrorism. The UK's Online Safety Act includes provisions that could require platforms to break E2EE. The EU's proposed "Chat Control" regulation would mandate client-side scanning of messages before encryption. Removing E2EE from Instagram DMs allows Meta to scan messages for child sexual abuse material (CSAM) and other harmful content — aligning with regulatory expectations.

Users lose control. Meta told affected users to download their encrypted messages and media before the May 8 deadline, as encrypted chat history will not be migrated to standard unencrypted chats. Users who want E2EE are directed to WhatsApp instead.

The E2EE landscape today. Here is how major platforms compare after Instagram's reversal:

The gap between platforms that treat encryption as a core architectural commitment (Signal, WhatsApp, iMessage) and those that treat it as an optional feature (Instagram, Telegram, Discord) has never been clearer. For businesses building messaging features, this is the critical design decision: E2EE must be foundational, not bolted on — because optional encryption can be taken away.

What E2EE does not protect

For any application that implements or relies on E2EE, it is important to understand the limits:

• Metadata. E2EE protects content, not metadata. The platform still knows who messaged whom, when, how often, and from which IP address. Research by EFF has shown that metadata alone can reveal sensitive information about relationships and behavior patterns.
• Endpoint compromise. If the device itself is compromised — by malware, spyware like Pegasus, or physical access — the attacker reads messages after decryption. E2EE protects data in transit and on the server, not on a compromised device.
• Cloud backups. If chat backups are stored unencrypted in iCloud or Google Drive, E2EE is effectively bypassed. WhatsApp offers encrypted backups, but users must enable them.
• Human factors. No cryptographic protocol prevents a recipient from taking a screenshot or being socially engineered into sharing a conversation.

How it all fits together in a real application

When we build secure applications for our clients, encryption is not a single feature — it is a layered architecture where each type of encryption plays a specific role:

1. Elliptic curve cryptography establishes trust between parties and securely exchanges keys — with smaller, faster keys than older RSA-based approaches.
2. Symmetric encryption (AES-256) handles the high-speed encryption of actual data — files, messages, database records, API payloads.
3. Digital signatures and checksums prove authenticity and detect tampering — from signed API tokens and software updates to verified webhook payloads.
4. End-to-end encryption ensures that even the service operator cannot access user content — essential for healthcare, legal tech, finance, and any application where user privacy is a regulatory or competitive requirement.
5. Post-quantum readiness protects long-lived data against future threats — a consideration that forward-looking businesses are already addressing.

The right encryption strategy depends on what you are building: a mobile app handling personal data, a B2B platform processing financial records, a messaging feature, or an IoT system. Each has different threat models and regulatory requirements, and the encryption architecture should match.

References

• Shor, P. (1994). Algorithms for quantum computation: discrete logarithms and factoring. Proceedings 35th Annual Symposium on Foundations of Computer Science.
• Grover, L. (1996). A fast quantum mechanical algorithm for database search. arXiv.
• Cohn-Gordon, K. et al. (2016). A formal security analysis of the Signal messaging protocol. Cryptology ePrint Archive.
• NIST (2024). Post-Quantum Encryption Standards.
• NSA (2022). Post-Quantum Cybersecurity Resources.
• Meta Engineering (2024). End-to-end encryption on Messenger.
• EFF (2013). Why metadata matters.
• Citizen Lab (2021). Hooking Candiru: another mercenary spyware vendor comes into focus.