Cryptography-Digest Digest #767, Volume #10 Sun, 19 Dec 99 11:13:01 EST
Contents:
Re: First Bijective Arithmetic Compression ("Gary")
Re: 'Simple' password storage (CLSV)
Re: The 20 years periods did apply to 2 of the 3 patents. >> Thanks for
([EMAIL PROTECTED])
Re: First Bijective Arithmetic Compression (SCOTT19U.ZIP_GUY)
Re: The 20 years periods did apply >> Avpr, jgfunj !!! ([EMAIL PROTECTED])
Re: Casio's Multi Dimensional Space Rotation encryption (SCOTT19U.ZIP_GUY)
AES and MATTS COMPRESSION (SCOTT19U.ZIP_GUY)
Re: CryptoPunk - 128 bit encryption? (Tom St Denis)
Re: random numbers straight out of MS BASIC (Tom St Denis)
Re: Casio's Multi Dimensional Space Rotation encryption (Tim Tyler)
Re: First Bijective Arithmetic Compression ("Gary")
Re: Casio's Multi Dimensional Space Rotation encryption (CLSV)
Re: compression & encryption (Tim Tyler)
dictionary attack ("Michael Velten")
Re: First Bijective Arithmetic Compression (Tim Tyler)
----------------------------------------------------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Date: Sun, 19 Dec 1999 13:07:37 -0000
First of all you constantly state Compress(Decompress(X))=X, as if this is
all an analyst can use to confirm a sucessful decryption. However your
system still doesn't stop an analyst checking Decompress(X) for headers such
as those found in jpeg,bmp,exe and text strings like "the" " a ". IE your
compression routine is little more than a time consuming process an analyst
has to go through to get to the the actual information he wishes to analyse.
Seconly to get the one to one property you've had to introduce rules to
bodge illegal decompressions.
Take your 4th rule;
David says:"
Rule four: ( hardest rule of all) If the last byte has the last token start
in the last 7 bits of the last byte and only contains zeros on that byte .
You assume that there are hidden ones that where chopped off during
compression. Only if the file that is one token shorter than this one, would
have had hidden 1 bits cutoff during its compression. This rule means that
the all zero start of the last token in the last 7 bits could depend on what
would have happened to the next shorter file, and that file status could be
a function even further back in the file. It was the lack of focus on my
part that made me miss this recursive rule for a while, and I kept getting
more and more complicated special cases. I hope this solves this.
"
If an analyst found that this rule was invoked and knows that you never
randomly chopped off hidden ones in compression, it would indicate to him
that this is an illegal non 1-1 decompression and can be chucked out!
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: 'Simple' password storage
Date: Sun, 19 Dec 1999 13:30:31 +0000
Jerry Coffin wrote:
>
> [EMAIL PROTECTED] says...
> > Where do I find all of the AES entrants source code? I am relatively new to
> > cryptography, but a firm programming background makes it a lot easier to
> > understand what you are talking about.
Better get a firm crypto background. Reading source code
without understanding the cryptographic principles is not the
way to go. OTOH learning the basic principles with real-world
examples at hand is.
> Some of them are available from the individual entrants [...]
For links see the Block Cipher Lounge:
http://www.ii.uib.no/~larsr/aes.html
> Assuming (as appears to be the case) that you're located inside
> the US, you can also get a CD-ROM from NIST that contains source
> to all of them plus various other technical information about them.
You can also get this CD-ROM from NIST when you are outside
the US. Look at their homepage how to apply for an export
license:
http://csrc.nist.gov/encryption/aes/aes_home.htm
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: The 20 years periods did apply to 2 of the 3 patents. >> Thanks for
Date: Sun, 19 Dec 1999 08:38:35 -0500
Thanks for the contributions. It has been great !
--
Thanks, Richard
=====================================================
[EMAIL PROTECTED] wrote:
>
> The 3 most known patents in the encryption area are :
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: First Bijective Arithmetic Compression
Date: Sun, 19 Dec 1999 14:29:47 GMT
In article <83ilim$1b8$[EMAIL PROTECTED]>, "Gary" <[EMAIL PROTECTED]>
wrote:
>First of all you constantly state Compress(Decompress(X))=X, as if this is
>all an analyst can use to confirm a sucessful decryption. However your
>system still doesn't stop an analyst checking Decompress(X) for headers such
>as those found in jpeg,bmp,exe and text strings like "the" " a ". IE your
>compression routine is little more than a time consuming process an analyst
>has to go through to get to the the actual information he wishes to analyse.
>
If the analyst knows your trying to compress any file with headers of
any type. The analyst can check for those headers regardless when he
uncompresses assumming he can uncompress. What you can't seem to
understand is that this compression is not encryption. It can't totally hide
what is in the file being encypted. What it does do is not add additional
information to help an attacker.
>
>Seconly to get the one to one property you've had to introduce rules to
>bodge illegal decompressions.
Again you not using your brain your wrong!!
>Take your 4th rule;
>David says:"
>Rule four: ( hardest rule of all) If the last byte has the last token start
>in the last 7 bits of the last byte and only contains zeros on that byte .
>You assume that there are hidden ones that where chopped off during
>compression. Only if the file that is one token shorter than this one, would
>have had hidden 1 bits cutoff during its compression. This rule means that
>the all zero start of the last token in the last 7 bits could depend on what
>would have happened to the next shorter file, and that file status could be
>a function even further back in the file. It was the lack of focus on my
>part that made me miss this recursive rule for a while, and I kept getting
>more and more complicated special cases. I hope this solves this.
>"
>
>If an analyst found that this rule was invoked and knows that you never
>randomly chopped off hidden ones in compression, it would indicate to him
>that this is an illegal non 1-1 decompression and can be chucked out!
>
What are you talking about the rules I have on endings can and do occur
with any large set of text files. You obviously have not tested this out.
If an analyst gets a binary file that he is decompressing and follows my
set if rules he gets a unique file. If it was ascii so be it. But your wrong
in assuming that based on rule 4 or any for that matter that there is
something that indicates that is a faulty compression so chuck it.
You still don't understand.
Show an example if your can?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: The 20 years periods did apply >> Avpr, jgfunj !!!
Date: Sun, 19 Dec 1999 08:44:10 -0500
Avpr, jgfunj !!!
--
Thanks, Richard
========================================================
wtshaw wrote:
>
> Ambiguity is at the heart of the matter.
> --
> Death is easy, life is difficult.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Casio's Multi Dimensional Space Rotation encryption
Date: Sun, 19 Dec 1999 14:43:23 GMT
In article <83ii44$ms1$[EMAIL PROTECTED]>, "Barry" <[EMAIL PROTECTED]> wrote:
>Any information as to the security of this algorithm? Casio say that they
>have developed it themselves, but why when there are more reliable,
>road-tested ones out in the public domain!
>
Maybe they developed there own since they don't have as much
faith in the so called road-tested ones that the NSA may have
already broken.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: AES and MATTS COMPRESSION
Date: Sun, 19 Dec 1999 14:41:53 GMT
IF Matts compression is also bijective or one to one or what ever
and if the rightup on his page is correct then it has one advantage
with a slight mod that mine does not have. The way mine is coded
for all trees to work and get good compression I use 256 symbols.
My ending for 8 bit muliplys requires 129 to 511 symbols. IF I wanted
to go to 64 or 128 bits I can be writting code that bijectively maps
any 8 bit type of file to 64 or 128 or whatever. But Matts seemd to
go to any bytes size directly. He converts his fintely odd bit stream
to a nonnegtive integers and than applies a series of %256 to get it
to byte. If one use a larger base you could go to any byte size in
a one to one or bijective way. This would for those who will be
stuck using AES encryption with there large block sizes solve
the ending problem where a file does not match the mutliple
of bytes needed this would be far better than useing some of
the stupid padding methods the AES would want one to use.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: CryptoPunk - 128 bit encryption?
Date: Sun, 19 Dec 1999 14:13:54 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (MEGstir) wrote:
> http://download.cnet.com/downloads/0-10105-100-917695.html?
tag=st.dl.10105
> _103_1.lst.titledetail
> or
> http://www.winsite.com/info/pc/win95/misc/CryptoPunk11.zip/
>
> So what do you think? Any comments?
>
Seems a bit awkward to me. It mentions '128 bit crypto' but not much
else. It also states it uses a LFSR in some block cipher or something
like that. It also does not say what it uses to make the points [ type
of rng], or the size of the ECF.
I personally would not use the product for more reasons:
1. It can only encrypt files. Big deal. I can use PGP for that
2. It's interface is less then usefull
3. What ciphers does it use?
4. Lack of documentation or source.
Does this person have a website?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: random numbers straight out of MS BASIC
Date: Sun, 19 Dec 1999 14:18:57 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I keep reading about how weak and predictable the built in RNG from MS
> is, so I did some testing. The MS RNG has a repeat series of approx.
> 256^3 or 16777215.
> If I create 10 sboxes with 1000 rnd numbers betw. 0 and 256 based on
2,
> rather large, seeds (> 111111111111111 & < 999999999999999) and a
keybox
> of 1000 rnd numbers betw. 0 and 256 with a seed of ~100000 then I do
> not believe the following is unreasonable.
> Combos ~ 1/4*1/4*1/4 or 4,000,000*4,000,000*25,000. That translates
into
> 4 e17 different attack combos before hitting paydirt. Even at
50,000,000
> combos per second it'd take ~253 years for success. I don't think I'm
> too worried! Have we all forgotten that 20 years after WWII any $5.-
> Encyclopedia had an 'how to' article on the nuclear bomb.
> Perhaps an ill conceived use of the MS RNG is weak, but with a little
> ingenuity in implementation I am at a loss to see the weakness.
> Peter Rabbit
Ok first off you cannot increase entropy with what you have. You have
to add to the pile first. So if there is [for example] 21 bits of
entropy in the RNG, you can't create 2^1024 unique random 1024 bit
states. IT just ain't cricket. Basically no matter what you do, the
entropy of the resulting system is 21 bits.
This means your point is moot. Anything you tack onto the MS rng
function will not make it more random. If you simply change the
algorithm the period will be the same, just different order. My
suggestion is to use a better rng, heck even a LFG would be better in
this case [no more secure.].
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Casio's Multi Dimensional Space Rotation encryption
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Dec 1999 14:39:32 GMT
[Casio's "Multi-Dimensional Space Rotation (TM)" encryption]
Here's a link - for any who missed it:
http://www.casio.co.jp/en/prize_e2v.html
Remember folks, "flow with the Digital Groove" [sic].
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Save the whales. Collect the whole set.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Date: Sun, 19 Dec 1999 14:53:09 -0000
Show me a compressed file that invokes rule 4 on decompression without
amending the compressor to randomly chop off bits!
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Casio's Multi Dimensional Space Rotation encryption
Date: Sun, 19 Dec 1999 14:59:32 +0000
Tim Tyler wrote:
>
> [Casio's "Multi-Dimensional Space Rotation (TM)" encryption]
>
> Here's a link - for any who missed it:
>
> http://www.casio.co.jp/en/prize_e2v.html
Thanks,
Has anyone tried to analyze the algorithm?
(I'm still busy trying to understand it.)
Regards,
CLSV
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: compression & encryption
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Dec 1999 14:56:39 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
[question about compressors addding opatetrened information to the file]
: The alternative view is that the amount of known plaintext revealed by
: this is typically so small that it makes no real difference -- the
: attacker has to have broken the encryption quite thoroughly before a
: tiny amount of known plaintext is even marginally useful. A known-
: plaintext attack against a block cipher normally has to have ALL the
: plaintext for a complete block (e.g. 256 bits) known before it's of
: any use at all.
Curious. The ability to mechanically reject 65535 out of 65536 keys
based on decrypting only the first two bytes of a file effectively
knocks sixteen bits off the key. It pretty much reduces (say) a 64-bit
keyspace to a 48-bit one.
Decrypting the first two bytes of a file is really not much effort
compared to decrypting the whole thing, decompressing it and then looking
for the statistics of English text.
/Perhaps/ your cypher can withstand such a keyspace reduction - if it has
a large enough key in the first place - but why should you tolerate such
nonsense?
If there is some other attack, or the attacker can determine some bits of
the key by other means, the plaintext provided by the poor compression may
be the final straw.
Many types of compression leak information while compression is
in progress - as well as any header they add.
AFAIK, only things like Huffman and Arithmetic coding typically /only/
leak information at the end of the file. Anything (orthodox) that uses a
sliding window, for example, will leak all the way through the compression
process.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
MODEM - Monumentally Overpriced Data Eating Machine.
------------------------------
From: "Michael Velten" <[EMAIL PROTECTED]>
Subject: dictionary attack
Date: Sun, 19 Dec 1999 16:07:33 +0100
Hi,
can anybody tell me, where i can find a good (german) dictionary for a Brute
Force-Attack?
Thanks
Michael
___________________________
Michael Velten
eMail: [EMAIL PROTECTED]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Reply-To: [EMAIL PROTECTED]
Date: Sun, 19 Dec 1999 15:18:35 GMT
Gary <[EMAIL PROTECTED]> wrote:
: First of all you constantly state Compress(Decompress(X))=X, as if this is
: all an analyst can use to confirm a sucessful decryption. However your
: system still doesn't stop an analyst checking Decompress(X) for headers such
: as those found in jpeg,bmp,exe [...]
You you're saying if your data itself has been compressed with a method
that adds known plaintext, David's compression scheme won't fix it?
You're right - but SO WHAT!?
The conclusion should be to that it might help to use a 1-1 compression
program targetted at these filetypes, that reduces the known plaintext in
these headers down to virtually nothing. The point seem to have no
bearing on the claimed utility of such 1-1 compression programs
themselves.
[...] and text strings like "the" " a ". [...]
A /good/ 1-1 compressor targetted at text will produce text full of
"the" " a ", etc, if you decompress a file of random data. This is one of
the cood things about compression: it increases the proportion of messages
that look plausible once decrypted and decompressed, frustrating any
brute force termination criteria being used by the attacker.
: IE your compression routine is little more than a time consuming process
: an analyst has to go through to get to the the actual information he wishes
: to analyse.
No. This bit at least is in the text books.
To quote from the (embarassingly tiny) section on compression in "Applied
Cryptography":
``Cryptanalysis relies on exploiting redundancies in the plaintext;
compressing a file before encryption reduces these redundancies.''
Compression has other security benefits as well. It reduces the quantity
of cyphertext the opponent has available to analyse, for any given message
traffic, for example. This is not to be sneezed at.
: Seconly to get the one to one property you've had to introduce rules to
: bodge illegal decompressions.
"Bodge"???
David's is the *only* Huffman compression scheme /without/ a "bodged"
end-of-file. His method of termination is actually perfect!
[snip rule]
: If an analyst found that this rule was invoked and knows that you never
: randomly chopped off hidden ones in compression, it would indicate to him
: that this is an illegal non 1-1 decompression and can be chucked out!
You've read David's explanation - but you don't understand it :-(
David's compression demonstrably contains no information that was not in
the original file.
Given the text of the message - or the compressed message, you can
determine which rule is applied to deal with the end of the file.
However, the analyst is looking at an /encrypted/ file. From this, he
has no way of knowing which rule was applied.
If he "telepathically" obtained this information, then it might help him.
...but if he "telepathically" guessed the entire message, that might help
him as well...
You've never stated exactly how an analyst found that a particular rule
was invoked.
Unless you propose some such method, your supposed weakness is without any
visible foundation.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Corduroy pilloys are making headlines.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
