AFAIK this is an attack on the underlying Merkel-Damgard paradigm which both SHA-1 and MD5 (amoungst others) employ. The paradigm goes as follows:
IV | Intialisation vector of n-bits
MB_i | Message Black i of n-bits
HB_i | Hashblock i of n-bits f:(IV , MB_i) -> HB_i | is the underlying compression function which takes both an IV and a message block as input and outputs a hashblock.
First the orginal messaage is split up (and padded if need be) into n-bit blocks. Then f is applied with an IV and MB_1 as input resulting in HB_1. f is then applied iteratively each time tacking the next message block as input while using the previouse hash block as the IV input.
Merkle and Damgard proved that the over all construction is collision resistent given that the compression function f is collision resistant.
As the parent post pointed out though the last block had better include the over all message length. If this is not the case then by extendeing 2 different but colliding messages x,y with the same plain text q the input to the compression function becomes identical since H(x) = H(y) = IV input for f. If on the other hand the length of the orginal message is included in the last block then even though the IV input for f is the same for f(H(x),q_1) and for f(H(y),q_1)..., the final message block (q_s) will again be different resulting in a different final hash block.
If on the other hand len(x) = len(y) then the problem persists since both IV and message blocks will be the same when the final iteration of the algorithm is reached.
Infact this attack is even stronger since by the same reasoning one can see that to produce H(x+q) all one needs is to know is H(x) (and len(x) if that is included in the last message block). No other information is needed about the orginal message x! H(x) is simply inserted as the IV for f when hashing q and so the iteration is "jump started" just where x finishes. (If the length is included in the last block then all that need be used is len(x)+len(q).)
Disclaimer: Not to 100% sure about all this though so please feel free to correct me if i'm wrong...:-)
in the last 25 years there has been another development in cryptography which bruce has seemingly left. namely the formal what is often refered to as provable cryptography. i.e. the proccess:
1) Formaly defining both the working model (network, involved parties, computational & other capbabilities...)
2) Defining the variouse forms of security to be achieved. (For example a protocol must be secure if run once, many times in a sequential manour or even in a concurrently manour. Each is a different kind of security and results in a different protocol.)
3) Designing a solution (algorithmn, protocol,...) and useing mathematical methods to PROVE the defficulty of breaking the stated security in the given model is equivalent to some common mathematical problem. (such as certain "large" integers or calculating the descreet log in "large" algebraic groups.)
Public key cryptography is the first practical product of this type of cryptography, however theoretical cryptography is almost nothing BUT this kind of work. the problem with protcols and algorithms designed in such a way is that they are often alot more inefficient then there conventional counter parts. thus most practical cryptographic algorithms (SHA-*, RC*, MD*, DES, AES,...) are not designed in such a rigorouse manour. (if this were the case then the entire field of cryptanalysis would be relegated to efficiently solving a few basic mathematical problems efficiently.) A quick example of a compareson is the note that one provably secure hashing algorithm requires a modular exponentiation per bit hashed. compare that with md5...
As Bruce said, desiging secure protocols is VERY difficult even for the most experienced of cryptographers. This has been the main motivation behind developing and applying a provable approach to cryptography. as the cost of computation and communication decrees and the theoretical tools become more and more efficient i think we will be seeing more of this type of cryptography in practical use. (Zero Knowlege proofs, for example, are already being used in some authentication schemes.) In any case IMHO it is a "trend" to be watched as it is the FIRST line of research in cryptography that truely quantifies security. (i.e. by reduceing the security of a scheme to the difficulty of solving a specific mathematical problem of a given size.)
as far as i understood TCP/IP, these protocols (specificaly TCP) DO use cryptography. just not encryption. sepcificaly one of the main security features of TCP are it's sequence numbers. the idea is that they are an unpredicatble (to the attacker), i.e. pseudo-random, sequence of numbers. generating such a sequence of numbers is a classical cryptographic problem. (Common solutions to this problem are the usage of stream cipher outputs or a pseudo-random number generater such as the one sugested in Schneier et al.'s paper about the Yarrow design methodology.)
as to useing crypto to deal with the Spam problem... well there have been sugestions that email's should cost computing power to send. i.e. in order for A to send an email to B it must first solve a mathematical problem which B sends it. once B has verified that the problem has been correctly solved it accepts the email from A. The thing is that coming up with such a problem which is difficult to solve (say an NP-complete problem) is boardering on if not part of cryptography. Of course this is NOT an optimal solution for Spam but merely a suggestion; just think of mailing lists or sending email from computationaly constrained devices. but my point is that crypto is more then just secure message exchange (encryption). so i wouldnt rull out crypto as a field for solving (or at least reducing) the problem of spam email.
PS: The problem with useing these these hash functions is that they are quite inefficient. For example the one based on factoring Blum ints. requires a modular exponentiation for every bit of the input to the hash function. so for password hashing this might still somehow be feasible but for hashing an ISO for example or for integrity of network comunication (where things need to be calculated in real time) these functions are of no use.
still theoretically it does show that (given some basic common assumptions) hash functions do NOT have be breakable.
In fact there have been a few reductions as far as hashing is concerned. Specificaly it has been showen that hash functions can be created where breaking them (in the existential collisions sense as well as inverting them) is polynomially reducable to factoring large Blum integers (n = p*q where p and q are two large roughly equaly sized primes) or where breaking the hash function is polynomially reducable to solving the descrete log problem.
more precicely the methods i refer to rely on the existance and security of pairs of claw free one way functions. that is f_1 and f_2 with the porperty that its hard (computationaly impossible) to find a pair x_1 and x_2 such that f_1(x_1) = f_2(x_2). such functions have intern been showen to exists based on the hardness of the DLP or on finding both square roots of quadratic residues mod a (large enough) blum integer. and finding both roots of quadratic residues mod a blum int is hard if factoring the blum int is hard.
not all value systems are the same. though with the advent of the french revolution and later even more so, the US revolution, the west is based heavily on the freedom of the individual, this is NOT the case everywhere.
as the grandparent post explained in the (han) chinese value system stability (and thus in there view unity) is often more important then indvidual freedoms.
for that matter how often have u heard in recent times US citizens, when being interviewed about how the patriot act cuts into their freedom and privacy, say things along the line of "well, I'm willing to give some of that up if thats the price of safty". in other words safty has higher value then personal freedom to them.
why is it so suprising then that to many chinese stability is more important then personal freedom...? nobody is asking u to share the belief (in stark contrast to the US values.......)
(and as a side note there is alot more personal freedom in china then there was even 20, 15 or even 10 years ago.)
odd... i was there in february (actually also in tianjin for a while) and ended up during the course of several conversations with variouse people comeing accross the subject of tiananamen. i was never met with the clueless-ness u speak of... though ofcourse they did have a rather different view of it then someone born n raised on a strict diet of western media might.
from a cryptographic point of view there is a rather strong argument for the need of actual hardware. in a purely software solution (i.e. determinisitic) it is imposible to create random numbers which are essential to any cryptographic protocols.
one improvment is to have a small (and individual to each piece) random number stored permanantly on board sellected in the factory. this is how smartcards and atm cards do it. (your public/private keys are the random nubers). useing appropriate random number generators the secret random seed can be securly extended to any required amount of random bits (though for this a state must be stored which is again vulnerable to attack as it gives everything away).
the other problem with that solution is the important and all knowing role which the factory plays. this is not only a single point of failure but comercialy unviable for products whos selling point is security from EVEYONE. thats the real advantage of a true hardware random number generator on board each and every device. only like that can one really gaurantee that the cryptographic protocols implented are as secure as they're proofs claim
(as an after thought u could always just leave the security of chooseing a truely random seed to the user of each device. "enter password:") *g*
it seems to me that quantum entagelment as you have explained it (and its limitations) can be used for another basic problem in cryptography "flipping a coin over a phone".
the senario is a follows: Alice and Bob need to agree upon a random bit. i.e. one which neither Alice or Bob can influence (significantly) yet neither can verify that the other is following a given protocol (because they are on oposate ends of the line). Given some common intractability assumptions such as factoring or the DLP there are several exponentialy asymptoticly secure solutions. In other words they are not absolutely secure, just statisticaly and they are based on un proven grounds.
Now what if Alice and Bob at some previouse point in time set up a pair of entangled particles between them. (This is akin to setting up a tellephone line between them.) Well I geuss the rest is pretty clear. At a predefined time, or one dynamicaly agreed upon through insecure channels each reads the state of their partical and there u have your random bit with absolute certainty that neither party influenced the outcome. (aditionaly, though not neccesary, both Alice and Bob can be sure that no other party knows the bit.)
evil earny breaks into ur firewall, provider, or whatevers between (or even just next to? ethernet?) u and the rest of the net. there he sets up up a fake dns server which redirects all ur requests for www.es5.com to the ip of the computer he just owned. a fake update server daemon he has running on the same computer recieves ur request and thus serves u a fake update.
crypto to the rescue!
each client software knows the update servers public key. when clients want an update they request one from the update server and only acept updates which are signed with the private key of corresponding to the public key they know.
I dont know about u but Tempest for Eliza sure cuts it for me as an example of someone useing something out of CS and getting it to do something totaly different from its intended purpose.
but there is a difference between being a multimillionar and makeing a living! musicians alwasys made a living. but they werent always some the richest people in society! thats the problem i have with the industry as its set up now. things have been scewed out of proportion.
Microsoft is infact targeting the home users as well, but through content/service providers. Basicaly they are trying to provide a securied (for the provider mind you, not the end user) platform/enviornment where a provider of say, music files, or films for example can be sure that only software aproved by them will be running and able to use (play back) the data they provide.
For example company big$co wants to sell data file D to john doe. big$co gives a copy of D encrypted with the secret key on john doe's Palladium enabled comp to john. (notice i dont say John Doe's key as this is not the case. thats exactly what Rivest and Diffie are, rightly IMHO, complaining about.) The secret key in the box can only be accessed through the trusted OS (nexus) which in turn makes sure that only trusted software (i.e. some app provided (and sold) by big$co). Since the pladium part of the system will only boot if the nexus is trusted (i.e. hasnt been tampered with, and thus hashes to a predefined and stored value) and the nexus checks that only trusted software talks to it, the enviornment is controled by big$co and Redmond.
The reason i say this is how they are targeting the end user is because they are trying to create an environment which is favorable to content providers such as big$co. Thus there should then be more such companies, more offers, and more content. This in turn should provide some kind of killer ap (should as far as Microsoft is concerned ofcourse). And thus the end user now HAS to get a palladium comp, if they want all the content.
one problem with this setup which is partly what rivest and deffie were argueing, is that if john doesnt own his key, what if say he buys a new computer or his old one just plain breaks for example. all his payed for content becomes worthless. this is ofcourse mearly one example of what is so grossly wrong with all of this, never mind the moral issues that u dont own ur computer anymore.
just migrating from linux -> openbsd and all i have to say is:
cd/usr/ports/bla/foo
make install
or maybe just pkg_add foo.tgz
i dont know. doesnt get much easier then that. i think its just a matter of what one is familier with. about the only complaint i have with (open)bsd so far is the instalation (mainly the formating of the HD was not intuitive). that really is kinda crude, but apart from that.... not so evil really.
but please correct me if i am wrong. lets have examples mind you... not just vague complaints or comments... after all i do wanna learn!:-)
(actualy i am just trying to decided between a grsecurity enhanced linux box and an openbsd box for a secure firewall, gateway and webserver... so this is pretty relevant. the point is it should be maintainable by a nonexpert as well once setup properly...)
"Our technology, VME (Virtual Matrix Encryption), is quite simply the only unbreakable encryption commercially available." - quote from www.meganet.com front page.
i dont know about the rest of u but this kind of hype only manages to tick me off. i mean what a load of BS! before even looking at the (very minimal and decidedly not technical) information on their site about there supposedly briliant algorithm, this kind of quote screems "BOGUS!" to me.
simply put, this looks like a big load of crap to me.
So the problem here is how do u want to reproduce ur messurements (so as to have a second copy of the OTP for decryption). If ur answer is to just record ur random noise once and then make a copy of the OTP which is then passed on "securely" to the point of decryption then why not just send the data along this same route. such truely random OTP pad generation technices are only usefull if u have a way of transfering the OTP to all places it will be needed in, with out compromising security (or u can reproduce the messurments, however then what stops the bad guys from doing the same?). I.e. modern day versions of code-books for diplomatic comunication which are transported in person for example...
as alternative sugestion what about useing a (provably reducable to the hardness of some underlying one-way function) pseudo-RNG. The seed for the PRNG can be used as the key, and as long as a sufficiently large security parameter is used for the internals of the PRNG (i.e. the OW-F), say 1024 or even 2048 for the seriosly paranoid, the "random" stream is both reproducable, and yet provably _sufficiently_ random as to provide for all the security a OTP has to offer. (the size of the shared secret has also been reduced an order of magnitued)
as an example try BBS if u believe factoring to be hard. (if not how bout a nice post on why not?):)
Slashdot Mirror
AFAIK this is an attack on the underlying Merkel-Damgard paradigm which both SHA-1 and MD5 (amoungst others) employ. The paradigm goes as follows:
...
:-)
IV | Intialisation vector of n-bits
MB_i | Message Black i of n-bits
HB_i | Hashblock i of n-bits
f:(IV , MB_i) -> HB_i | is the underlying compression function which takes both an IV and a message block as input and outputs a hashblock.
First the orginal messaage is split up (and padded if need be) into n-bit blocks. Then f is applied with an IV and MB_1 as input resulting in HB_1. f is then applied iteratively each time tacking the next message block as input while using the previouse hash block as the IV input.
f(IV, MB_1) = HB_1
f(HB_1, MB_2) = HB_2
f(HB_s-1, MB_s) = HB_s = H(Message)
Merkle and Damgard proved that the over all construction is collision resistent given that the compression function f is collision resistant.
As the parent post pointed out though the last block had better include the over all message length. If this is not the case then by extendeing 2 different but colliding messages x,y with the same plain text q the input to the compression function becomes identical since H(x) = H(y) = IV input for f. If on the other hand the length of the orginal message is included in the last block then even though the IV input for f is the same for f(H(x),q_1) and for f(H(y),q_1)..., the final message block (q_s) will again be different resulting in a different final hash block.
If on the other hand len(x) = len(y) then the problem persists since both IV and message blocks will be the same when the final iteration of the algorithm is reached.
Infact this attack is even stronger since by the same reasoning one can see that to produce H(x+q) all one needs is to know is H(x) (and len(x) if that is included in the last message block). No other information is needed about the orginal message x! H(x) is simply inserted as the IV for f when hashing q and so the iteration is "jump started" just where x finishes. (If the length is included in the last block then all that need be used is len(x)+len(q).)
Disclaimer: Not to 100% sure about all this though so please feel free to correct me if i'm wrong...
AFAIR there is a problem with weak keys with IDEA. i.e. there is a subset in the keyspace for which the algorithm is alot weaker then it should be.
in the last 25 years there has been another development in cryptography which bruce has seemingly left. namely the formal what is often refered to as provable cryptography. i.e. the proccess:
1) Formaly defining both the working model (network, involved parties, computational & other capbabilities...)
2) Defining the variouse forms of security to be achieved. (For example a protocol must be secure if run once, many times in a sequential manour or even in a concurrently manour. Each is a different kind of security and results in a different protocol.)
3) Designing a solution (algorithmn, protocol,...) and useing mathematical methods to PROVE the defficulty of breaking the stated security in the given model is equivalent to some common mathematical problem. (such as certain "large" integers or calculating the descreet log in "large" algebraic groups.)
Public key cryptography is the first practical product of this type of cryptography, however theoretical cryptography is almost nothing BUT this kind of work. the problem with protcols and algorithms designed in such a way is that they are often alot more inefficient then there conventional counter parts. thus most practical cryptographic algorithms (SHA-*, RC*, MD*, DES, AES,...) are not designed in such a rigorouse manour. (if this were the case then the entire field of cryptanalysis would be relegated to efficiently solving a few basic mathematical problems efficiently.) A quick example of a compareson is the note that one provably secure hashing algorithm requires a modular exponentiation per bit hashed. compare that with md5...
As Bruce said, desiging secure protocols is VERY difficult even for the most experienced of cryptographers. This has been the main motivation behind developing and applying a provable approach to cryptography. as the cost of computation and communication decrees and the theoretical tools become more and more efficient i think we will be seeing more of this type of cryptography in practical use. (Zero Knowlege proofs, for example, are already being used in some authentication schemes.) In any case IMHO it is a "trend" to be watched as it is the FIRST line of research in cryptography that truely quantifies security. (i.e. by reduceing the security of a scheme to the difficulty of solving a specific mathematical problem of a given size.)
as far as i understood TCP/IP, these protocols (specificaly TCP) DO use cryptography. just not encryption. sepcificaly one of the main security features of TCP are it's sequence numbers. the idea is that they are an unpredicatble (to the attacker), i.e. pseudo-random, sequence of numbers. generating such a sequence of numbers is a classical cryptographic problem. (Common solutions to this problem are the usage of stream cipher outputs or a pseudo-random number generater such as the one sugested in Schneier et al.'s paper about the Yarrow design methodology.)
as to useing crypto to deal with the Spam problem... well there have been sugestions that email's should cost computing power to send. i.e. in order for A to send an email to B it must first solve a mathematical problem which B sends it. once B has verified that the problem has been correctly solved it accepts the email from A. The thing is that coming up with such a problem which is difficult to solve (say an NP-complete problem) is boardering on if not part of cryptography. Of course this is NOT an optimal solution for Spam but merely a suggestion; just think of mailing lists or sending email from computationaly constrained devices. but my point is that crypto is more then just secure message exchange (encryption). so i wouldnt rull out crypto as a field for solving (or at least reducing) the problem of spam email.
PS: The problem with useing these these hash functions is that they are quite inefficient. For example the one based on factoring Blum ints. requires a modular exponentiation for every bit of the input to the hash function. so for password hashing this might still somehow be feasible but for hashing an ISO for example or for integrity of network comunication (where things need to be calculated in real time) these functions are of no use. still theoretically it does show that (given some basic common assumptions) hash functions do NOT have be breakable.
In fact there have been a few reductions as far as hashing is concerned. Specificaly it has been showen that hash functions can be created where breaking them (in the existential collisions sense as well as inverting them) is polynomially reducable to factoring large Blum integers (n = p*q where p and q are two large roughly equaly sized primes) or where breaking the hash function is polynomially reducable to solving the descrete log problem.
more precicely the methods i refer to rely on the existance and security of pairs of claw free one way functions. that is f_1 and f_2 with the porperty that its hard (computationaly impossible) to find a pair x_1 and x_2 such that f_1(x_1) = f_2(x_2). such functions have intern been showen to exists based on the hardness of the DLP or on finding both square roots of quadratic residues mod a (large enough) blum integer. and finding both roots of quadratic residues mod a blum int is hard if factoring the blum int is hard.
oxymoron of the day: enforced freedom
not all value systems are the same. though with the advent of the french revolution and later even more so, the US revolution, the west is based heavily on the freedom of the individual, this is NOT the case everywhere.
as the grandparent post explained in the (han) chinese value system stability (and thus in there view unity) is often more important then indvidual freedoms.
for that matter how often have u heard in recent times US citizens, when being interviewed about how the patriot act cuts into their freedom and privacy, say things along the line of "well, I'm willing to give some of that up if thats the price of safty". in other words safty has higher value then personal freedom to them.
why is it so suprising then that to many chinese stability is more important then personal freedom...? nobody is asking u to share the belief (in stark contrast to the US values.......)
(and as a side note there is alot more personal freedom in china then there was even 20, 15 or even 10 years ago.)
odd... i was there in february (actually also in tianjin for a while) and ended up during the course of several conversations with variouse people comeing accross the subject of tiananamen. i was never met with the clueless-ness u speak of... though ofcourse they did have a rather different view of it then someone born n raised on a strict diet of western media might.
from a cryptographic point of view there is a rather strong argument for the need of actual hardware. in a purely software solution (i.e. determinisitic) it is imposible to create random numbers which are essential to any cryptographic protocols.
one improvment is to have a small (and individual to each piece) random number stored permanantly on board sellected in the factory. this is how smartcards and atm cards do it. (your public/private keys are the random nubers). useing appropriate random number generators the secret random seed can be securly extended to any required amount of random bits (though for this a state must be stored which is again vulnerable to attack as it gives everything away).
the other problem with that solution is the important and all knowing role which the factory plays. this is not only a single point of failure but comercialy unviable for products whos selling point is security from EVEYONE. thats the real advantage of a true hardware random number generator on board each and every device. only like that can one really gaurantee that the cryptographic protocols implented are as secure as they're proofs claim
(as an after thought u could always just leave the security of chooseing a truely random seed to the user of each device. "enter password:") *g*
it seems to me that quantum entagelment as you have explained it (and its limitations) can be used for another basic problem in cryptography "flipping a coin over a phone".
the senario is a follows: Alice and Bob need to agree upon a random bit. i.e. one which neither Alice or Bob can influence (significantly) yet neither can verify that the other is following a given protocol (because they are on oposate ends of the line). Given some common intractability assumptions such as factoring or the DLP there are several exponentialy asymptoticly secure solutions. In other words they are not absolutely secure, just statisticaly and they are based on un proven grounds.
Now what if Alice and Bob at some previouse point in time set up a pair of entangled particles between them. (This is akin to setting up a tellephone line between them.) Well I geuss the rest is pretty clear. At a predefined time, or one dynamicaly agreed upon through insecure channels each reads the state of their partical and there u have your random bit with absolute certainty that neither party influenced the outcome. (aditionaly, though not neccesary, both Alice and Bob can be sure that no other party knows the bit.)
hm....
am i completely off?
apropos security quick scenario,
evil earny breaks into ur firewall, provider, or whatevers between (or even just next to? ethernet?) u and the rest of the net. there he sets up up a fake dns server which redirects all ur requests for www.es5.com to the ip of the computer he just owned. a fake update server daemon he has running on the same computer recieves ur request and thus serves u a fake update.
crypto to the rescue!
each client software knows the update servers public key. when clients want an update they request one from the update server and only acept updates which are signed with the private key of corresponding to the public key they know.
I dont know about u but Tempest for Eliza sure cuts it for me as an example of someone useing something out of CS and getting it to do something totaly different from its intended purpose.
but there is a difference between being a multimillionar and makeing a living! musicians alwasys made a living. but they werent always some the richest people in society! thats the problem i have with the industry as its set up now. things have been scewed out of proportion.
Microsoft is infact targeting the home users as well, but through content/service providers. Basicaly they are trying to provide a securied (for the provider mind you, not the end user) platform/enviornment where a provider of say, music files, or films for example can be sure that only software aproved by them will be running and able to use (play back) the data they provide.
For example company big$co wants to sell data file D to john doe. big$co gives a copy of D encrypted with the secret key on john doe's Palladium enabled comp to john. (notice i dont say John Doe's key as this is not the case. thats exactly what Rivest and Diffie are, rightly IMHO, complaining about.) The secret key in the box can only be accessed through the trusted OS (nexus) which in turn makes sure that only trusted software (i.e. some app provided (and sold) by big$co). Since the pladium part of the system will only boot if the nexus is trusted (i.e. hasnt been tampered with, and thus hashes to a predefined and stored value) and the nexus checks that only trusted software talks to it, the enviornment is controled by big$co and Redmond.
The reason i say this is how they are targeting the end user is because they are trying to create an environment which is favorable to content providers such as big$co. Thus there should then be more such companies, more offers, and more content. This in turn should provide some kind of killer ap (should as far as Microsoft is concerned ofcourse). And thus the end user now HAS to get a palladium comp, if they want all the content.
one problem with this setup which is partly what rivest and deffie were argueing, is that if john doesnt own his key, what if say he buys a new computer or his old one just plain breaks for example. all his payed for content becomes worthless. this is ofcourse mearly one example of what is so grossly wrong with all of this, never mind the moral issues that u dont own ur computer anymore.
just migrating from linux -> openbsd and all i have to say is: cd /usr/ports/bla/foo
make install
or maybe just pkg_add foo.tgz
i dont know. doesnt get much easier then that. i think its just a matter of what one is familier with. about the only complaint i have with (open)bsd so far is the instalation (mainly the formating of the HD was not intuitive). that really is kinda crude, but apart from that.... not so evil really.
but please correct me if i am wrong. lets have examples mind you... not just vague complaints or comments... after all i do wanna learn! :-)
(actualy i am just trying to decided between a grsecurity enhanced linux box and an openbsd box for a secure firewall, gateway and webserver... so this is pretty relevant. the point is it should be maintainable by a nonexpert as well once setup properly...)
"Our technology, VME (Virtual Matrix Encryption), is quite simply the only unbreakable encryption commercially available." - quote from www.meganet.com front page.
i dont know about the rest of u but this kind of hype only manages to tick me off. i mean what a load of BS! before even looking at the (very minimal and decidedly not technical) information on their site about there supposedly briliant algorithm, this kind of quote screems "BOGUS!" to me.
simply put, this looks like a big load of crap to me.
'nough said
So the problem here is how do u want to reproduce ur messurements (so as to have a second copy of the OTP for decryption). If ur answer is to just record ur random noise once and then make a copy of the OTP which is then passed on "securely" to the point of decryption then why not just send the data along this same route. such truely random OTP pad generation technices are only usefull if u have a way of transfering the OTP to all places it will be needed in, with out compromising security (or u can reproduce the messurments, however then what stops the bad guys from doing the same?). I.e. modern day versions of code-books for diplomatic comunication which are transported in person for example... as alternative sugestion what about useing a (provably reducable to the hardness of some underlying one-way function) pseudo-RNG. The seed for the PRNG can be used as the key, and as long as a sufficiently large security parameter is used for the internals of the PRNG (i.e. the OW-F), say 1024 or even 2048 for the seriosly paranoid, the "random" stream is both reproducable, and yet provably _sufficiently_ random as to provide for all the security a OTP has to offer. (the size of the shared secret has also been reduced an order of magnitued) as an example try BBS if u believe factoring to be hard. (if not how bout a nice post on why not?) :)