home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / sci / crypt / 7200 < prev    next >
Encoding:
Text File  |  1993-01-28  |  4.5 KB  |  116 lines
  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!bernina!caronni
  3. From: caronni@nessie.cs.id.ethz.ch (Germano Caronni)
  4. Subject: Re: Generating good keys
  5. Message-ID: <1993Jan29.030159.7177@bernina.ethz.ch>
  6. Keywords: random sources, usage of, public random data, entropy measurement
  7. Sender: news@bernina.ethz.ch (USENET News System)
  8. Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
  9. References: <1993Jan28.201110.23210@qualcomm.com>
  10. Date: Fri, 29 Jan 1993 03:01:59 GMT
  11. Lines: 103
  12.  
  13.  
  14. In article <1993Jan28.201110.23210@qualcomm.com> you (Phil Karn) write:
  15. >
  16. >The question, of course, is knowing when you have enough. MD-5 itself
  17. >is pretty fast, but gathering all of this information could still slow
  18. >you down. And you'd run the risk of generating correlated results if
  19. >you do it too often. Comments?
  20. >
  21. Hi,
  22. just bear with me if this gets close to nonsense :-)
  23. Your idea sounds good to me. And intuitively I agree in the 'destillation'
  24. of random data by e.g. MD-5 . Perhaps there are formal reasons for it ?
  25.  
  26. I can't say anything certain about getting correlated results, but I guess
  27. when doing data-finding in certain intervalls or at certain given times,
  28. correlation might get higher. How about sampling at randomly :-)
  29. specified times, and store this data in a private place, where it can be
  30. consumed as one-time random-bit-stream ? 'randomly' means here
  31. to use the last sample(s) of random data for determining the time
  32. of the next sample-taking.
  33.  
  34. What sources do we have (I am just trying to think them out, some of
  35. them are valid only for certain OS) ?
  36.  
  37. Time of Day
  38. Mouse position, (latency of) actual keystrokes
  39. number of current scanline on the monitor
  40. contents of the actually displayed image.
  41. Hash on Main-Memory,FAT's,Kernel Tables,DiskBlocks as you stated
  42. Access/Modifytimes of /dev/tty??s
  43. Cpu-Load
  44. Network-Packets
  45. Login/Logout-Times of Users
  46. PID/UID
  47. Reponse-Times for some ping(1)s :-)
  48. Temperature/Pressure/etc if measurable 
  49. (e.g. input of measurement-units for the current environment)
  50. (like turning on the mike on a NeXT and do some sampling :-))
  51. Actual number of ethernet-collisions
  52. Remote Users ... (everything you can gain from a network)
  53. The latest News (as lately stated)
  54. ...
  55.  
  56. Can you imagine other sources ? 
  57.  
  58.  
  59.  
  60. Now about knowing when you got enough.
  61.  
  62. Reference to J. of Cryptology (1992) 5: 89-105
  63. A 'Universal' Statistical Test for Random Bit Generators
  64.  
  65. from which I derivate my idea explained below.
  66.  
  67. I could collect several of these events and transform them into
  68. a bit stream which would have high redundance, as most of 
  69. subsequently collected data does not change enough or not randomly
  70. enough. Then I could calculate the entropy of this sequence.
  71. If the entropy is high enough, I have enouh randomness, can now
  72. hash the collection by MD5 and store it for further use. Some
  73. time later, which is perhaps defined by the first byte of the
  74. 16 bytes obtained this way, i begin a new sampling sequnce.
  75.  
  76. Question is, how do I find the actual entropy of the sequence ?
  77. Would it be sufficent to try to 'compress' it, and be content
  78. with the result if an sufficent low percentage of compressibilty
  79. is reached ? Or are there reasons why you can't use this ?
  80. You do not need to actually compress the sampled data, in the paper
  81. mentioned above an 'easy' way is shown to calculate the per-bit
  82. entropy of the sequence you want to test.
  83.  
  84. Hmmm. How about taking adaptive compression, compress all input
  85. and use the output of this continual process ? (While forgetting
  86. all data to remember the actual compression-tables) Wouldn't this
  87. data meet all needed standards for non-redundancy ? So you could
  88. hash the compressed output and use it.
  89.  
  90. I guess on some systems you could install a kind of demon,
  91. which collects such data, and presents an periodically changing
  92. window (size: several megs?) of it in a publicy available file.
  93.  
  94. I could imagine such demons on several machines, occasionaly
  95. exchanging data to make the public random source even more
  96. random.
  97. Having the user, when he needs some random data accessing somre 
  98. remote demons to get it isn't a bad idea neither, as long 
  99. enemies to not know what parts of the recieved data you actually
  100. use. (But I prefer regular exchange between demons) which then hash
  101. data into (parts of) their own pulic random-data.
  102.  
  103. So, what is your opinion about this ?
  104.  
  105. And how would the user choose part of the random-data visible
  106. in that file for his own use?
  107.  
  108. Friendly greetings,
  109.     Germano Caronni
  110.  
  111. -- 
  112. Instruments register only through things they're designed to register.
  113. Space still contains infinite unknowns.
  114.  
  115. Germano Caronni    caronni@nessie.cs.id.ethz.ch
  116.