Cryptography-Digest Digest #473, Volume #10 Sat, 30 Oct 99 20:13:04 EDT
Contents:
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Joe Rongen")
Re: announcement: steganography program "steghide" (jerome)
Re: Bruce Schneier's Crypto Comments on Slashdot (wtshaw)
Re: Compression: A ? for David Scott (Tom)
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: the ACM full of Dolts? (SCOTT19U.ZIP_GUY)
Re: This compression argument must end now ("Douglas A. Gwyn")
Re: Re: Compression: A ? for David Scott (CoyoteRed)
Re: Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
Re: Bruce Schneier's Crypto Comments on Slashdot (SCOTT19U.ZIP_GUY)
NEW CLUE FOR CONTEST (SCOTT19U.ZIP_GUY)
Re: Bruce Schneier's Crypto Comments on Slashdot (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
Reply-To: "Joe Rongen" <[EMAIL PROTECTED]>
From: "Joe Rongen" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Sat, 30 Oct 1999 18:20:55 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]...
>
> On Sat, 30 Oct 1999 02:34:42 GMT, in
> <[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED]
> (Scott Nelson) wrote:
>
> >>[...]
> >>(1)
> >>The machine you are most likely now using contains a number of
> >>quartz
> >>crystals used for timing various processes, including the
> >>operation of
> >>the CPU. The crystals are accurate to ~0.02%, as I recall.
> >
> >You recall incorrectly.
> >Quartz crystals are _guaranteed_ to .0002% and are usually more
> >accurate than that, with better than 1 part per 10,000,000
> >being fairly typical.
> >
All that was 'before' the common usage of 'phase-locked-loop' (PLL)
oscillators (and some temperature compensated crystal oscillators.)
Just for fun...compare those in size and accuracy to the 'huge crystal
ovens' employed by HP in the '60 for their frequency counters. :-)
Regards Joe
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: announcement: steganography program "steghide"
Reply-To: [EMAIL PROTECTED]
Date: Sat, 30 Oct 1999 19:15:11 GMT
On 30 Oct 1999 17:12:59 GMT, David A Molnar wrote:
>
>Assuming you can guarantee that an adversary who inspects what you're
>sending can't figure out the receiver, of course. :-)
how the adversary could find out ?
it is a single communication channel. everybody send data in it and only
the receiver and the sender know which part of the data is the message.
i fail to see how a adversary can find out where is the message in the
data.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Bruce Schneier's Crypto Comments on Slashdot
Date: Sat, 30 Oct 1999 14:03:48 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
> Omar Y. Inkle ([EMAIL PROTECTED]) wrote:
> : [EMAIL PROTECTED] (jerome) wrote:
....
> : Since he can account for all of the really brilliant cryptographers, the
> : only way there could be some working for the NSA would be if they were
> : secretly cooking them up in a lab somewhere or recruiting beings from
> : another planet.
...
Remember that military doctrine preaches that men can be trained to do
anything required. This is not always so. And, when there is a need
larger than current supply, like in WWII, a doulble whammy hits them.
Speciality functions may resist training, as individuals must be sought,
like 7 foot basketball players, the dream of giving growth hormone to
selected people in order to create a pool not being socially acceptable.
> the open community has not matched. On the other hand, they do seem to
> have expertise in judging the strength of cipher systems, at least against
> currently known attacks, much more precisely than is done in public.
NSA acts like an individual, good a certain things, mediocre in most, and
an utter failure in others. Trying to fight top-down organization is
sometimes a doomed effort as those in power positions often lack the
necessary gut intelligence to be able to appreciate the results of their
*lessers.*
--
To make a mountain out of a molehill, just add dirt.
------------------------------
From: [EMAIL PROTECTED] (Tom)
Subject: Re: Compression: A ? for David Scott
Date: Sat, 30 Oct 1999 23:09:04 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 30 Oct 1999 13:27:48 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> By one to one I mean for any file X Compress( Decompress (X)) = X
>while most only consider for any file Y Decompress( Compress (Y)) = Y
>most only consider the second but with encryption you need to consider
>both.
>..
That means that in some cases you'll be reducing patterns, and in
other cases creating them.
Worse than that - this scheme makes the implementation of a chosen
plaintext attack trivial, where using standard compression makes some
forms of chosen plaintext attack completely impossible.
So the data may have patterns, isn't necessarily shorter, is in some
cases more vulnerable to attack. In short, if you want to de-pattern
the data before encryption, use encryption software, not compression
software. If the compressor's job was to hide data, it'd be called a
cipher.
I do find the concept of symmetrical compression interesting, but at
this point I'm certain it's not practical for cryptography.
More useful would be headerless compression, or even header specific
compression, that is something that compressed the header of a zip or
other compressed file, or removed checksums so that anything would
always decompress to *something*. As an example of the former, say if
a byte of the header was used to keep track of a value from 0 to n,
where n<255, add random data in the form of x^n, where x is a pseudo
random integer >=1, then mod n to decompress. Maybe that's not a
great example, but it would at least offer some resistance to known
plaintext attacks.
All interesting, though, and fun to follow.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Sat, 30 Oct 1999 20:56:02 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>
>> Mok for his example if you changed the entry so that it did not appear
>> in the dictionary. THen on decompression using his method that part
>> of code would remain unchanged so there is no problem. It is still
>> 1-1.
>
>But this unchanged part, now on the source side, can by chance combine
>with some symbols preceeding it to form a valid larger entry in the
>dictionary and thus leads to something different when one applies
>compression again. This means 1-1 is not fulfilled unless the
>dictionary satisfies some special conditions, which I don't know
>yet how to formulate at all.
>
Show me?
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)
Subject: Re: the ACM full of Dolts?
Date: Sat, 30 Oct 1999 21:05:40 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY schrieb:
>>
>> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>> >SCOTT19U.ZIP_GUY wrote:
>> >>
>> >
>> >> Quote Start
>> >> -- There are several major technical pieces that are missing from this
>> >> article. Most importantly, no motivation is ever presented for designing
>> >> compression algorithms to be one-to-one. Further, I have an easier
>> >> solution to the "file ending problem" -- use a filesystem that stores the
>> >> bit- length of each file rather than the byte-length. (After all, the
>> >> conventional view that a file's size is some multiple of 8 bits is an
>> >> illusion
>> >> provided by the filesystem, which actually allocates in larger chunks.)
>> >> Quote End
>> >
>> >In another thread (Unbiased one-to-one compression, initiated by
>> >John Savard), I happened to have expressed the view that,
>> >if one uses an adaptive Huffman with an initial distribution
>> >unknown to the analast, then one could allow the 'luxury' of
>> >explicitly stating the length in number of bits, thus circumventing
>> >in some sense the one-to-one problem. I guess that it could be that
>> >the referee had something similar to that in mind.
>> >
>> Since there was no communications with the referee one will never
>> know what he had on is mind. But if you hard code the number of bits
>> as a number then it will not be one to one and you are inserting information
>> that would be of use to the attacker. The whole point of one to one was to
>> prevent the addition of information to the file when one uses compression.
>> The ending problem is solved in my version of adaptive huffman compression.
>> so it is wasteful to add the lenght to the file.
>
>You evidently neglected the point that, your attempted prevention
>of the analyst being able to gain any information from the
>'non-one-to-one' property is no longer essential (of importance),
>when the compression scheme is such that he doesn't know the
>proper way to use it. What matters if one adds plaintext information
>to the file which the analyst can't use it to any 'practical'
>advantage? Note that, if an adaptive Huffman is started from different
Why add anything extra to the plaintext when it clearly is not needed?
>initial frequency distribution then the output will generally be of
>different length. He can try a very large number of different
>distributions to obtain the length that is stated in plaintext and
>available to him. But the huge work factor will in practice render
>his attempt futile. And, even if he succeeds to guess a distribution
>that gives the correct length, he is still not sure to have indeed
>found the right distribution and hence the right Huffman tree.
>
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: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: This compression argument must end now
Date: Sat, 30 Oct 1999 20:30:34 GMT
Tom St Denis wrote:
> Ok, explain to me what good knowing the file extension would be?
That wasn't what he meant -- it was knowing the *type* of file.
.EXE and .DLL files aren't just arbitrary data that happen to have
been assigned names ending in those "extensions"; they have a
specific purpose (executable image or dynamically-linkable object-
module library) and as such have exploitable internal structure.
Even a simple .TXT file (meaning: contents are ASCII text) has
its own characteristic internal structure that is easy to exploit.
Even if the names (extensions) were changed, the characteristic
structure of the contents would remain, and that is what can be
exploited.
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Re: Compression: A ? for David Scott
Date: Sat, 30 Oct 1999 19:32:23 GMT
Reply-To: this news group unless otherwise instructed!
On Fri, 29 Oct 1999 13:09:39 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> For that matter just XOR your data with the random data in the
>first place and kiss off compression all together.
I may need to re-read the manual on PGP but isn't the actual key to
the encrypted data pretty much a random file that has been encrypted
with your public key?
So a plain text file encrypted with a file of random data is secure
from attack (with sufficiently long key) AND the random file that is
the key HAS no recognizable data to analysed, does this mean that this
scheme is free from analysis?
Second, if you are using compression to hide patterns, wouldn't XORing
a random file be just as effective AND without the "built-in"
cryptanalytic tool of compression; one-to-one or other wise?
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Re: Compression: A ? for David Scott
Date: Sat, 30 Oct 1999 22:06:16 GMT
In article <[EMAIL PROTECTED]>, this news group unless otherwise
instructed! wrote:
>On Fri, 29 Oct 1999 13:09:39 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>> For that matter just XOR your data with the random data in the
>>first place and kiss off compression all together.
>
>I may need to re-read the manual on PGP but isn't the actual key to
>the encrypted data pretty much a random file that has been encrypted
>with your public key?
IN theroy that was what it was suspose to be. I have not read the manual
since 2.6.3
>
>So a plain text file encrypted with a file of random data is secure
>from attack (with sufficiently long key) AND the random file that is
>the key HAS no recognizable data to analysed, does this mean that this
>scheme is free from analysis?
Nonthing is totally secure from some sort of attack. But if you
encrypt a random file with a random key you should hope that it is
secure from attack since the attacker would not know the correct key
from the incorrect key. But when you throw a bad compressor (non one to one)
in the mix. It may be quite possilbe that the only key that decrypts to a file
which decompresses nicely is the random file that you ran through the
compressor and then encrypted.
Note by decompresses nicely I mean if you decompress a test file than
recompress it comes back to the test file. Most compression routines have
this feautre lacking.
>
>Second, if you are using compression to hide patterns, wouldn't XORing
>a random file be just as effective AND without the "built-in"
>cryptanalytic tool of compression; one-to-one or other wise?
That is correct if you can XOR with a random file and you can share
that random file with you buddies you can kiss compression and pgp
good bye. Since you can use a proveable secure ONE TIME PAD
the trick is the so called random file.
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)
Subject: Re: Bruce Schneier's Crypto Comments on Slashdot
Date: Sat, 30 Oct 1999 21:56:58 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(wtshaw) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
>
>> Omar Y. Inkle ([EMAIL PROTECTED]) wrote:
>> : [EMAIL PROTECTED] (jerome) wrote:
>.....
>> : Since he can account for all of the really brilliant cryptographers, the
>> : only way there could be some working for the NSA would be if they were
>> : secretly cooking them up in a lab somewhere or recruiting beings from
>> : another planet.
>....
>Remember that military doctrine preaches that men can be trained to do
>anything required. This is not always so. And, when there is a need
>larger than current supply, like in WWII, a doulble whammy hits them.
>
>Speciality functions may resist training, as individuals must be sought,
>like 7 foot basketball players, the dream of giving growth hormone to
>selected people in order to create a pool not being socially acceptable.
I see you don't keep up with reality. I saw a special at least a year ago
about the wide spread abuse of human growth hormones that are being
prescribed by doctors so parents can create future basket ball players.
I already see super model eggs for sale on the net. I am sure sports figures
will be selling there sperm shortly. By the way any females out there I will
let you have mine cheap.
>
>> the open community has not matched. On the other hand, they do seem to
>> have expertise in judging the strength of cipher systems, at least against
>> currently known attacks, much more precisely than is done in public.
>
>NSA acts like an individual, good a certain things, mediocre in most, and
>an utter failure in others. Trying to fight top-down organization is
>sometimes a doomed effort as those in power positions often lack the
>necessary gut intelligence to be able to appreciate the results of their
>*lessers.*
Seeing how the rest of the government is going down the shitter it would
be no surprise to see or hear the NSA is going down to. But that does not mean
they are not way ahead of the rest of us. Becasue they not only get to see
what we see and more. They get to spread disinformation and lies which has
become one of the major functions of the US government.
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)
Subject: NEW CLUE FOR CONTEST
Date: Sat, 30 Oct 1999 22:40:32 GMT
Well It is not yet Nov 1 but the latest nibble was
added for the gloat contest. You know the one that
if anyone even tried to do this with any of the weak
AES methods the solution would have been so easy
that the anwser would be obvious. This was done to show
how ridiculous the AES methods are.
There are only 28 bits that are left unknown even Tommy
ought to be able to brute force it know.
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)
Subject: Re: Bruce Schneier's Crypto Comments on Slashdot
Date: Sat, 30 Oct 1999 22:45:44 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> ... He has absolutely no proof that the socalled
>> attacks against Skipjack were not known by the NSA. ...
>> Does he really think they meant it to be secure?
>
>It was the LEAF, not the Skipjack encryption algorithm, that was
>intended to permit law enforcement access to the message contents.
>The encryption algorithm was a member of a family of "Type I"
>algorithms, meaning that the general methodology was considered
>adequate for protecting critical information against any serious
Note critical does not mean TOP SECRET info.
>external threat in the foreseeable future. Skipjack hasn't
>actually been cracked, to my knowledge; the so-called "attacks"
>have been more of academic interest than practical.
>
>Another point is that the system in question was developed by one
>of numerous separate groups within NSA, the ISSO as I recall,
>and although its design was "vetted" by analysts from another group,
>it doesn't necessarily represent the absolute best that anybody in
>NSA is capable of producing.
I agree they could and can do much better. I was being critcal of
Mr BS. who was trying to seduce the rest of us into thinking the
NSA is not to far ahead of the public in the crypto field. He was just
pushing stuff the NSA wants the masses to belive.
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***
------------------------------
** 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
******************************
