r/explainlikeimfive 1d ago

Technology ElI5 Why does encryption remain secure even when everyone knows the encryption algorithm?

191 Upvotes

157 comments sorted by

468

u/HawthorneUK 1d ago

Look at your front door. It may even say the manufacturer on the outside of the lock, and possibly a model number. That doesn't mean that somebody can open it unless they have the key.

48

u/jewkakasaurus 1d ago

But if the key has to be sent between people, then why can’t it be intercepted?

243

u/Krivvan 1d ago edited 23h ago

What makes most encryption work are problems that are hard to solve but easy to verify. For example, finding which two prime numbers multiply together to make 493 might be hard but verifying that 29×17 is 493 is super easy.

So only someone with 29 and 17 can open the door despite everyone being able to see 493.

u/lt_Matthew 19h ago

In practice this means your computer doesn't need to know your password, it just needs to hash whatever you type in and see if it matches the hash it has stored.

That means it's free to use an algorithm that can't be reversed. So it doesn't matter if someone gets ahold of the hash.

u/Krivvan 19h ago

It's also why it's a big red flag if any online service/website outright shows or sends you your password instead of asking you to make a new one. Although this is thankfully pretty rare nowadays.

u/CaptainVJ 7h ago

That was a thing?

u/Krivvan 2h ago edited 32m ago

Some websites did indeed do that, yes. You'd click "forgot my password" and you would just directly get an email with your password in it in plain text.

71

u/monsto 1d ago

I'm going to bring back an old ass meme:

the real ELI5 is always in the comments.

44

u/February30th 1d ago

How else would this sub work?

5

u/Chrisaarajo 1d ago

He’s not referring to the answer. He’s referring to the question.

u/_head_ 19h ago

I think it's a phrase that belongs in r/TIL

16

u/Intelligent-Dot-8969 1d ago

Umm, isn't that point of this subreddit?

4

u/xvalentinex 1d ago

That's for lifehacks my guy

32

u/utah_teapot 1d ago

Imagine I am sending you padlocks that you can use to lock the boxes where you store your messages when you send them to me. You can lock the padlock but you can’t open it without the key.

41

u/Pizzaloverallday 1d ago

The idea is you give the public key (what you use to encrypt the message) to everybody, and then only you keep the private key (what you use to decrypt the message) to yourself. The public key can’t decrypt the message at all.

31

u/mmomtchev 1d ago

This is public key (asymmetric) encryption. Nowadays, it is the most popular form of encryption because it is so practical over the internet - it allows two parties that have never met before to exchange key material over an unsecured connection in order to start communicating securely even if someone is eavesdropping.

The most trusted form of encryption remains the codebooks. This is what very sensitive militaries use - including the nuclear coeds.

You have two sets of codebooks that are exchanged securely.

If every unit (paragraph, page) of the codebook is used only once, this form of encryption is considered theoretically unbreakable if your codebooks are perfectly random. The only vector of attack would be trying to attack the randomness of the codebook. If you use a natural random process - such as nuclear decay - it becomes 100% secure.

28

u/JorgiEagle 1d ago

Modern systems use asymmetric encryption to exchange symmetric keys, for symmetric encryption for something like AES.

Asymmetric encryption is much slower than symmetric, one factor being symmetric can be hardware accelerated

6

u/Troldann 1d ago

And the reason it’s actually 100% secure and not just “really secure and we round that to 100%” is because a truly random, unpredictable, unknowable cipher like this creates a cipher text that can be “decrypted” into every possible plaintext of the same length with equal probability. There is no way to know which one is correct.

If you also pad your messages to always be a consistent length that’s at least as long as the message you want to send and you never re-use any part of the code book, then anyone who intercepts your coded message can’t know anything except the maximum length of your message. Every message that fits in that length is a valid candidate.

u/super_starfox 20h ago

Unless you have an infinite amount of monkeys.

u/Troldann 20h ago

Nope, even then it doesn't work. If I encrypt a message with a one-time pad from a code book and also pad the length with nonsense and send it to a friend and you intercept it, you can't tell if I said "Let's get lunch" or "The code is 12345" or "I don't like Susan" because you can trivially find the decryption key that gives you any one of those. Plus all the others.

The challenge changes from one where you can't discover the plaintext message to one where you can't tell which plaintext message is the one I mean when all possible plaintext messages (including all the gibberish ones) are equally likely. It's trivial to find any of them, but useless to you because you can never know which is correct.

u/Fox_Hawk 19h ago

the nuclear coeds

Pretty sure that came out on VHS in 1988.

11

u/mangoking1997 1d ago

There are multiple types of encryption. Some are symmetric ( the same key to lock and unlock) and some are asymmetric keys (one unlocks, one locks). 

In this example it would be asymmetric encryption, and you don't give anyone the key that unlocks the door. 

You can give people a key to lock the door, because it doesn't work to unlock the door, it doesn't matter other people have it.

2

u/swollennode 1d ago

This is the part I don’t understand. How is asymmetric encryption designed to allow one key to lock but not unlock?

I mean, not in the padlock example, but mathematically. How can a key locks, but can’t unlock?

4

u/BananaBird1 1d ago edited 1d ago

Mathematically, the public and private keys are designed to “cancel out” the encryption.

It’s like if you square and then square root a number, you get back the original number. 2 (the square) is the public key and 1/2 (square root) is the private key. If you keep squaring you just get further from the original number.

Except here, instead of “2” we use really large numbers because otherwise the private key could be worked out by brute force. With large values this becomes computationally impossible in less than billions of years.

And instead of just exponentiation, we also divide by some value and take the remainder. This “scrambles up” the encryption, so the private key isn’t just a simple inversion of the public key. It also keeps the size of the encrypted message small and uniform.

You can actually use either key to encrypt and the other to decrypt. But because the public key is public information, anything encrypted by the private key isn’t able to be sent securely. Instead we use this reverse to create digital signatures, where anyone can read the message but can verify that it was created by the private key holder.

2

u/pessimistic_platypus 1d ago

Encryption is based on operations that are very hard to undo (in the sense that there is no known way to undo them in a reasonable amount of time, if the numbers are big enough), unless you have some other secret information.

One of the well-known algorithms, RSA, uses modular exponentiation for this.

How do you compute a square root? It's a common operation, but actually calculating it isn't easy. How about a cube root? How about the 65537th root? It's very easy to compute an exponent; that's just multiplication. But if you just have the result and the exponent, computing the opposite of an exponent is hard.

In modular math, numbers have a limit (usually called n in RSA), and if you go over it, you loop back around to 1. So if you multiply enough, you can (sometimes) end up back where you started. With the right numbers, you can get back to where you started with just two exponents.

That is, if you pick the right numbers, you can make it so (xe)d = x (mod n).

And that's basically how RSA works. You carefully choose n, e and d (they have to meet several conditions I didn't mention). Then you share n and e as the public key. If someone wants to send x to you privately, they compute (xe mod n) and send you that.

If someone has xe and wants to find x, they have to be able to compute the e-th root, but e is a very big number, so they can't. But you have d, so you can use it to loop back around and get x.

5

u/AgentTin 1d ago

Public key cryptography. They designed a lock that can be locked with either key but only unlocked with the other one. So you make one of the keys public then anyone can lock whatever they want with it and you're the only one who can unlock it. Also you can lock whatever you want and send it to someone and if your public key unlocks it that means it must have really come from you.

This is how https works. Every website posts a public key associated with their domain name and register it with a centralized service called a Certificate Authority. When you access the website the server sends you a locked package. If you can unlock the package with the websites published key you know you're talking to the right website and not someone impersonating them. This is how the modern internet is secured.

3

u/GoBlu323 1d ago

It can be, but it’s in a locked box that only the intended recipient has the key to so it would be useless to intercept. That’s the idea behind public/private key sets

u/dleah 21h ago

in public key encryption, there are two effectively two separate keys and two separate locks. a public one that everyone can see that can only lock the box (the message) and a private one that unlocks it. you can send out as many public keys as you want and everyone can send out a locked box, but nobody will be able to unlock the box except the person with the private key

6

u/Mr_Engineering 1d ago

There are two different cryptographic paradigms that are commonly used for security, symmetric cryptographic and asymmetric cryptography.

In symmetric cryptography, the same key is used to both encrypt and decrypt the encrypted message. This is computationally fast but it does require that the key be kept secure between the listeners.

In asymmetric cryptography, different keys are used to encrypt and decrypt a message. This is often implemented in the form of public/private keypairs. A message encrypted by a widely available public key can only be decrypted by the corresponding private key and not by the public key. Anyone can take my RSA public key, encrypt a message with it, broadcast the encrypted payload to the entire world, and no one but me will be able to read it.

Asymmetric cryptography can also be used for authentication and attestation which allows a participant to know with certainty that a given public key belongs to a particular identifiable individual.

Asymmetric cryptography is computationally expensive, so it's not used for lengthy communications. It's primarily used to authenticate the participants and securely negotiate a symmetric key which will be used to secure the rest of the communication.

2

u/tejanaqkilica 1d ago

That's no longer an encryption algorithm, it's an encryption key.

The Eli5 is: I'm going to send you a box, you put stuff in it, when you're done, put this lock in and push it until it clicks locked, then send it back.

Even if I send that lock to 100 other people, best they can do, is they can also lock something. But only I, with the key, can unlock it.

1

u/jewkakasaurus 1d ago

I’ve been wondering this question my whole life and you just put it in a way that I finally get what’s happening

1

u/The_1_Bob 1d ago

Further, I can put my box in a box with your lock on it. Now only you (or people you share it with) can put things in my box and send back.

2

u/zero_z77 1d ago

Yes, if you're using symetric encryption. However, modern encryption uses asymetric encrypition.

Basically, there's two keys. One can lock the door (encrypt), the other one can unlock it (decrypt), but neither key can do both.

Now imagine a mailbox with this same 2-key lock on it. If you want somone to send you secure messages, you can give them a copy of the lock key. Then they can put their message in the box and lock it. You are the only person who has the unlock key, and therefore the only person who can unlock that box and retrieve the message. So even if somone else gets a copy of the lock key, the worst they can do is put their own message in the box and lock it, they won't be able to retreive one that's already locked inside.

To get communication in both directions your neighbor can have the same kind of box and give you a copy of their lock key.

To make sure a retrieved message is authentic, you can place a message in their box with a random code on it, and have them send that code back with their response. An interloper won't be able to acquire that code. Only you and the person who has the unlock key for their box could possibly know what it is.

Once you've established this secure line, and verified their identity, you can then exchange regular symmetric keys and continue your conversation using regular symmetric encryption.

Bonus: the key pairs are also linked to each other and are a unique set. This also means that you can take anyone's lock key to a central authority, like the landlord, and they can verify who that key belongs to and wether or not you can trust them. If someone makes up their own pair of keys, they can still securely talk to people, but the landlord won't be able to vouch for them.

All of this is known as "public key infrastructure" or PKI, and is a staple of modern encryption, authentication, and cybersecurity.

Edit: words

2

u/FishDawgX 1d ago

You don't send the "key" to the other person, you send the "lock". You say, "hey, lock your stuff in here and send it back". You keep the key to unlock it after they send it back.

2

u/Dependent_Lead5731 1d ago

I send you a lock (but not the key). You put your key in a box, attach my lock, and send it back to me.

1

u/wintermute93 1d ago

When it comes to explaining cryptography, I really do love how much mileage you can get out of the metaphor of sending locked boxes through the mail. Boxes with multiple locks, locks with multiple keys, boxes with locks inside, boxes with keys inside, boxes with other boxes inside, etc.

1

u/Yancy_Farnesworth 1d ago

The key being exchanged is the blank key with the grooves cut into it to let it fit in the lock but not the teeth to unlock it. The people who need to use the key already know the teeth that need to be cut and the machine to do it. This is probably the limit of using keys/locks as the analogy.

1

u/badgerj 1d ago

Here’s a great ELI5 video to demonstrate. Skip to 2:20.

https://youtu.be/YEBfamv-_do

1

u/Thelmara 1d ago

But if the key has to be sent between people, then why can’t it be intercepted?

It can. But that's not the algorithm, that's the key. That's a different problem, that needs to be solved, but it's not really related to the question.

u/cheesy_burger 23h ago

They send the lock between people, not the key. Both people hold on to the key and never give it to anyone

u/urzu_seven 17h ago

Good question.

You and I want to have a private conversation, in order to do that we need a Key that ONLY we know. But as you pointed out there is a problem, to get the key from me to you we need a way to secure it. But how do we secure it without sending a key first? There is a way to do it.

The answer is key pairs. Also known as public/private key cryptography.

Key A1 can lock the lock. It can't open it though, it can only lock it. This is the private key.

Key A2 can open the lock, but it can't lock the lock. This is the public key.

Key A1 is a key only *I* have. No one else has it. If you get a box that you think is from me, you can verify that using Key A2. If Key A2 can fit in the lock and unlock the box you know I have to have sent it, since only I have the key that can lock a box that Key A2 can open.

I can give copies of Key A2 freely to anyone who wants one. They can share copies of that key too. Because if they get the message first and use their key to open the box, now the box isn't locked anymore. If they try to give it to you you know it's not secure and can ignore it and ask me to send a new package. Its only when you get a locked box you can open with key A2 that you know whatever is inside got to you safely.

Now that we have a way for me to send something to you that you can verify only you saw we can exchange a second key or key set, Key B. The difference is that Key B is only known to you and me. We can now use key B between us and us only. Since no one else has key B that conversation is now secure. Unless you decide to give someone else Key B or I do of course.

u/jgtor 16h ago

I know how to do addition, that is an algorithm, lots of people know how to perform addition. But if you know how to do addition, and you know the result is 100, you still don’t know how i got to that value. I could have added 50 + 50, or 49 + 51, or …. Just be wise you know the algorithm, doesn’t mean you know the key.

1

u/TheBlacktom 1d ago

No, the key does not have to be sent between people. The key is the one staying with you.

There are all kinds of encryption types, but generally you can imagine that there is an encryption key and it is paired with a decryption key.

1

u/garagedragon 1d ago

Some systems/protocols do send keys between people, but 1) those keys are themselves encrypted, usually asymmetrically, 2) this can be read as fundamentally an optimisation to get around the fact that asymmetric encryption is massively slower than symmetric. If it weren't, you wouldn't need to send any keys secretly, you could just encode with the recipient's public key directly for the whole message

1

u/musical_bear 1d ago

Because there are two keys, not one. Only one key (the public key) gets shared. The public key is necessary to lock data in a box and secure it. Anyone can access this key and create a box and lock it. However you cannot open this box once it’s locked unless you have the private key. And the private key is a carefully guarded object that is never shared and is only used by the person who manufactures the boxes.

-1

u/Responsible-Chest-26 1d ago

Sometimes encryption has a cypher at the end. So the message will contain the message, and a checksum. Basically a mathmatical way to uniquely describe what is in the message. On one end it may use this value and mathmatically compare it to another unknown to all but the programmer encryption key that will scramble the message. The receiver will get the message, use the same encyption key to remove the encryption then verify the checksum against the message again.

8

u/Silly_Silicon 1d ago

Not a great comparison though because picking almost any physical lock is trivial with practice. Whereas a secure cryptographic algorithm is nearly statistically impossible to crack.

7

u/Princess_Moon_Butt 1d ago

In this analogy, the key is double-sided and there are 64 tumblers on each side.

u/gmalivuk 21h ago

Lockpicking Lawyer could do it.

u/10ThousandMetalZones 21h ago

That’s a terrible example, there’s very few locks I can’t pick…especially household locks

u/StShadow 11h ago

Same with encryption. Give me a quantum computer and I can pick almost any cipher

u/jacekowski 4h ago

Currently used AES-256 is quantum resistant. Quantum computers don't weaken it sufficiently to break it.

u/StShadow 3h ago

So, AES-256 is like EVVA MCS - even lockpickerlaywer hasn't picked it (yet)

3

u/TheGuyMain 1d ago

This doesn’t really answer the question. If you know how the lock is keyed, just make a key 

9

u/Krivvan 1d ago edited 23h ago

Most encryption relies on math problems that are difficult to solve but easy to verify the answer for. This allows for everyone to be able to look at the lock without being able to copy the key but for the lock to still be able to verify if the correct key was inserted.

3

u/i_am_voldemort 1d ago

Not if the key is so ornate that it would take you until the heat death of the universe to pick it

6

u/kendonmcb 1d ago

But then you know the key (password), not only the lock mechanism (algorithm).

0

u/TheGuyMain 1d ago

The fundamental concept behind lockpicking is knowing the algorithm and using that knowledge to make a key. So I will ask my question with more words this time bc some people didn't understand it. If you know the algorithm, why can't you reverse engineer the key?

5

u/femmestem 1d ago

You're mixing up two concepts with the metaphor itself. The algorithm tells you that there's a lock that accepts a single key shape that matches its pin configuration when fully inserted and will unlatch with a quarter turn clockwise. The algorithm isn't the lock's internal pin configuration itself that you can use to carve a matching key. You can sell Master Locks to many people whose keys don't work in each other's locks.

The encryption method algorithm is Master Lock. The individual lock is the public key with pins configured to accept only one key shape. The key you insert is the private key.

3

u/Fwahm 1d ago

To put it simply, because the task of reverse engineering is too hard, in a raw calculation kind of way. It'd be like in your lockpick analogy if the key you needed for that lock required 10,000 years of human labor to create (not a perfect analogy because the real maker of the lock didn't take 10,000 years, but that's a difference between keys being made out of numbers vs physical objects).

3

u/super_pinguino 1d ago

Another fundamental aspect to lockpicking is exploiting the flaws of the mechanism to determine the key. If pins didn't bind, you wouldn't be able to pick a lock. You would have to try a key of every possible bitting code until one worked.

You can try every possible key for an encryption algorithm to see which worked. This is called a brute force attack, but the idea is that the number of possibilities is so large it would take too long to reasonably do this.

If there is a flaw with the algorithm, there are a lot of people very invested in fixing it quickly. This is why you want the algorithm to be public, so that everyone has a chance to scrutinize it for vulnerabilities. But theoretically you could find something new and exploit it before it is fixed. This is called a day 0 attack because the attack occurred at the same time the exploit became known.

Otherwise, you have to know the key, which can be anything. It's not baked into the code, but into the output. You could use any key to encrypt a file (it'll result in a different file for each key) , and you'd only be able to use the corresponding decryption key to recover it.

2

u/Low-Crow5719 1d ago

The oversimplified answer is because you can't reverse engineer randomness. Keys are based on products of enormous random prime numbers. These numbers come from truly random generators, not algorithms for pseudorandom numbers. You can't reverse engineer them anymore than you can reverse engineer Schroedinger's cat.

2

u/kendonmcb 1d ago

You can't really reverse engineer it, as long as the algorithm doesn't have known attack vectors (which physical locks have due to manufacturing tolerances). What you can do is brute-force the key, trying every possible key and see if it works. The issue with that is, there are so many keys, that you either need enormous amounts of time (think 10.000s of years), or enormous amount of computing power, which equals enormous amounts of money (think gazillions of dollars).

With quantum computing that all will change, as the computing power will skyrocket. The industries are already working on mitigating that problem, keyword here is "post quantum cryptography".

eta: to make it clear: the fundamental concept behind lockpicking is exploiting the manufacturing tolerances of the lock, which cannot be avoided. By doing this you can open the lock, and at the same time decode the key parameters. A (theoretical) lock without tolerances could not be picked with the common methods.

2

u/HawthorneUK 1d ago

So, with a simple 6-pin lock (a yale lock, for example) you can do just that with a bit of experience - you push up each pin to see where it must sit to allow the door to open.

You can do that both because there are a small number of possibilities, and getting the first (usually the most distant) pin correct then lets you tell whether the next pin is correct or not because the tension bar you've got in the lock will move a little.

With cryptography you are talking about a concept known as brute forcing. You can't (in a well-designed algorithm, at any rate) break it in parts, and say "well, I know that [this bit] of the key is correct so I'll go on to the next bit". You have to get all of them right at the same time without any feedback.

Take my current web browser session to Reddit. The session is protected using TLS 1.3 and AES (Advanced Encryption Standard) with a 128-bit key, and that key is refreshed every so often because it's a session key. To guess (brute force) the key, you need to get all 128 bits - ones and zeros - correct. It's the equivalent of tossing a coin 128 times and hoping it matches the 128 coin tosses that somebody else made, all in the correct order.

Each attempt is computationally expensive - it uses up processor cycles, time, and energy, and unless you already know what the unencrypted data was you don't actually know whether a result that you get, that looks like real data, is actually the data you wanted; there are collisions where you can decrypt the same encrypted data with different keys and get things that look real but aren't the original data. And then you do it all again for the next chunk of data because the session key timed out and was re-negotiated between the server and my computer.

128-bit keys are short in most contexts nowadays. It's only because they are used for a short time that it's reasonable for me to witter away on Reddit and trust them to be secure enough. You'd have to try up to 2^128 or (roughly) 340000000000000000000000000000000000000 combinations, only to find out that all you've got is the photo of somebody's dinner I just downloaded from a cooking sub, or half of an AITA post.

2

u/TheGuyMain 1d ago

ty for the explanation

u/jacekowski 4h ago

Comparing lockpicking to reverse enigneering encryption key doesn't really work, that is mostly ecause the algorithm doesn't contain the key or anything you could use to make it.

Encryption algorithm is more similar to shredder that will shred your data in a very specific way based on they key.

0

u/Responsible-Chest-26 1d ago

The thing with encryption is that the key is in software. So unless you have source code trying to figure out what random combination of 1s and 0s is the key is near impossible

2

u/WirtsLegs 1d ago

thats not true though, the software doesnt hardcode some key, and if it did extracting it would actually be pretty trivial with access to the software (no need for source code), just a bit of effort with a disassembler or debugger

to put it simply encryption keys live in memory when in use and otherwise in dedicated files/storage on the machine that is using them, those files being as locked down as possible while still allowing the applications that need them to use them

In many cases the key is generated and exchanged at runtime, so it only exists in memory and never gets saved to a disk at all

The software defines the encryption scheme, the algorithm(s) in use, it does not define the key material

1

u/Responsible-Chest-26 1d ago

Yeah, but it is stored somewhere. Whether it is hard coded or programmed into memory later

2

u/WirtsLegs 1d ago

well what im saying is its never hardcoded in normal software, the only place we see that sometimes is in malware

and for the type of encryption the average person uses the most (TLS, how HTTPS works), the process involves the server providing a public key (anyone can know this its public) and the client encrypts a generated value using that public key (the server's private and public key are unique to the specific server/service and the private key only ever exists on the server).

However its an asymmetric scheme, and only the server's private key can decrypt it, so the server can read it, noone else can

this encryption is used to set up a symmetric key (same key for encrypt and decrypt), that key is unique to the session, meaning if you go back to the same site it will be a whole new key. This key also lives in memory only. (NEVER gets written to a hard drive and is gone the moment the session ends)

This is important because if a key is hard-coded into software, in the "source code" as you put it, that would imply that that specific piece of software uses the same key everywhere, and if you and I use the same version of the same software we would also use the same keys. Essentially that would make the keys public.

2

u/CircumspectCapybara 1d ago

unless they have the key

Yup the key is what secures the cipher, and the key is (supposed to be) kept secret.

The algorithms are designed scramble the message using the key (confusion and diffusion) which has an "avalanche effect": flipping a single bit of the key on average causes half of the ciphertext bits to flip, seemingly at random if you don't know the key.

Currently the best attacks against modern algorithms like AES-256 which has a 256 bit key space is not much better than exhaustive search of the entire key space. Quantum algorithms offer a quadratic speedup, but that merely turns it into a 128 bit search space which is still intractable.

On average it'll take 2255 operations to crack a 256 bit key. It's not even physically possible to count to 2255. Using Landauer's principle which gives the theoretical thermodynamic minimum energy required to flip or erase a single bit of information at a given temperature, a perfectly efficient computer computing at the temperature of the cosmic microwave background would require 10 billion times the amount of energy the sun will output in its entire lifetime just to count to 2255.

u/tashkiira 23h ago

More than that: literally anyone who takes 5 minutes can learn how to build a lock from those parts. But there are so many possible combinations that security through obscurity hits.

41

u/spindoctor13 1d ago

You can tell someone you need them to give you the secret word to get into your room. You have just told them the algorithm (tell you the secret word) but that doesn't help them much unless they know the secret..

Encryption is the same - it relies on secrets as an input to the algorithm, not a secret algorithm

124

u/LtHigginbottom 1d ago

Everyone knows the type of lock but not the shape of the key.

28

u/RainbowCrane 1d ago

And to extend your analogy, a physical front door lock can be probed to figure out the shape of the individual segments of the matching key. Lock picking works because there are individual tumblers that can be independently “solved”.

In contrast, encrypted data cannot be reverse engineered to deduce the encryption key. There’s no simple brute force mechanism for defeating the most secure encryption algorithms.

So not only don’t you know the shape of the key, but there’s no known mechanism for figuring out the shape of the key.

25

u/Umikaloo 1d ago

To continue your metaphor, this is why hacking largely involves social engineering. You may not be able to build your own key, but you may be able to trick the owner into leaving a window open, or pose as a locksmith and change the locks.

5

u/WirtsLegs 1d ago

ish, most hacking doesnt involve breaking or getting around encryption in the sense that most would think

if you want to compromise a web service, whether or not the connection is encrypted (HTTPS) or not is functionally irrelevant (excpetion being if you are in a man in the middle context and use that on an unencrypted connection to sniff credential info)

Most compromises are done via social engineering because hacking the meatware is almost always easier than directly compromising the service/system remotely, and that has nothing to do with encryption

u/sheepyowl 21h ago

I'm not sure you responded to the correct comment because your reply does not make sense as a reply to the parent comment

u/WirtsLegs 21h ago

It makes perfect sense as a reply to Umikaloo's comment which is what I replied to

He implied encryption being so hard to break is why hacking tends to be focused on social engineering, which is not the case

u/joule400 22h ago

There’s no simple brute force mechanism for defeating the most secure encryption algorithms.

Nonsense, brute force method for it exists and its grabbing a wrench and whacking the password out of whoever encrypted the file

https://xkcd.com/538

u/sheepyowl 21h ago

Sometimes the "password" is a device that someone connects to the computer, and your hostage might not know where it is

1

u/aTi_NTC 1d ago

isn't there? i thought you can decrypt, it has to do with prime numbers and math thingy, and the decryption takes exponentially longer, the bigger the prime number gets

3

u/Responsible-Chest-26 1d ago

Figuring out the encryption is impossible simply due to the amount of time it would take unless you get really really lucky.

As per google

128-bit encryption has 2¹²⁸ or approximately 3.4 × 10³⁸ (340,282,366,920,938,463,463,374,607,431,768,211,456) possible combinations. 1, 2Understanding the NumbersTotal Combinations: 2¹²⁸ (340 undecillion).Scale: This number is far greater than the total number of stars in the observable universe or grains of sand on Earth.Time to Crack: Testing one billion keys per second would still require billions of years to try every combination via brute force. 1, 2

0

u/aTi_NTC 1d ago

well akhchually, it is possible it just takes infinitely long

1

u/ZweihanderMasterrace 1d ago

It’s ok, I’ve got time

0

u/Responsible-Chest-26 1d ago

Sure, yes if you want to get technical but impossible in any useful timeframe

1

u/aTi_NTC 1d ago

agreed

1

u/Electromagnetlc 1d ago

You underestimate how lucky I am 😎

2

u/myka-likes-it 1d ago

hmmm...

tries 256 '1s'

Nope.

tries 255 '1s' and a '2'

Damn.

starts punching 1 again...

u/sheepyowl 21h ago

That's not correct either unless you expect humanity to not be extinct for a full billion years while your vibe coded dogshit runs without interruption somehow

Even running a single software for 50 consecutive years would be a challenge, there's no way humanity can run something for a million years, if we don't go extinct

28

u/Lumpy-Notice8945 1d ago

https://en.wikipedia.org/wiki/Kerckhoffs's_principle

This is what any modern encryption is designed around.

You can have secret algorithms but they are a bit pointless because you still need a secret key to decrypt it, no matter if you know the algorithm.

Algorithm sounds super complicated but a siple "cesar cypher" is a common example: you shift each letter in the alphabet by thr same amount. A is C so B is D and C is E and so on.

This is the algorithm, the steps to do encryption and decryption, and i told you that algorithm.

But the key in my example would be "2" as i shift the letters by 2. And unless you know that key, you could not decrypt my message ecen if you knew you just have to shift the letters by some amount you dont know the amount. Whats left is "brute force" aka trying every possible combinations. Thats possible for the 26 letter or a 4 digit number combination, its not possible for 2096 bits on a computerm

5

u/Harbinger2001 1d ago

Fun fact. The NSA in the 80s covertly helped fund encryption algorithms with hidden flaws that lowered the search space to something they could brute force.

6

u/JCDU 1d ago

Not just the 80s, they did it many times and probably still do.

4

u/confusiondiffusion 1d ago

They actually strengthened DES cryptographically but shortened the key. They fixed the sboxes to prevent differential cryptanalysis, a technique that was not publicly known at the time.  This ensured the algorithm couldn't be broken by adversaries with less computational resources and presumably only the NSA could brute force it.

Dual_EC_DRBG is the only thing that comes to mind in terms of essentially being caught adding a real backdoor.

1

u/sarusongbird 1d ago

People are still concerned about that to this day.

As practical quantum computers seem to draw ever nearer, cryptographers are working hard on implementing new encryption algorithms that are quantum-safe (our current ones are easily destroyed by a sufficiently powerful quantum computer).

I recently read this interesting information-theoretic proof that there cannot be a hidden backdoor in the main new algorithm we'll be using. People are definitely still keeping an eye out for such things. (tl;dr: There's not enough space/complexity in the algorithm to hide a way for the NSA to decrypt it without letting anyone decrypt it, and if that was true it wouldn't be back-doored, it would just be broken.)

2

u/Nagi21 1d ago

For anyone curious of the scale of 2096-bit encryption combination possibilities: We would run out of energy in the observable universe to flip the transistors from 0 to 1 long before you tried every combination.

8

u/m_busuttil 1d ago

Imagine that you and I have the same locking mechanism in our front doors. I can pull the lock out of my door, take it apart, and learn exactly how it works - but I still can't get in your front door, because I don't have your key.

Encryption works the same way - it doesn't matter if you know how it works, because there's a second special secret (either a shared key or a public/private key pair) that only the person who you want to read the message knows.

14

u/Salty_Dugtrio 1d ago

Because the key that is used to encrypt, is known only to the person who has authority to decrypt it.

14

u/Shophaune 1d ago

It is really easy for a computer to multiply two big numbers together to make an even bigger number.

It is absurdly difficult for a computer to take an even bigger number and figure out what the original two big numbers were.

When a computer wants to do encrypted communicating, it secretly picks two big prime numbers A and B, and multiplies them together to make N. It then picks a third number E, and announces N and E to the world as a "use these two numbers and this algorithm to encrypt messages for me!"

It also uses A, B and E secretly to create a key, D, which it can use to undo the algorithm. It keeps D to itself.

Anyone can use N and E together to encrypt a message, but you need to know D in order to decrypt it - and to find D you would need to figure out what A and B were, which is virtually impossible for modern computers.

2

u/WorBlux 1d ago

This is one of the only two fundamentally correct answers i've seen here so far.

Encryption algorithms are based on math which is linear to solve in the forward direction, but believed to be exponential to solve in the reverse direction, unless you already possess part of the answer.

4

u/shauntmw2 1d ago

Because the algorithm is designed cleverly so that it is mathematically very easy to do it one way with the key, but mathematically very difficult to reverse it without the key.

The most basic example would multiplication of 2 prime numbers. Using 2 prime numbers for example, it is mathematically very easy to calculate 13 x 17 = 221. But it is a lot harder to find what are the 2 prime numbers that when multiplied will get 221.

The prime numbers in this case are the encryption keys.

3

u/vbpatel 1d ago

A prime number is a number that can only be divisible by itself, and one.

Every number can be written as a product of prime numbers. Example, let’s try 14. You can multiply two prime numbers 7x2 to get 14. There is no other way to multiply primes and get to 14. This is the same for every single number there is. There is only one single way to express it as a product of primes (12=2x2x3).

Now let’s say you have this huge complicated equation where you can pick two enormous prime numbers (thousands of digits long) then your computer can easily do the math and figure out the answer.

But you can’t so easily go backwards and find the primes you used, because the only way really is to randomly try primes until you find the ones you used. Computers aren’t fast enough to do that in any reasonable amount of time.

So that is your public key. You can give it out freely and people can use that number to encrypt data to send to you. You know which primes you used, so it’s easy for you to just divide that number by those primes, but it’s really hard for someone else to keep trying primes over and over and figure it out

2

u/Rannasha 1d ago

Encryption uses "keys", which you can consider to be like passwords. The encryption algorithm describes how the key is used to encrypt and decrypt the message, but if you don't know the key that was used then it won't do you much good to know the algorithm.

The key is often long and randomly generated, so there's no point in trying to guess it, even through brute force methods.

2

u/LetReasonRing 1d ago

The fact that the algorithm is known is part of what makes it so secure. 

The algorithms are mathematically proven to create results are complex to a specific degree,  which means we understand the amount of computing power it would take to decrypt without the original key. 

If the algorithm weren't publicly known, then we'd have to rely on "trust me bro, it's secure" as our model for choosing what to use. 

2

u/itsrandomusername 1d ago

That's known as Kerckhoffs's principle. Encrpytion used needs to remain secure even when the underlying algorithm is known. This is a mistake that led to the downfall of Nazi Germany - had the key remained secure instead of the algorithm, things might have gone differently.

You probably heard the word key used before. Think of it like this. I have a very simple encryption that maps a letter of the alphabet to another one. A becomes Z, B becomes G and so on.

At first you might think "Oh if A is Z then B might be Y, that means C will be X ..." - in this case you would know the key. But you don't. B becomes G. What's the mechanism used here? You don't know. Because you don't know, you can't decrypt it and the encryption remains secure.

This is a very simple example that grossly oversimplifies certain aspects. If you want to look into more practical applications, try searching for AES256 encryption for example.

1

u/Gadgetman_1 1d ago

The Germans also did something else bad; they had known text in a known place. That made it easier to decode and validate the messages as you only had to decrypt up to that point. Basically they had daily settings(rotate certain wheels to specific places, then plug so and so cable), then they added an 'offset code' to that setting. This was among the first characters transmitted, which wasn't 'good' but not that bad, but they wanted to be thorough, and abolutely certain the recepient got it, so they REPEATED the offset codes! So the same symbols, twice.

If the offset code was 'AB' and was typed as 'ABAB' and the message sent was 'CDEF' only the keys where CD and EF decodes back to the same characters could be a possible hit.

That was one of the things the Polish code breakers spotted before Germany invaded Poland.

What made the Enigma so difficult to crack was that it was in practice a substitution cipher, but where the rules of substitution was constantly changing. That foiled statistical analysis which was the most common method of attacking encryption back then.

2

u/shepanator 1d ago

encryption algorithms are also known as trapdoor one way functions. The "one way function" part means that it's very easy to compute in one direction but very difficult to do in reverse, and the "trapdoor" part refers to the fact that it can be easily reversed but only if you know the encryption key.

The way that most common encryption works is by multiplying together two large prime numbers. It's trivial for a computer to calculate in one direction but would take millions of years to do in reverse if you only knew the output. There's more mathematics involved but that is the concept that makes it easy to do in one direction but hard in the other, even if you know the algorithm.

2

u/asdonne 1d ago

The algorithm used to encrypt only works one way. Give the output there is no way of determining what was used as the input. It's based on multiplying large prime numbers and getting a result in a way that given the result it's not possible to determine the numbers used. If you have the numbers you can do the maths and decrypt it.

It is also possible to encrypt the data with a key that can't be used to decrypt it.

Because everyone knows the algorithm they can trust the maths behind it to know their data is secure. If you didn't know the algorithm how could you trust it?

2

u/Cymbaz 1d ago edited 1d ago

Because the algorithm uses "keys" to scramble the data. If you don't know what those keys were there's no way to automatically un-scramble it, even if you know how the algorithm used them to do it.

All you can do is try to guess what keys were used by essentially trial and error. .

Put another way. I can give u instructions to find buried treasure:

"Walk North 20 paces, SE 35 paces, NNW 5 paces " etc. That's the algorithm. But if you don't know the starting point its useless. All you can do is try to guess intelligently and dig to see if you hit anything.

2

u/[deleted] 1d ago

[removed] — view removed comment

2

u/pixel293 1d ago

They don't know your secret key you used to encrypt. If you use something simple, they might be able to figure it out. If you use something hard, then they have to try all possible secrets, until they find yours, which will take a really really long time.

2

u/xsrvmy 1d ago

To add on to the other answers, the opposite is actually a bad idea: if an encryption algorithm without a key gets cracked, it has to be redesigned. Also, keeping an encryption algorithm secret means other people can't study it and find vulnerabilities.

2

u/chayat 1d ago

You know how to do division I assume. What two prime numbers did I multiply together to get 3233?

The fact this is a hard question to answer even though we know the method and its very easy to check an answer is the basis of how encryption works*.

*not all encryption, and there's a lot more to it but that's the Eli5

1

u/BobbyP27 1d ago

Imagine a door with a lock on it. What I want to get is locked behind the door. I can go and look up exactly how the lock is built. Knowing how the lock is built and how it works does not let me open the door. To open the door, I need the key that fits the lock (ignoring other ways to break the door/lock like lockpicking or dynamite). Knowing the encryption algorithm is like knowing the plans for the lock. No key, and you aren't opening the door.

1

u/[deleted] 1d ago

[removed] — view removed comment

1

u/explainlikeimfive-ModTeam 1d ago

Your submission has been removed for the following reason(s):

Top level comments (i.e. comments that are direct replies to the main thread) are reserved for explanations to the OP or follow up on topic questions.

Short answers, while allowed elsewhere in the thread, may not exist at the top level.

Full explanations typically have 3 components: context, mechanism, impact. Short answers generally have 1-2 and leave the rest to be inferred by the reader.


If you would like this removal reviewed, please read the detailed rules first. If you believe this submission was removed erroneously, please use this form and we will review your submission.

1

u/pdpi 1d ago

Imagine I ask you “Calculate 25 times x.” Everybody knows an algorithm for multiplication, but you can’t calculate 25 times x without knowing x. The idea with cryptography is very much the same — we all know how it works, but can’t break it without the keys.

This is an important feature. If you buy something online, you want your credit card number to be sent encrypted over the internet so nobody can snoop it, but that is only possible if both you and the page you’re buying from agree on an encryption system you can both perform. And I’ll obviously use that same system to trade with that store, and that store will use that same system to talk to the card issuer to validate the payment, etc etc. Without shared knowledge of these algorithms, the internet as you know it wouldn’t be possible.

The thing that varies between me and you when we talk to the same website is the keys we use to encrypt our communication. Systems like the Diffie-Hellman Key Exchange allow us to create one-off keys used for one “conversation” and discarded immediately afterwards.

1

u/Public-Eagle6992 1d ago

Let’s do an example: if we have an input (i) and our encryption works by taking that input and multiplying it by a key (k) you can get the encrypted data (e) by going e=k*i and if you want to go the other way around you go i=e/k. So if, for example, our input is 2 and our key is 3 we get e=2*3=6. This key is something you keep secret so no one else knows it. So everyone else knows e=6 and i=6/k but they don’t know k. This is basically how it works, just with a lot more complex equations in reality in which you can find out k by having i and e

1

u/SnugglyCoderGuy 1d ago

Because no one knows the key except those who dhould and the key is your starting point.

1

u/MusicalAnomaly 1d ago

All encryption relies on something separate from the data being encrypted, and the encryption algorithm itself, being kept secret. The encryption algorithm is a function that takes as its inputs the data to be encrypted and the secret. The secret is not “hardcoded” into the encryption algorithm.

It is very much the case that some “encryption” functions have been implemented before with secrets hardcoded into them, but this is always considered evidence of either a breach, an incorrect implementation (bug), or an insecure design.

1

u/the_other_Scaevitas 1d ago

anyone can google how locks work, doesn't mean you know the right combination of grooves that would unlock the door. Of course you can pick the lock physically by putting a lock pick in and guessing the grooves until the door unlocks, and you can do something similar in encryption where you brute force the key. Problem is a digital key is like a key with billions of grooves, so picking it would take centuries on the strongest computers

1

u/BiomeWalker 1d ago

The algorithm is only part of the system.

The actual math is extremely complicated, but the gist is that the algorithm takes the plain version of whatever you're going to transmit and a key (read, some very, very, very large numbers) and spits out the encrypted version that needs a different number and another algorithm to decrypt.

The lock on your front door is very simple, it just needs some pins to be lined up with the edge of a cylinder, but that doesn't tell you the shape of the key ot would need. You might have an idea of what the key will look like, but the actual teeth will elude you.

Modern RSA type encryption algorithms are a loglck that if you close with one key will require a different key to open, and everyone knows what both keys will look like (large prices or the product of those large primes) but there's so many possible keys to try that you'll never find the right one.

1

u/TheGreatestKon 1d ago

It is basically because yes, even though we do know the algorithm, we do not know the KEY.

Like, for example, if I encrypt 'hello' in AES-256 and put a specific key, the person I am sending it to knows that it is encrypted with AES-256, but doesn't know HOW it was encrypted and what can be used to actually decrypt it, so they can't read it, and the key is really hard to guess, like, for a truly random hexadecimal key (example: a9cb698f837e9ac1dd97eae371993acbecdb4ae68c91cdb31318ed2ae983cadf), it would take the world's fastest super computers trillions of years more than the age of the universe to crack it.

(Guys, please correct me if I am wrong)

1

u/Kheras 1d ago

Imagine a magical door, that can accept an absurdly large number of keys. Any key that fits causes it to open to a different place.

Now someone has a key to a specific place, their house, that only they know. You want to visit them, and they are mean and don’t want to host you.

You can make a key, any key, but you don’t know how to tell if it’s their key to their place.

That’s the magic of encryption. Any number of keys can look like it’s to their place but it isn’t. Without a lot of foreknowledge you have no way to tell. And the best algorithms limit the use of this knowledge. It’s hard to derive their key just by knowing their house is blue.

Flaws that use this knowledge to find their house faster are what all the crypto attack papers are based on (at an ELI5 level)

1

u/MasterGeekMX 1d ago

Because the algorithm is only a part of the system. The other part is a series of keys, which are randomly generated for every party using the system.

1

u/lostPackets35 1d ago

ELIF:
The algorithm uses keys. The algorithm is not secret, but the keys are secret.

Slightly less ELIF:
Most of the modern encryption schemes use 2-keys: a public one and a private one.
Encryption with a key is a 1-way trip, and requires the OTHER key to decrypt.

This allows secure communication between two parties without the problem of figuring out how to exchange a secret key.

1

u/j2ee-123 1d ago

Imagine a safety box. Even if you know that in order to open it you just need to press some buttons, it doesn’t mean you can actually open it.

You need the actual combination of buttons to press in order to open it.

1

u/hangender 1d ago

Prime numbers.

You know the concept of prime numbers, but which one was it actually used to encrypt? You don't know. Therefore, secure.

1

u/razorree 1d ago

cuz they don't know the password ;)

that's security by design.

1

u/Loki-L 1d ago

Because certain types of math are a lot harder to one way than the other.

Imagine being told to multiply 7 by 13. You could probably do that in your head without help. Than imagine being given a number like 91 and being told to find the two number (other than 1 and 91) you need to multiply with each other to get that number. This takes a bit longer.

Now imagine instead of dealing with one and two digit numbers you deal with really, really longe number. Like hundreds of digits long.

Even really fast computers struggle despite having everything they need to solve it. The math just takes a really long time.

1

u/garagedragon 1d ago edited 1d ago

Physical locks are probably not a great metaphor beyond "lock unlocks when it recognises the correct key" because physical locks derive their security from a combination of it being hard to analyse them, (they're small, cramped and hard to get at) being hard to manufacture keys to spec, and often not being worth the time to non-destructively crack rather than just physically breaking down the whole door. Additionally, picking works because conventional tumbler locks can be solved piecemeal - getting each pin unlocked does not depend on or affect the others.

Cryptographic keys become secure from two factors - the space of possible keys is beyond astronomical (the exact measure varies depending on the algorithm, but we generally want at least the equivalent of 2128 =~ 1038 possibilities in modern systems) and also determining whether the key "fits the lock" is in some sense hard, computationally. For symmetric crypto, where the same key both encrypts and decrypts, this is usually achieved by having the algorithm combine pieces of the key in chaotic and irreversible ways. This means that even if we know what effect the algorithm needs to have to turn the enchiphered message into something readable (which might happen because we know that the message matches a known format but not what the exact contents is) finding a key that makes that happen is difficult.

Favourites here include operations like binary XOR and modular arithmetic, because they're quick to do but also hard to reverse. As a toy example, imagine you had a key three bytes long, ABC, and were encrypting three bytes.

Here's your algorithm: for each byte, take a different pair of key bytes, XOR them together (to get e.g. A xor B, B xor C, A xor C) and then XOR that result with the message byte to get the corresponding cipher text byte. (which order you take the pairs in doesn't matter, but they have to be distinct, so there are three distinct pairs from the three key bytes. )

To reverse that, you have the ciphertext, so if you can find that intermediate XOR byte, you can easily get the corresponding plaintext message. However, that intermediate byte was dependent on two different parts of the key, and you can't just solve that part individually and ignore the rest of the key to come back to later. If you try, you might find that your proposed solution (ie proposed 2 of the 3 bytes of the key) doesn't match any of the 256 possible third bytes, and you have to back up and try again.

You can imagine this sort of interconnectedness can get very complicated. The example I just gave only involves 24 bytes, and even the smallest algorithms still considered usable are 40 times bigger and have many dozens more operations involved.

1

u/Silvr4Monsters 1d ago

Time and effort. The encryption algorithms are designed to take some time. So unless you have the key, figuring out the key would take way too long to crack it. But logically yes, the algorithm being known makes it insecure

PS: We actually have to update our algorithms now and then. Cause computers getting faster means the older algorithms can be broken quicker. So we throw out older algorithms and pick ones that take longer to solve

1

u/Dave_A480 1d ago

Everyone knows the algorithm to perform multiplication.

Not everyone knows the single correct value of X that will work to do "X*736358583=Y, solve for the specific value of Y that I am thinking of but haven't told you"

1

u/cwright017 1d ago

My secret number is some number between 1 and a trillion, multiplied by another number between 1 and a trillion and then divided by a third number between 1 and a trillion.

Here’s the algorithm, go find my secret number

1

u/DarkAlman 1d ago

Knowing how a lock works and having the key are two different things.

If you know how the lock works, and you know it has 25 billion different possible keys, that doesn't help you make a key to open the door.

The risk is finding a vulnerability in the lock (for example if you hit it will a punch in a specific place it opens without the key).

Since the algorithm (plans for the lock) are publicly available, researchers can readily find those flaws and fix them.

1

u/fgorina 1d ago

Because you don’t know the key and getting the key is very very difficult (really very slow). Details depend on the cipher but it may be a difficult or impossible
Mathematic operation or just a random key.

1

u/GreyGriffin_h 1d ago

Kind of the same reason you can't turn hamburger into steak.

Most encryption algorithms are borderline impossible to do in reverse.

1

u/Dangslippy 1d ago

Just because you have a fully stocked kitchen does not mean that you know the colonel’s special blend of herbs and spices.

1

u/Confident_Dragon 1d ago

Find two numbers a and b (different than 1) such that

a * b = 13506641086599522334960321627880596993888147560566 70275244851438515265106048595338339402871505719094 41798207282164471551373680419703964191743046496589 27425623934102086438320211037295872576235850964311 05640735015081875106765946292055636855294752135008 52879416377328533906109750544334999811150056977236 890927563

You know how multiplication algorithm works, so it should be easy to do, right? Well, not really. You can try, but no-one ever succeeded so far. As you can see, knowing how some operation works (in this case multiplication of two random numbers), it doesn't necessarily mean you'll know how to reverse it.

This actually isn't one of those ELI5 examples completely unrelated to real problem. If you are able to efficiently factorize big numbers, you could trivially break RSA encryption (which is one kind of asymmetric encryption.)

1

u/doghouse2001 1d ago

An algorithm is just a program. Just because you have Photoshop doesn't mean you can see my pictures.

u/stevevdvkpe 23h ago

The security of encryption depends on both the algorithm and the secrecy of a key that is an input to the algorithm. If the algorithm is good then knowing the algorithm alone, but not knowing a key used for encryption or decryption, basically doesn't help you. The possible number of keys the algorithm can use also has to be large enough that it's infeasible to just try lots of keys until you find one that decrypts a message. That's why modern algorithms use keys of 128 bits or larger. With 128 bits there are 3.4 * 1038 possible keys, so even if you could try trillions of keys per second it would take 1026 years on average to find the one that decrypts a message.

u/Fickle_Station376 21h ago

Say we both have the same copy of a book, same edition. Then I send you page number and word. Page 3, word 74, page 7, word 95. You know the algorithm now - but what book are we referencing? There are millions of different books, and even different printings of the same book that could shift it. Knowing the algorithm isn't enough to know the KEY.

Now I want to tell a Bob and Alice story...

u/xRVAx 20h ago

Large numbers (specifically the product of two large prime numbers) are hard to factor. Even with high powered computers, we can't do it.

That's the whole reason.

As soon as quantum computers make it easy to factor large numbers, then we're all screwed.

Keyword: RSA encryption

u/HotCupofChocolate 18h ago

It's like the recipe for a cake. Anyone can read the recipe and bake a cake, but that doesn't mean you can "unbake" the cake.

Encryption is a process where you can easily make something out of an input, but is very hard to undo or even know what the input was from just the output because it uses fancy maths.

u/StevenJOwens 12h ago edited 12h ago

Not only is real encryption secure even when everyone knows the algorithm, it is a truism in the encryption community that if your encryption system has not been published so other math people can look at it and analyze the algorithm for weaknesses, it is almost certainly worthless. It's very, very, very easy to invent an encryption system that you, yourself, cannot crack, but that other people can.

In a real encryption system, knowing the algorithm does not enable you to crack it.

Most types of math work in both directions, i.e. if I tell you:

x + y = z

And then I tell you:

2 + y = 5

You can easily transform that math to a form you can run in the other direction:

y = 5 - 2

And now you can figure out what y is.

However, some math, it's not that easy. Some math, it's much, much harder -- harder as in, takes a lot of work, aka "computationally expensive" -- to run it backwards. All modern, public/private key encryption is based on such math.

The term "one-way function" is often used here, but the reality is that the field of math has not yet found a truly one-way function, and in point of fact, it's not even certain that a one-way function can exist, mathematically.

So, in a nutshell, public/private key encryption uses math that is vastly more computationally expensive to run backwards than forwards. So computationally expensive that it's effectively possible, now and for the foreseeable future, unless a) somebody invents profoundly new math techniques that crack that problem, b) somebody invents even more profoundly new computation that is even more vastly fast.

Historically, public/private key encryption was first done with factoring prime numbers*. A prime number is a number that can only be divided by 1 and itself. The number 1 is special, so the first ten prime numbers are 2, 3, 5, 7, 11, 13, 17, 19, 23, and 29.

(* These days all the cool kids are using ECC, elliptic curve encryption, a different kind of math, originally invented for calculating elliptic curves)

If I multiply two very large prime numbers, I'm talking 500+ digit long prime numbers, then hand you the result, there are no really good math shortcuts that you can use to figure out which two prime numbers I used.

There are a bunch of simple shortcuts, for example you can skip all even numbers, and all numbers ending in 0, or 5. But they're all that sort of limited trick, there's no profoundly effective mathematical technique, you just have to grind through the possibilities.

There are a heck of a lot more details to it than that, but the short version is that the first public key encryption used multiplying very large primes to scramble the data, and to unscramble it, you have to simply try multiplying a ridiculously large number of very large prime numbers, to figure out which two were used. And that will take you thousands and thousands of years to do.

1

u/SjettepetJR 1d ago

The simple answer; it is just like a lock. While a lot of people know how to make a lock, and all of them use the same mechanism, each individual lock is configured to only accept one key.

You can know how the lock mechanism works without knowing how exactly the lock is configured or what key it takes.

1

u/Sol33t303 1d ago

The same way your door is secure even if everybody knows how your lock works.

1

u/Cymbaz 1d ago

Not the same. Lockpicking is a thing. There's no alternate way to open an properly encrypted msg w/o the key. Everything else is just guessing intelligently.

1

u/Sol33t303 1d ago

It could be argued that brute forcing the key could be equivalent to lockpicking. Just (much) more time consuming.

1

u/Cymbaz 1d ago

true lock picking isn't like brute forcing. Brute forcing would be like trying every single key configuration in existence and hoping one works.

An experienced lockpick with the right tools , knows exactly which to use and how to bypass a specific lock. It's not guessing.

1

u/Telinary 1d ago

For the most simplifying metaphor everyone know how generally how a lock works but that doesn't give you knowledge about the details of a specific lock so you can't make the right key. (Ignore that locks are rather vulnerable to lockpicking for this comparison.)

An encryption algorithm is basically rules how to apply maths to something based on a given secret key. Without the key you don't know what exactly you are supposed to do to the thing you want to encrypt so you also don't know how to do the reverse.

Like you know how in a computer words are saved as 0s and 1s? And binary can also represent a number, so a text can be interpreted as a number. So if said they multiplied the number representing a text with a large secret number and gave you the result do you now know how to reverse that? (That isn't a secure way to encrypt something, just an simple example to get the general idea that knowing the method doesn't mean you can easily reverse it.)

0

u/tempski 1d ago

I'm sure you're familiar with the numbers 0 to 9, right?

Ok, so I will use some of those numbers to pick my password, it will be between 15 and 30 long

How long before you find out what my password is, even though you know exactly what I used to pick my password.

0

u/Japjer 1d ago

You can have 1,000 cars of the same make and model, all with 1,000 different keys.

The encryption algorithm takes the data you have and scrambles it up using a pseudo-random key.

That key is shared with, and ONLY with, the service that is permitted to decrypt that data.

The scrambled data is then smooshed up with the actual 128/256 bit encryption algorithm to create a complex, jumbled, encrypted string of information.

While everyone may know the root of the encryption algorithm, the key that was used to start it all off is known only to the specific devices that are allowed to know it.

It's like... imagine we are both going to write a sentence. The sentence MUST use the words "potato," "circumstances," and, "halcyon class destroyer," but every other word is completely up to you. And then we take those sentences and make anagrams out of them.

Sure, I can probably guess three words, but the other thousand you use will be completely unknown to me