Cryptography-Digest Digest #466, Volume #10 Fri, 29 Oct 99 18:13:05 EDT
Contents:
Re: announcement: steganography program "steghide" (Tom St Denis)
Bruce Schneier's Crypto Comments on Slashdot (Bill Lynch)
Re: ComCryption (SCOTT19U.ZIP_GUY)
Re: Symetric cipher (Bill McGonigle)
Re: Compression: A ? for David Scott (Clinton Begin)
Re: Bruce Schneier's Crypto Comments on Slashdot (SCOTT19U.ZIP_GUY)
Re: Disk wiping code or utility (Dan Day)
Re: the ACM full of Dolts? (SCOTT19U.ZIP_GUY)
Re: VXD Memory Allocator for Win9x (Paul Koning)
Re: Symetric cipher (SCOTT19U.ZIP_GUY)
Re: Bruce Schneier's Crypto Comments on Slashdot (jerome)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: announcement: steganography program "steghide"
Date: Fri, 29 Oct 1999 18:09:31 GMT
In article <[EMAIL PROTECTED]>,
Stefan Hetzl <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have written a steganography program called "steghide". It is
> designed to be portable and configurable and features hiding data in
> bmp, wav and au files, blowfish encryption, MD5 hashing of passphrases
> to blowfish keys and pseudo-random distribution of hidden bits in the
> cover-data. It is copyrighted under the GNU General Public License.
>
> Steghide is written in ANSI C so the source code should compile on
many
> systems. Binaries are available for Windows and Linux. It is available
> from: http://www.crosswinds.net/~shetzl/steghide/index.html
>
> Criticism is welcome.
While I couldn't get the binaries off your site (too slow) I will take
a peek at the source later. A quick comment or two..
1. It's not usefull for general run-of-the-mill daily messaging. You
need too many different pictures/sounds to make it usefull.
2. Software is not copyrighted under the GPL, they are protected under
it.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bill Lynch <[EMAIL PROTECTED]>
Subject: Bruce Schneier's Crypto Comments on Slashdot
Date: Fri, 29 Oct 1999 13:30:06 -0500
VERY interesting read -- thank you Bruce for taking the time to do this:
http://slashdot.org/interviews/99/10/29/0832246.shtml
-- Bill
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ComCryption
Date: Fri, 29 Oct 1999 19:53:15 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:
>One "Dr. Richard Crandall of Apple Computer" is credited with
>suggesting, at a conference in 1998, an encryption idea called
>"ComCryption", where a key of n bits is used to select one of 2^n
>compression algorithms...since the result of compression appears
>random, the cipher might be secure.
Do you know if these compression algorithms where one to one
or not?
>
>I'll have to admit I don't think this is a particularly good idea.
>It's a fruitful original thought, which one can play with in some more
>pedestrian ways, such as Huffman coding with random, keyed code
>assignment as a simple subsitution without easily visible boundaries.
>
>But universal algorithms which are relatives of LZW start out by not
>compressing until they "learn" about the text, so an unknown algorithm
>of that type could still be guessed at...see if the characters make
>sense as 9 bits plus a flag bit; if something different comes along,
>see where the earlier string is that could fit here, and figure out
>how the following bits might point there.
>
>Anyhow, someone had been asking what had become of it. I suppose there
>is the difference between someone like Dr. Crandall - who threw out a
>potentially fruitful suggestion for creative thought - and others who,
>once thinking of an idea that doesn't happen to be really very
>practical, tirelessly advocate it as the cure for ingrown toenails.
Gee did someone on here ask about it?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Bill McGonigle)
Subject: Re: Symetric cipher
Date: Fri, 29 Oct 1999 14:38:03 -0400
In article <[EMAIL PROTECTED]>, Emmanuel Drouet
<[EMAIL PROTECTED]> wrote:
> Please, could you give me informations about several cryptosystems :
> Blowfish, CAST5 and SAFER
Run, do not walk to amazon and get Bruce's "Applied Cryptography". :)
Really, it's an excellent overview, and good enough for many 'engineers'.
-Bill
=====
[EMAIL PROTECTED] / FAX: (419) 710-9745
Dartmouth-Hitchcock Medical Center Clinical Computing
------------------------------
From: Clinton Begin <[EMAIL PROTECTED]>
Subject: Re: Compression: A ? for David Scott
Date: Fri, 29 Oct 1999 18:47:04 GMT
I think I found an interesting property of your compression scheme (and
most likely all compression schemes) that may involve the structure of
the information.
When your decompressor encounters invalid 'compressed' information, the
size of the information remains almost the same (within 1% or 2%) when
the information is 'decompressed'.
Obviously, when valid information is decompressed, the size doubles or
triples (otherwise the 'compressed' information is invalid or the
information was compressed more than once).
Could this be considered a structural weakness? I don't know, but it
seems that an attack similar to the one you are trying to avoid can be
employed by a hacker because of this property of one-to-one compressed
information.
For example, (if you remember from alt.security.pgp) here is the attack
(simplified) that is avoided by using your one-to-one compression:
1) Attempt decryption with random key [M=D(C)]
2) Decompress M to M1
3) Recompress M1 to M2
4) If M2 <> M then key is probably invalid. Eliminate key. Go to 1.
5) Else, perform further analysis on key.
Next, here is the attack that I believe is made possible for the reasons
I described prior to the last example. This is possible with your
one-to-one compression example (and most likely other forms of
compression):
1) Attempt decryption with random key [M=D(C)]
2) Decompress M to M1 *
3) Calculate x = AbsoluteValue(SizeOf(M) - SizeOf(M1))
4) If x < (GetThreshold(SizeOf(M))) then key is may be invalid. **
Eliminate key. Go to 1.
5) Else, perform further analysis on key.
* If decompression fails, the key is invalid. This note applies to
other forms of encryption. Yours never seems to 'fail'.
** This may also mean that the information was compressed by some other
means, before the one-to-one compression. In this case, the hacker
could easily add another step in the process to attempt a second
decompression etc. (i.e. the user encrypted a *.ZIP file, which would
also open up the original attack from the first example).
I believe this attack may be just as dangerous as the one you describe
(first example). In order to avoid it, the decompressor would have to
successfully decompress and change the size of the information to make
it appear as though it could be valid.
I don't know if it would be possible to avoid this attack. In order to
decompress a file, there always has to be some sort of structure. If
the structure isn't there, the decompression fails in one way or
another. Hence, structure is a risk that we cannot avoid. Information
without structure is not information at all. The best we can do (to
date) is reduce the amount of redundancy in our structure.
Given this, my feeling is that sticking with the best possible
compression ratio is probably still the best bet.
Thoughts?
Cheers,
Clinton.
PS: This was a hard concept to describe. If I was unclear, I apologize.
In article <7vcg8v$n94$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <7vc81f$128$[EMAIL PROTECTED]>, "Tim Wood"
<[EMAIL PROTECTED]> wrote:
>
> >True. But it does depend on your definition of bad (low
> >compression/predictable structure).
> My defination of bad is a compressor that adds information
> to a file as it compresses.
> >
> >>If the problem is only that a
> >>good compression program (i.e. pkzip) adds known information to the
> >>header (as exist in many file formats), why wouldn't moving the
> >header
> >>to the end of the plaintext, and running in a feedback mode
> >>effectively eliminate or greatly reduce the problem?
> >
> >Running in a feedback mode would reduce the problem - however it
would
> >be better to eliminate the problem (i.e. find a cure not treat the
> >symptoms) by removing all added structure from the post-compression
> >plaintext.
> And one way to do that is to use a one to one compression scheme.
> >
> >>Additionally,
> >>why wouldn't running a bad compression program be potentially as bad
> >>as no compression, as it could lead to predictable patterns within
> >the
> >>body of the plaintext?
> >
> >Running a compressor that adds sinificant predictable
> >structure/information to your plaintext is probably as bad or worse
> >than no compression (depending on the plaintext you are
commpressing).
> >And certainly not more secure than no compression.
> It is definitely worse.
> >
> >>What if the "compression" program is actually designed to
> >allow/insert
> >>patterns specifically to provide someone with a known plaintext
> >>attack?
> >
> >This should be avoided. Although it is certainly possible. All third
> >party programs suffer from similar possible problems; it comes down
to
> >who you trust... micro$oft for instance? ;-)
> >
> >>If the compression program doesn't actually compress,
> >
> >The compression program should compress (only random data should be
> >uncompressible).
> Becasue of the counting theorm all compressors only make a subset
set
> of files smaller. In fact most files would incearse in lenght of you
looked at
> the class of all real binary files.
> >
> >>wouldn't it make
> >>a whole lot more sense to use an unrelated but standard cipher
> >>(different key, of course) first?
> >
> >That is a whole diffrent issue.... encrypted data should be mostly
> >uncompresible.
> >
> >>It just seems like trying to use a screwdriver as a hammer, and not
> >>doing either very well.
> >
> >This is possibly true, it would be wrong to rely on compression to
> >secure your cipher, but there is nothing wrong with adding extra
> >security. Compression complements encryption.
> Compression can complement security if used correctly however
> in practice this seems to seldom be done. Since people have not taken
> the time to really look at the security issues involvled. Except for
groups
> like the NSA which undoubtly through there contacts with the public
and
> through the chosen few like Mr BS who talk about his great contacts
with
> the NSA I am sure would not like the masses to learn about bad
compression
> that is used with encryption or his book would have had a decent
discussion
> on the topic which it does not. Makes one wonder what else is missing
or
> worded to misinform the person trying to really learn about crypto. I
am
> graetly disappointed that Wagner has choosen to keep the disception
and
> misinformation about compression and encryption alive.
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> http://members.xoom.com/ecil/index.htm
> NOTE EMAIL address is for SPAMERS
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Bruce Schneier's Crypto Comments on Slashdot
Date: Fri, 29 Oct 1999 20:17:30 GMT
In article <[EMAIL PROTECTED]>, Bill Lynch
<[EMAIL PROTECTED]> wrote:
>VERY interesting read -- thank you Bruce for taking the time to do this:
>
>http://slashdot.org/interviews/99/10/29/0832246.shtml
>
>
>
>-- Bill
Bill I read it was a load of crap from the get go here is part of
a quote about his views of the NSA which should educate any one
with have a brain that he is a front man for the NSA trying to keep
us in the dark about secure crypto
QUOTE
Over the past five years, there has been a lot of open research in
cryptography. We
have discovered many different types of attacks, and have learned a
lot about how to
design ciphers. The best and brightest of the cryptographers are
staying in the open
academic community, and are not being swallowed up by the NSA (or
by its
counterparts in other countries). There is a vibrant academic
community in cryptography;
people can exchange ideas, share research, build on each other's
work. We've seen
attacks against the NSA-designed algorithm Skipjack that almost
certainly were not
known by the NSA
END QUOTE
IF that is not a Bull Shit anwser from MR BS to buddy up to his friends
at the NSA I don't know what is. He has absolutely no proof that the socalled
attacks against Skipjack were not known by the NSA. Don't forget Skipjack
is something the Clinton Adminstration wanted everyone to use as it was to
be hidden in the Clipper Chip. Does he really think they meant it to be
secure?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Disk wiping code or utility
Date: Fri, 29 Oct 1999 19:31:02 GMT
On Fri, 29 Oct 1999 02:57:35 GMT, Tom St Denis <[EMAIL PROTECTED]> wrote:
>
>What is the big deal with securing local information? For the most
>part any security you try to provide locally is moot. Clearing
>stack/swap space is a prime candidate. Since I could more easily [good
>grammar?] remotely install a trojan and hitch you keys out of ram, then
>sort thru a multi-meg swap file for a key in binary form ...
I believe that disk-wiping tools, like any type of security tools, are
meant to help add security in a specific situation. And for "wipe"
tools, that particular situation is one where your system has not
yet been compromised, but has a chance of being seized or searched
"tomorrow". In cases like that, your main concern is making sure that
an adversary ends up more or less empty-handed with regards to whatever
you had on the computer last week.
It's the computer equivalent of shredding your documents before
you throw them into the trash can, in case someone decides to
go dumpster diving behind your office tonight.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: the ACM full of Dolts?
Date: Fri, 29 Oct 1999 20:29:46 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"Tony T. Warnock" wrote:
>> The review's comments seem in order.
>
>I disagree. The comment that an easier solution to the partial
>byte issue is to use a bit-length oriented filesystem was crazy.
Of course it was crazy. It was just some excuse made by someone
like MR BS to keep it from being published. They don't want real new
concepts. My guess is some famous asshole will rewrite the paper in
a year or two and take the credit himself. It would not surprise me in the
least to see Wagner write it up in a Journal in a year or two.
>
>I haven't been able to access the draft of the paper yet to see
>whether the comment about lack of motivation for so-called 1-1
>compression was valid.
In case you lost the link it is http://members.xoom.com/ecil/dspaper.htm
>
>Sometimes, "peer review" does encounter a bad reviewer. Usually,
>one can appeal the review to the editor, with a reasoned response,
>and another reviewer may be assigned.
I asked more than once for a response but got nothing except the
oringinal no appeal were not interested good bye you piece of shit letter. I
did write back to get more info. Of course the popmous assholes
never anwsered. Maybe they are to stupid to anwser or don't like
my carefree letter writting style. It pisses me off when you tell them
up front your not a writer and the assholes promise to work with you
but they really don't give a fuck.
>
>Neither the ACM nor the DoD is full of dolts, but they're not
>much more dolt-free than the rest of the population.
All I can say is one time the important job was to get the
job done at the Navy. But when I left protecting ones ass
and being politically correct was far more important than
actually doing anything productive.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: VXD Memory Allocator for Win9x
Date: Fri, 29 Oct 1999 15:09:31 -0400
Rick Braddam wrote:
>
> Eric W Braeden <[EMAIL PROTECTED]> wrote in message
>news:3818f657$0$[EMAIL PROTECTED]...
> > You sure you want to write a VxD? Win95/98 will be
> > around for quite a while yet, but WDM is the wave of
> > the future. It will work on all future WinXX OSes.
> >
> > Eric
> >
>
> Yes, at least for now. The VxD model is easier for me to understand, and I already
>have a skeleton running. The step from VxD to WDM
> should be smaller than the jump straight to WDM.
>
> I think that future WinXX OSes will be closer kin to NT than 9x. NT Workstation
>isn't that much more expensive than the upgrade to
> 98 from 95. There may still be a lot of Win3.1 software running out there, and the
>service packs for Win98 indicate that MS isn't
> ready to orphan the 3.1 software yet. I think the time is coming, though.
There are a lot of reasons still left for not running NT,
such as application incompatiblity, hardware incompatibility,
lack of USB support, etc.etc.etc. Eventually, Win00 will ship,
and a few service packs later it may work well enough and
resolve some of these issues (but not all of them). Much later
still, Win98 will be retired, and its replacement may or may
not be good enough...
> Note to Paul Koning: I followed the link you suggested, but I didn't find anything
>which would help much trying to determine the
> "bookkeeping" strategy. I have a copy of one malloc (for *nix machines) and the
>source for Win9X's malloc... neither seems to me
> quite suitable. I looked at NT's allocation, and tried to find a way close to it.
My reason for pointing you at that link is that it compares a number
of different malloc() implementations -- which differ in their
allocation strategies -- to see how they perform. I'd suggest
you pick one that looks good and track down its source code.
It's been a while since I read that article, but I remember that
it had a clear winner (the emacs one?). Using a malloc that
came with an OS is probably not the best approach. Using one
that came from MS is quite likely to be a bad idea...
paul
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Symetric cipher
Date: Fri, 29 Oct 1999 20:59:02 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill McGonigle) wrote:
>In article <[EMAIL PROTECTED]>, Emmanuel Drouet
><[EMAIL PROTECTED]> wrote:
>
>> Please, could you give me informations about several cryptosystems :
>> Blowfish, CAST5 and SAFER
>
>Run, do not walk to amazon and get Bruce's "Applied Cryptography". :)
>Really, it's an excellent overview, and good enough for many 'engineers'.
>
>
>-Bill
>-----
Actually this must be Mr BS's new form of SPAM since I have not recently
got a direct mailing from him. He does not anwser mail. It would be far better
to just look on the web for enryption sources. Or if your weak and must look
at the book go to Barnes and Noble you can read the realvent sections by just
browing. But just keep in mind he admits that he is buddy buddy with the NSA
so his book most likely supports there point of view. Which is to keep the
masses truely ignorant about encryption so they can read your mail. It fails
to cover important aspects about encryption like when using compression with
encryption one must be very careful or you can be making it easy to break then
if you did not compress at all.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Bruce Schneier's Crypto Comments on Slashdot
Reply-To: [EMAIL PROTECTED]
Date: Fri, 29 Oct 1999 20:10:19 GMT
from bruce schneier
> The best and brightest of the cryptographers are staying in the open
> academic community, and are not being swallowed up by the NSA (or
> by its counterparts in other countries).
How can he affirm that ? It is unlikle that anybody on the world has
the knowledge to affirm that, just because it require to know each
military cryptographic service and it is a secret field by definition.
------------------------------
** 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
******************************
