Cryptography-Digest Digest #237, Volume #14 Thu, 26 Apr 01 05:13:00 EDT
Contents:
Re: AES poll (Benjamin Goldberg)
Re: Censorship Threat at Information Hiding Workshop (Bryan Olson)
Re: First analysis of first cipher ([EMAIL PROTECTED])
Re: Graphical representation of a public key (or fingerprint)? (Benjamin Goldberg)
Re: Censorship Threat at Information Hiding Workshop (Bryan Olson)
Merkle's one-time signature scheme ("Terry")
Re: AES poll (SCOTT19U.ZIP_GUY)
Re: Merkle's one-time signature scheme (Paul Rubin)
Re: AES poll (Benjamin Goldberg)
RC4 Source Code ("Dirk Mahoney")
Counter-Heisenberg 2-Phase Inequalities in Quantum Computers - Doctorow ("Osher
Doctorow")
Re: What Is the Quality of Randomness? ("Brian Gladman")
Re: What Is the Quality of Randomness? ("Brian Gladman")
Re: Wolf's Secure Channel Theorem (Matthias Geiser)
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: AES poll
Date: Thu, 26 Apr 2001 04:21:50 GMT
SCOTT19U.ZIP_GUY wrote:
>
> [EMAIL PROTECTED] (Paul Crowley) wrote in
> <[EMAIL PROTECTED]>:
>
> >[EMAIL PROTECTED] (David Wagner) writes:
> >> For what it's worth, the "polls" of the research community showed
> >> a significant leaning towards Rijndael even before it was selected
> >> by NIST. I, for one, think they made a fine choice, and I'm very
> >> pleased with the results of the standards process.
> >
> >...and remember, this is one of the Twofish authors writing. In fact,
> >the extended Twofish team officially endorsed three of the final five
> >(Rijndael, Serpent, Twofish) in their final presentation. They are
> >the people who did the most cryptanalysis of the AES candidates.
>
> Are you attempting to say the endorsement was real and not just the
> poltically correct thing to do. If the TWOFISH team actaully made
> an honest statement saying please pick Rijndael its better than
> TWOFISH I would call that an endorsement any thing short of that
> sounds FISHY.
More like, the twofish team said, our cipher is very secure, and these
other two ciphers are about as secure as ours (maybe a tiny fraction
less secure, but not so much that it's noticable). But the people doing
benchmarks said, Rijndael is fastest. And since there wasn't any
security reason *not* to use Rijndael, and there *was* a indication that
Rijndael would be faster, the decision was to use Rijndael.
> Besides part of the game is to pretend you like some of the
> competition so that you can fake the moral high ground. You pick the
> one that you think your better than so if another product is far
> better people will exculde looking at it.
IIRC, the twofish team considered theirs to be securitywise better than
all of the other 4, and considered serpent and rijndael to come closest
to it in strength.
> That way your product may
> only be compared by others to the one you sort of liked. People will
> falsely assume the possible far better product was not very good.
The problem with this is that you try to say that that truly horrible
<whatever> is the only thing that even comes close to ours, and look how
bad it is -- this means that ours must be wonderful. All five AES final
candidates were pretty decent, none of them were horrible.
> "Since you seem to be fair" since you said one was sort of good so the
> others must not be so good. It really a very clever business trick.
It only works if the people who you are describing stuff to have no way
of judging for themselves. The twofish team did analysis, and the
judges read it and understood it. Tricks like you suggest can only work
if the judges are stupid/ignorant and are forced to take the analysts'
claims of relative strength at face value -- they aren't, they can look
at the possible attacks and make their own decisions. The only thing
that the judges need to trust the analysts to do is to include all
attacks they can find -- after that, the judges have sufficient brains
to look at the attacks and see how damaging they are to the cipher.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Wed, 25 Apr 2001 21:23:28 -0700
"Donald L. Nash" wrote:
>
> Bill Unruh wrote:
>
> >It is not theft. Theft is depriving someone of some good. Copying is
> >leaving that person with that good, and making another one. The use of
> >emmotive and totally inappropriate terms like theft usually indicates a
> >attempt to circumvent thought by emotion.
>
> Theft can also be defined as the obtaining of some good or service
> without due compensation to the provider.
This is about specific acts by specific people. While the
above is probably a good enough argument for a defense
against slander, I object to calling someone's actions theft
when the law calls it different.
Then again, I'm not entirely sure what law people think is
at issue here. Copyright is covered by title 17 of the US
Code, which defines various violations as "infringement".
Can anyone cite where what is called "intellectual property
law" actually defines covered works as property, or
violations as theft?
> For example, if I hook up a
> black market descrambler to my cable TV connection, I'm not depriving my
> cable company of their video signal, I'm simply making a copy of it
> which I can view on my TV. But the law calls that "theft of service"
> because I'm not paying for it. A similar analogy applies to copyright
> law.
There's a much more important analogy: tapping the cable is
theft of service because, as you wrote, "the law calls that
'theft of service'". Copyright violation is infringement
and not theft because the law calls it infringement and not
theft.
> If I make an unlicensed copy of a copyrighted work outside the
> bounds of fair use then I am denying the copyright holder due
> compensation for the work. I don't think that using the word
> "theft" is a stretch here.
I disagree. In the quote above, you describe the act in
specific terms from law. The "stretch" went all the way
from what the law actually says to your "Theft can also be
defined as..."
--Bryan
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: First analysis of first cipher
Date: Wed, 25 Apr 2001 19:43:42 -0800
Tom St Denis wrote:
>
> <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
[snip]
> > I've seen some papers discussing the use of bent functions to generate
> > strong S-boxes. Other papers discuss Hadamard matrices. What are the
> > other common methods of generating strong S-boxes.
>
> Bent functions are bad ideas. They are not bijective and generally I think
> any function that loses information is a bad idea.
>
> You can also use GF inversion, feistel networks, sp networks..
>
What is the underlying design principle? If my S-box is a matrix filled
with
m-bit elements and the S-box input chooses the row and column, wouldn't
the
idea be to fill the matrix with elements that are maximally distanced
from
each other
> DES like designs are stupid...
Hindsight is 20/20. Ten years from now today's smart algorithms may look
"stupid" too.
>..They lack formal proofs of security. Current
> trends are more towards mathematical designs...
Proof of security or proof of complexity? I'm only aware of one cipher
system
that is provably secure and it is practically insecure due to key
management problems.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Graphical representation of a public key (or fingerprint)?
Date: Thu, 26 Apr 2001 04:49:55 GMT
Michael Schmidt wrote:
>
> Hi,
>
> I know that there has been research on the topic "graphical
> passwords", i.e. keys being created from graphical user input.
>
> I'm wondering whether there has been any research conducted on the
> topic "graphical representation of a public key" or the key's
> fingerprint.
So instead of key from graphics, you want graphics from keys.
> My goal is to authenticate a public key (or better: its fingerprint,
> like with PGP) securely by creating and comparing its graphical
> representation with an "original", which is unique enough for every
> key/fingerprint, yet easy to be processed and compared by the human
> brain.
In otherwords, the same thing as comparing the hex version of the key's
fingerprint, but visually. The "original" still has to be sent out of
band, but by being graphical, it's something we can hope to remember
easily, rather than having to write it down.
I would suggest converting the fingerprint into a floating point number
between 0 and 1, and using that as some parameter for some sort of
fractal image. Or, perhaps using the fingerprint as the seed of some
prng, which is then used to generate some distinctive piece of graphics.
Of course, you *could* concievably use the bits in the raw, and produce
a square or rectangle of black and white dots -- you could use this for
comparing fingerprints visually if you have them side by side, but it
wouldn't be easily memorizable.
Actually, if you want it memorizable, and distinctive/collision-free, it
will likely have to be a rather large picture, something with solid
areas of color, or shadings from one color to another, with few seperate
objects, but each one of unusual shape/color/texture. Otherwise, the
picture will look too "busy" and not be easily recognized. You might
need a compromise on how many objects appear in the graphic, versus how
complicated each object is.
A "raw" graphical fingerprint takes it to the extreme of having as many
objects as bits, and each one is supremely simple (being either black or
white). A human can't remember that many details. The opposite extreme
is to use the fingerprint to represent one single color or shade of grey
-- but a human cant distinguish that many shades. A balance is needed.
You need to take advantage of how people's eyes and brains distinguish
and remember visual data, so as to produce 2^N noticably different
pictures.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Wed, 25 Apr 2001 21:50:22 -0700
Terry Ritter wrote:
> If you don't like the word "theft" because you think it biased,
> presumably you have a better word in mind. But what would that word
> be?
[...]
> From classic times, writers have sold their work to an audience of
> individuals. When that audience receives that same work in other ways
> -- even if others just give it away -- the market for the original
> work is reduced. If that is not "stealing" worth from the
> intellectual property owner, what is it?
Infringement. See US Code Title 17, Chapter 5 "COPYRIGHT
INFRINGEMENT AND REMEDIES".
--Bryan
------------------------------
From: "Terry" <[EMAIL PROTECTED]>
Subject: Merkle's one-time signature scheme
Date: Thu, 26 Apr 2001 14:49:32 +1000
Hi, I am looking for the source code of an implementation for Ralph C.
Merkle's one-time signature scheme, using authentication trees. My preferred
language is C++, C or Java, but any implementation would help.
Thanks,
-Terry Tollisen
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES poll
Date: 26 Apr 2001 04:43:32 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>
>It only works if the people who you are describing stuff to have no way
>of judging for themselves. The twofish team did analysis, and the
>judges read it and understood it. Tricks like you suggest can only work
>if the judges are stupid/ignorant and are forced to take the analysts'
>claims of relative strength at face value -- they aren't, they can look
>at the possible attacks and make their own decisions. The only thing
>that the judges need to trust the analysts to do is to include all
>attacks they can find -- after that, the judges have sufficient brains
>to look at the attacks and see how damaging they are to the cipher.
>
Actually I could tell you many horror stories of how the government
committes decide something. Its foolish to think it has any relationship
with getting to the correct solution. Look I have seem first hand
this kind of stuff for 26 years and I doubt you know what your talking
about.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Merkle's one-time signature scheme
Date: 25 Apr 2001 22:47:01 -0700
"Terry" <[EMAIL PROTECTED]> writes:
> Hi, I am looking for the source code of an implementation for Ralph C.
> Merkle's one-time signature scheme, using authentication trees. My preferred
> language is C++, C or Java, but any implementation would help.
I've never heard of anyone actually implementing this. It's a very clever
scheme but the resulting signatures are quite large. Also, it is still
patented in the US.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: AES poll
Date: Thu, 26 Apr 2001 05:50:17 GMT
SCOTT19U.ZIP_GUY wrote:
>
> [EMAIL PROTECTED] (Benjamin Goldberg) wrote in
> <[EMAIL PROTECTED]>:
>
> >
> >It only works if the people who you are describing stuff to have no
> >way of judging for themselves. The twofish team did analysis, and
> >the judges read it and understood it. Tricks like you suggest can
> >only work if the judges are stupid/ignorant and are forced to take
> >the analysts' claims of relative strength at face value -- they
> >aren't, they can look at the possible attacks and make their own
> >decisions. The only thing that the judges need to trust the analysts
> >to do is to include all attacks they can find -- after that, the
> >judges have sufficient brains to look at the attacks and see how
> >damaging they are to the cipher.
>
> Actually I could tell you many horror stories of how the government
> committes decide something.
I suspect the fact that such horror stories exist proves rather than
invalidates my point. If the panel is ignorant or stupid or doesn't
read the analysts' reports, then a bad decision will be made.
If the panel is knowledgable and intelligent and does read and
understand the reports, then a good decision will be made.
Note that the *majority* of the panel must be knowledgable, etc, for a
good decision to be made.
> Its foolish to think it has any relationship with getting to the
> correct solution.
What "it" are you talking about? The analysis? The level of ignorance
on the panel? The level of stupidity of the panel? The lazyness of the
panel?
> Look I have seem first hand this kind of stuff for 26 years and I
> doubt you know what your talking about.
I say, ignorant, stupid, lazy people generally make poor decisions. I
say, smart, knowledable people who are willing to listen, read and
learn, and who aren't lazy generally make good decisions. You are
perfectly free to disagree with me.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
Reply-To: "Dirk Mahoney" <[EMAIL PROTECTED] (remove the _)>
From: "Dirk Mahoney" <[EMAIL PROTECTED] (remove the _)>
Subject: RC4 Source Code
Date: Thu, 26 Apr 2001 06:36:34 GMT
Hi all,
Can anyone point the way to RC4 source code written in C or C++?
Thanks,
- Dirk
------------------------------
From: "Osher Doctorow" <[EMAIL PROTECTED]@ix.netcom.com>
Subject: Counter-Heisenberg 2-Phase Inequalities in Quantum Computers - Doctorow
Date: Thu, 26 Apr 2001 00:35:07 -0700
From: Osher Doctorow [EMAIL PROTECTED], Wed. April 25, 2001 11:25PM
Take a look at sci.physics from the last few days for my proof of an
analogue of the Heisenberg Uncertainty Principle involving 2 phases (2
inequalities, one > = a constant, the other < = the same constant) instead
of just the one inequality of Heisenberg. One of the main methods is to
convert from uncertainties, which involve distance-functions/metrics, to
proximity functions, which intuitively describe *nearness* rather than
*farness*.
The implications for quantum cryptography should be quite remarkable. I
know that there has been a recent influx of research money into quantum
cryptography of the Heisenberg-Bohr school which justifies itself totally in
terms of the Heisenberg Uncertainty Principle. I know this because I got
thrown off one of the main lists for courteously suggesting that Bohr and
Heisenberg may have made some mistakes. Perhaps it is time for scientists
and engineers to request that research money be allocated to more than just
one mainstream theory (perhaps it's hard to do since then somebody might
challenge *bipartisan foreign policy*?).
See my paper in B. N. Kursunuglu's et al's (Editors) 2000 volume Quantum
Gravity, Generalized Theory of Gravitation, and Superstring Theory-Based
Unificaiton, Kluwer Academic/Plenum: N.Y. 89-97 for some background
material, or see fairly detailed abstracts of 52 of my papers at
http://www.logic.univie.ac.at, Institute for Logic of the University of
Vienna (select ABSTRACTS, then select BY AUTHOR, then select my name).
Osher Doctorow Ph.D.
Ventura College, Doctorow Consultants, etc.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: What Is the Quality of Randomness?
Date: Thu, 26 Apr 2001 09:32:00 +0100
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9c7r92$4882$[EMAIL PROTECTED]...
> > It would still be random if your source for encrypting was random. I.e
if
> > you take an OTP to a string of zeroes it's still random. If you know as
> an
> > attacker beforehand that the plaintext is all zeroes then the plaintext
is
> > not random, no shit, but that's not the point. The point of encrypting
> > something is to hide non-trivial knowledge.
>
> Ok, try this thought experiment. We can both probably agree that a
> perfectly random OTP that satisfies the condition of a 2^-N probability
for
> N-bit sequence can yield no useful information. This condition can only
be
> met by an infinitely large pad so let's assume a very large pad to get us
> pretty close to 2^-N. Now let's XOR our very large pad with two messages
of
> opposite extremes, a message of all 0's and a message of all 1's. In the
> first case our original pad is left totally unchanged, in the second case
> every bit is flipped to yield a reverse pad but with exactly the same
> distribution. So anything in between those two extremes will affect the
> statistical distribution of the resultant ciphertext. If my message was
all
> ASCII A's it would most certainly skew the stats of the ciphertext.
No it would not. Consider the following.
Take your original OTP bit stream and divide it into 8-bit units and count
the number of each of the bytes that result. In other words create 256
buckets numbered 0 to 255, put the bytes from the bit stream into their
appropriate buckets and count how many there are in each bucket at the end.
Now add a stream of 'A's - decimal 65 - to this bit stream and count the
output bytes again in the same way.
What happens is that any byte that originally went into bucket 0 now goes
into bucket 65, bytes that went into bucket 1 now go into bucket 66 and so
on. So all that the xoring of the 'A's has done is to shift the numbers on
each of the buckets without changing the number of bytes they contain. And
because the statistics depend on the counts and not on the bucket labels
this means that the statistics will be identical.
It turns out that, provided the OTP bitstream is from a truly uniformly
distributed random variable, the statistics of the stream added to it will
not change this.
You can think of this another way by asking if it is possible to devise a
stream to add to the OTP that will change its statistics.
In order to bias the statistics you need to change either more '1's into
'0's without changing '0's or more '0's into '1's without changing '1's.
But, in order to know whether to xor with a '0' or a '1' bit in order to do
this, you need to be able to predict the next bit in the stream and since it
is random you cannot do this.
> It wouldn't yield anything really useful in terms of decrypting it, but of
> course it wouldn't be a very useful message either. However, a long real
> message could yield enough information to at least give the number of each
> letter in the message.
Not true I am afraid.
Brian Gladman
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: What Is the Quality of Randomness?
Date: Thu, 26 Apr 2001 09:48:01 +0100
"Brian Gladman" <[EMAIL PROTECTED]> wrote in message
news:0YQF6.32368$I5.177615@stones...
> "Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
> news:9c7r92$4882$[EMAIL PROTECTED]...
[snip]
>
> No it would not. Consider the following.
>
> Take your original OTP bit stream and divide it into 8-bit units and count
> the number of each of the bytes that result. In other words create 256
> buckets numbered 0 to 255, put the bytes from the bit stream into their
> appropriate buckets and count how many there are in each bucket at the
end.
>
> Now add a stream of 'A's - decimal 65 - to this bit stream and count the
> output bytes again in the same way.
>
> What happens is that any byte that originally went into bucket 0 now goes
> into bucket 65, bytes that went into bucket 1 now go into bucket 66 and so
> on. So all that the xoring of the 'A's has done is to shift the numbers
on
> each of the buckets without changing the number of bytes they contain.
And
> because the statistics depend on the counts and not on the bucket labels
> this means that the statistics will be identical.
I used addition here when I should have used xor. Hence bucket 1 goes to
bucket 64, not 66, and so on. But the principle is the same.
Brian Gladman
------------------------------
From: [EMAIL PROTECTED] (Matthias Geiser)
Subject: Re: Wolf's Secure Channel Theorem
Date: Wed, 25 Apr 2001 13:01:05 +0200
On Tue, 24 Apr 2001 09:26:54 -0500, Mark G Wolf <[EMAIL PROTECTED]> wrote:
>> Your conjecture is wrong.
>>
>> Proof: Cut the wire!
>
>There are no wires in information space.
Sure, not wires per se, but abstract channels. You have to make the assumption
that a (insecure) channel is availlable at all times.
Matthias
--
"If they give you ruled paper, write the other way."
Juan Ramon Jimenez
PGP KeyID: 1024/688E6CD9 FP: 3C59 DE10 DFD4 ED57 E8F4 19A8 B048 1FD2
------------------------------
** 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
******************************
