[RC5] Visualizing Keyspace

Peter Cordes peter at llama.nslug.ns.ca
Mon Jan 31 23:03:33 EST 2000


On Wed, Jan 26, 2000 at 09:59:02AM -0000, Ben Ketteridge wrote:

> > I think such a graphic would help to understand the progress we make in
> cracking
> > keys.
> YES! This would be really useful in getting new users, I am sure.
> Although the axes would be carefully thought out, as the block space is really
> rather one-dimensional! (sorry have no suggestion just now, but will think on
> it)

 (notation: bit 63 is the MSB of the 64bit keyspace.  bit 0 is the LSB.)

 If we do a 1024x1024 pixel 2D image, and Y is bits 54 to 63, X is bits 44
to 53, then that leaves a 44 bit space.  Note that this is similar to the
way C arrays are addressed :).  X varies most quickly as the key number is
increased sequentially.  This should make for easy remembering of how the
keyspace is distributed over the plot.

e.g.:

00 01 02 03
10 11 12 13
20 21 22 23
30 31 32 33


Since work units are 28 bits, that leaves 16 bits for colour or grayscale.
To map done keys into colours, it seems necessary to count done blocks,
rather than try to map the done work units into colours (since each pixel can
only be one colour, we can't have a colour for each work unit.)

 If we use grayscale, the count -> colour task is easy, since the count is
simply the grayscale value.  If we use colour, we could arrange the bits
like this:

MSB                                                          LSB
|15 |14 |13 |12 |11 |10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
 G5  R4  G4  B4  R3  G3  B3  R2  G2  B2  R1  G1  B1  R0  G0  B0  
 
 where R0 is the LSB of the red pixel intensity, R4 is the MSB of red, etc.
The colour weighting would be the usual 565 (for RGB respectively).

 This colour mapping scheme is rather arbitrary, and maybe it would make
more sense to use either 8bpp colour-mapped colours, with a colour map which
goes from red to green with increasing work units done.  Even better might
be only 2 bits/pixel, giving 4 colours: No blocks at this co-ordinate done,
less than half done, more than half done, or all done. This could easily be
4 shades of gray, or it could be red:none done, orange: < 1/2, yellow: >1/2,
green: all done.

 I think either 2 or 4 bpp would be best for this.  people who want the data
on exactly what block have been done should be able to get it, but sending
it as a PNG is not the best way!  People who want a good feel for
what's going on would be better served by fewer colours, to make it easier
to tell when _no_ work units from a pixel region have been done, or when _all_
work units from a pixel have been done.  If we use 4bpp or even 8bpp, we
should make the none and all colours stand out from the others.

 Also, don't forget that 1024x1024 is 2^20 pixels, and 8bpp is 1MByte of
image (before PNG compression.)  2bpp is 2Mbits == 256kBytes of image
(before compression.)  PNG should be used to distribute the image, because
jpeg wouldn't get much out of the (semi-random?) scatter of dots, and the
compression is lossy :(.  GIFs have pattent problems
(http://www.gnu.org/philosophy/gif.html).

-- 
#define X(x,y) x##y
DUPS Secretary ; http://is2.dal.ca/~dups/
Peter Cordes ;  e-mail: X(peter at cordes.phys. , dal.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE

--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list