Cryptography-Digest Digest #769, Volume #12 Mon, 25 Sep 00 12:13:01 EDT
Contents:
Re: What am I missing? (Sagie)
Re: What am I missing? (Sagie)
Re: What make a cipher resistent to Differential Cryptanalysis? (SCOTT19U.ZIP_GUY)
Re: Question on biases in random-numbers & decompression (Bruno Wolff III)
Re: Why is TwoFish better than Blowfish? (Runu Knips)
Re: Encrypted File Systems..? (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
Re: Question on biases in random numbers & decompression (SCOTT19U.ZIP_GUY)
Re: Why is TwoFish better than Blowfish? (SCOTT19U.ZIP_GUY)
Re: Question on biases in random-numbers & decompression ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: Sagie <[EMAIL PROTECTED]>
Subject: Re: What am I missing?
Date: Mon, 25 Sep 2000 14:13:50 GMT
> Try starting w/ the following excellent resources:
>
> http://www.cl.cam.ac.uk/~fapp2/steganography/
> http://www.isse.gmu.edu/~njohnson/
Okay, I'll give it a shot sometime, thanks.
> It would be unbelievable if they didn't. If you'd like, I
> can submit a compressed-then-decompressed audio track to one
> of their oracles, but I'm almost absolutely certain that
> all the proposed schemes do survive MP3.
You are being hypothetical again. It is obvious that they want it to
survive MP3, but the fact is that you have not tested it on either of
the technologies. Surviving MP3 compression is actually rather vague,
because I have no doubt it depends on the target MP3 parameters (stereo
mode, bitrate, encoder quality, sample rate, etc).
> >First of all, you don't know (well not for sure) what techniques are
> >being used by any of these watermark technologies. Secondly, I think
> >you are being short-sighted. Psycho-acoustic models are constantly
> >being improved.
>
> That doesn't matter. There are some operations that SHOULD
> NOT be undone by a compressor, even if they COULD.
The only modifications that should not be performed by a compressor are
such that are audible by the human ear.
> Here's a stupid example: take an audio clip (we'll call it
> clip B) and do a little multirate on it to shift all the
> frequencies up one half step (we'll call this version clip C.)
> Now sic some amazing compression algorithm on both clips B and
C.
> Is there any chance the compressor could undo that half-step
shift?
>
> Of course not: given clip C, there is no way a compressor could
> know whether C is a deformation of B, or if C was really
recorded
> that way, the musicians actually playing in a key a half step
up.
> Any compression scheme that compresses B and C to the same
thing is
> a broken compression scheme!
>
> It's a stupid example, of course, because shifting the
frequencies
> up a half-step is very unreasonable modification. Notice,
however,
> that without the original clip B for reference, most people
wouldn't
> notice anything "wrong" with clip C: only those musically
inclined,
> who may know the song is usually in the key of B.
>
> See?
As you said, it is a stupid example because the change can be detected
by the human ear. Even if some people normally would not detect it,
others would, and in general it means (as I said in a previous post)
that we are getting fucked up because the watermark screws the audio.
Audio technicians are working their ass off to create a final mix with
a pleasant sound and best EQ settings, and then some asshole comes and
fucks up the whole equalization.
> There's this set of operations that are considerably more
subtle,
> which would turn a clip A into a clip B such that A and B
> _should not_ be compressed to the same file. By "subtle" I mean
> such that one can listen to A and B one at a time and not tell
> how they are different. Maybe playing both at once one can hear
> the difference, but since only B will be distributed that
doesn't
> matter.
If the changes are so sublte and undetectable by the human ear you can
count on it that compression methods will use those tricks for the
compression process (if they create a more effective representation of
the signal, obviously) or remove these changes as part of the
optimization. Any watermarking technique that will use those tricks
will therefore be harmed. MP3 compression already replaces some
frequencies with others that sound the same, removes sounds that are
being obstructed by other sounds, and more. Who knows what techniques
will be used next?
> Really, this is the wrong tree. It's not compression they
> have to worry about, but hackers. I'm extremely, very, super-
> duper confident that any serious audio watermarking scheme
> will survive any compression algorithm developed during the
> scheme's expected lifetime of deployment. I say this as a
> (relative) expert.
As I said, only future will tell.
> Still, with these extra utilities, you are still not going to
> figure it out just by looking around. You'll see some patterns
> (symmetry in the FFT, for instance,) but getting from that to
> how it works is like getting from the discovery that DES
ciphertext
> is in 8-byte blocks to figuring out the plaintext.
You're forgetting that we have the "before" and the "after". We already
have the exact watermark signal that was introduced to the audio, we
don't have to "find" it. Now, we can examine the properties of this
signal and how it is modifying the original signal. We don't have to
crack the technology -- all we have to do is cause enough inaudible (or
slightly audible) damage to the signal to render the watermark
undetectable and get the 10K$ paycheck... Maybe introducing some high-
frequency noise, for instance. With enough pocking around I think it is
possible.
> Guy, in cryptography the word "analysis" has a special meaning.
> It means, roughly, "deciphering" or "breaking."
Okay, I'll keep that in mind for my next posts.
> Often true, but _good_ watermarking schemes are also designed
> to avoid discovery by hackers. Of watermarking schemes that use
> secret keys, for instance, many are such that you will NEVER
find
> any pattern.
Okay. We all agree that without any information of the watermark inner-
workings it is probably useless to try and analyse it.
> Also see the work of Lisa Marvel et al, who developed a spread-
> spectrum stego scheme that can conceal about 5 kilobytes very
> robustly (and error correction is all taken care of) in a
512x512
> monochrome image.
That's very impressive, but one should wonder what artifacts are
introduced to the image as a result (we are talking about 1-bit depth
per pixel, right?).
> Fair enough, but unless you're a real whiz, you'll still not
> detect it. If you hit upon just the right filter, then yes.
> And again, the difference between noticing a pattern and
> deciphering the thing is great. You will instantly find that
> the Digimarc mark is almost periodic and rotationally symmetric.
> You're still a long, long way from seeing the bits.
>
> Better to just get the algorithm by reading the patent.
That's the reason why I said SDMI did not give enough information.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Sagie <[EMAIL PROTECTED]>
Subject: Re: What am I missing?
Date: Mon, 25 Sep 2000 14:25:48 GMT
> However, in practice, I'll grant you the point. The watermarkers have
> a large advantage here; they need only find a few machine
> distinguishable bits to play with, while the compressors would
> probably need AI to know what is and isn't fair game (as far as the
> human ear is concerned).
True, but they are doing this with respect to the current genration of
audio compression methods (mainly MP3), whereas the current generation
of audio compression (again, mainly MP3) is close to the end of its
life. New compression methods are already well underway, and by the
time the SDMI watermark will catch up (if ever), the current genration
will already be replaced by the next (AAC, Ogg, whatever).
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: 25 Sep 2000 14:44:18 GMT
[EMAIL PROTECTED] (John A. Malley) wrote in
<[EMAIL PROTECTED]>:
>Mr. Scott,
>
>Are you running Tom St. Denis' posts through an "Eliza"-like program
>that echos/cuts and splices/merges strings from his posts with strings
>from a library of stock phrases available to the program? Or did you
>compose these responses yourself?
>
>Just curious,
>
>John A. Malley
>[EMAIL PROTECTED]
>
Are you running Tom St. Denis posts with strings from his man-servant, the
LORD: I say unto his heart, what is thy dead. Thus
saith the LORD spake unto you, the program that echos/cuts and said unto
his posts through an Eliza"-like program? Or did
you, verily, nor his posts with strings from his maid-servant!
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (Bruno Wolff III)
Crossposted-To: comp.compression,sci.crypt.random-numbers
Subject: Re: Question on biases in random-numbers & decompression
Date: 25 Sep 2000 15:02:41 GMT
On Mon, 25 Sep 2000 00:42:09 -0700, Roger Schlafly <[EMAIL PROTECTED]> wrote:
>Benjamin Goldberg wrote:
>> I've been looking for a way to convert a stream of unbiased random bits
>> into an unbiased stream of random numbers in an arbitrary range, and I
>> think I've hit on an idea that hasn't been suggested before:
>>
>> Take an arithmetic dececoder, and initialize it to believe that the
>> values 0, 1, 2 are equiprobable, and no other values will occur. Then
>> feed it the stream of random bits. This should result in an unbiased
>> stream of random numbers in the range 0..2. However, I don't understand
>> arithmetic decompression well enough to know for certain if this will
>> work as I've suggested.
>
>Yes, that will work, but why not just use the bits directly?
>Ie, if you have 64 bits, convert to an unsigned 64 bit integer,
>and divide by 2^64 to get a real number in the range from 0 to 1.
>For other intervals, multiply by an appropriate scale factor.
Because multiplying by a scale factor doesn't work. It will add bias.
The way to do this is to generate a random number from 0 to 3 and when
3 is picked repeat the process. For arbitrary ranges you can do essentially
the same thing. One thing you can do with numbers out of the appropiate
range is try to extract some bits from them to cut down on the amount of
new random bits needed. I don't have a general algorithm for this specified
yet, though I was thinking about it recently when I was looking at adding
some new features to my die rolling service. However I have been using
something for generating 6 sided rolls that can be used to illustrate
what you can do.
To generate a 6 sided roll I generate a number from 0 to 7 by fetching 3 bits
from /dev/random. If the result is in the range 2 to 7, I return that number
minus 1. If the result is 0 or 1, I treat that number as the first random bit
for the next try, and fetch 2 more bits from /dev/random and repeat the
process.
Since random bits are fairly valuable compared to a few cpu cycles,
you want to try to extract as much of the randomness as possible out of
the random bits you get.
------------------------------
Date: Mon, 25 Sep 2000 17:05:36 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Why is TwoFish better than Blowfish?
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> Albert Yang <[EMAIL PROTECTED]> wrote:
> > "David C. Barber" wrote:
> > > TwoFish is newer, and I would think better, than BlowFish (unless
> > > the AES requirements required a worse cipher), but I've never see
> > > n a list of reasons just why.
In fact, the main reason why Twofish is better than Blowfish is NOT
improved security. Blowfish is a pc cipher, and Twofish is a general
cipher. Twofish offers key agility, while Blowfish doesn't. Twofish
can be implemented in relatively slow resource environments, while
Blowfish always require >4KB of key schedule data.
> > I personally trust Blowfish a bit more than Twofish. [...]
> > There are a class of weak keys in Blowfish, but not that big of
> > a deal IMHO.
Agreed. Twofish MIGHT have a design flaw where nobody has an idea of,
while Blowfish is just extreme chaos. Maybe there are more classes of
weak keys in Blowfish, but I would be surprised if there would ever
be something practical.
> > The one I trust me? Serpent! :-)
>
> Why? Serpent is even newer!
AFAIK its not much newer than Twofish :) Too, Serpent is based on
VERY simple principles - and it has 32 rounds. Thats also the
reason why it is that slow in software.
------------------------------
From: [EMAIL PROTECTED] (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Subject: Re: Encrypted File Systems..?
Date: 25 Sep 2000 17:25:31 +0200
In article <8qk0l9$j7h$[EMAIL PROTECTED]>, halofive wrote:
>Is the idea of a "secure filesystem" logical? I've been playing around
>with Linux (suse, in particular) and love it- but I'd like to know if
>this would sound logical to try:
>
>Create a small partition with the boot loader software and decryption
>alorithm- using something similar to DES or IDEA.
>
>Then, encrypt your entire partition file system (root etc).
>The only way to access would be to enter the correct password at the
>bootup, which would then decrypt the contents of the hard drive.
>
>Maybe I'm thinking out of my ass, the problems would be obvious.
>Where can I store the files as they're being decrypted?
>and
>Any files decrypted or downloaded would be saved on the disk- making
>the possibility of recovering the data stored on the disk possible.
>
Good starting points:
http://marc.mutz.com/Encryption-HOWTO/
http://www.kerneli.org
--
Gisle S�lensminde ( [EMAIL PROTECTED] )
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Tying Up Loose Ends - Correction
Date: 25 Sep 2000 15:25:10 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On 25 Sep 2000 03:18:41 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote, in part:
>
>>One could count on using his method of padding when if it is for
>>a byte you put a three bits code and it tells to how many bits
>>are random fill. But even in this case it has to be applied in a
>>way not biasised. That is he can't just add to the end of a full huffman
>>symbol. He still would need to do something like my endings and use
>>if for where the trailing zeros appear( assuming your not using my
>>focused huffman coding.)
>
>Also correct, and that's precisely how I lay it out on my web page.
>
Having read your WEBPAGE that's not how I see it. But your clever
enough never to write real code and I don't see what is to be gained
by this kind of discussion. I feel I made my point. I could easily
write a version to do just what my above response says. and I may some
day. But why don't your write some code for a change instead of
continue hand waving where the fine details are left out. To now
say what I say is what you say is not valid since you have no code
to test. The proof in the pudding is in the eating and you provide
nothing to eat.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: com.compression
Subject: Re: Question on biases in random numbers & decompression
Date: 25 Sep 2000 15:11:32 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>
>: I've GOT a random bitstream, which means random 0s and 1s. What I want
>: from this get random 0s, 1s, and 2s. I want the arithmetic encoder to
>: convert from one form to the other.
>
>: Since I think that if I were *starting out* with random (equiprobable)
>: 0s, 1s, and 2s, and *en*coded them with an arithmetic coder, I *should*
>: get a random bitstream (with 0 and 1 equiprobable), I think that using
>: an arithmetic *de*coder on a random bitstream should let me producde
>: random 0s, 1s, and 2s.
>
>: The reason I want to try this, is that if I take my random bitstream,
>: and take two bits at a time, getting a number in the range 0, 1, 2, 3,
>: and discard all 3s to get a number in the desired (0, 1, 2) range, I'm
>: WASTING 25% of my random bits, AND I might end up taking an arbitrarily
>: long time to get a single trit. Bleh. [...]
>
>It sounds like using arithemetic decompression routine will do
>much of what you want.
>
>I think you will find you might still wind up taking an arbitrarily long
>time to get a single trit, though - I don't think there's any way around
>that without introducing bias.
>
>I suspect that your arithmetic compressor will need access to an unbounded
>quantity of RAM as well in order to be guaranteed to operate correctly.
>
>In all, the idea sounds a bit like converting a binary number to base 3
>(or base n), with the MSBs coming first.
>
>If thinking about it this way, consider treating the stream as binary and
>tertiary (or n-ary) expansions of real numbers between zero and one.
This is ture you have to make some trade off if you want to get
exactly a random 33% chance at each symbol. You can as I sugguest
take 2 bits. and use only the first 3 states tossinge the fourth state.
Or if you want take 4 bits. then you have 16 states. You can assign
15 of them easily since 3*5 = 15 put toss the 16th state and get 4 bits
more. Using an arithmetic coder involves these kind of trade offs if
you need exactly 33% likelyhood from each symbol. If you don't want
33% random but want close use an arithmetic coder where one symbol slightly
heaver than the other 2. And when the heaver symbol comes up shift the
weight of it so the next symbol weighs more. This way you can get close
to 33% random and you don't have to wait forever to get a symbol out.
To do this with 2 bit pairs. Assign "0" to 00 "1" to 01
"2" to 10 and 11
when a two comes up assign the 11 to symbol "1" you can to this
with more bits but thought I would explain the idea. You could
also leave the 11 assigned to the value it was last shifted too
that when whenever you restart the program you wont get a biasis
for the first trit being a "2" in case some one is analysising
the ouputs.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Why is TwoFish better than Blowfish?
Date: 25 Sep 2000 15:38:26 GMT
[EMAIL PROTECTED] (Runu Knips) wrote in
<[EMAIL PROTECTED]>:
>Tom St Denis wrote:
>> In article <[EMAIL PROTECTED]>,
>> Albert Yang <[EMAIL PROTECTED]> wrote:
>> > "David C. Barber" wrote:
>> > > TwoFish is newer, and I would think better, than BlowFish (unless
>> > > the AES requirements required a worse cipher), but I've never see
>> > > n a list of reasons just why.
>
>In fact, the main reason why Twofish is better than Blowfish is NOT
>improved security. Blowfish is a pc cipher, and Twofish is a general
>cipher. Twofish offers key agility, while Blowfish doesn't. Twofish
>can be implemented in relatively slow resource environments, while
>Blowfish always require >4KB of key schedule data.
>
>
Having known people who know the man who designed blow fish or
two fish leads me to believe both ciphers are most likely broken by
the NSA before they were introduced to the public. At least these
are my feelings about these fishy ciphers. It seems like NSA humour
to give both ciphers FISHY names.
But since the idea of a cipher is security. It is plain stupid to
say Twofish is better than Blowfish becasue Blowfish is a PC cipher.
If one has a PC and is sending messages to someone with a PC then why
use a cipher that could becasue of its ability to be run on many machines
would ecpoxe it to more attacks. Even if they algoritmically had
the same level security which can't be proved anyway.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
Date: Mon, 25 Sep 2000 11:49:39 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Question on biases in random-numbers & decompression
Bruno Wolff III wrote:
> On Mon, 25 Sep 2000 00:42:09 -0700, Roger Schlafly <[EMAIL PROTECTED]>
>wrote:
> >Benjamin Goldberg wrote:
> >> I've been looking for a way to convert a stream of unbiased random bits
> >> into an unbiased stream of random numbers in an arbitrary range, and I
> >> think I've hit on an idea that hasn't been suggested before:
> >>
> >> Take an arithmetic dececoder, and initialize it to believe that the
> >> values 0, 1, 2 are equiprobable, and no other values will occur. Then
> >> feed it the stream of random bits. This should result in an unbiased
> >> stream of random numbers in the range 0..2. However, I don't understand
> >> arithmetic decompression well enough to know for certain if this will
> >> work as I've suggested.
> >
> >Yes, that will work, but why not just use the bits directly?
> >Ie, if you have 64 bits, convert to an unsigned 64 bit integer,
> >and divide by 2^64 to get a real number in the range from 0 to 1.
> >For other intervals, multiply by an appropriate scale factor.
>
> Because multiplying by a scale factor doesn't work. It will add bias.
> The way to do this is to generate a random number from 0 to 3 and when
> 3 is picked repeat the process. For arbitrary ranges you can do essentially
> the same thing. One thing you can do with numbers out of the appropiate
> range is try to extract some bits from them to cut down on the amount of
> new random bits needed. I don't have a general algorithm for this specified
> yet, though I was thinking about it recently when I was looking at adding
> some new features to my die rolling service. However I have been using
> something for generating 6 sided rolls that can be used to illustrate
> what you can do.
>
> To generate a 6 sided roll I generate a number from 0 to 7 by fetching 3 bits
> from /dev/random. If the result is in the range 2 to 7, I return that number
> minus 1. If the result is 0 or 1, I treat that number as the first random bit
> for the next try, and fetch 2 more bits from /dev/random and repeat the
> process.
>
> Since random bits are fairly valuable compared to a few cpu cycles,
> you want to try to extract as much of the randomness as possible out of
> the random bits you get.
hrubin has posted on this topic several times. His generator consumes the the random
stream one bit at a time capturing almost all of the entropy of source in the resulting
stream of numbers. I'm sure you can find this on a usenet archive.
------------------------------
** 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
******************************
