UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 13.9 Free with a free account
What Encryption Actually Does to Your Data
Ethics in Technology · Chapter 13: Digital Espionage, Online Threats, and the Science of EncryptionSection 13.9 · lesson 86 of 11612 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Ethics in Technology.
Lesson complete
Earn the 3 college credits for Ethics in Technology
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: The Mathematical Building Blocks Behind Symmetric and Asymmetric Encryption Methods →← From Ancient Ciphers to Modern Algorithms: How the Art of Secret Writing Has EvolvedNext lesson: The Mathematical Building Blocks Behind Symmetric and Asymmetric Encryption Methods →
In this lesson
Confidential data, integrity checks, signatures, and certificates.
- Explain plaintext, ciphertext, keys, and reversible encryption.
- Distinguish protection at rest from protection in transit.
- Compare encryption with hashing and password verification.
- Explain signatures, certificates, and public key infrastructure.
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,536 words). Read along, or search it.
Chapter 13
What Encryption Does
Encryption supports familiar activities, from sending messages to logging into accounts and paying online. We will follow what happens to data, then distinguish secrecy from integrity and identity. Plaintext and ciphertext name the readable original and the transformed version of that data. Keys control the relevant cryptographic operations, and their protection is essential to practical security. Encryption protects stored information with mechanisms suited to that setting. Network traffic needs its own protection while traveling between the communicating endpoints. Hashing instead produces a comparison value; it is not a substitute for confidential storage. Digital signatures connect data with a key, while certificates help identify whose key it is. By the end, choose the appropriate tool and explain the limits of its protection.
Basic Vocabulary
Plaintext, Ciphertext, and Keys Describe Different Parts of the Process
Begin with plaintext: the original information in a form an authorized user can read. It might be a text message, a document, or a record stored in a database. Ciphertext is the transformed result produced when an encryption algorithm operates on that plaintext. Its purpose is to prevent someone lacking the necessary secret from obtaining the protected content. The key supplies information that controls the cryptographic operation, according to the chosen algorithm. Think of it as key material, commonly represented by bits, rather than a physical object. Describing a key as a long number can help, but remains a simplified analogy. The algorithm and key work together. Merely renaming a file does not encrypt its contents. Keeping these terms distinct makes it easier to explain both the transformation and its reversal.
Encryption and Decryption
A Suitable Key Allows the Intended Reversal
Read the diagram from left to right: plaintext enters the encryption operation with its key. The operation produces ciphertext, which can be stored or transmitted without exposing its original content. Later, the appropriate decryption operation and key recover the original readable data for authorized use. The keys are those required by the scheme; encryption and decryption need not use identical values. That designed reversibility distinguishes encryption from the one-way comparison tool we will discuss next. However, unreadable-looking output alone provides no assurance that the method actually protects the information. A secure design needs appropriate parameters and sound implementation. The relevant secret keys also need protection from unauthorized access. Weak encryption or a stolen decryption key can defeat the intended confidentiality of the ciphertext.
Where Data Is Protected
Storage and Network Movement Need Complementary Protection
Encryption at rest protects stored information, including data on disks, in databases, and in backups. An encrypted drive or an encrypted database column illustrates protection applied to a stored copy. Encryption in transit protects information while it travels across a network between communicating endpoints. HTTPS traffic between a browser and website is a familiar example of this network protection. If the receiving system saves readable data, transit encryption has not automatically encrypted that storage. Conversely, encrypting a stored file does not automatically secure its journey across an unprotected connection. Applying both protections addresses separate gaps, rather than making either one redundant in the system. Authorized processing can still make data readable, so access controls and endpoint safeguards remain important. Storage encryption depends on protected keys. Consider what an unlocked system already allows someone to access.
Hashing versus Encryption
The Tools Have Different Purposes and Outputs
Encryption and cryptographic hashing solve different problems, even though both transform data through defined algorithms. Encryption is designed to be reversed through the appropriate decryption process with the correct key. A hash function has no corresponding decryption operation that restores the original from its digest. A conventional cryptographic hash produces a fixed-length digest from information of different possible lengths. It serves as a compact comparison value, sometimes described as a fingerprint of the input. Small input changes typically produce extensive digest changes, helping reveal differences when values are compared. Secure hash designs resist useful reversals and collisions; they do not make every possible input unique. A hash alone does not keep the original content secret or establish a trustworthy sender.
Integrity Comparison
A File Digest Needs a Trusted Reference
Consider a downloaded file whose publisher provides an expected digest for users to check. First, obtain that reference through a trustworthy source or an appropriate authenticated verification mechanism. Next, compute the downloaded file’s digest using the same specified cryptographic hash function as the reference. Compare the values: a mismatch shows that the checked data differs from the expected version. A matching value supports the comparison, subject to the hash function and the reference being trustworthy. If an attacker can replace both the file and its reference, the replacement can match. That is why the digest’s origin matters alongside the calculation performed on the downloaded data. The fingerprint analogy describes comparison. It does not prove a file is harmless or identify its author. Use a suitable cryptographic hash and authenticate the reference, rather than relying on appearance alone.
Password Verification
Store a Protected Verification Value Instead of Recoverable Passwords
For password verification, a service generally needs to check a submitted password rather than recover it. Keeping a reversible original creates additional exposure when the database or its decryption secrets are compromised. A suitable password hashing scheme instead stores a protected value that supports checking submitted credentials. It includes a salt, so identical passwords need not produce identical stored verification results. A computational cost makes each attempted guess more expensive for someone holding stolen verification data. One-way processing does not stop an attacker from testing a candidate and comparing its result. Ordinary fast hashing alone is therefore inadequate protection. Use an appropriate salted password hashing scheme with a suitable computational cost. Strong passwords and the surrounding account controls also matter, because hashing cannot remove every login risk.
Digital Signatures
Signing and Verification Bind Data to a Key Pair
A digital signature uses a private key to create a value associated with signed data. The verifier checks that value using the corresponding public key, the signature, and the relevant data. Signature generation often involves hashing, although the precise procedure depends on the chosen signature algorithm. Modern signing is not generally described correctly as encrypting a hash with a private key. A signature algorithm defines its own signing and verification operations, distinct from encryption and decryption. Successful verification provides evidence that the signed data and matching key have the expected relationship. It does not automatically tell you whose key was used. That identity connection needs a trustworthy verification mechanism. It also does not conceal the message, so confidentiality requires a separate suitable protection mechanism. A signature can accompany either stored data or information being transmitted between communicating parties.
Three Signature Assurances
Authentication, Integrity, and Evidence Depend on Valid Trust
The source groups the benefits of signatures under authenticity, integrity, and non-repudiation, meaning attribution evidence. Authenticity concerns whether the signature was generated using the private key matching the verification key. That assurance depends on trusting the public-key identity. Preventing unauthorized use of the corresponding private key is also essential. Integrity concerns detecting changes to the signed data through a secure algorithm and correct verification. Non-repudiation describes evidence that can help attribute the signature to a signer in a later dispute. It does not automatically settle every legal question about a human being’s actions or intentions. A compromised key, weak procedures, or unreliable identity binding can affect what the evidence supports. Protect signing keys and maintain trustworthy processes, rather than treating successful verification as unlimited proof.
Certificates and Authorities
PKI Connects Public Keys with Verified Identities
A signature can check against a public key without establishing that key’s claimed identity. Public key infrastructure, usually shortened to P K I, addresses this underlying trust gap. A certificate is a digital document that binds a public key to an identity. For a website, that identity can be its domain name rather than every claim about its operator. A certificate authority performs the required checks and signs certificates according to its applicable policies. The larger infrastructure includes certificates, authorities, standards, policies, and the validation processes used by relying parties. Trust therefore depends on the actual identity checks and accepted issuers, not merely a familiar-looking document. Certificates support a validated key-and-identity connection; they do not eliminate the need to protect private keys.
A Browser Connection
Certificate Validation Supports the Intended Website Connection
In a typical certificate-authenticated browser connection, the website presents its certificate to the browser. The browser validates a certificate chain that connects the presented certificate with an accepted trust anchor. It also checks the intended domain and relevant validity requirements for the connection being established. The secure protocol uses authenticated key information to help protect traffic with the intended peer. These checks explain how certificate-based infrastructure supports trust between parties that have not previously met. But a domain certificate does not guarantee that the website’s operator is honest or its content accurate. A deceptive site can still use encrypted connections, so inspect the intended address and context. Take certificate warnings seriously, and distinguish connection protection from broader judgments about the website.
Review and Apply
Choose the Tool for the Actual Protection Goal
First, explain the key’s role: it controls the cryptographic operation and the appropriate way to reverse encryption. Second, explain the storage gap: protected network traffic does not automatically protect a readable saved copy. Third, explain password hashing: verification can avoid routinely recovering an original password from stored data. Include salts and computational cost in that answer, because stolen values can still be subjected to guessing. Fourth, describe signatures as supporting authenticity, integrity, and attribution evidence through suitable algorithms and trustworthy keys. Fifth, explain that certificates and infrastructure add a validated connection between a key and its claimed identity. Choose encryption for secrecy. Choose hashing for an appropriate comparison or verification task. Choose signatures for authentication and evidence, with trustworthy identity bindings. Throughout, protect keys, check identity bindings, and safeguard endpoints where authorized processing makes information readable.
About Ethics in Technology at UPI Study
Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses
Compare: Cybersecurity vs Ethics in Technology · Which ethics course?
Why take it here
Why students take Ethics in Technology with UPI Study
Where the credit goes
Universities that work with NCCRS
Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About What Encryption Actually Does to Your Data
What is the difference between encryption at rest and encryption in transit?
What is the difference between hashing and encryption?
Why should passwords be hashed with a salt instead of encrypted?
Does the HTTPS padlock mean a website is safe?
About the Ethics in Technology course
How many college credits is Ethics in Technology?
How much does Ethics in Technology cost and what is included?
Which universities accept UPI Study credits?
How long does Ethics in Technology take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Ethics in Technology.
116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →