3 Types of Encryption to Discuss With Your System Administrator

If you manage a business, a team, or a budget, encryption will come up in conversations with your system administrator, an IT provider, or a vendor. You will be told data is encrypted, passwords are protected, or a connection is secure, and be expected to nod along.

You do not need to become a cryptographer to discuss this well. You need a plain-English picture of the three ideas underneath almost every encryption claim: symmetric encryption, asymmetric encryption, and hashing. Once you know what each does and where its limits are, the right questions become much easier to ask.

This article is a conversation guide for non-technical managers and owners: each type explained, with examples, how they work together, and the questions worth putting to your administrator.

What are the 3 main types of encryption?

Strictly speaking, the first two below are forms of encryption, and the third, hashing, is a closely related technique often grouped with them because it protects information in a different way. Administrators talk about all three together, so this guide does too, while being clear about the difference.

Symmetric encryption uses one key to both lock and unlock information. Asymmetric encryption uses a matched pair of keys, one public and one private. Hashing does not lock information for later unlocking at all: it turns information into a fixed-length fingerprint that cannot be reversed.

Almost everything else you will hear about — protecting files, securing a website connection, storing passwords, checking a download has not been altered — is one of these three ideas, or a combination of them.

1. Symmetric encryption: one key locks and unlocks

Symmetric encryption is the most intuitive of the three. Imagine a locked box and a single key: whoever holds that key can lock the box and unlock it again. In digital terms, data is scrambled using a secret key, and the exact same key unscrambles it back into readable form.

Because the same key does both jobs, symmetric encryption is fast and efficient, even on large amounts of data, so it is the usual choice for bulk information: files, folders, hard drives, and backups. The best-known standard is AES, the Advanced Encryption Standard, standardised by NIST and used widely in software and hardware. When disk encryption or an encrypted backup protects your data at rest, symmetric encryption is doing the heavy lifting.

Its weakness is that everything depends on that one key. If it is lost, the data may be unrecoverable; if it is stolen, whoever holds it can read the data. And two systems sharing encrypted information must first share the secret key itself without interception — the problem the second type was designed to solve.

Questions here are mostly about key care: where keys are stored, who can access them, how they are backed up, and how often they change. In real incidents, poor key handling, not a broken cipher, is usually the cause of trouble.

2. Asymmetric encryption: a public key and a private key

Asymmetric encryption, also called public-key encryption, uses two mathematically linked keys instead of one. One key is public and can be shared freely. The other is private and must be kept secret by its owner. Data encrypted with the public key can only be decrypted with the matching private key, and the pair can also be used in reverse to prove identity, through a digital signature.

A helpful comparison is a postbox. Anyone can drop a letter through the slot, because the slot is public. Only the person holding the postbox key can open it and read the letters inside. You can tell the whole world where your postbox is without giving away your ability to read what arrives.

This solves the key-sharing problem: two systems that have never met can exchange information securely because each can publish its public key openly. The best-known system is RSA, and elliptic-curve methods are also widely used, achieving similar protection with smaller keys. You meet it most often in TLS certificates — behind the padlock in a web browser — and in tools administrators use to sign in to servers.

The trade-off is speed. Asymmetric operations are much slower and impractical for large volumes of data. In practice, as the TLS example below shows, asymmetric encryption is used briefly at the start of a connection, to establish trust and agree a symmetric key, after which the faster symmetric method takes over. Its other weakness is trust: a public key only helps if you are confident it belongs to who it claims to represent, which is why certificates exist.

3. Hashing: a one-way fingerprint

Hashing works differently from both types above. A hash function takes an input of any size — a password, a file, a document — and produces a fixed-length string of characters, called a hash or digest. SHA-256, part of the SHA-2 family, is a widely used example, producing a 256-bit fingerprint.

Three properties make hashing useful. It is one-way: you cannot reverse the process to recover the original input. It is consistent: the same input always produces the same hash. And it is sensitive: changing even one character of the input produces a completely different-looking hash.

Those properties make hashing ideal for checking without revealing. To verify a file has not been altered, compare its current hash with a trusted earlier hash: a match means unchanged, a difference means something changed. For passwords, a system stores the hash, not the password itself, and at sign-in hashes what you type and compares hashes — so it never keeps a readable copy, which matters greatly if its database is ever stolen.

Hashing has limits. It cannot hide data for later recovery, because there is no key and no reversal. And a fast hash alone is not enough for passwords: attackers with a stolen database can test huge numbers of guesses very quickly. Password storage needs a deliberately slow method, covered below.

What is the difference between encryption and hashing?

This is the most useful distinction to take into a meeting, because the two words are often used loosely, even by vendors.

Encryption is reversible, by design, for whoever holds the right key. Its purpose is confidentiality: keeping information secret now so an authorised person can read it later. Stored files, backups, and website connections must be recoverable by the right party, so they use encryption.

Hashing is not reversible. Its purpose is integrity and comparison: proving something matches what it was before, without storing the original. Password and file-integrity checks do not need the original back, so they use hashing.

A simple test helps: does anyone ever need the original information back? If yes, it should be encryption. If the system only needs to check a match, it should be hashing — and talk of decrypting it is a warning sign.

How the three types work together: a TLS connection

The clearest everyday example of all three ideas cooperating is TLS, the technology that secures connections to websites and many other online services, visible as HTTPS and the padlock symbol in a browser. The sequence shows why no single type is enough on its own.

First, asymmetric encryption establishes trust and agreement. Your browser checks the website’s certificate, which contains the site’s public key and evidence linking it to the site’s name, and the two sides use asymmetric methods to agree a fresh secret key for this one connection, without ever sending that secret across the network in readable form.

Second, symmetric encryption carries the conversation. Once both sides share the temporary session key, page content, form entries, and everything else you exchange are encrypted symmetrically, because that is fast enough for real use. When the session ends, that temporary key is discarded.

Third, hashing protects integrity throughout. Hash-based checks confirm that messages have not been altered in transit, so each side can detect tampering rather than quietly accepting changed data.

Notice the division of labour: asymmetric for trust and key agreement, symmetric for speed, hashing for integrity. The same basics sit underneath secure file-sharing for deals, where sensitive documents move between companies over protected connections — a practical comparison of data room vs Google Drive shows how much difference the surrounding controls make once encryption is in place. Listening for which part does which job tells you a great deal about whether a design makes sense.

Which type of encryption is used for passwords?

Passwords should be protected with hashing, not encryption — specifically, with a slow, purpose-built password hashing method such as bcrypt or Argon2, applied with a unique random value, called a salt, for each password.

The slowness is deliberate. A legitimate sign-in happens once and can afford a fraction of a second. An attacker with a stolen database must test millions or billions of guesses, and a slow method makes each guess costly. The salt matters because two users sharing a password still get different stored hashes, so attackers cannot precompute one table of common passwords and match it against every account.

If a vendor says passwords in their system are encrypted, ask a follow-up. Encrypted passwords can be decrypted by anyone who obtains the key — yet well-designed systems never need your password back, only to check it, so they should be hashing it. This one question reveals a lot about a system’s design.

Questions to actually ask your system administrator

You do not need technical knowledge to ask these questions. You need clear answers, in plain language, and a note of what was said. If an answer is vague, that vagueness itself is information.

What encrypts our data at rest? Ask which laptops, servers, and backups are encrypted, whether it is automatic, and whether any storage is an exception. Data at rest is stored data — what is at risk when a laptop is lost.

What encrypts our data in transit? Ask about your website, email, remote access, and cloud connections. Data in transit is information moving across a network, where it could be intercepted if unprotected.

How are keys stored, and who can get to them? Ask whether keys are stored separately from the data they protect, who can access them, and whether access is logged. Keys kept alongside the data they unlock offer far less protection than the word encryption suggests.

How often are keys rotated? Rotating a key means replacing it with a new one. Ask whether it happens on a schedule, when a staff member with access leaves, and whether it has been tested.

Are passwords hashed with a slow algorithm? Name bcrypt or Argon2 and ask directly. Also ask about older systems still using a fast, general-purpose hash, and ask the same of important suppliers.

What happens if a key is lost? Ask whether keys are backed up or held in a recovery arrangement, and whether the business accepts that in some designs a truly lost key means truly lost data. Better to hear that in a meeting than during an incident.

Common misunderstandings worth clearing up

Hashing is not encryption. Encryption is reversible with a key; hashing is a one-way fingerprint. If a supplier describes hashed passwords as encrypted, they may be speaking loosely, but clarify it, because the two designs have very different security properties.

Encoding is not encryption either. Encoding, such as Base64, merely changes how data is represented so it can travel through systems that expect text. Anyone can decode it instantly, with no key. Text that looks scrambled is not necessarily protected.

“Military-grade encryption” is marketing, not a specification. There is no official grade by that name. The meaningful questions are which standard is used, such as AES, whether it is configured correctly, and how keys are managed. A strong algorithm with its key on a shared note is weak protection in practice.

Encryption does not fix everything else. It does not stop an authorised account being misused after a phishing attack, patch outdated software, or help if staff are persuaded to hand information over. It is one essential layer, not a substitute for the others.

Stronger is not a simple scale. A longer key is not automatically right if it is configured badly or managed carelessly. Sensible, standard, well-managed encryption beats exotic encryption handled poorly, every time.

Having the conversation

You are not auditing your administrator; you are making sure you understand, at a business level, how information is protected, and that someone has thought clearly about keys, passwords, and recovery. Bring the questions above, write down the answers, and agree a short list of gaps to close, with owners and dates.

If answers are clear and specific, take reasonable confidence from that. If they are mostly reassurance without detail, treat that as the finding, and ask for the detail in writing. Good administrators generally welcome these questions.

FAQ