Question! Capture Mouse Movement :)

[Luc The Perverse]

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

 

[Norb]

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

 

[Roedy Green]

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.

 

[zero]

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.

 

[Oliver Wong]

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

 

[Luc The Perverse]

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?

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

 

[Roedy Green]

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

 

[Roedy Green]

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...

 

[Roedy Green]

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.

 

[Chris Uppal]

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

 

[Chris Uppal]

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.

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

 

[Roedy Green]

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

 

[Luc The Perverse]

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...

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

 

[Chris Uppal]

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

 

[Luc The Perverse]

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.

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.

 

[Chris Uppal]

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

 

[Roedy Green]

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.