Re: NONSTOP Crypto Query
[A quick contemplation of the wavelength of the sounds in question would put an end to that speculation I suspect. --Perry] I know this has been somewhat done to death, but there's a nice comparison: GPS positioning using carrier phase tracking is equivalent (well, it's reversed - clicks come from the microphones/satellites and the key/receiver calculates its position - but the principle is the same). This can give millimetre accuracy with carrier wavelengths of 19cm (if you're very careful, have lots of time and maybe some luck). The precision comes from cross-correlating wave trains rather than trying to measure a particular point (eg the initial rise of the click) accurately. You wouldn't do as well with keyboard clicks, but then you don't need to. Note that usually GPS positioning is not done using carrier phase tracking - that, together with problems like different atmospheric paths from differnet satellites and, in the past, noise added to civillian signals, gives much lower precision. See, for example, http://www.colorado.edu/geography/gcraft/notes/gps/gps.html Accuracy for keyboards would depend on how many wavelengths can be detected at good signal-to-noise within a single "click" (and having stable recordings with no wow or flutter). Also, it would be useful to know the identity of one key - return for example - to help solve for the position of the keyboard relative to the microphones. Getting an initial solution might be difficult - it would be a big help to know the relative position of keyboard and mcirophones to within a wavelength or two (and have all recordings marked by synchronized clock ticks). If the user moved their keyboard during typing it would cause havoc with any attempt to converge on a solution. Maybe we should all start walking around as we type... Andrew (In a previous job I wrote software to calculate positions from GPS satellites - Paul Crowley may be able to correct me if I have made any errors as he was there too...)
Re: Beginners books on security
There's a Nutshell book with a green cover and a shark (can't remember the title and don't have it here) that is a very nice gentle introduction to security. Looking at Amazon, it's called "Web Security and Commerce" so I guess that one reason I have such good memories of it is that it would have been very relevant to our work. Even so, I think it was pitched at so high (or low, depending on your point of view ;-) a level that it was also a good general introduction. Not sure it covered copy protection, though. Andrew Ben Laurie wrote: I was asked to recommend boks on security/crypto/copy protection for the non-tekky and realised I had no idea at all! Does anyone out there have suggestions? Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: Man arrested over theft of Enigma coding machine
William Knowles wrote: Grouped together in the so-called 'Ultra' project, the code-breakers, chief among them British mathematical genius Alan Turing working alongside mathematicians, linguists and champion chess players, endeavoured to decipher messages sent between Nazi leaders and military chiefs through what the Nazis was convinced was an unbreakable code. I guess many here will be familiar with all this, but can I just butt in for an off-topic moment to recommend the biography of Turing by Andrew Hodges for more information on both the man and the work at Bletchley? I've just finished it and found it an excellent, fascinating book (only maybe a tenth covers crypto work, but Hodges is a mathematician and explains things well - in particular it hammers home the dangers of human error, mis-use and over-confidence). Thanks, Andrew
Re: PRNG State [was: KeyTool internal state]
Hi, OK, I had - stupidly - confused key lengths for public key and private key systems. Provided Sun has a good implementation everything is OK (for example, 160 bits of state is sufficient for 3DES). (I spent hours yesterday banging my head against a wall trying to work out how to get "extra" state out of a PRNG...) Thanks to A Reinhold (I think he has copied his email here, although I haven't seen it on the list yet) and apologies to Sun (I hope in all my posts I have been clear about my reasoning, so hopefully only people even more silly than me have been led astray ;-). Cheers, Andrew Andrew Cooke wrote: Hi, Can someone please correct the following? I expect a PRNG with an internal state of n bits to produce output that is predictable given n consecutive bits of output. Is that correct? If so, then doesn't a PRNG used to generate a key require at least as large an internal state as the key length (otherwise, given the first n bits, the rest is predictable, reducing teh effective length to n)? This is the basis of my earlier post questioning the security of Sun's keytool. I've included the relevant parts of my post and the reply below - I've also checked the FIPS document, which doesn't mention this (I cannot find a public copy of the IEEE document). My apologies if the reasoning above is incorrect - I would really appreciate comments on this as it is important that I understand whether or not the keytool is useful (and also, given the response, I suspect I am labouring under some pretty major misconception about random PRNGs). Thanks, Andrew Gary Ellison wrote: " " == Andrew Cooke [EMAIL PROTECTED] writes: [...] Most importantly, as far as I can tell, keytool does not generate "fully random" keys when used "naively". [...] The Sun provider for SecureRandom follows the IEEE P1363 standard, Appendix G.7: "Expansion of source bits", and uses SHA1 as the foundation of the PRNG. Additionally, we verify that the Sun SecureRandom provider complies with NIST's FIPS PUB 140-1 section 4.11. [...] - The Java SecureRandom class contains only 20 bytes of random state and these are initialised by some kind of thread contention process (which may not generate "really random" values either). [...] In 1996 when SecureRandom was implemented 20 bytes of state seemed sufficient for FIPS 140-1 compliance. Perhaps this is no longer a sufficient target (your suggestions are welcome). The Sun provider for SecureRandom mixes in other sources of entropy with the results from the thread contention process. Among other things this includes the current time, the state of the VM's memory usage, system properties, and file system activity. [...]
Re: KeyTool internal state
Hi, I asked on this list a while back for info on keytool. I had some private replies and have finally come up with an answer - I'm posting here to make leave a public record to help others in my position, in case anyone knows better and can correct me, and to warn of apparent insecurities. Most importantly, as far as I can tell, keytool does not generate "fully random" keys when used "naively". Although keytool appears as a standalone app in the JDK/JRE, it is implemented as Java code which can be inspected by getting the full JDK source via the Sun/Java Community Download process. Checking this code shows that: - Unless other crypto/security providers are registered, the source of random numbers is the Java SecureRandom class. - The Java SecureRandom class contains only 20 bytes of random state and these are initialised by some kind of thread contention process (which may not generate "really random" values either). To use keytool securely, it seems that you must configure Java to use a different provider for the SecureRandom class. The procedure for doing this is described in the docs that come with the JDK. I tried to get info from Sun/Java by emailing various addresses and posting a question to the security forum; I did not ask on the java-security list as I couldn't register (no response from the LISTSERV password register). Although all the above is standard Java info (the internal state for SecureRandom is documented in the API docs) it was not clear that keytool is implemented in Java and, therefore, uses the standard Java security code. Cheers, Andrew Andrew Cooke wrote: Does anyone know the size of the internal state for the random number generator in Java's keytool? A pointer to appropriate Java docs would be sufficient. (This seems to be pretty critical info for deciding how reliable the keys are - the default random number generator in Java does not have much state and to get sufficient state by seeding multiple instances using Java's thread race mechanism - even if that is reliable - takes longer in my own Java code than the time keytool takes to generate new keys!) I've looked through all the docs I can find, and also checked this list's archives (I could only search titles (subjects) for keytool, and only did the last 6 months, so if it's under a different title or earlier, could you give me the title and/or date?). I've also posted a question on the Sun Java discussion foums, but had no reply.
