Thank you! The only question I have - how receiving part will know IV? Do we send IV with message itself every time? Is IV visible for "everyone" or encrypted as well. :)? What is best practice? Thanks a lot.
Yes you have to send it with the message itself. And it is not encrypted. You can put it at the Fron of the message. You can just put it at the front. Even if they know what bytes are the iv they won't be able to determine the secret key
supposed that i capture the encrypted message 500 with IV of 3 then resend it back to the server then I would still win the game. I just have to capture the encrypted message every time I win, it does not matter if the message is different every time I win, i just resend that encrypted message and still win. Is the IV sent along with the encrypted message? Is the IV one time use only?
@@cimbot yes that's correct, and how you send the iv is secret. So it could be appended to the back, or it could be put at the front, or he could do something crazy like every other character is the iv
You should all be asking why now: Why not only rely on a random seed? IV+Key is just one password. You can remove key and only use a random IV and will end up with the same result. Key would just be there if you don't want to generate larger random numbers at the expense of security.
It you need a certain amount of information e.g. 512 bits and you want to use 256 bits as a static key e.g. 32 letters you can use one half of the 512 bits as the static key which means the second half must be random. You see? Having two parts makes no sense, its stupid. Just forget about the static key and use 512 random bits which you can use to feed two algorithms. Having a static key which you reuse is just one more point of failure if you use not enough random bits of cause. Also handling the information of the static part is another unnessary problem.
Thanks. It is very informative. I have a few doubts though - 1. if we are generating IV on client-end then how will the server decrypt the message correctly ? 2. if we be generating a new IV each time we have to send a new message. Then how will we keep track of those IVs on both client-side and server-side ?
The iv is like a public key basically. So we simply tell the server what that key is, each message will have its own IV. You send the IV with the message, it's part of the same payload
You send the iv with the message. It is a known size, so how you send it is up to you. You could send it as the first x amount of characters in your message. Or the last x characters. Or maybe every other character for the first 2x characters is part of the iv.
@@matthewventures ok, so we do not send IV separately, we mix it up in final encrypted message. And server-end knows how to extract IV from encrypted message also, it must also have information about the key and the algorithm to decrypt the message using both IV and key.
Why not use random key then? Basically you just used pair (IV, Key) as new Key, and it is as random as IV, so what is the point of keeping one part fixed, when you always use it in bundle with random part?
The receiver needs to know the key in order to decrypt the message. If you used a random key then it would just be another IV. The key is randomized, it's just not randomized every message. The whole point is that the key is something special that the receiver needs and that we can hopefully give to them in a way that someone who is reading all of the messages in between us will not have access to. For example, we might bundle the key in the source code of the program rather than having to send a key over the network. So that even if they can see all of the internet packets, we are passing back and forth which will include the IV and the message itself. It will not include the key. They would have to hack the client to to get the key.
Yes you have to send the iv. From my understanding the standard practice is that you don't even encrypt the iv. So I think it is sufficient to just send it in the front of your payload. But it's basically like a public password if you want to think of it that way, as if you have a public password and a private password
@@matthewventures so if IV is the 'public password' and encrypted message is the 'private password' then, is the algorithm used to achieve the encryption the hidden link which hackers need to decode ? and what about key. Does server know the key in this case ?
@@samartajshaikh2601The algorithm is known to everyone. What's secret is the key that the both parties share and don't send to each other. They only send the iv. Also hi, I'm currently trying to write an encrypted chat program from scratch for fun and I randomly stumbled on this video while learning about these things.
If IV is public then the player can guess the key again: 1. IV=4, Message=600 2. IV=3, Message=500 It is very clear that each increment in IV results in 100 increment in message.
Thanks man, I was going over WPA for my CCNA and I had no idea what the hell an Initialization vector was, and they did not care to explain it.
Thanks! This helped a lot. I had an idea of what IV was, but I needed an example to solidify my learning.
Thanks. Your explanation really helped. Great job 👍🏽
Great video Bud explained it well
that was amazing ! thank you for the great service
Amazing video, thanks a lot
Thank you. This helped a lot.
Thank you! The only question I have - how receiving part will know IV? Do we send IV with message itself every time? Is IV visible for "everyone" or encrypted as well. :)? What is best practice? Thanks a lot.
Yes you have to send it with the message itself. And it is not encrypted. You can put it at the Fron of the message. You can just put it at the front. Even if they know what bytes are the iv they won't be able to determine the secret key
This was super useful, thanks
critical mind explanation...thanx a lot
supposed that i capture the encrypted message 500 with IV of 3 then resend it back to the server then I would still win the game. I just have to capture the encrypted message every time I win, it does not matter if the message is different every time I win, i just resend that encrypted message and still win. Is the IV sent along with the encrypted message? Is the IV one time use only?
yes iv is one time use only. a new one is created for each message and sent with the message.
Amazing!! Thanks!!
Thanks!
Thanks for the video!
In this example, it means that the IV will also always be sent between client-server right? Besides the encrypted message
But the hacker won't know that the transmitted IV is important to decrypt the data, because they doesn't know that it's an IV
Am I correct?
@@cimbot yes that's correct, and how you send the iv is secret. So it could be appended to the back, or it could be put at the front, or he could do something crazy like every other character is the iv
@@matthewventures I see, thank you very much Matthew!
Great explain
Good Man, it easy understand
блядь, а как расшифровывать-то????
NO WAY! It's Kevin McCallister from Home Alone! From protecting homes to protecting Networks. Love to see it 😁😁
Definitely looks like the Home alone boy Macaulay Culkin 😁
thanks a lot but what are similarities between DES and AES plz
thats a pretty interesting menu bar
Awesome
then how does the server decrypting know this IV to be able to decrypt?
You don't encrypt the IV. You just deliver it. You're like, "here is the encrypted message: 4747477438 and here is the IV: 54".
Thanks
You should all be asking why now:
Why not only rely on a random seed?
IV+Key is just one password.
You can remove key and only use a random IV and will end up with the same result.
Key would just be there if you don't want to generate larger random numbers at the expense of security.
How would you decrypt data then?
It you need a certain amount of information e.g. 512 bits and you want to use 256 bits as a static key e.g. 32 letters you can use one half of the 512 bits as the static key which means the second half must be random. You see? Having two parts makes no sense, its stupid. Just forget about the static key and use 512 random bits which you can use to feed two algorithms.
Having a static key which you reuse is just one more point of failure if you use not enough random bits of cause. Also handling the information of the static part is another unnessary problem.
nice example
Thanks. It is very informative. I have a few doubts though -
1. if we are generating IV on client-end then how will the server decrypt the message correctly ?
2. if we be generating a new IV each time we have to send a new message. Then how will we keep track of those IVs on both client-side and server-side ?
The iv is like a public key basically. So we simply tell the server what that key is, each message will have its own IV.
You send the IV with the message, it's part of the same payload
but you still need to send the IV with the encrypted message (because no one else would be able to decrypt it), right?
Yes you send the iv, that's right.
How does the receiving end of the encrypted data know what IV was used to decrypt?
You send the iv with the message. It is a known size, so how you send it is up to you. You could send it as the first x amount of characters in your message. Or the last x characters. Or maybe every other character for the first 2x characters is part of the iv.
@@matthewventures ok, so we do not send IV separately, we mix it up in final encrypted message. And server-end knows how to extract IV from encrypted message also, it must also have information about the key and the algorithm to decrypt the message using both IV and key.
what does IV stand for ?? please PS: great video
Initialization vector
Why not use random key then?
Basically you just used pair (IV, Key) as new Key, and it is as random as IV, so what is the point of keeping one part fixed, when you always use it in bundle with random part?
The receiver needs to know the key in order to decrypt the message. If you used a random key then it would just be another IV. The key is randomized, it's just not randomized every message. The whole point is that the key is something special that the receiver needs and that we can hopefully give to them in a way that someone who is reading all of the messages in between us will not have access to. For example, we might bundle the key in the source code of the program rather than having to send a key over the network. So that even if they can see all of the internet packets, we are passing back and forth which will include the IV and the message itself. It will not include the key. They would have to hack the client to to get the key.
@@matthewventures Okay, I see, thanks
But he must also send the iv so that the server can decrypt, right?
Yes you have to send the iv. From my understanding the standard practice is that you don't even encrypt the iv. So I think it is sufficient to just send it in the front of your payload. But it's basically like a public password if you want to think of it that way, as if you have a public password and a private password
@@matthewventures so if IV is the 'public password' and encrypted message is the 'private password' then, is the algorithm used to achieve the encryption the hidden link which hackers need to decode ?
and what about key. Does server know the key in this case ?
@@samartajshaikh2601The algorithm is known to everyone. What's secret is the key that the both parties share and don't send to each other. They only send the iv.
Also hi, I'm currently trying to write an encrypted chat program from scratch for fun and I randomly stumbled on this video while learning about these things.
i thought iv was four lol
Hello bro
Bro do you actually use that much softwares ??? Clean that task bar it makes me stressful
If IV is public then the player can guess the key again:
1. IV=4, Message=600
2. IV=3, Message=500
It is very clear that each increment in IV results in 100 increment in message.
That's only because my algorithm is simple. You'd have to decrypt the dull aes process which they cannot do.
Thanks@@matthewventures