They are only deterministic if human behavior is deterministic. fjf3ef349gf349fjierjferr89dthu5futh54ht4u5gtfrhiu9th8u54htf8u9h544f4utjdewijtriutjeruithd8h84ht87f5r4hy8wthldwhkeriutrthf8888487yt4ewf0ewuf984u8934uf8u8uewifjewqiofjewjfwjfewifh8uewygf847gyreugiehrijzxvbxmbvdhsbubiewrgyh4ryghyuerhgeriugheurhgudsih3g223727832ry7y73yreurhiuwfhiuewhfuiehfhdsdsjnckcdfv;few;ewf]wefe]w]few[f]w\\ewff32u0u89u89u89````9hfewfhewfh89h893hfew9fhewiufhewuhf994rhhegrheiugherugherggkerkrkegirigkriegkiergkiergkrgjiuerhkfduehtwiufth9e47ty43yt745yt4873ty875y87ty54yt75yt754yt48y4t8y8t7y4t758ty57tytrjhgteriugher do you think an intelligent adversary could guess that I would press those keys on the keyboard? Even assuming that this only contains twenty bits of randomness, which is a very conservative estimate, 96f294735d4ee78d9327680498947e717166da6b03c1c48ff14ddc3d39b54468 would also contain 20 bits of randomness (in fact it probably contains 256 bits of randomness). However perhaps using this source of randomness would remove information theoretic security, I am not certain if the security would then fall to the hashing algorithm which has not been proven as information theoretic. I think I would still feel safe using the sha256 sum of the output produced by my random pounding on the keyboard as a one time pad key. Microphone input can actually be used to generate very secure random numbers, there are some 'true' RNG's which use microphone input to generate 'very high quality' random numbers, but honestly I would feel safe enough pounding on my keyboard for a five minutes and hashing the output with some secure digest. An adversary who could guess the random keystrokes I just pressed could just as quickly guess a passphrase which is extremely likely to be much less random than that. So I highly doubt that such an adversary is at all realistic. If we assume that the output I typed contains a single byte of randomness, and I type something 256 times as large prior to taking the sha256 sum of it, I will be extremely confident that unless sha256 is flawed the digest it outputs will be 256 bits of pure randomness. That is the neat thing about distillation of randomness, you can be extremely conservative. As long as the input contains 256 bits of randomness, the output will be 256 bits of randomness. If you assume that pounding on the keyboard for half an hour produces merely 256 bits of randomness (an extremely conservative estimate), then it is a conservative statement to claim that the resulting sha256 hash is a 256 bit random number. Side channel attacks generally avoid the requirement for oodles of computational power. Here is a side channel attack. if password == input puts "secret message!" else puts "fail!" end that (shitty) example is weak to a side channel attack because == short circuits. If the password is "cats" and the input is "cans" the compare will break on the n to t comparison, but if the input is dog and the password is cats then the compare will break on the d to c comparison. An attacker who can measure the amount of time it takes to puts "fail!" can thus determine how many characters of the password they guessed correctly. That is a cryptographic timing attack. Other side channel attacks include power analysis, noise analysis, etc. And this secret chip has infinite storage capacity? Yes nations are always paranoid about using hardware from other nations. Neither is the result of me pounding on my keyboard. Also, the result of me pounding on my keyboard is secret, but the stock market is public, hence my dice example (which I ripped off from xkcd). The stock market is public, so even if it is random it is a horrible source of entropy. I have absolutely no worry that the timing movement between my keystrokes + timing between mouse movements + direction of mouse movement + screen capture + key strokes + drive access times will not produce sufficient randomness. Especially since it can all be distilled, as the cryptographic hashing algorithms output contains the total amount of randomness present in all of its inputs (up to its output size) so even if each of the sources of randomness result in a few bits, and even if some produce no randomness at all, in the end it can gather up a huge input of all the different sources and then distill it down to its total randomness. Even if pounding on my keyboard produces only ten bits of randomness, I can just keep doing it and after a conservative amount of keystrokes have been gathered hash the total buffer of input and get my randomness as the cryptographic hash output. Need to know which algorithm? Also the attacker would just record the timestamp and check the stock market price at that time. And they would record the transfer of the algorithm as it takes place in the clear. Essentially you suggest that a OTP be based on the publicly viewable possibly-randomness of the stock market, at a precise moment in time that is sent in plaintext between communicating parties. That idea simply will not work. The randomness for the OTP is publicly viewable making it worthless, and your solution for key exchange is actually not a solution at all and consists of doing a plaintext key transfer. Didn't you just suggest that Alice and Bob share (via plaintext transfer) a moment to gather entropy from the (publicly viewable) stock market? I doubt it. People don't need to type perfectly randomly, they just need to type randomly enough that the entirety of what they type has enough bits of entropy to fill up the output of the hashing algorithm. Conservative estimates put English at having about one bit of entropy per character. You could be ultra conservative and say every four characters have one bit of entropy. Then just type 1,024 characters worth of "random" English words and hash them together. Chances are high that the resulting output will contain 256 bits of entropy, if you use SHA 256 anyway.