This is actually a good point. I should have mentioned it during the video. If you watch the animation from 3:55 onward you will see every number is left-padded (add 0's to the left) to 8 bits. So every number is 1 byte, and if it can be stored in less bytes then it's just less efficient. This is because ASCII is a fixed-length encoding, whereas something like Unicode makes this more complicated. Hope that makes sense

There isn't any specific way to do this, ideally this is a step you would do "in-private", since if you do it "in-public" this part would need to be secured somehow (no specifics given in the OTP protocl). If eve is able to get ahold of the pad while in transfer then the whole system is no longer secure. One option is to do public-key exchange and then encrypt the pad with a key when you send it. Something like diffie-hellman can do this, which I created a repo to explain here: github.com/descent098/diffie-hellman Thanks for watching!

I did quite a lot of digging, and found something that *might* be true about this. To understand this you need to know a few things Python in general is written in C/C++, in C/C++ header files (.h files) are used to tell you about functions. There are a few common windows ones like windows.h. Looking into the source code for winreg it seems to be using windows.h, but it seems to also be using a function defined in another .h file called RegOpenKeyExW() (learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regopenkeyexw), I do not know enough about the intricacies of C/C++ or windows to be able to confirm this, but it seems like this is what's being called by python (python actually runs C code and passes your variables to the C code under the hood) In the python source code only 1 place specifies the value can be something non-zero: github.com/python/cpython/blob/main/PC/winreg.c#L1731-L1771 and this is because it's replaced by a zero here github.com/python/cpython/blob/main/PC/winreg.c#L1793 Reading the documentation for RegOpenKeyExW() here: learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regopenkeyexw#:~:text=%5Bin%5D%20ulOptions,when%20absolutely%20necessary. It states that the value being passed as "reserved" is 0 for a regular link or set to the constant REG_OPTION_OPEN_LINK to make it a symbolic link. (with the warning "Registry symbolic links should only be used when absolutely necessary"). I am not as familiar with the registry, but a symbolic link in general is basically a "file" or "file-like" object that points to another (like a shortcut). It seems like this is the only other possible value, but they don't want you to do this in python (or C) because I would assume like normal symbolic links if the thing you're linking to is deleted, everything linking to it breaks as well! I apologize I couldn't be more precise in my response. As I said this is largely speculative, and my best guess. I would not act on this information until there is something more obvious to confirm this info, but I suspect this is what's happening. For time being, listen to the comments and leave it on 0

Nope, VS Code will use your python install (bottom right corner it will tell you which one it's using). But it only loads the packages you have when you open the editor, so if you install something while VS code is open you need to close it and reopen for the autocompletion to recognize the package.

How so?

Unfortunately not, I have not modified any of this code for a long time after searching for more information for a while

The pad in this example is typically the thing that is kept secret or is somehow obfuscated. This means the content itself can be distributed publicly without worry, and the only thing you need to keep safe is the pad. Likewise it means you can use the same pad for multiple pieces of content (VERY NOT IDEAL security wise) which means you only have to keep 1 thing private and everything else after that can just be distributed publically. Alternatively it can be distributed with some sort of encryption that then has a handshake to allow the decryption key to be distributed. For example you might distribute an encrypted pad over a public channel, but it is locked behind a 16 digit password that was transferred using something like the Diffie-Hellman key exchange (github.com/Descent098/Diffie-Hellman), or even just setup a secure connection with something like SSL (www.ssl.com/faqs/faq-what-is-ssl/) using a key exchange to distribute the pad privately.

For a video like this Unicode is unwieldy, this is meant to be an intro not a how-to necessarily. The primary purpose of this video was for a course I took where the prof wanted a teaching utility to show people about the protocol. ASCII is just simple because it's a small enough collection to do by hand while being expressive enough to be useful. In the real world the character encodings themselves get incredibly annoying to deal with (especially with bloody emoji's), and Unicode would be better especially for languages other than English. Thanks for watching!

There are essentially an infinite number of ways to do this. These could include any form of network interaction like sending messages back and forth via WIFI, all the way to printing the details out and doing it by hand would work. That section of the protocol allows for a ton of leniency to implement however works best for you.

It may not have used ASCII specifically (numbers may have been different), but it would've worked exactly the same. The ASCII version, and any other character coded system can be done on paper (I had to do that for this video actually).

OTP was mainly used by Secret services. Agents were given a sheet of numbers (The equivalent to the key here) with which they could decrypt secret messages.