Hi. Nice video but the "rand" function from the c stdlib does not produce "real" random numbers. Instead, it uses an algorithm under the hood to generate pseudo random numbers, which will always be the same for each seed. In this case (without calling seed) the numbers will always be the same, meaning if you restart your program you will get the same (random) key again. To get cryptographically secure random numbers, you could take a look on /dev/urandom and /dev/random (if you are on linux).
Yes, you are correct! You, of course, need to seed the random number generator first. I actually learned this in scope of another video that is scheduled to be published soon. Thanks for pointing out, I'll pin your comment. A quick, but significant improvement sufficient for most use cases is to add srand(time(NULL)); at the beginning of the main method. You can improve randomness yourself, using e.g. the process ID: srand((unsigned int)time(NULL) ^ (unsigned int)getpid()); A true complete makeover for absolute unbreakabillity is to use a secure random number generator, either a library or /dev/urandom and /dev/random (just read in a couple of random bytes from there).
this is a nice and simple encryption algorithm! one concern I do have is how do we go about sharing the key and encrypted data securely? Will there be a follow up video for secure distribution?
With the one-time pad, every method of sharing it is less secure than the one-time pad itself. Typically you either use it to encrypt files only locally and keep the key hidden somewhere, or if you use it to encrypt messages, you exchange the key with the recipient in person. And yes, it is (or was) actually done this way for extremely sensitive government-level information.
@@HirschDaniel from what I can tell then, it seems like the name of the game is to keep the encrypted file and key file apart from each other as long as possible (assuming key file was reliably randomly generated) while getting them to the intended recipient. Only when both of them are together will you get back the secret.
@@tkothadev Exactly! Also, you could do a timely separation of both files. Assuming a fixed file size to contain your message, give the recipient a large set of e.g. 100 one-time pad keys. And for each encrypted file that you send the recipient he uses the next key, starting from the first. This way you can exchange keys for the next 100 messages beforehand, only encrypting as you go. To do that, you'd need to adapt the code a bit to generate a key file independently of the encrypted file. But it'd be a solid communication protocol.
@@HirschDaniel thats a good idea! i'll look into it for sure. One thing I'm also wondering is if OTP can be adapted to asymmetric key schemes (like Diffie Hellman), such that you treat the public and private keys as "rolling keys" for each message communicated in the session. You only keep the initial public key to restart lost communication, but otherwise internally the 2 users effectively act on a OTP basis, similar to the scheme you described
Hi. Nice video but the "rand" function from the c stdlib does not produce "real" random numbers. Instead, it uses an algorithm under the hood to generate pseudo random numbers, which will always be the same for each seed. In this case (without calling seed) the numbers will always be the same, meaning if you restart your program you will get the same (random) key again. To get cryptographically secure random numbers, you could take a look on /dev/urandom and /dev/random (if you are on linux).
Yes, you are correct! You, of course, need to seed the random number generator first. I actually learned this in scope of another video that is scheduled to be published soon. Thanks for pointing out, I'll pin your comment.
A quick, but significant improvement sufficient for most use cases is to add
srand(time(NULL));
at the beginning of the main method.
You can improve randomness yourself, using e.g. the process ID:
srand((unsigned int)time(NULL) ^ (unsigned int)getpid());
A true complete makeover for absolute unbreakabillity is to use a secure random number generator, either a library or /dev/urandom and /dev/random (just read in a couple of random bytes from there).
Can't wait for the Next Videos......
Keep going , great content !
Legend
You'll go long way! - Your 543rd subscriber :)
Thank you so much!
Clean stuff
this is a nice and simple encryption algorithm! one concern I do have is how do we go about sharing the key and encrypted data securely? Will there be a follow up video for secure distribution?
With the one-time pad, every method of sharing it is less secure than the one-time pad itself. Typically you either use it to encrypt files only locally and keep the key hidden somewhere, or if you use it to encrypt messages, you exchange the key with the recipient in person. And yes, it is (or was) actually done this way for extremely sensitive government-level information.
@@HirschDaniel from what I can tell then, it seems like the name of the game is to keep the encrypted file and key file apart from each other as long as possible (assuming key file was reliably randomly generated) while getting them to the intended recipient. Only when both of them are together will you get back the secret.
@@tkothadev Exactly! Also, you could do a timely separation of both files. Assuming a fixed file size to contain your message, give the recipient a large set of e.g. 100 one-time pad keys.
And for each encrypted file that you send the recipient he uses the next key, starting from the first.
This way you can exchange keys for the next 100 messages beforehand, only encrypting as you go.
To do that, you'd need to adapt the code a bit to generate a key file independently of the encrypted file.
But it'd be a solid communication protocol.
@@HirschDaniel thats a good idea! i'll look into it for sure. One thing I'm also wondering is if OTP can be adapted to asymmetric key schemes (like Diffie Hellman), such that you treat the public and private keys as "rolling keys" for each message communicated in the session.
You only keep the initial public key to restart lost communication, but otherwise internally the 2 users effectively act on a OTP basis, similar to the scheme you described
Either that, or you just start the exchange using public/private keys, then all files in OTP are encrypted/decrypted using those key pairs
I am a beginner, it's very inspiring ❤
Is there any real world application
Yes, governments and secret services used this encryption method. I don't know if they still use it. I don't think they'd tell us
Subbed. Keep the vids coming.
Thanks, videos are scheduled out until almost end of the year already!