Cryptography-Digest Digest #940, Volume #13 Mon, 19 Mar 01 11:13:00 EST
Contents:
Re: How to eliminate redondancy? (Benjamin Goldberg)
Re: NTRU parameters (Benjamin Goldberg)
Re: OTP unbreakable? (Frank Gerlach)
Re: Cipher Idea #1 Block Cipher 512-bit block, arbitrary keysize (long) (Benjamin
Goldberg)
Need help with x-base65 Faxmission encoding (Rick Richardson)
Re: Idea (John Joseph Trammell)
Re: IP ("Mxsmanic")
Re: Idea (John Joseph Trammell)
Re: SSL secured servers and TEMPEST (Frank Gerlach)
Re: => TV detection (was: FBI easily cracks encryption ...?) (Richard Herring)
Re: OT: TV Licensing - final answer - sorry for xpost (Richard Herring)
Re: FIPS 140-1 does not adress eavesdropping (Frank Gerlach)
Re: NTRU, continued... (Benjamin Goldberg)
Re: Is SHA-1 Broken? (Jim Steuert)
Q: ANSI X9.68 certificate format standard (=?iso-8859-1?Q?Tom=E1s?= Perlines Hormann)
Re: How to eliminate redondancy? (Joe H. Acker)
Re: Idea (amateur)
Re: Idea (amateur)
Re: Idea (amateur)
Re: How to eliminate redondancy? ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Mon, 19 Mar 2001 12:27:35 GMT
SCOTT19U.ZIP_GUY wrote:
>
> see.signature (Nicol So) wrote in <[EMAIL PROTECTED]>:
>
> >
> >That's not true. Lossless compression works exactly by reducing the
> >redundancy in the representation of information.
> >
>
> Actaully most Lossless compressors that are not bijective
A compressor which is lossless is bijective.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: NTRU parameters
Date: Mon, 19 Mar 2001 12:39:20 GMT
I think the problem wasn't [just?] that it might get broken easily, but
that it might not be invertable in some cases.
I wonder... suppose we used as NTRU parameters, p=257, q=2^32. We could
do a trivial conversion from data to -128..128, simply by taking 8 bit
signed values, and not producing a +128 value. The bias would be
trivial, and would not weaken the system (much).
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: OTP unbreakable?
Date: Mon, 19 Mar 2001 14:00:15 +0100
So why are you jamming the newsgroup with that ?
Tom St Denis wrote:
> Is the OTP really really really really really unbreakable?
>
> hehehehe
>
> How many times are people gonna ask this.... ARRG
>
> Tom
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Cipher Idea #1 Block Cipher 512-bit block, arbitrary keysize (long)
Date: Mon, 19 Mar 2001 13:04:12 GMT
Joseph Ashwood wrote:
[snip]
> > Space requirements:
> > be doable at about the 10k transistor level, which would make it one
> > of the
>
> Is incorrect, I believe that outside of the space needed for the RAM
> for the sboxes, it can be done in 10k transistors, the RAM for the
> Sboxes will take ~24k additional. This will still make it smaller than
> many of the smaller block ciphers done in parellel hardware.
I think that many of the block ciphers which can gain an advantage by
being done in parallel hardware don't necessarily use more memory than
your cipher. Consider my cipher hypercrypt, or my more recent, unnamed
cipher (posted Wed, 07 Mar 2001). These can be done in parallel, and
would take very little memory, due to their simplicity.
Also, Tom Denis's TC5, or any of Ritter's fft-based ciphers can be
parallelized... although I'll admit Ritter's are ridiculously
inefficient in terms of RAM.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Rick Richardson <[EMAIL PROTECTED]>
Subject: Need help with x-base65 Faxmission encoding
Date: Mon, 19 Mar 2001 13:10:32 GMT
Roadrunner high speed cable provides an extra service called "Faxrunner",
used so cable customers can send/receive FAXes.
Faxrunner sends FAXes by emailing a MIME document with a control
header and an encoded TIFF image to a fax server. Clients are provided
for Mac and Windows. But there is no Linux client.
Its a simple matter to make a Linux client, however, as it is easy to form
the proper email message. The gotcha is that the TIFF image isn't encoded
in normal base64 encoding. Its encoded in what Faxmission calls "x-base65"
encoding.
Here is a snippet of that encoding...
Content-Type: image/tiff; name="FAX589ff.TIF"
Content-Transfer-Encoding: x-base65
Content-Disposition: attachment; filename="FAX589ff.TIF"
YGADKdkGKCkpKBwqAUcpKBwqAUcpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2Up
KBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4
q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2Up
KBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4q2UpKBw4
q2UpKBw7QWtAKIj5wV0TNCeuaoj5wV0TNCeuaoj5wV0TNCeuaoj5wV0TNCe9ucFdEzQnrmqI+cFd
EzQnrmqI+cFdEzQnrmqI+cFdEzQnrmqMDRM0J65qiPnBXRM0J65qiPnBXRM0J65qiPnBXRM0J65q
I'm pretty sure the alphabet is drawn from this string...
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
Its a TIFF image, so decoded the first 4 bytes in hex should be 49 49 2A 00 (or
possibly
4D 4D ... if its a big endian TIFF).
Anybody have an idea what the "x-base65" encoding/decoding algorithm might be?
-Rick
--
Rick Richardson [EMAIL PROTECTED] http://home.mn.rr.com/richardsons/
Scientists will achieve human immortality by 2100. Do you want the
government (you) to pay for *me* to live forever? Think about *that* before
voting for government insurance programs. I could be around a long time.
------------------------------
From: [EMAIL PROTECTED] (John Joseph Trammell)
Subject: Re: Idea
Date: Mon, 19 Mar 2001 13:18:54 GMT
On Mon, 19 Mar 2001 09:02:50 GMT, Douglas A. Gwyn wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> I hate it when people think it is necessiary to prove one
>> is qualified to do something.
>
> Trammell put it wrong. What he should have said was, why
> should I waste my time responding to your challenge cipher,
> when I am sure that you won't learn much from my breaking it?
I stand by my original challenge. Anyone who does not understand
the ideas in the first chapter of Schneier (or the SCR FAQ, for
that matter) is not qualified to write a modern cryptosystem.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: IP
Date: Mon, 19 Mar 2001 13:20:29 GMT
"David Schwartz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Anonymity is not a defense against any vulnerability
> I know of.
Do you know of any anonymous banks that have been robbed? You have to
be able to identify something before you can target it for attack.
------------------------------
From: [EMAIL PROTECTED] (John Joseph Trammell)
Subject: Re: Idea
Date: Mon, 19 Mar 2001 13:21:21 GMT
On 19 Mar 2001 06:58:53 GMT, SCOTT19U.ZIP_GUY wrote:
> Time is to precious wasting it using a spell checker.
Your time is more precious than mine, then? I'd say that
time is too precious to waste writing unintelligible
scribblings, but hey, maybe that's just me.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: SSL secured servers and TEMPEST
Date: Mon, 19 Mar 2001 14:23:47 +0100
Mark Currie wrote:
>
>
> You say that you may be able to record these accelerator emanations on VCR's
> in a previous thread, but the private key word movement/handling at this level
> may be happening at clock frequencies of several 100Mhz. Now assuming that you
As I wrote in another posting, the signals can be down-converted to the
recording-devices bandwith.
This is a basic principle of electronic engineering: A signal of n Hz can be split
in x signals of n/x Hz without
losing information (at least theoretically).
This means you would need ca. 400 VCRs for a Bandwith of 2GHz.
> can pick out the "blips" when private key operations occur (as you mention in
> previous threads, will the VCR bandwith allow you to extract data at several
> 100 Mhz ?
> bearing in mind that the data bits are switched in parallel (word
> read/writes).
It is true that the parallel transmission of data makes eavesdropping much more
difficult.
Still, consider an 8 bit SCSI bus: Just looking at the sum of the amplitudes will
yield
some (log2(9) ??- too lazy to sum up all 256 cases) of the 8 bits !
This is just the most simple attack. Taking into account that
not every signal propagates as fast as its "peers", an arithmetic unit might
expose
many more bits. Don't count on the 3/4 letter agencies to be fools :-)
> Perhaps I am looking at it in the wrong way ? I do admit that I
> am not an RF expert.
I am not either, although I was taught some basics of analog engineering and
signals
at the university.
Just on the basis of Shannon's formula, repeating signals seem to be a very
interesting
target, although they are quite difficult to recover...
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => TV detection (was: FBI easily cracks encryption ...?)
Date: 19 Mar 2001 13:12:59 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Dave Howe
([EMAIL PROTECTED]) wrote:
> flat) and really spent much of their time either at their parent's
> houses or otherwise occupied - and got sick of having their cupboards
> searched for the TV or radio set they "must" have.
Not that a radio would be relevant.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: OT: TV Licensing - final answer - sorry for xpost
Date: 19 Mar 2001 13:19:16 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Dave Howe
([EMAIL PROTECTED]) wrote:
> In our last episode (<alt.security.pgp>[Sat, 17 Mar 2001 11:06:31
> +0000]), David Hayward <[EMAIL PROTECTED]> said :
> >The actual offence is "TV licence payment evasion" and is covered
> >under the Wireless Telegraphy Act 1940 sect 1. I am fairly sure you
> >would have to be "operating" a TV set without a licence for a
> >prosecution to be worth while as I am led to understand that the
> >guideline sentence is a discharge or fine for the offence. HTH
> The current situation is odd though - a TV used only for a video
> recorder to play pre-recorded movies does not require a licence, but
> one used as a monitor for early computers that had a PAL output does -
> Not entirely sure why.
This sounds like urban mythology blurring a change of status with time.
I think the final "does" in that sentence should be "did".
In the days when people used TVs as computer monitors, there were no
exceptions to the law for such special cases. Later it was amended
to provide specific exemptions for using the TV as a video monitor.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: FIPS 140-1 does not adress eavesdropping
Date: Mon, 19 Mar 2001 14:39:10 +0100
Lyalc wrote:
> Creating a valid threat scenario is useful.
> Can the power connection to the FIPS140-1 device be isolated from other
> 'noise' sources, where noise is signals other than the target of interest?
> If not, then do the other noise sources effectively swamp the TOI?
> And is there are reasonable 'safe three dimensional perimeter' around the
> unit, safe at least 5 m, preferably 20 or more?
I was just taking power line analysis as an example of FIPS 140-1 not adressing
compromising emanations threats.
>From a theoretical point of view this is OK, but why bother with physical
protection of a device if a malicious security officer can use some electronic
device to record the secret key ?
Analyzing emanations might be much easier than breaking up the device.
The threat model "physical attack against device" doesn't look really
important to me. FIPS 140-1 seems to be useful in addressing malicious stimuli
coming from compromised software, which is quite realistic even without any
security officer's consent. This is just the reality of software development
:-(
What I am missing are at least basic measurements regarding emanations.
There are as many bad hardware engineers as there are bad software
engineers. I suspect there is more than one crypto device which should
better be called "crypto device with parasitic radio".
In general I am not a fan of Lenin, but regarding electrical enginnering of a
crypto device I would say "control is better than trust".
Just look at how the brits made fun of the frogs by discovering a faint
plaintext
signal from the french crypto device :-)
>
> Lyal
>
> Frank Gerlach wrote in message <[EMAIL PROTECTED]>...
> >In response to the Paul Rubin's reference to the IBM 4758 cryptographic
> >coprocessor I have read a paper from IBM, describing the FIPS 140-1
> >validation process:
> >http://www.research.ibm.com/secure_systems/papers/nfips.pdf
> >
> >It clearly states that FIPS 140-1 does not even adress power line analysis.
> >140-1 just has a different threat model: mainly active attacks conducted
> >physically (e.g. opening the device) or through stimuli (e.g. malicious
> >commands by application software).
> >I consider the stimuli-based threat model very important, but it is not
> >related to the threat model in this discussion threat.
> >
> >A good discussion of a security issue should always define a threat model,
> >because discussion will otherwise be virtually useless.
> >
> >FIPS 140-1 is also a very good sociologic example of how standards can be
> >misused. When I talked to some colleagues of mine, who know more about
> >crypto coprocessors, the "FIPS standard" was mentioned, as it happened in
> >this discussion thread. After looking at 140-1, I conclude that it does not
> >adress emanations/TEMPEST at all. It seems that even experienced engineers
> >like to believe into simple truths like "this device is FIPS 140-1
> >certified - don't worry".
> >
> >
> >
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: NTRU, continued...
Date: Mon, 19 Mar 2001 13:53:38 GMT
Daniel Lieman wrote:
>
> > Hi -
> >
> > Dan Bailey recently posted performance numbers - I'll copy his post
> > here.
>
> OK, let me reformat that....his post is below (again!) but I've (tried
> to) reformat the numbers so they are legible :).
>
> Daniel Lieman
It looks like you're using a proportional font, rather than a fixed
width font. Here's *my* attempt at making the numbers line up:
> > Function Units NTRU 251 RSA 1024 ECC 155
> > Enc Keygen Keys/sec 1512 ??? 259
> > S/V Keygen Keys/sec 1996 N/A N/A
> > Encrypt Blocks/sec 16556 2744 132
> > Decrypt Blocks/sec 8620 90 70
> > Sign Sigs/sec 3215 94 255
> > Verify Sigs/sec 3225 2949 151
Since ECC and RSA use the same key for sign/verify as ciphering, they
are listed as N/A for that line. I *am* curious as to why he didn't
give a speed for RSA 1024 keygen, however.
One should note that if this is to replace PGP, a certificate needs to
have both an Enc and S/V key... so the number of keys/second is
1/(1/1512+1/1996), or 860 keys/sec, which is still reasonably fast.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: Is SHA-1 Broken?
Date: Mon, 19 Mar 2001 09:46:19 -0500
In his paper, Richard Dean states that it "took a few minutes on a
300Mhz Pentium II computer, and required less than 128MB of RAM"
in order to find the initialization vector for which "abc" (padded and Merkle-
Damgard strengthened) was a fixed point. The implication is that he
could easily find many more fixed points.
This attack was launched using a general-purpose BDD language "Ever",
and a awk script to create the inputs. What concerns me is the
ability of a government agency to 1) use more special-purpose algorithms,
2) use faster or dedicated hardware 3) use more RAM, so that
any direct use of SHA-1 may already be symbolically inverted
by some government agency.
(invert 160 boolean equations in 160 variables with some huge
number of expressions, which may somehow be reduced/factored/
tabulated so that we aren't really dealing with a 2^160 complexity).
Richard Dean goes on to state three defenses against this attack,
better Merkle-Damgard type strenghtening, more chaining of the
initialization vectors, and multiple hashing.
However, a lot of us have been misled into thinking that SHA-1 was
basically usable in any sense. Have I been too trusting of the
"conventional wisdom" of cryptography? Of course we can use
universal hashing/UMAC constructions, which require random
number generators (which themselves are likely iterated ciphers
or hash functions). The entire cryptography world is a LOT less secure
in all areas given what Richard Dean has done, with a general
package and general purpose slow hardware.
Paul Rubin wrote:
> Jim Steuert <[EMAIL PROTECTED]> writes:
> > Yes, it is a doctoral thesis (dated Jan 99) that I found at
> > www.cs.princeton.edu/sip/pub/ddean-dissertation.php3
> >
> > To quote (except) from the abstract:
> > "...Finally, we turn our attention to cryptographic hash functions
> > and their analysis with binary decision diagrams (BDDs). We show
> > that three commonly used hash functions (MD4, MD5, and SHA-1)
> > do not offer ideal strength against second preimages..."
>
> Thanks, that's interesting. I wonder if anyone is using the BDD tools
> to examine other ciphers, like AES/Rijndael.
>
> I wouldn't say the hash functions are "broken", or anyway they're less
> "broken" than MD5 is due to Dobbertin's finding collisions in the
> compression function. However, easily discovered short cycles in a
> hash function are surely not a good thing.
>
> I haven't looked at the description carefully enough to figure out whether
> the attack is stopped by constructions like HMAC.
------------------------------
From: =?iso-8859-1?Q?Tom=E1s?= Perlines Hormann <[EMAIL PROTECTED]>
Subject: Q: ANSI X9.68 certificate format standard
Date: Mon, 19 Mar 2001 16:10:12 +0100
I was wondering whether someone of you have a clue where to get the
draft (or already standard) from ANSI X9.68 certificate format as I have
been searching through ANSI webpages and some other sites and just found
a draft dated from march 1st, 1999.
I guess there must be a recently updated draft versionor even the full
standard.
Does anybody know anything about the current state of this certificate
format for mobile applications?
I would be very satisfied if you could pelase help me out regarding this
issue.
Thanks in advance and best regards.
--
Tomás Perlines Hormann
EED/R/A e-mail: [EMAIL PROTECTED]
Ericsson Eurolab Deutschland phone: +49 2407 575-98128
52134 Herzogenrath, Germany fax: +49 2407 575-150
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: How to eliminate redondancy?
Date: Mon, 19 Mar 2001 16:06:09 +0100
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> SCOTT19U.ZIP_GUY wrote:
> >
> > see.signature (Nicol So) wrote in <[EMAIL PROTECTED]>:
> >
> > >
> > >That's not true. Lossless compression works exactly by reducing the
> > >redundancy in the representation of information.
> > >
> >
> > Actaully most Lossless compressors that are not bijective
>
> A compressor which is lossless is bijective.
...if you compare possible outputs of the compressor with possible
inputs of the compressor. But if I understand David A. Scott correctly,
he compares possible inputs of the compressor with all permutations of
the possible outputs. That is, if you feed 64 bits of binary data into
the compressor and it compresses them to 32 bit, it should also
decompress any arbitrary sequence of 32 bits to something. If you feed
128 bit and it compresses them to 63 bit, then it should also decompress
any arbitrary sequence of 63 bits to something, and so on.
At least to me, it seems plausible why a bijective compressor in Scott's
sense is desirable. The question is rather, wether the overall
enhancement of security by this kind of compression is significant or
almost neglectible.
Regards,
Erich
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Idea
Date: Mon, 19 Mar 2001 10:11:38 -0400
John Savard wrote:
>
> On Sat, 17 Mar 2001 16:09:35 -0400, br <[EMAIL PROTECTED]> wrote, in part:
>
> >I'm going to explain clearly my idea.
>
> I'm afraid you have not succeeded in doing so.
>
> I think you are saying that you want to encrypt a message more
> securely by using a trick involving the following principle:
>
> - divide the symbols of the plaintext alphabet into two classes
>
> - encipher the symbols in each class by a separate algorithm
>
> That is useful, although there are pitfalls.
>
> If you encipher each symbol to a symbol in its own part of the
> alphabet, then a frequency count might distinguish the pattern of
> symbols in the two groups (if the ciphers are otherwise very secure,
> so that frequencies within each group are flat).
> ___________________________________________
Wrong. I encipher EVERY BIT using a type of symbol. All symbols are
choosen randomly.
Sample bin string 1001 = 3829 ( odd for 1 and 0 for even)
The input is random odd even even odd. So 1 = {1,3,5,7,9} and 0 =
{0,2,4,6,8} and the second key k2 is random two.
You have just to decrypt what I wrote, reading it carefully.
You may not use k1 if you want. It's not necessary, but it add more
security.
____________________________________
> If you rearrange the symbols somehow, you need to add extra
> information to the message to allow it to be reconstructed.
> _________________________________
The extra-information it could be distiinguish by anyone if :
1. he knows that is used two types
2. he read all the message with his key k2. Computer could not
distinguish two types.
If I use two types of alphabet (i.E hebrew and russian) everyone could
distinguish neatly between the two.
_____________________________________
> For example, you could take a message consisting of bytes of binary
> data, split it into two groups consisting of the bytes starting with 0
> and the bytes starting with 1. Putting the bytes in the first group
> first - as 7-bit symbols - followed by the bytes in the second group,
> encipher these bits in DES. But the first bit of each byte is also
> needed, to indicate where these 7-bit symbols are to be put to
> reconstruct the message.
_________________________________
I don't need that trick
_______________________
>
> My web site, in the first chapter of 'A Cryptographic Compendium',
> talks about a number of elaborate fractionation schemes. Perhaps you
> will see something there similar to your idea.
>
_________________
Thank you for your useful comments.
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Idea
Date: Mon, 19 Mar 2001 10:15:31 -0400
Please, just try to read not to decrypt what I wrote before step by
step.
I'm very sorry to not using "high level technical language" of
cryptographers. I'm just an amateur.
I just want answers for every step. I thank Mister Savard for his
comments. He, certainly' read my message.
Thank you.
John Joseph Trammell wrote:
>
> On 18 Mar 2001 19:50:25 GMT, SCOTT19U.ZIP_GUY wrote:
> >[EMAIL PROTECTED] (John Joseph Trammell):
> >>If you are so confident, prove to me that you're qualified to
> >>write a cryptosystem. :-)
> [rant snipped]
>
> What an emotional response. I must have touched a nerve.
>
> Let me know when you all decide to get around to working
> on cryptography instead of (a) frothing at the mouth or
> (b) taking wild stabs at cryptosystems.
>
> Oh, and lighten up. There's a smiley in the message for
> a reason. And learn how to use a spellchecker.
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Idea
Date: Mon, 19 Mar 2001 10:21:17 -0400
???
John Joseph Trammell wrote:
>
> On Mon, 19 Mar 2001 09:02:50 GMT, Douglas A. Gwyn wrote:
> >"SCOTT19U.ZIP_GUY" wrote:
> >> I hate it when people think it is necessiary to prove one
> >> is qualified to do something.
> >
> > Trammell put it wrong. What he should have said was, why
> > should I waste my time responding to your challenge cipher,
> > when I am sure that you won't learn much from my breaking it?
>
> I stand by my original challenge. Anyone who does not understand
> the ideas in the first chapter of Schneier (or the SCR FAQ, for
> that matter) is not qualified to write a modern cryptosystem.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Mon, 19 Mar 2001 15:36:51 GMT
Nicol So wrote:
> [In the article Trevor L Jackson III was reponding to, I discussed the
> definition of redundancy and why masking plaintext with PRNG does not
> affect redundancy.]
>
> "Trevor L. Jackson, III" wrote:
> >
> > I'll not waste a lot of time on rebutting the individual statements, but merely
> > observe that the final statement is false. The phrase "theoretically best
> > encoder of the masked plaintext stream" can only exist in the context of the
> > weighted message space.
>
> I don't know what you meant by a "weighted message space".
I meant the probability distribution of a message source with a limited set of
outputs.
>
>
> > Now, for extra credit, what do you think the OP, br, meant when he asked the
> > original question? Did he mean apparent (a metric applicable to a single
> > message) or "latent" (a metric applicable only to a sample of a weighted
> > message space)?
>
> I *think* the original poster was asking about reducing redundancy as
> the concept is used in information theory.
The OP has displayed no understanding of information theory.
> It was you, based on the
> statement you made, that I thought had "apparent" redundancy in mind.
I did. I thought it was the hidden assumption of the OP.
> I
> didn't use the word "latent" and don't know how you use it. The concept
> of redundancy is meaningful only when discussed in the context of a
> probability distribution.
>
> > Obviously I thought he meant the former, and that is the context in which my
> > reply makes sense. Note also that PRNG masking is a form of lossless
> > compression (with zero efficiency), so the distinction you constructed is not
> > really applicable.
>
> If you want to model PRNG masking as a form of degenerate lossless
> compression, that's fine. But that doesn't mean it reduces the
> redundancy in the source messages. Usually the term compression is used
> when the source is compressible, i.e. not of maximal entropy, AND the
> compressor achieves a non-zero amount of compression on average. If you
> want to include degenerate schemes as compression, then I would reword
> what I said to "Non-degenerate lossless compression... reduces
> redundancy because it makes the information representation more
> 'compact'". The amount of redundancy reduction depends on the
> compression ratio. The greater the compression ratio, the more the
> redundancy reduction. The closer to the degenerate case, the closer to
> no redundancy reduction.
>
> If redundancy as used in information theory was what you had in mind,
> your statement was false. Although masking plaintext using a PRNG
> usually makes the distribution of symbols more uniformly distributed,
> *when you model successive masked symbols as independent and identically
> distributed RVs*, that's NOT a reduction in redundancy. It only appears
> so because the wrong (non-optimal) statistical model is used. With the
> right predictor, an obvious example of which has the PRNG and its
> parameters built in, a compressor can still be constructed to shorten
> the masked plaintext to the same degree as the unmasked version, showing
> that masking does not remove redundancy. It is critical that an optimal
> statistical model is used.
>
> --
> Nicol So, CISSP // paranoid 'at' engineer 'dot' com
> Disclaimer: Views expressed here are casual comments and should
> not be relied upon as the basis for decisions of consequence.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
