Re: Bit-swaps

On Sep 9, 2:22 am, David Eather <eat...@xxxxxxxxxx> wrote:
hayes...@xxxxxxxxx wrote:
On Sep 8, 3:14 pm, David Eather <eat...@xxxxxxxxxx> wrote:
hayes...@xxxxxxxxx wrote:
On Sep 7, 1:10 pm, jonas.thornv...@xxxxxxxxxxx wrote:
On 7 Sep, 18:37, jonas.thornv...@xxxxxxxxxxx wrote:
On 4 Sep, 16:44, hayes...@xxxxxxxxx wrote:
I was looking at bit-swaps as a means of disconnection passwords from
data
Looking at a single byte 8 bits labeling the bits ABCD EFGH
I wanted to see the number of potential swaps that existed obvious for
a swap that means your bit has to move so no duplicates and it can not
remain in the same location.
The result being 14833 combinations a small fraction of 8 to the power
of 8. Which means you need a minimum of 14 bits of data to be able to
select all the combinations. Even then it isn't an even distribution..
The best bet is to use enough data to cover the field numerous times
and reduce the unevenness of usage. going to a full 2 bytes would help
but it would be more effective to use 3 bytes of data even if you did
something like (B1*B2*B3)%14833.
This would be even more effective with larger values 16 bits, 32, 64,
and 128. However, I am not sure it can be done to a very large scale
certainly not using a table they would be far to large. It also can
make for a fairly intensive routine.
char List[]="ABCDEFGH";
    unsigned int t=0;
    for (int a=0;a<8;a++){
    for (int b=0;b<8;b++){
    for (int c=0;c<8;c++){
    for (int d=0;d<8;d++){
    for (int e=0;e<8;e++){
    for (int f=0;f<8;f++){
    for (int g=0;g<8;g++){
    for (int h=0;h<8;h++){
    if(a!=b && a!=c && a!=d && a!=e && a!=f && a!=g && a!=h && b!=c &&
b!=d && b!=e && b!=f && b!=g && b!=h && c!=d && c!=e && c!=f && c!=g
&& c!=h && d!=e && d!=f && d!=g && d!=h && e!=f && e!=g && e!=h && f!
=g && f!=h && g!=h)
    {if(a!=0 && b!=1 && c!=2 && d!=3 && e!=4 && f!=5 && g!=6 && h!=7)
    {cout<<t<<" "<<List[a]<<" "<<List[b]<<" "<<List[c]<<"
"<<List[d]<<" "<<List[e]<<" "<<List[f]<<" "<<List[g]<<"
"<<List[h]<<"\n";t++;}}
    }}}}}}}}
You idea is good but you make it more complicated then it need to be.
Any password can be transformed to a permutation table of invidual
elements.
And there is nothing that prevents the actual table from holding more
states than the actual key.
With other words even an 8 bit password can be transformed into a 4096
bit key.- Dölj citerad text -
- Visa citerad text -
And of course you can use the 4096 bit key as an initiator, In one of
your avalanching streams.
How many states the actual permutation can take on depend on the bit
size of the element you choose to move around. I prefer to split the
stream in two permutation tables than use bytewise swaps between the
tables xor together for your pseudorandom stream.
The real point of that was to make reverse trees pretty much
impossible.
There still smaller issues. Such as 255 would only translate to 255
regardless.
254 would only have 7 actual other results. So there is problems with
it.
But that is why it would only get used as a fraction of the entire
process.
You might find something of interest in the ciphers of A.A. Moldovyan
and N.A. Moldovyan (one of manyhttp://en.wikipedia.org/wiki/CIKS-1)
They do not use bit permutations for a key schedule but use it for the
data path of the cipher.

Thanks for the idea David

Um, most of Moldovyan's ciphers are broken because the bit permutation
function is not strong enough.



I thought about using it with something like this below. Can you
imagine the
headache it would create for someone trying to resolve the functions
used
in ciphering the data. Not to mention not having to write 14833 if
statements.
It would be fast as heck not having to do all the tests as well. Well
I guess that
depends more on how the compiler implements it.
/
*****************************************************************************************/
#include <iostream>
#include <stdio.h>
using namespace std;

typedef int(*pt2function)();

int hello();
int goodbye();

int main(int argc, char* argv[])
{
   pt2function FunctionArray[2];
   FunctionArray[0]=&hello;
   FunctionArray[1]=&goodbye;

   int b=0;
   for (int a=0;a<10;a++)
   {
           b=a%2;
           cout<<b<<" ";
           FunctionArray[b]();
           cout<<"\n";
   }
   system("PAUSE");
   return 0;
}

int hello(){cout<<"hello";}
int goodbye(){cout<<"goodbye";}

Your right they aren't any different that say a poly-alphabetic
cipher. Which is why you have to do more than just that.
In truth you look at most methods and break them down they are
relatively simple parts just added on top of one another.
The trick is to compensate in a way that makes them stronger.
.

Relevant Pages

  • Re: Bit-swaps
    ... How many states the actual permutation can take on depend on the bit ... stream in two permutation tables than use bytewise swaps between the ... most of Moldovyan's ciphers are broken because the bit permutation function is not strong enough. ... int hello; ...
    (sci.crypt)
  • Re: Bit-swaps
    ... Visa citerad text - ... How many states the actual permutation can take on depend on the bit ... stream in two permutation tables than use bytewise swaps between the ... tables xor together for your pseudorandom stream. ...
    (sci.crypt)
  • Re: Bit-swaps
    ... How many states the actual permutation can take on depend on the bit ... stream in two permutation tables than use bytewise swaps between the ... You might find something of interest in the ciphers of A.A. Moldovyan ... int goodbye; ...
    (sci.crypt)
  • Re: Bit-swaps
    ... I wanted to see the number of potential swaps that existed obvious for ... How many states the actual permutation can take on depend on the bit ... stream in two permutation tables than use bytewise swaps between the ... tables xor together for your pseudorandom stream. ...
    (sci.crypt)
  • Re: Bit-swaps
    ... How many states the actual permutation can take on depend on the bit ... stream in two permutation tables than use bytewise swaps between the ... tables xor together for your pseudorandom stream. ... You might find something of interest in the ciphers of A.A. Moldovyan ...
    (sci.crypt)