Re: cryptanalyzing bitwise tramps?
- From: HHaller <hhaller@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 24 Mar 2008 09:51:54 -0800 (PST)
Doug <nospam@xxxxxxxxxx> wrote:
I'm thinking of a btc which takes a password and uses it to
determine an input buffer size. The (alphabetic) order of
the letters determines a scheme for "swapping" 0 or 1 bits
within that buffer, producing characters unlike the input
byte stream. After each buffer is written out, the password
is "progressed" by rotating the letters and re-figuring the
bit swapping plan, so any attack s/b an algorithmic one.
(Obviously, the password size has to be multiplied by 8 to
create a large enough plan and buffer.)
This isn't "real math", it's just a mechanical program, but
I wanted something simple enough for beginners to play with.
My question is, how would a knowledgable cryptanalyst attack
it? Is it trivial enough that I don't need to worry about
it being of (morbid) interest to our government?
does it provide a one to one mapping of input to output ?
In the sense that the same number of bytes comes out as goes
in, yes. But no one input byte corresponds to any one output
byte, since its bits are distributed throughout the whole
working buffer, which could be several k long.
consider how you would de-encrypt it.
Decryption involves reversing the swap, (the program
encrypts and decrypts reliably.)
Here's the actual swap code:
int order[number_of_bits] contains the "destination" array
indices with which the source buffer's bits (accessed in order
via for(;;) loop) are swapped. order[] is built by multiplying
the password length by 8 and analyzing the alphabetic order
of its letters to produce unique integers.
+++++++++++++++++
inline void
TBit::mixbit( bool encrypt, int * order, char * inBuffer, char *outBuffer)
{
for (int rbit = 0 ; rbit < number_of_bits ; rbit++)
{
if (encrypt)
{
if (testBit(rbit, inBuffer))
{
setBit(order[rbit],outBuffer) ; // (buffer starts with all bits cleared)
}
}
else
{
if (testBit(order[rbit], inBuffer))
setBit(rbit,outBuffer) ;
}
} // for rbit
return ;
} // mixbit
+++++++++++++++++
how do you keep track of indexing, word boundaries, etc.
I don't think that's relevent. When I say "transpose bits"
I don't mean "transpose bits within bytes", but rather,
"transpose bits in a (large, usually) multi-byte buffer.
The program doesn't care about word boundaries, and in fact,
I'm expecting the user to compress (zip) the input before
encrypting, since a long run of nulls or 0xFFs would come
out as chunks of nulls or FFs, there being no '1' (or '0')
bits in the input stream, and swapping identical bits only
doesn't change anything.
(I suspect that a long run of identical input bytes would
provide an entry for reconstructing the password from the
output, too, or is that naive?)
The resistance (if any) of the program to a brute force
attack comes from using long passwords -> big buffer, where
bits may be swapped among many bytes.
My questions concern how a professional would develop a
plan of attack if they don't know the password length
(and therefore the buffer size), and don't want to try
brute force. Not being a math major, I'm still guessing
there are ways to do it which I've not heard of.
(Thanks for responding, btw:)
.
- Follow-Ups:
- Re: cryptanalyzing bitwise tramps?
- From: yarrkov
- Re: cryptanalyzing bitwise tramps?
- References:
- cryptanalyzing bitwise tramps?
- From: HHaller
- Re: cryptanalyzing bitwise tramps?
- From: Doug
- cryptanalyzing bitwise tramps?
- Prev by Date: Re: my KDF vs dictionary attacks
- Next by Date: Re: Boneh-Franklin Identity Based Crypto
- Previous by thread: Re: cryptanalyzing bitwise tramps?
- Next by thread: Re: cryptanalyzing bitwise tramps?
- Index(es):
Relevant Pages
|
|