Improving the AONT pakagetransform



Iits hard to find a PDF copy of anything any more I searched for Ron
paper on the
package transform. It may be out there but for most its harder and
harder to get
real research papers because they are tied up in things like IEEE when
asked to
referee a paper It was almost impossible to get access to their
references but they
would make an exception while doing look up on paper I was reviewing.
But sadly
there was no access to the code they use to produce such results makes
one
wonder if many papers are bogus.

That aside in in Ron's all or nothing package transform you take a
message say its
a long message of English text you first encrypt it say with AES in a
mode where
he uses say a key of 256 bits. Then you would do hash on the message
use it
with the key store at end of file. For sake of argument lets assume
that all block
16 bytes and a different key selected at "random" every time you
encrypt.

At this point say your stuck with 40 bit crypto you then encrypt
whole file with
it again assume block size the same and pass it on.

The fact is his method increases the unicity distance in the Shannon
sense form
what it would be for the just the plain 40 bit crypto. Because know
you have to
calculate the unicity distance for at most 40 + 256 bit crypto.
Actually it closer
to 256 bits than the sum above but who cares. The point is to extend
the number
of cipher text blocks needed to have enough information to break the
encryption
with a ciphertext only type of attack. For something like English
this is only
a few extra blocks so from an informational point of view its not much
protection.

There may not be a yet public available way to break this but from
Shannon
theory even a few blocks shows that there is enough information for a
break.
Don't take it wrong there is a lot more work involved that in trying
to break
a 40 bit key. Yet the fact is such an attack even with the larger
effective key
is possible in only a few short blocks.

The common thing to do about this is to never worry about plaintext
attacks or
ciphertext only attacks when the attacker his a good idea of the file
type your
encrypting. I call this approach the hide head in sand approach which
means if
the attack is not publicly available even though Shannon theory tells
you it possible
in a few short blocks who cares. This sadly is how modern cyrpto is
done today.
Or you can do something like what follows.

In my view if you do the inner package the same but before you do
the outer
40 bit crypto do my special binary bijective UNBWTS then there will
not even be
enough information for any kind of break in short segment of a file
since it will
effectively incearse the unicity distance.

But I suspect people here will ignore the extra step since its seems
that having
a long encrypted message where you can insure more informational
security by
insuring that it would take most of the file before such a break is
possible is of
little or no concern. But with many message with common info repeated
in fixed
parts of message you would think someone would care.


David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
.



Relevant Pages

  • Re: Matrixview SWISH almost two times better compression then GZIP and much faster
    ... like open source, chosen plaintext, lots of computing power. ... the ciphertext was encrypted with ME6 -- or simply encrypt the ME6 ... computing power and lots of crypto experts to help. ... If ME6 can't withstand such an attack, ...
    (comp.compression)
  • Re: strengthening /dev/urandom
    ... ]> crypto primatives it should make no difference. ... made a reasonable guess as to how much predictability there is in the ... If I can use this data in an attack, ... There is more than enough evidence that drinking and accidents are ...
    (sci.crypt)
  • Re: strengthening /dev/urandom
    ... While it may use crypto to "mix the pool" and to ... distill entropy in the input it should not depend on ... If I can use this data in an attack, ... assume that AES whatever is NOT secure. ...
    (sci.crypt)
  • Re: strengthening /dev/urandom
    ... If I can use this data in an attack, ... "Blocking on more entropy input exposes traffic analysis of event ... "Assuming AES256/SHA256 are secure is a bad judgment." ... > a hobby, not a crypto expert. ...
    (sci.crypt)
  • Re: Protect exe code against being decompiled
    ... encrypt it then it has what it needs to unencrypt it to ... your own crypto code. ... > because users can't run anauthorized executables. ... > Somebody knows some tool to encrypt an EXE file of such ...
    (microsoft.public.security)