# cracking any know algorythm [closed]

So, I know what algorithm is used for a secure connection with TLS v 1.2 for eg. And say I know what websites a person is using for eg me. And I also know what packets that website is sending ofc. Therefore, if i find a default pattern with a message long enough I could try to recover session key by brute forcing and searching for a fragment of default message. Like this:

"my default message is quite long la dee daaaah and so on."

All I got to do is to take part of this message lets say 66% of it and scroll through encrypted data in attempt to recover an entire hidden message. so if i take only "my default message is quite " and produce few keys that will be used against same data all over again and then, if I find full message

"my default message is quite long la dee daaaah and so on."

That means that I have a full key for that particular session and from that point i can read the rest of conversation if i apply this method for both sides - client and server.

The 1st question is: has anyone of you tried this yourselves? and if you did, did you succeed?

The 2nd: Does anyone of you know, if the design of our communication encryption systems, has anything against these attacks. And theoretically, does this method has any chances in compromising the security of such connections?

Because the key lengths are not that high 128 bits is just 16 symbols. So i do not think that playing around with known message and looking for the key that unlocks everything is a big deal. Maybe for a laptop that would be a tough task but if you have a cloud of computers it might solve the problem of computational power.

• >Because the key lengths are not that high 128 bits is just 16 symbols. ---------- You seem to assume that keys consist of letters and digits, like passwords selected by humans. They do not. They are random binary 128-bit strings, which makes the brute force computationaly infeasible even for "a cloud of computers". Maarten gave you the math in his answer. – tum_ Oct 16 '16 at 21:41
• trusting the math and probabilities is 1 thing. but practice is slightly different. like completely "random" rand() function in windows. – user6590212 Oct 16 '16 at 21:57
• True but irrelevant to your own question. You're talking about brute force, so brute force it is. In which case "the math", i.e the number of keys to try is the only thing that matters. If you were to find a vulnerability in the key generation in TLS 1.2 that would be a completely different type of attack.. – tum_ Oct 16 '16 at 22:05
• That brute force is rather making keys based on plane text and encrypted text and then trying these keys on an encrypted text again. brute force is in checking every key but you are not checking every possible combination. you are only fishing the phrase that you expect to find and then try to decrypt the text. since you do not know where your message begins you have to slide from the beginning to the very end of text 1 by 1 like a zip lock. thats what i call brute force. when you do not mathematically calculate what it is but make a guess and check if it is correct. – user6590212 Oct 16 '16 at 22:13
• so if you get a packet and you think you know what text it contains and you work back your key you reapply it to see if it can crack other packets too. that is a very simple way of telling what this method is. my question was if anyone has tried it. practically against real world set up. – user6590212 Oct 16 '16 at 22:16

The 1st question is: has anyone of you tried this yourselves? and if you did, did you succeed?

Sure thing. But if the cipher is Chosen Plaintext (CPA) secure and has a strong enough key (say of strength 128 bits), then you cannot brute force the key. Nor can you recover additional plaintext even if you have, say, 66% of the plaintext already. Actually, a CPA secure cipher (and e.g. AES is CPA secure, to the best of our knowledge) has a stronger security premise.

The 2nd: Does anyone of you know, if the design of our communication encryption systems, has anything against these attacks. And theoretically, does this method has any chances in compromising the security of such connections?

Yes, ciphers do consider CPA security. And if you implement the protocol correctly, it should be CPA secure as well. Ciphers such as AES can be mathematically described. But that hasn't produced any practical attacks as of yet; you're still stuck on finding the key basically.

Note that it is easy to bugger up the protocol implementation, e.g. by introducing a CBC padding oracle. Those attacks to not directly attack the cipher itself, but rather the padding scheme. Those are possible because up to TLS 1.2 authenticate-then-encrypt (with CBC and PKCS#7 padding) was used rather than an authenticated cipher such as GCM.

Because the key lengths are not that high 128 bits is just 16 symbols. So I do not think that playing around with known message and looking for the key that unlocks everything is a big deal. Maybe for a laptop that would be a tough task but if you have a cloud of computers it might solve the problem of computational power.

No, you are completely wrong here. 128 bits of security is considered enough against normal attacks. Attacking a secure block cipher with a 128 bit symmetric key. To get an idea: divide the bits by 10 and then multiply by 3 to get approximately the number of possible keys: that's at least a 1 with 38 zero's behind it. Or, with a calculator, 340,282,366,920,938,463,463,374,607,431,768,211,456 keys to iterate.

Only an advanced quantum computer could make a dent in the security - after which it is easy to upgrade to 256 bit keys, giving you 340,282,366,920,938,463,463,374,607,431,768,211,456 x 340,282,366,920,938,463,463,374,607,431,768,211,456 keys to iterate. This is considered safe even against quantum computers. These machines do currently not exist (to the best of our knowledge).

• Added " Ciphers such as AES can be mathematically described. But that hasn't produced any practical attacks as of yet; you're still stuck on finding the key basically." to try and handle the issue you mentioned in the comments. – Maarten - reinstate Monica Oct 17 '16 at 11:42