Merry Christmas 13
2 views
Skip to first unread message
LCC
Nov 29, 2010, 6:09:36 AM11/29/10
to Lonnie Courtney Clay
Merry Christmas 13 specification
Use the technique of "Merry Christmas 2" to generate random number
SEEDS.
Table 1 - Preceding 3 bytes for initializing each code block
From the first random number seed, generate a 256x256x256 array of
unduplicated 24 bit values. An easy way to do that is a diminishing
size single dimensional vector. Initialize the vector with each value
equal to its own 24 bit index. The index of the selected value to be
obtained from the vector is the current pseudo random number generated
from the seed modulo the number of entries remaining in the vector. As
each value is pulled from the vector, the current size of the
remaining vector is decremented by one, then the contents of the
vector at that index are used to overwrite the vector at the same
index as the value just now pulled from the vector. As values are
pulled from the vector, it evolves from an ordered sequence into
something more closely resembling randomness, so that it does not even
resemble a copy of the 24 bit stream generated by the first random
number seed.
Table 2 - Code block sizes
Using the second random number seed, generate a 256x256 block length
array using the same technique as for Table 1, except of course the
vector is of initial length 64k and values range from 0 to 64k-1, with
array entry size of two bytes rather than three.
Tables 3,4 - Variable geometry translation array (VGTA) and inverse
(IVGTA)
Allocate a size 2**27 entry one dimensional array of 32 bit integers
initialized to -1 (IVGTA). Allocate a 2**24 size data structure with
two components in the data structure - a list length and pointer to
list head (VGTA). Allocate a 2**27 entry stack of list members giving
the next link address and a 32 bit unsigned value which is an index to
the IVGTA.
1) Use the third random number seed to initial a PRNG. Sequentially
step through the VGTA. The index to the VGTA is the same as the source
code three byte sequence to be translated. As each random number is
pulled, it specifies a single dimensional index to the IVGTA for the
list head translation. If the IVGTA indexed value is not -1,
indicating that the node is already in use, discard the random number
and pull another. When the node is unused, place the index to the VGTA
into the IVGTA node 32 bit integer. Place the index to the IVGTA into
the list head entry for the currently indexed VGTA entry. Once all
2**24 entries of the VGTA have their list heads initialized, move
onwards to step 2.
2) Use the fourth random number seed to generate pseudo random
numbers. Step sequentially through the IVGTA array. For each entry
whose value is still -1 (unallocated), pull another random number and
convert it to a 24 bit index in the VGTA array. If the number of
entries in the list at that VGTA index exceeds the maximum permitted
list length, then pull another random number. Otherwise, add the node
index of the IVGTA array to the linked list, incrementing the list
length. Set the value in the current IVGTA array entry to the 24 bit
VGTA index and move onwards to the next IVGTA entry.
3) At the end of this process, each entry in the IVGTA has one and
only one translation to a VGTA index. For each source data three byte
sequence there will be an AVERAGE of 8 possible translations to an
output sequence. I consider that insufficiently secure, which is why I
introduce the concept of variable geometry.
Table 5 - IVGTA dimensions array (IDA)
Allocate a size 64k array of 32 bit unsigned integers for IDA.
The index to the IVGTA is 27 bits long. This index can be formed from
a 16 dimensional vector with each dimension size being either
1(ignore),2,4, or 8. The product of the 16 dimensions is in this
example 2**27. The configuration currently in use can be specified by
16 pairs of bit codes, forming a 32 bit value. The bit codes would
translate as 00 = 1, 01 = 2, 10 = 4, and 11 = 8 for the size of the
dimension. Only those bit codes which translate into an array size of
2**27 are valid. Validity can be determined by allocating weights to
each bit code of 00 (2**0) = 0, 01 (2**1) = 1, 10 (2**2) = 2, and 11
(2**3) = 3. The total value of the weights can be determined in
various ways, but the simplest would probably be to use a 16x4 array
of bit masks. Loop through the 16 dimensions adding the weight
associated with the matching bit mask to the sum. If the total is 27,
then add the 32 bit value to IDA. Proceed until the IDA is full,
generating each dimensional test vector from a pseudo random number
initialized by the fifth random number seed.
Table 6 - IDA index array
Use the same technique as for table 2 (and the sixth random number
seed), except that the values will be used to index IDA. The table 2
block size is paired with a table 6 dimensional map to give each code
block a different mapping into the IVGTA array.
4) Using the dimensional mapping of IDA for the current data block,
the index to the IVGTA is translated from a 27 bits of 32 one
dimensional array index into a 32 bit coordinate in the 16 dimensional
view of the same table. The previous value and the current value form
a pair of coordinates. If you want to get REALLY elaborate, then
generate a 16x4 bit difference vector from the previous to the current
coordinate as the value to be output, with a bloat factor of eight
from input to output. For your first implementation, I recommend just
using the translated 32 bit coordinates of the IVGTA entry, with a
bloat factor of four from input to output.
---------------------------
Ready to rock and roll!
Step sequentially through tables 2 and 6. For the current code block
they provide the block size and the IDA coordinate map. Using the
seventh random number seed generated current random number, the
preceding three uncoded bytes is looked up in table 1 to initialize a
block. The current block first byte is added to that sequence to form
a-b-c-x, then the b-c-x entry in the VGTA is accessed. Using a TRUE
random number modulo the list size of the VGTA entry, select a list
member to provide an IVGTA index. Translate the IVGTA index into a 16
dimensional coordinate using the current IDA coordinate map. That
coordinate is the output value for the first byte. For subsequent
bytes, the oldest byte of the three byte sequence is discarded and the
uncoded current byte is concatenated on.
To decode a stream of 32 bit coordinates, generate all tables in
precisely the same manner as for encoding. Step sequentially through
the data blocks using the seventh random number seed. Within each data
block there will be 4n bytes of output for the n bytes of uncoded
input. Simply translate each 4 byte sequence from coordinates in a 16
dimensional vector to an index to the one dimensional IVGTA. From the
IVGTA pull the value of the VGTA entry, which is the three byte
uncoded data sequence. Extract the single byte of new data to be added
to the decoded byte stream. For verification purposes, check that the
preceding two bytes indicated match the previous two decoded bytes in
the stream. Decoding is MUCH simpler (and faster) than encoding!
-------------------------------
Index to coordinates transformation
For a particular value between 0 and 2**27, slice it into 16 fields
using the IDA table entry specification. For an IDA field 00, there is
no dimension, so just concatenate 4 bits with value zero onto the
result. For IDA field 01, the dimension is two - one bit, so slice one
bit from the LSB end and form a 4 bit value from it to concatenate
onto the result. For an IDA field 10, slice two bits. For an IDA field
11, slice three bits. How you form the result from the 16x4 bits is
something which I would make a user option to either go big-endian or
little endian. Alternatively you could use one of the 16 factorial
possible shuffles provided by a lookup table, if you designed the
translation to be THAT flexible…
Lonnie Courtney Clay
Use the technique of "Merry Christmas 2" to generate random number
SEEDS.
Table 1 - Preceding 3 bytes for initializing each code block
From the first random number seed, generate a 256x256x256 array of
unduplicated 24 bit values. An easy way to do that is a diminishing
size single dimensional vector. Initialize the vector with each value
equal to its own 24 bit index. The index of the selected value to be
obtained from the vector is the current pseudo random number generated
from the seed modulo the number of entries remaining in the vector. As
each value is pulled from the vector, the current size of the
remaining vector is decremented by one, then the contents of the
vector at that index are used to overwrite the vector at the same
index as the value just now pulled from the vector. As values are
pulled from the vector, it evolves from an ordered sequence into
something more closely resembling randomness, so that it does not even
resemble a copy of the 24 bit stream generated by the first random
number seed.
Table 2 - Code block sizes
Using the second random number seed, generate a 256x256 block length
array using the same technique as for Table 1, except of course the
vector is of initial length 64k and values range from 0 to 64k-1, with
array entry size of two bytes rather than three.
Tables 3,4 - Variable geometry translation array (VGTA) and inverse
(IVGTA)
Allocate a size 2**27 entry one dimensional array of 32 bit integers
initialized to -1 (IVGTA). Allocate a 2**24 size data structure with
two components in the data structure - a list length and pointer to
list head (VGTA). Allocate a 2**27 entry stack of list members giving
the next link address and a 32 bit unsigned value which is an index to
the IVGTA.
1) Use the third random number seed to initial a PRNG. Sequentially
step through the VGTA. The index to the VGTA is the same as the source
code three byte sequence to be translated. As each random number is
pulled, it specifies a single dimensional index to the IVGTA for the
list head translation. If the IVGTA indexed value is not -1,
indicating that the node is already in use, discard the random number
and pull another. When the node is unused, place the index to the VGTA
into the IVGTA node 32 bit integer. Place the index to the IVGTA into
the list head entry for the currently indexed VGTA entry. Once all
2**24 entries of the VGTA have their list heads initialized, move
onwards to step 2.
2) Use the fourth random number seed to generate pseudo random
numbers. Step sequentially through the IVGTA array. For each entry
whose value is still -1 (unallocated), pull another random number and
convert it to a 24 bit index in the VGTA array. If the number of
entries in the list at that VGTA index exceeds the maximum permitted
list length, then pull another random number. Otherwise, add the node
index of the IVGTA array to the linked list, incrementing the list
length. Set the value in the current IVGTA array entry to the 24 bit
VGTA index and move onwards to the next IVGTA entry.
3) At the end of this process, each entry in the IVGTA has one and
only one translation to a VGTA index. For each source data three byte
sequence there will be an AVERAGE of 8 possible translations to an
output sequence. I consider that insufficiently secure, which is why I
introduce the concept of variable geometry.
Table 5 - IVGTA dimensions array (IDA)
Allocate a size 64k array of 32 bit unsigned integers for IDA.
The index to the IVGTA is 27 bits long. This index can be formed from
a 16 dimensional vector with each dimension size being either
1(ignore),2,4, or 8. The product of the 16 dimensions is in this
example 2**27. The configuration currently in use can be specified by
16 pairs of bit codes, forming a 32 bit value. The bit codes would
translate as 00 = 1, 01 = 2, 10 = 4, and 11 = 8 for the size of the
dimension. Only those bit codes which translate into an array size of
2**27 are valid. Validity can be determined by allocating weights to
each bit code of 00 (2**0) = 0, 01 (2**1) = 1, 10 (2**2) = 2, and 11
(2**3) = 3. The total value of the weights can be determined in
various ways, but the simplest would probably be to use a 16x4 array
of bit masks. Loop through the 16 dimensions adding the weight
associated with the matching bit mask to the sum. If the total is 27,
then add the 32 bit value to IDA. Proceed until the IDA is full,
generating each dimensional test vector from a pseudo random number
initialized by the fifth random number seed.
Table 6 - IDA index array
Use the same technique as for table 2 (and the sixth random number
seed), except that the values will be used to index IDA. The table 2
block size is paired with a table 6 dimensional map to give each code
block a different mapping into the IVGTA array.
4) Using the dimensional mapping of IDA for the current data block,
the index to the IVGTA is translated from a 27 bits of 32 one
dimensional array index into a 32 bit coordinate in the 16 dimensional
view of the same table. The previous value and the current value form
a pair of coordinates. If you want to get REALLY elaborate, then
generate a 16x4 bit difference vector from the previous to the current
coordinate as the value to be output, with a bloat factor of eight
from input to output. For your first implementation, I recommend just
using the translated 32 bit coordinates of the IVGTA entry, with a
bloat factor of four from input to output.
---------------------------
Ready to rock and roll!
Step sequentially through tables 2 and 6. For the current code block
they provide the block size and the IDA coordinate map. Using the
seventh random number seed generated current random number, the
preceding three uncoded bytes is looked up in table 1 to initialize a
block. The current block first byte is added to that sequence to form
a-b-c-x, then the b-c-x entry in the VGTA is accessed. Using a TRUE
random number modulo the list size of the VGTA entry, select a list
member to provide an IVGTA index. Translate the IVGTA index into a 16
dimensional coordinate using the current IDA coordinate map. That
coordinate is the output value for the first byte. For subsequent
bytes, the oldest byte of the three byte sequence is discarded and the
uncoded current byte is concatenated on.
To decode a stream of 32 bit coordinates, generate all tables in
precisely the same manner as for encoding. Step sequentially through
the data blocks using the seventh random number seed. Within each data
block there will be 4n bytes of output for the n bytes of uncoded
input. Simply translate each 4 byte sequence from coordinates in a 16
dimensional vector to an index to the one dimensional IVGTA. From the
IVGTA pull the value of the VGTA entry, which is the three byte
uncoded data sequence. Extract the single byte of new data to be added
to the decoded byte stream. For verification purposes, check that the
preceding two bytes indicated match the previous two decoded bytes in
the stream. Decoding is MUCH simpler (and faster) than encoding!
-------------------------------
Index to coordinates transformation
For a particular value between 0 and 2**27, slice it into 16 fields
using the IDA table entry specification. For an IDA field 00, there is
no dimension, so just concatenate 4 bits with value zero onto the
result. For IDA field 01, the dimension is two - one bit, so slice one
bit from the LSB end and form a 4 bit value from it to concatenate
onto the result. For an IDA field 10, slice two bits. For an IDA field
11, slice three bits. How you form the result from the 16x4 bits is
something which I would make a user option to either go big-endian or
little endian. Alternatively you could use one of the 16 factorial
possible shuffles provided by a lookup table, if you designed the
translation to be THAT flexible…
Lonnie Courtney Clay
LCC
Dec 21, 2010, 11:27:36 PM12/21/10
to Lonnie Courtney Clay
From sci.crypt - copied here for reference...
On Nov 29, 5:08 am, LCC <claylon...@comcast.net> wrote:
> Index to coordinates transformation
> For a particular value between 0 and 2**27, slice it into 16 fields
> using the IDA table entry specification. For an IDA field 00, there is
> no dimension, so just concatenate 4 bits with value zero onto the
> result. For IDA field 01, the dimension is two - one bit, so slice one
> bit from the LSB end and form a 4 bit value from it to concatenate
> onto the result. For an IDA field 10, slice two bits. For an IDA field
> 11, slice three bits. How you form the result from the 16x4 bits is
> something which I would make a user option to either go big-endian or
> little endian. Alternatively you could use one of the 16 factorial
> possible shuffles provided by a lookup table, if you designed the
> translation to be THAT flexible…
I notice that the specification above assumed that you WOULD be using
the coordinate difference method rather than the packed 32 bit
values.
In case someone out there is a mental cripple, the 16x4 bits can be
translated into 16x2 bits by assigning weights as follows for the
matching fields -
IDA field 00 - 0000 - no bits
IDA field 01 - 000x - x - 1 bit
IDA field 10 - 00xx - xx - 2 bits
IDA field 11 - 0xxx - xxx - 3 bits
The decision of which form to use is up to you, but probably the
deciding factor will be whether the data is stored on hard copy, or
transmitted in some fashion. Unpacking 32 bits takes much longer, but
they transmit twice as fast. Also consider the transmission medium
error rate, with the possibility that a block may become
indecipherable if multiple errors occur beyond the ability of ECC to
correct.
The coordinate difference will use all four of the bits to form a
vector from the most recent IVGTA coordinates to the current one,
signed and of magnitude between -7 and +7 for each four bit field.
Another factor to consider is that if you do indeed want to perform a
shuffle within the 16 factorial possibilities for the packed
coordinates, then you just bought yourself a headache doing the task
of unpacking them for decoding...
In summary, only a miser would use the bloat factor of 4 versus 8
encoding scheme.
Lonnie Courtney Clay
On Nov 29, 5:08 am, LCC <claylon...@comcast.net> wrote:
> Index to coordinates transformation
> For a particular value between 0 and 2**27, slice it into 16 fields
> using the IDA table entry specification. For an IDA field 00, there is
> no dimension, so just concatenate 4 bits with value zero onto the
> result. For IDA field 01, the dimension is two - one bit, so slice one
> bit from the LSB end and form a 4 bit value from it to concatenate
> onto the result. For an IDA field 10, slice two bits. For an IDA field
> 11, slice three bits. How you form the result from the 16x4 bits is
> something which I would make a user option to either go big-endian or
> little endian. Alternatively you could use one of the 16 factorial
> possible shuffles provided by a lookup table, if you designed the
> translation to be THAT flexible…
the coordinate difference method rather than the packed 32 bit
values.
In case someone out there is a mental cripple, the 16x4 bits can be
translated into 16x2 bits by assigning weights as follows for the
matching fields -
IDA field 00 - 0000 - no bits
IDA field 01 - 000x - x - 1 bit
IDA field 10 - 00xx - xx - 2 bits
IDA field 11 - 0xxx - xxx - 3 bits
The decision of which form to use is up to you, but probably the
deciding factor will be whether the data is stored on hard copy, or
transmitted in some fashion. Unpacking 32 bits takes much longer, but
they transmit twice as fast. Also consider the transmission medium
error rate, with the possibility that a block may become
indecipherable if multiple errors occur beyond the ability of ECC to
correct.
The coordinate difference will use all four of the bits to form a
vector from the most recent IVGTA coordinates to the current one,
signed and of magnitude between -7 and +7 for each four bit field.
Another factor to consider is that if you do indeed want to perform a
shuffle within the 16 factorial possibilities for the packed
coordinates, then you just bought yourself a headache doing the task
of unpacking them for decoding...
In summary, only a miser would use the bloat factor of 4 versus 8
encoding scheme.
Lonnie Courtney Clay
Reply all
Reply to author
Forward
0 new messages