 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2005Question! Capture Mouse Movement :)
Hi, I would like to capture mouse movements over a section of a dialog, store their points in a byte array and pass it through a cryptographic hash, such as SHA-1 which I am going as a seed for the ISAAC PRNG. (The question is not related to the PRNG, however, or I would post a link.) Any suggestions on what way is best to do this? -LTP Hi, in short, just create a subclass of JComponent (or Component), add it to your dialog, implement a MouseMotionListener, add it as a listener and overwrite the mouseMoved method. This method gives you a mouseEvent which you can ask for the mouse position (getX() and getY()). You then can store those coordinates wherever you like and do with it what you want. Hope that helps, norb On Mon, 24 Oct 2005 06:26:34 -0600, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >Hi, I would like to capture mouse movements over a section of a dialog, >store their points in a byte array and pass it through a cryptographic hash, >such as SHA-1 which I am going as a seed for the ISAAC PRNG. (The question >is not related to the PRNG, however, or I would post a link.) > >Any suggestions on what way is best to do this? Capturing mouse movements is done with a MouseListener. See http://mindprod.com/gloss/event11.html To compute the hash see http://mindprod.com/jgloss/digest.html for your choices. Follow links for specific code. You might do some filtering to reject mouse moves that appear too regular or too small, such as sitting still vibrating back and forth between two positions. You might XOR in a SecureRandom as a little extra insurance. You might be interested in the Mexican Peasant algorithm for creating random one-time cryptographic pads. You use the low order bits of the high res cpu timer (See http://mindprod.com/products1.html#PENTIUM) to time keystroke intervals, again checking for suspicious regularity. These can be collected as a side effect of ordinary use.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > Capturing mouse movements is done with a MouseListener. See > http://mindprod.com/gloss/event11.html You probably meant MouseMotionListener :-) btw, mindprod.com seems to be down at the moment. >btw, mindprod.com seems to be down at the moment. This is weird. The site goes into a funny sort of down - accessible to some people but inaccessible to others. You would think the way the Internet is constructed that should not happen. I suspect the problem may be some sort of DNS server corruption. I share my IP with other customers of my ISP, so you can't simply get in via ip. Dedicated IPs are getting more and more expensive. My ISP said they are working on a DNS-free way for people to get to my site in such a case. I suspect putting an entry for my site in your hosts file will help things though. My IP is stable. see http://mindprod.com/jgloss/hosts.html The political commentary on the site has attracted various forms of attack in past. One way out of this is to use the Replicator to maintain an up to date local mirror on your own hard disk for fast access. See http://mindprod.com/webstarts/replicator.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > You might be interested in the Mexican Peasant algorithm for creating > random one-time cryptographic pads. You use the low order bits of the > high res cpu timer (See http://mindprod.com/products1.html#PENTIUM) to > time keystroke intervals, again checking for suspicious regularity. I don't know too much about cryptography, but isn't "checking for suspicious regularity" a "Bad Thing(tm)"? You'd be essentially eliminating certain values from the value-space, thus making the job of the "Bad Guys" easier (assuming they know your algorithm). Depending on what exactly this check for regularity is, you may be reduce the bruteforce search time by several orders of magnitude. That being said, humans are usually terrible at generating random data. I once heard a story in which the Germans used one-time pads during a war whose keys were generated by secretaries hitting keys randomly on a type writer. The cryptanalyst on the opposing team noticed that the secretaries would always alternate between the left and right hand and would avoid using the same finger twice in a row, and thus were able to discover the keys easily. How do you capture this "human nature" element, and weight it against the "don't eliminate parts of the value-space"? Has there been any studies that show whether these checks improve, or worsen, the randomness? - Oliver >> You might be interested in the Mexican Peasant algorithm for creating >> random one-time cryptographic pads. You use the low order bits of the [quoted text clipped - 19 lines] > the "don't eliminate parts of the value-space"? Has there been any studies > that show whether these checks improve, or worsen, the randomness? This is exactly why using some form of XOR against the collected data directly would be exceptionally stupid. But if you collect say 1000 points, and then apply them to the magic cryptographic hash function, then you get out a 128 bit value which is random enough :) Use this as a seed to an unbroken cryptographic PRNG, or an encryption algorithm :) If you are really paranoid and think the numbers still aren't random enough, then you could do both, and make 2 keys and encrypt a random number string! I wish to familiarize myself with these systems in Java. I'm planning on making cryptographic software and attempting to sell it. Wish me luck :) First I need to get a lot better at making GUIs. Right now I'm just writing some fun little apps to improve my abilities :) (And sneaking in little things about crypto that might help me down the line ;) -- LTP On Mon, 24 Oct 2005 14:46:41 -0600, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >This is exactly why using some form of XOR against the collected data >directly would be exceptionally stupid. XORing never reduces randomness unless the thing you are XORing is a function of what you already have. XORing a random stream with the lord's prayer won't hurt randomness, even if everyone knows you did it. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > But if you collect say 1000 points, and then apply them to the magic > cryptographic hash function, then you get out a 128 bit value which is > random enough :) It is /at most/ as random as the input points. It may be less random (since the hash function may map the space of possible inputs to a smaller space of possible outputs). If the inputs are not "random enough" then the hash is buying you nothing. If the input /is/ random enough then all it's buying you is an easy way of discarding the non-random part of the input. E.g. mouse movements can only be measured over a smallish area, so all the randomness in the input is concentrated in the low-bits of the co-ordinates. If you simply xor them together then you'll be xoring the random bits together, and xoring the non-random bits together. If all the inputs have 3 bits of randomness then the output will have 3-bits of randomness... Using a hash (doesn't have to be crypto-quality) will ensure that you don't throw away any of your randomness as you combine the values. It would be interesting to know how much entropy there is in a typical mouse movement -- especially in an aimless one. I presume someone has looked into it, but I don't know the answer myself (personally I doubt if there's all /that/ much). But the problem is that you can't know how many samples to collect in order to be "random enough" without that information... -- chris >> But if you collect say 1000 points, and then apply them to the magic >> cryptographic hash function, then you get out a 128 bit value which is [quoted text clipped - 27 lines] > /that/ much). But the problem is that you can't know how many samples to > collect in order to be "random enough" without that information... What are you talking about? Even if there were only two states of the mouse, and they were 1 bit of entropy per four collections and you collected 1024 points, you would still have 256 bits of entropy or 2^256 different "results". Come back when you have created a listing of every version of UP DOWN LEFT RIGHT 64 times :) -LTP > Come back when you have created a listing of every version of UP DOWN LEFT > RIGHT 64 times :) First find a user who will move the mouse randomly at that granularity. My guess is that most mouse sweeps could be fitted by not more than a few splines. If that's the case then you only have as much information as is required to specify the parameters of each spline. That in itself (if true) would show that there was no more randomness than the number of bits in the parameter values. Now note that the parameter values are themselves limited since the curve they are fitting lies in a (small) constrained box, and reduce your estimate of randomness accordingly. Lastly you can increase your estimate of the total randomness if you find that the mouse positions actually jitter around the spline rather than lying on it, but that won't be more than a bit or two per sample. -- chris >> Come back when you have created a listing of every version of UP DOWN >> LEFT [quoted text clipped - 19 lines] > bit or > two per sample. I was just trying to make a point. Basically I had imagined it something in the likeness of a 256x256 grid in which the user has been asked to move the mouse randomly. Even if the entering pixel were changed you have like 10 bits of entropy to choose from. Even a simple change in the first numbers of the plot will have drastic effects on the resulting hash. (That is what makes them useful for masking passwords, when the passwords cannot be brute forced.) I agree completely, If someone hands you 999 points and says, guess the last point, that would be trivial, very few choices. But when no information, except the hash, which should be virtually if not completely impossible to reverse, is known, I feel very confident that this is a secure setup. When I hear someone question whether or not 1000 points of pseudorandom mouse sampling is enough to make an unguessable 128 bit key, I wonder to myself if this individual understands the concept of a crypto-quality hash. -- LTP :) > Even a simple change in the first numbers of the plot will have > drastic effects on the resulting hash. I repeat. /Hashing does not add randomness/ If you have 100 bits of entropy in the input to the hash, then you have no more than 100 bits of the entropy in the output. The fact that it /looks/ more "random" means absolutely nothing. > I wonder to > myself if this individual understands the concept of a crypto-quality > hash. I have aslready made my mind up about /your/ understanding of the basics. Bye. -- chris On Sat, 29 Oct 2005 13:55:32 +0100, "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly quoted someone who said : >If you have 100 bits of entropy in the input to the hash, then you have no more >than 100 bits of the entropy in the output. The fact that it /looks/ more >"random" means absolutely nothing. If a 10,000 bit compressed to the nines message is hashed to 32 bits, obviously there is less Shannon information in the hash than the original message. You can't reconstruct the message just from the hash. The hash is not random. It is fully predictable, repeatable function. It is random only in the sense the values are evenly distributed with a well written hash function. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >I don't know too much about cryptography, but isn't "checking for >suspicious regularity" a "Bad Thing(tm)"? You'd be essentially eliminating >certain values from the value-space, thus making the job of the "Bad Guys" >easier (assuming they know your algorithm). Depending on what exactly this >check for regularity is, you may be reduce the bruteforce search time by >several orders of magnitude. In theory yes, but he things you eliminate would happen naturally in a truly random stream would happen extremely rarely anyway. It is sort of like eliminating all runs of more than 20 heads in a row from your random samplings. The code would almost never kick in unless there was something going wrong with the random process, the head sensor was stuck... SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > > You might be interested in the Mexican Peasant algorithm for creating > > random one-time cryptographic pads. You use the low order bits of the [quoted text clipped - 7 lines] > check for regularity is, you may be reduce the bruteforce search time by > several orders of magnitude. Say you timestamp 100 keystrokes with microsecond precision. Say all the timestamps turn out occur on millisecond boundaries. You can reject the idea that that happened by chance with high confidence. The odds against are 1000**100 == 10e300. (If they all turn out to be separated by exact multiples of one millisecond, but not lie on millisecond boundaries then the odds are "only" 10e997 against). The /reason/ we are justified in mistrusting these long-odds-against coincidences is that situations occupy only a very tiny part of the total space. So, by eliminating them, we by definition do not materially weaken the randomness, and hence do not materially weaken the cryptography. -- chris On Tue, 25 Oct 2005 11:59:46 +0100, "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly quoted someone who said : >Say you timestamp 100 keystrokes with microsecond precision. In the original DOS implementation I had a tight loop wasting CPU cycles, counting running at megahertz clock speed. I was also receiving characters the instant they were keyed. In DOS, the keyboard is not polled. The original Pascal DOS code is still posted. See http://mindprod.com/products3.html#ENCODE It should still run under Windows, though it might not come out as random as the original DOS since in Windows you can have other apps eating up CPU and more keystroke buffering and processing. In the proposed Windows/Java implementation, I would use the high res Pentium timer which is running in the gigahertz range. Your problem there ensuring you are getting the keystrokes immediately they are typed, not in bursts from a buffer. In that case simply discarding a keystroke that came too fast on the heels of its predecessor might do it for you. If you want some REALLY random numbers in quantity, see http://mindprod.com/jgloss/truerandom.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.