Cryptography-Digest Digest #91, Volume #11 Thu, 10 Feb 00 17:13:01 EST
Contents:
Re: micropayments and denial of service? (Ian Goldberg)
Opinions please: Serpent (fvw)
Re: I'm returning the Dr Dobbs CDROM ([EMAIL PROTECTED])
Re: Anybody know about this flaw? (Dan Day)
Re: Message to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: Guaranteed Public Key Exchanges (Dan Day)
Thank you Don Taylor and Fauzan Mirza ("TJ")
Re: Message to SCOTT19U.ZIP_GUY (James Felling)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: Opinions please: Serpent (JCA)
Re: Weak Blowfish implementations? (John Savard)
Re: new standart for encryption software ("Joseph Ashwood")
Re: NIST, AES at RSA conference (Terry Ritter)
Re: Using Gray Codes to help crack DES ("Nick Shaffner")
Re: Guaranteed Public Key Exchanges (Darren New)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (zapzing)
Re: NIST, AES at RSA conference (David Wagner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: micropayments and denial of service?
Date: 10 Feb 2000 19:17:50 GMT
In article <87se24$pmn$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>(I grant you that requiring payments is probably suicide for an online
>business whose competitors allow anonymous free access. And I'm
>fond of being an anonymous free user myself.)
Micropayments don't have to represent $$; they can represent CPU cycles.
For example, something like "hashcash": in order to connect, your
SYN packet must contain a value x such that the first k bits of
SHA1(N,x) match the first k bits of, say, the current time. N is
a publicly-known fixed value that could also change over time.
Or something like that. If clients had to burn CPU to connect (whereas
the check for the server is easy), they'd have a hard time engaging in
floods.
But then again, can you "get there from here"? You'd have to have
application, if not OS, support, on the client side. What about all
those people that don't want to upgrade?
- Ian
------------------------------
From: [EMAIL PROTECTED] (fvw)
Subject: Opinions please: Serpent
Reply-To: [EMAIL PROTECTED]
Date: Thu, 10 Feb 2000 19:29:05 GMT
I'm considering different symmetric encryption algorithms for an encrypted
disk. Several are available, most of which are thouroughly documented
in applied crypto. However, Serpent
(http://www.cl.cam.ac.uk/~rja14/serpent.html) is not in this book.
I have no real cryptographic knowledge, apart from reading AC once... So
I'd like to hear your opinions on this algorithm, and whether you advise
it or not, especially since it appears to be pretty new.
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: 10 Feb 2000 19:34:55 GMT
Vernon Schryver <[EMAIL PROTECTED]> wrote:
> If the contents are only scanned images, then how can you "search and
> cut-and-paste the text"?
That's a damn good question that I'd love an answer to myself! I've
got several CDs with scanned page images, including the DDJ CDROM, and
I can cut and paste right out of the scanned image as text. So either
Adobe Acrobat is doing OCR on the fly, or there's other meta
information that's stored in the PDF file (probably from a previous
OCR pass). Anyway, I'm not sure why I'd want to cut-and-paste like
that, but it's pretty cool that you can do it. The question of "how?"
remains a curiosity though...
--
Steve Tate --- srt[At]cs.unt.edu | Gratuitously stolen quote:
Dept. of Computer Sciences | "The box said 'Requires Windows 95, NT,
University of North Texas | or better,' so I installed Linux."
Denton, TX 76201 |
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Anybody know about this flaw?
Date: Thu, 10 Feb 2000 19:36:32 GMT
On Thu, 10 Feb 2000 08:25:55 GMT, Greg <[EMAIL PROTECTED]> wrote:
>> The whole point of a "public key" is that it doesn't MATTER if it's
>> intercepted. You don't NEED a "secure way" to exchange them.
>> You could publish them in the newspaper if you like.
>
>A newspaper constitutes another form of communication.
I'm aware of that. I was not offering it as a form of communication
that meets the original poster's question, I was offering it as
an example of how it doesn't matter if a public key is intercepted.
(That's simple interception, of course -- interception and spoofing
is another subject entirely.)
--
"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: Message to SCOTT19U.ZIP_GUY
Date: Thu, 10 Feb 2000 20:28:43 GMT
In article <[EMAIL PROTECTED]>, James Felling
<[EMAIL PROTECTED]> wrote:
>
>Wouldn't a better scheme be:
>pass 1: compress with compression X
> 2: encrypt with cypher A using key 1 in a chained mode starting at
>"middle" of file (treating file as a ring buffer)
> 3: encrypt with cypher B using key 2 in a chained mode that starts at
>begining of file
> 4: encrypt with cypher C using key 3 in a chained mode starting at
>"middle" of file (treating file as a ring buffer)
> ( 5: compress with compression Y)
>
>Where cypher's A,B, and C are different cyphers, and X and Y good
>compressors.(X is good for compressing whatever is expected as input, and Y
>if used is a good general purpose compressor). middle is defined in the spec.
>
>Reasoning.
>Compressing first will reduce the amount of input to cypher A -- this means a
>shorter input so less data will need to be encoded, and less cyphertext will
>be generated in the end.
I still think the first compression should be a one-one compression.
>
>chaining will diffuse the data through the file in a fairly efficient manner,
>and in theory every block will have a chance to affect all others.
The problem is most methods routinely without any thought use the NSA
blessed 3 letter chaining methods which such big time.
>
>The final compression is im my opinion unnecessary, but may be done to save
>bandwidth.
The way this is set up it is mostly likely that if compression attempted at
this point not only is it unnecessary but will make the file longer.
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***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Guaranteed Public Key Exchanges
Date: Thu, 10 Feb 2000 19:52:23 GMT
On Thu, 10 Feb 2000 17:29:39 +0800, No Brainer <[EMAIL PROTECTED]> wrote:
>> Ask it a different way. You and I are "unknown to each other." If you want
>> to exchange keys with *me*, why? You couldn't even verify I'm not the man in
>> the middle if you met me face to face, could you? Calling me on the phone
>> won't help if you don't know my voice. Etc.
>
>I totally agree, but *how* or *is* there a way to do it securely?
I believe Darren is raising a larger issue -- if the only contact you
have with someone is via email, why do you trust him enough to (try to)
engage in secure traffic in the first place?
Security is not as simple as merely exchanging secure keys -- that's
worthless if you can not establish trust, and a good reason to
exchange sensitive information with someone who is just an email alias.
In short, once you answer questions about the larger issue of who
you're talking to, how you know who they really are, why you're
exchanging information with them, and how you know you can trust them,
you'll find that the question of what protocols are necessary to
establish secure communications answers itself, or at least
becomes very much secondary to the issues mentioned above.
It might be a neat technical trick to figure out how to establish
secure communications with someone you have no contact with except
via email, but in the real world, that's exactly the sort of
situation in which you wouldn't (or at least *shouldn't*) WANT to
exchange sensitive information. In a case like that, the "man-in-the-middle"
is the *least* of your problems -- the guy at the other end of your
email traffic might *himself* be an enemy disguising himself as a friend.
--
"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: "TJ" <[EMAIL PROTECTED]>
Subject: Thank you Don Taylor and Fauzan Mirza
Date: Thu, 10 Feb 2000 20:08:03 GMT
For your help in response to a recent post I made.
It was a welcome breath of fresh air from the arrogance of others.
Once again, thanks.
TJ
BTW, I have kind of "cracked" the encryption, or at least, I have managed to
edit the file by a process of altering a few parts at a time, and noting the
effect.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Thu, 10 Feb 2000 14:28:38 -0600
"SCOTT19U.ZIP_GUY" wrote:
> In article <[EMAIL PROTECTED]>, James Felling
><[EMAIL PROTECTED]> wrote:
> >
> >Wouldn't a better scheme be:
> >pass 1: compress with compression X
> > 2: encrypt with cypher A using key 1 in a chained mode starting at
> >"middle" of file (treating file as a ring buffer)
> > 3: encrypt with cypher B using key 2 in a chained mode that starts at
> >begining of file
> > 4: encrypt with cypher C using key 3 in a chained mode starting at
> >"middle" of file (treating file as a ring buffer)
> > ( 5: compress with compression Y)
> >
> >Where cypher's A,B, and C are different cyphers, and X and Y good
> >compressors.(X is good for compressing whatever is expected as input, and Y
> >if used is a good general purpose compressor). middle is defined in the spec.
> >
> >Reasoning.
> >Compressing first will reduce the amount of input to cypher A -- this means a
> >shorter input so less data will need to be encoded, and less cyphertext will
> >be generated in the end.
>
> I still think the first compression should be a one-one compression.
I wouldn't argue with that one way or annother. If it is 1-1 I can see some advantage
to that. I am still inclined
to prefer efficiency to 1-1ness, but your mileage( and raodmap) may vary.
>
> >
> >chaining will diffuse the data through the file in a fairly efficient manner,
> >and in theory every block will have a chance to affect all others.
> The problem is most methods routinely without any thought use the NSA
> blessed 3 letter chaining methods which such big time.
Yes, I am familiar with your oppinion of CBC, et al., but they do accomplish their
goal especially if used in a
bricklayered manner.
>
> >
> >The final compression is im my opinion unnecessary, but may be done to save
> >bandwidth.
> The way this is set up it is mostly likely that if compression attempted at
> this point not only is it unnecessary but will make the file longer.
>
> 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***
>
> I leave you with this final thought from President Bill Clinton:
>
> "The road to tyranny, we must never forget, begins with the destruction of the
>truth."
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 10 Feb 2000 20:38:44 GMT
On 10 Feb 2000 11:02:41 -0800, in
<87v20h$qg0$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> From my view, part of the problem with AES is that it eliminates the
>> direct financial advantage for the creation of a good cipher. That
>> does not help generate the industry of cipher design (and related
>> analysis tools) that we need. We need to employ good people to work
>> on this all day every day for years, with a corporate memory of their
>> intermediate results. We need teams of experts with substantial
>> resources and no other responsibility. We have to pay for that.
>
>How much would it cost to assemble a team of experts as good as,
>or better than, today's de facto ragtag assembly of academics and
>others? My expectation is that -- even if you can find the bodies
>-- it might be extremely expensive.
Of course it's expensive. But *any* big company is expensive. It is
often breathtaking for individuals to realize just how much money it
takes simply to form a company to do fairly everyday things.
>(And finding the bodies might
>be even more of a challenge: there seems to be a very limited number
>of people in the industry with the required background, skills, and
>experience to do the job.)
We just discussed that in the last week or so: I am of the opinion
that one of the reasons we have relatively few people doing this is
that there is little market for it. I think we need only to create a
market for those skills, plus make continuing development a
requirement, and we will soon have people with the needed skills.
I also think it more important to have a team than to have any big
name. What is needed is groups of good people who concentrate on the
various problems.
>Do you have any sense for what the costs might run to, and who might
>fund it? (NIST is poor, so they certainly couldn't fund it.)
The point is that *the* *market* ought to fund it. But I can well
imagine that parts of the government would prefer that there be no
such market. And that is consistent with the AES giveaway.
In general, those who reap the benefit should pay. Selling new cipher
implementations for a few bucks each might be a reasonable financial
model if the market for those ciphers was big enough.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 10 Feb 2000 20:38:55 GMT
On 10 Feb 2000 11:06:03 -0800, in
<87v26r$qgk$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> The two sides of this opinion are not equal: If I want various other
>> security features in the system and I am wrong, then society may have
>> spent a little more than it needed to spend. But I do mean "little":
>> once the decision is made, I would expect the result to cost about the
>> same. Applications which use ciphering would be slightly slower.
>
>One problem is that there are also many applications where
>if the crypto is too slow, they'll just ditch it. (Put another way,
>the crypto is low on their priority list, so they'll only consider
>using it if it's cheap and easy and free.)
There are parameters, of course. But they are not all zero. I think
the increased cycles now available to most users make good crypto
mostly available. Three ciphering levels triples ciphering cost, but
is a far smaller proportion of the overall application. In fact, a
human-length pause for encryption could be like a good solid thunk! in
a car door. We need to convey to the users that something useful and
important is happening.
Free is nice, but we only have to look at the security problems on the
web for the past few days to think that buying and using good stuff
might be worthwhile after all.
>If we standardize on a slower, more over-engineered cipher, we have
>to balance the reduced risks of compromise against the increased number
>of systems which will decline to use the crypto. It seems challenging
>to find the right balance.
I think the market is the right place. A variety of products that can
be used mostly interchangeably would give the user the tools to make
those decisions.
>> It might be reasonable to take some ciphers which have been found weak
>> under specific attacks, or to generate some ciphers which would be
>> weak, and then see how they are strengthened by additions, with
>> respect to specific known attacks.
>
>Agreed!
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: Opinions please: Serpent
Date: Thu, 10 Feb 2000 12:37:46 -0800
Serpent is one of the final five contenders (together with MARS, RC6,
Rijndael
and Twofish) in the race to become AES. Some figures I have recently seen
seem to make Rijndael the fastest when effciently implemented for a group of
well-known 32- and 64-bit CPUs, followed by Twofish. I think that in these
tests it would only outperform RC6.
Don't construe this to means that Serpent is useless - I am just
describing
very particular results that do not tell much about the overall qualities of
any
algorithm.
You might like to wait and see which one gets away with it; this should
happen
within a few months.
fvw wrote:
> I'm considering different symmetric encryption algorithms for an encrypted
> disk. Several are available, most of which are thouroughly documented
> in applied crypto. However, Serpent
> (http://www.cl.cam.ac.uk/~rja14/serpent.html) is not in this book.
>
> I have no real cryptographic knowledge, apart from reading AC once... So
> I'd like to hear your opinions on this algorithm, and whether you advise
> it or not, especially since it appears to be pretty new.
>
> --
>
> Frank v Waveren
> [EMAIL PROTECTED]
> ICQ# 10074100
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Weak Blowfish implementations?
Date: Thu, 10 Feb 2000 14:15:09 GMT
[EMAIL PROTECTED] wrote, in part:
>I have tried out some Blowfish implementations and found that regular
>plaintext patterns, like entries with line delimiters pasted repeatedly,
>show up as regular patterns in the cyphertext.
Although Blowfish itself is a block cipher, and so can't be weaker
when properly implemented, apparently the programs you have
encountered use Blowfish in _ECB_ mode to encrypt files, which indeed
will lead to the problem noted here.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: new standart for encryption software
Date: Thu, 10 Feb 2000 01:27:18 -0000
I'm sorry, but your vast array of poor spelling, including
"standart" and "oficial" (which you actually quoted). There
is also an additionallly vast array of spelling/grammar
mistakes on your page, including HTML that isn't correct.
Given this, I would have to see the source code to even
bother downloading your program. Basically I'd say it's
rather likely that many hackers would like a list of people
who are using your software, it's probably about as easy to
hack as plaintext.
Joe
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 10 Feb 2000 21:11:15 GMT
On Thu, 10 Feb 2000 01:01:54 -0000, in <OI4oMW6c$GA.168@cpmsnbbsa02>,
in sci.crypt "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>[...]
>Given a function f() with output confined to a space k,
>given any input (of a value in k) to f() the odds of an
>identical output is at least 1/k for a further reapplication
>of the function f() n times the odds of there existing an m
>(m<n) such that f^n() = f^m() is at least (n-1)/k (m must
>not be negative, but may be zero indicating the plaintext)
It appears that my main issue is right here. In practice,
"non-groupy" may mean having different "spaces."
The block ciphers we use key only a tiny, tiny fraction of the
possible permutations in their simulated substitution table. That
small keyed fraction is its "space." And if, as we expect, different
ciphers make independent selections from among the universe of
possible permutations, then one cipher is probably not going to be
able to decipher the product of two ciphers because they are unlikely
to have much "space" in common.
Ideally, multiciphering would square the number of resulting
permutations; a few of those might be in one or the other component
ciphers, but with just two ciphers, that should be very rare. Of
course if we multicipher enough, eventually the permutation space or
universe will fill and that probability will increase. But I think we
can afford to have quite a few layers before we make that possibility
high enough to worry about.
>When n = (k +1) there must exist an m < n
>
>Given this f^n() (for n = k+1) is equivalent to f^m(), a
>goal that is computationally easier to achieve.
>
>It is also possible to change f() at some point in the
>stream and the proof is likely to still apply provided that
>k remains fixed across functions (although a similar proof
>will exist).
>
>Based on this I assert that there is a limit to the number
>of times a function f() (including any cryptographic
>algorithm) can be applied is K and in the case of a
>cryptographic algorithm of length x the maximum number of
>times that algorithm can be applied without being gaurenteed
>to provide a reduction of strength is 2^x.
>
>In short, I can't prove that applying an algorithm 3 times
>forms such a decrease, and I believe that for most
>non-groupy ciphers that tripling will likely increase the
>security, there is a limit to how far we can take it.
Sure, I don't doubt that there are limits. We always expect limits.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Nick Shaffner" <[EMAIL PROTECTED]>
Subject: Re: Using Gray Codes to help crack DES
Date: 10 Feb 2000 16:12:21 EST
Dan Day wrote in message <[EMAIL PROTECTED]>...
>On 8 Feb 2000 23:24:52 GMT, [EMAIL PROTECTED] wrote:
>>
>> count = count + 1
>> greycode = count ^ (count >> 1)
>
>Hey, that's really slick. But I'll be damned if I can figure
>out why it works...
Does Anyone know where I can get an explanation of what greycodes are and
their uses in cryptography?
Nick
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Guaranteed Public Key Exchanges
Date: Thu, 10 Feb 2000 21:28:04 GMT
Dan Day wrote:
> In a case like that, the "man-in-the-middle"
> is the *least* of your problems -- the guy at the other end of your
> email traffic might *himself* be an enemy disguising himself as a friend.
Right. My point is that even if I'm standing face-to-face with you, and you
have your public key on a floppy in your hand, how do you know you're giving
it to the right person? Your question as originally phrased is meaningless -
that you know nothing about the person you're trying to exchange keys with.
What you *do* know about the person is what you have to lever to get a
secure exchange. If you know nothing, then you have no reason to even talk
to that person in plaintext let alone via cyphers.
--
Darren New / Senior Software Architect / IZ, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: Thu, 10 Feb 2000 21:16:05 GMT
In article <87t0sk$std$[EMAIL PROTECTED]>,
"r.e.s." <[EMAIL PROTECTED]> wrote:
> "zapzing" <[EMAIL PROTECTED]> wrote ...
> : "r.e.s." <[EMAIL PROTECTED]> wrote:
> : > "Tony T. Warnock" <[EMAIL PROTECTED]> wrote ...
> : > : All combiners will have to be Latin squares.
> : >
> : > The Latin Square combiners appear to be a subset of all
> : > possible combiners, corresponding to "balanced" rows &
> : > columns in the table; so a combiner that's an Lsquare
> : > might be *better* than one that's not, in some context,
> : > but not all combiners need be Lsquares, as far as I can
> : > see in common usage of the term. (But it does seem that
> : > to be a combiner it must allow for later recovery of the
> : > message -- resulting in N!^N possible NxN combiners.)
> : >
> : > To take the most extreme example:
> : > If row corresponds to enciphering-symbol and column
> : > corresponds to message-symbol, then for an alphabet of
> : > 4 symbols even the square
> : >
> : > 0123
> : > 0123
> : > 0123
> : > 0123
> : >
> : > yields a combiner -- but not a good one, since a given message
> : > symbol will result in an output independent of enciphering
> : > symbol. Whether less-extreme non-balanced (i.e. non-Lsquare)
> : > combiners are ever desirable -- that would seem to be another
> : > question.
> : >
> :
> : OK, I posted about this before but apparently
> : I just did not make myself clear, or something,
> : so I will try again (assuming that the
> : moderators will be patient with my lack of
> : communication skills).
>
> I missed your earlier posting. We're in total agreement
> that a combiner need not be a Latin Square -- that's the
> point I was making, after all. (I have the feeling that
> your remarks are really intended for Tony, to whom I had
> replied in a similar vein.)
>
> (btw, this ng is unmoderated)
Newsgroups come and go so quickly around here.
This thread started in sci.crypt.reserach and then
hyperspace jumped over here, and I did not
bother to check, sorry.
>
> : You do *not* need a latin square,
> : because what you refer to as the
> : encyphering symbol never needs to be
> : recovered. The only thing you ever really
> : need to do is recover the message symbol
> : from the combined symbol.
> : I will give an example which is hopefully
> : better explained. Suppose we have two bit bytes,
> : then coinsider the combining function given
> : by the table:
> :
> : m= 0123
> : ----
> : e=0 3102
> : e=1 2130
> : e=2 0231
> : e=3 1320
> :
> : Now if you had the encyphering symbol
> : and the combined symbol then you could
> : recover the message symbol, but you
> : could not recover the encyphering symbol
> : from the combined symbol and the message
> : symbol, but that's OK, because you never
> : need to do that anyway.
> :
> : This sort of combining function would
> : be much easier to do than making a
> : latin square, and there are more
> : possibilities also, so why would you
> : need a latin square? That was not
> : a rhetorical question , I really
> : do want to know why, if you would
> : be so kind as to clue me in.
>
> Again, although your reply is to my posting, I'll
> assume the "you" in the above sentence is generic,
> since I didn't say that a Latin Square is needed--
> I said that one is *not* needed, and that it's
> a separate issue as to whether a non-LatinSquare
> combiner would be "good" in a given context.
>
> My 2-cents about the general situation, though, is
> that if a column is not a permutation of the entire
> output symbol alphabet, then some output symbols
> may tend to be more/less frequent than others when
> enciphering the same message symbol, and that might
> well be a weakness wrt frequency anaysis.
>
Yes, I see now. In the example I gave, if
the message was composed of all ones,
the output would be one fifty percent of
the time, assuming an evenly balanced
encrypting symbol. If that sort of combining
function were used, it would have to be used in
conjunction with other techniques, such as
pre or post block ciphering, with random noise
added in the blocks..
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 10 Feb 2000 13:34:04 -0800
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> We just discussed that in the last week or so: I am of the opinion
> that one of the reasons we have relatively few people doing this is
> that there is little market for it. I think we need only to create a
> market for those skills, plus make continuing development a
> requirement, and we will soon have people with the needed skills.
Ok. But creating the necessary expertise takes time, a lot of time.
You don't acquire experience making and breaking cryptosystems overnight.
> The point is that *the* *market* ought to fund it.
Well, so far the market has spoken: It seems that most people are happy
enough with the level of security afforded by free ciphers like Triple-DES
and AES that they are not willing to pay -- even a little -- for a "better"
non-free cipher. (Witness the fate of non-free ciphers, like SEAL.)
So it seems unlikely the market will fund it, if they are already happy
with the available free options.
------------------------------
** 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
******************************
