Cryptography-Digest Digest #411, Volume #10 Thu, 14 Oct 99 12:13:03 EDT
Contents:
Re: where to put the trust ("Trevor Jackson, III")
Re: crypto papers (again) (Tom St Denis)
Re: RSA Algorithm (Francois Grieu)
Re: where to put the trust (Patrick Juola)
Re: Should RC4 be free? (Gabriel Belingueres)
Re: where to put the trust (Patrick Juola)
Re: where to put the trust (Patrick Juola)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Peter
Galbavy)
Re: Should RC4 be free? (Gabriel Belingueres)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Derek
Bell)
Re: classifying algorithms ([EMAIL PROTECTED])
----------------------------------------------------------------------------
Date: Thu, 14 Oct 1999 07:49:44 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: where to put the trust
Anthony Stephen Szopa wrote:
> Tom St Denis wrote:
>
> > I have been getting alot of flak about 'how do you KNOW that 'place cipher
> > here' is actually this strong'. I admit there is no honest PROOF to it. No
> > cipher is unconditionally strong, none, zippo, zilch. If you use an OTP
> > wrong it can become weak. (Yes even the infamous Scottu19 has not been
> > proven to be strong).
> >
> > So what do we do?
> >
> > Well we trust experts.
> >
> > Let's take a survey... If you do any of the follwing post a short reply...
> >
> > drive a car, goto the doctors, eat fast-food, use a computer, drive on
> > bridges, live in an apartment, work in an office, gone to school ...
> >
> > You have probably relied on an experience expert. Do we trust them? Hell
> > yes. Do they do good jobs? 99.99% of the time yes.
> >
> > So does this apply to cryptography? Yes I think so.
> >
> > So although (for example) Twofish has not been proven to be strong, it has
> > been designed by people in the know, and I would trust it, just like I trust
> > my doctor to give a good evaluation of my health.
> >
> > Tom
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> BUNK!
>
> If you cannot determine the security strength of your encryption software, don't
> use it.
>
> Here is encryption you can be absolutely secure with:
>
> http://www.ciphile.com
Hmmm. you claim modern algorithms are bunk and your fake OTP is absolutely secure?
Please clarify. What is the unicity distance (c.f., Shannon) of your system?
Would you care to place a small monetary wager on the strength of your software?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: crypto papers (again)
Date: Thu, 14 Oct 1999 12:06:00 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]=NOSPAM (Gurripato) wrote:
> Thanx. And now, risking being off-topic, can you point me to
> a PS viewer? Itīs like a joke to me: when I need it, I find none
You can get gsview from
http://www.cs.wisc.edu/~ghost/aladdin/get550.html
I propably should have uploaded the files one at a time, but that's too
big... oh well... one big download and you get lots of goody stuff!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: RSA Algorithm
Date: Thu, 14 Oct 1999 14:03:45 +0200
[EMAIL PROTECTED] wrote :
> Published tables exist with (2^n)-1 up to 1000 bit numbers
> factorized, using old computers people would nowdays laugh at.
> Clearly, the above mentioned numbers was found to be easy
> to factor. Is there any objective reason for that, or is it the case
> that if we really need to factor those numbers, methods will be
> found that works ?
Special methods exist that help factor numbers of the form (2^n)-1,
called Mersenne numbers. For background see
<http://www.utm.edu/research/primes/mersenne.shtml>
It's not that trivial though, sometime the SNFS algorithm
(which I fail to fully understand, could not get past MPQS
with two large primes) is used. And many such numbers below
1000 bits are still only partially factored.
For example, 2^617-1 = 59233*68954123297*C171 where C171
is a 171 digits composite number of apparently unknown
factorisation. For a current list see
<http://www.cs.purdue.edu/homes/ssw/cun/index.html>
> How large is the largest number (2^n)-1 factored today ?
I can't find the answer. 2^1185-1 is factored, but there could
be much bigger ones, especially with n even.
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: where to put the trust
Date: 14 Oct 1999 08:42:49 -0400
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>> Put simply : if cryptographic "experts" didn't trust the opinions of
>> other experts, no one would read, or publish, the journals, and no
>> one would attend the conferences.
>
>The effect is real but the term "trust" is probably too strong unless it's the
>trust-but-verify flavor, which I find distasteful. The whole open source issue
>is based on the desire to minimize the degree of trust necessary to believe in
>one's security. Anyone, expert or amateur, who says "It's secure, trust me" is
>selling something I don't want to buy.
On the other hand, anyone who says "I don't like the look of that
Feistel cypher; it looks insecure" is much more likely to be believed
if the person saying it is Ron Rivest or Adi Shamir. Even without
a demonstration, Adi's expertise counts for something.
-kitten
------------------------------
From: Gabriel Belingueres <[EMAIL PROTECTED]>
Subject: Re: Should RC4 be free?
Date: Thu, 14 Oct 1999 12:22:59 GMT
In article <[EMAIL PROTECTED]>,
Darren New <[EMAIL PROTECTED]> wrote:
> Gabriel Belingueres wrote:
> > It was done by reverse engineering the code. As far as I can tell,
> > copyright laws don't protect code from reverse engineering in US.
>
> Especially given that in order to claim copyright, you're supposed to
give a
> copy of what you're copyrighting to the copyright office.
>
> See also Prolock v Copywrite, in Louisianna a couple decades ago.
(Sorry, it
> was a long time ago, and I don't remember a specific reference.)
Prolock
> tried to sue Copywrite for reverse engineering the code, and the judge
> basically said *because* it was copyrighted, that overrode the clause
in the
> license agreement prohibiting reverse engineering. Interesting, yes?
Yeah! And that fits pretty much with current crypto practice of
publishing the source code (or the method of encryption, at least) for
be reviewed by peers!
Gabriel
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: where to put the trust
Date: 14 Oct 1999 08:48:20 -0400
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> Douglas A. Gwyn (IST/CNS) <[EMAIL PROTECTED]> wrote:
>> >"Trevor Jackson, III" wrote:
>> >> So, what is the opinion of experts re trusting the opinion of experts?
>> >
>> >It is foolish to trust anyone as to the security of a cryptosystem
>> >when the person being trusted doesn't actually know. While you
>> >may judge an "expert" on the basis of past performance, nevertheless
>> >even experts make mistakes.
>>
>> This is foolish and borderline nihilistic -- there is little if any
>> true "knowledge" on this side of Judgement Day. Expert cryptographers
>> can indeed make mistakes, as can expert surgeons, expert typists,
>> expert chemists, expert pharmacists, expert mathematicians, and
>> expert expert-evaluators.
>>
>> If I were to say that "it is foolish to trust anyone as to the
>> contents of a medicine bottle when the person doesn't actually know.
>> While you may judge a chemical assay on the basis of past performance,
>> nevertheless even experts make mistakes," you would think I was
>> being silly. Yes, chemists make mistakes. But that doesn't mean
>> that it's foolish to believe the results of chemical assay.
>
>I disagree. There are ways to measure predictive power. When you apply them
>you gain a measure ot "expertness" within a domain. Do you know of some
>measure of predictive power within Cryptology? Not perfection, just reliable
>suggestions, or only suggestive hints.
Certainly. I believe, for instance, that (some of) the design criteria
of the DES S-boxes have been made public. The "avalanche" criterion --
that changing a single key bit should change (about) half of the cyphertext
bits -- is another measure. Key length -- a longer key is harder to
brute force but harder to secure -- provides another criterion. I
fact, I can even produce firm statements -- any symmetric cypher with a
40-bit or shorter key is too short and vulnerable to a particular named
attack (brute force). Another suggestive hint is that knapsack encryption
doesn't seem to work, even though we haven't examined all possible
knapsack algorithms, enough have fallen to "suggest" that knapsacks aren't
the way to go....
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: where to put the trust
Date: 14 Oct 1999 08:58:45 -0400
In article <7u3nmd$u6e$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <7u216r$7ke$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Patrick Juola) wrote:
>...
>>The bridge, however, has to stay up in all sorts of conditions,
>>including high winds, flooding, and so forth. Unless you can
>>create all possible situations of wind, water, load, &c, then
>>you can't test and confirm that the bridge will always stay up.
>
>Well, you are certainly right that there is no way to test a bridge for
>all possible conditions. The important point is that you can test it
>for its *basic* requirement, which is to carry weight (for a long time
>under normal environmental conditions).
>
>Dianelos wrote:
>>>No such test is known for ciphers. Cryptography is the only
>>>engineering field I know of, where you cannot actually test to see if
>>>what you build fulfils its design requirements.
>
>>Actually, I suspect that most engineering fields are like that --
>>it's a dictum in CS that "testing can never show the absense of bugs,
>>only their presence." I've already discussed civil engineering.
>>Chip testing is known to be only partially reliable in e.e. I don't
>>think we need to discuss aerospace engineering after recent events.
>>What type of engineering *were* you thinking of?
>
>Again, you can check to see if a plane flies most of the time, or
>whether a chip correctly computes most of the time. A cipher can suffer
>a catastrophic failure of a global scale and we cannot really test
>against that.
A "catastrophic failure of a global scale?" I'm not sure I understand
what you mean by this. Cryptographic systems don't fail all by themselves;
it's a difficult task, requiring a fair amount of expertise and skill,
to make a (properly used) cryptosystem fail.
So, yes, you can check whether a plane flies "most of the time" as long
as by "most of the time" you mean "under idealized, non-hostile situations."
But for a fighter plane, this isn't the interesting bit of time nor is it
the time that you are interested in. I can similarly prove that an
airbag "works" the 99+% of the time it's sitting quietly in the dashboard.
The only way we know to test whether or not an airbag works is by
simulating various sorts of events and hoping that it deploys properly.
Similarly, to test whether a cryptosystem works, we simulate various
attacks and see whether or not the system stands up to them. But just
as an automotive engineer can't test all the events in the world, neither
can a cryptographer.
>I think there is a big difference in degree. It is certainly imaginable
>that in the next 50 years somebody will publish a result that renders
>the AES, or RSA, or KEA, or whatever other critical standard there may
>exist then, useless. As a result of this a big crisis in the world
>financial and commercial system might develop. Now, it is not really
>imaginable that something will happen in the next 50 years that will
>make most bridges of the world crash down at the same time, or make
>most plains stop flying, or most computer chips stop working.
Obviously, you've never heard of the EMP bombs? Or, heck, the Y2K bug?
Bridges, being a little bit lower tech, are more likely to withstand
EMP bombing, but they're really sensitive to earthquakes.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Peter Galbavy)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 14 Oct 1999 13:02:17 GMT
Reply-To: [EMAIL PROTECTED]
In article <7u2q7m$9kp$[EMAIL PROTECTED]>, SCOTT19U.ZIP_GUY wrote:
> Well Mr BS is everyone supose to kiss your butt becasue you
>bragg about talking to the NSA. I personnel think that that
>was a low trick. Almost as low as your spamming. I really
[drivel deleted]
I respect Bruce because of the work he has done, the excellent book
"Applied Cryptography" that helped me understand lots of stuff, and
general helpful nature of his comments and posts. You one the other
hand are a sad example of an egotistical timewaster who doesn't appear
to be able to justify there use of the oxygen on this planet. Sod off.
Regards to the rest of the group,
--
Peter Galbavy
Knowledge Matters Ltd
http://www.knowledge.com/
------------------------------
From: Gabriel Belingueres <[EMAIL PROTECTED]>
Subject: Re: Should RC4 be free?
Date: Thu, 14 Oct 1999 13:01:29 GMT
In article <7u2fp8$gau$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
> In <7u20g9$l0a$[EMAIL PROTECTED]> Gabriel Belingueres <[EMAIL PROTECTED]>
writes:
>
> ]In article <[EMAIL PROTECTED]>,
> ] Paul Koning <[EMAIL PROTECTED]> wrote:
>
> ]It was done by reverse engineering the code. As far as I can tell,
> ]copyright laws don't protect code from reverse engineering in US. The
>
> This has nothing to with copyright laws. copyright laws are there to
> encourage people to publish,and the point of publishing is to allow
> people to read.
I disagree. Copyright laws are not intented to encourage people to
publish. They are intented to protect the investment and effort of
somebody for bringing your invention to the world. New inventions
satify people needs, and if you want to ever get paid for selling your
product or service, you need legislation to protect you. Of course,
copyright office need some publication or specification or a machine
that prove you have something witch not exist by the moment. In the
crypto case, you need to show a new encription method, togeter with a
*machinery* to show it works (ie, some source code).
>
> ]ILLEGAL thing could be explained with an analogy: If you walk along
the
> ]street and you find a house with an unlocked (or an open) door, you
can
> ]go in, open the refrigerator and still some beers, go out and close
the
> ]door. Besides the damage you could be done into the house, you know
from
> ]the school and your parents that doing that is bad. Technicly, there
is
> ]nothing wrong with get into a house and drink a beer. You just know
that
> ]in that circumstances, you can't do that.
> ]With the algorithm happens the same thing. You know that it is a
trade
> ]secret, ie. the source code isn't revealed (until that time, anyway)
and
> ]you get into the dissassembler to know how it works. Besides it is
not
> ]technicly illegal (in US at least), private property has to be
respected
> ]as it is.
>
> extrememly bad analogy. The person doing the reverse engineering owned
> that copy of the program. To use your analogy, it is like the
> refrigerator company telling you you aree not allowed to look into the
> your own fridge but just feel around in there for your food.
> Numerous court cases have stated that reverse engineering is a right
of
> the owner of a product.
The right of the consumer is to know what he/she is paying for. You
could use reverse engineering to know how the machine works. What you
can't do is publish it to the world, claiming to have discovered a
similar, interoperable machinery, such as the ArcFour algorithm, when
we all that ArcFour is nothing else than RSA's RC4.
> Would you consider a situation in which Starbucks took any other
company
> who opened a coffee bar in some city to court because Starbucks has
the
> idea first to open a coffee bar there? After all they had the idea
first
> and should be allowed to reap the benefits of their brilliant insight.
> "Coffee bar" should be their right, and noone should be allowed to
take
> away their customers. Think how many millions of dollars Starbucks has
> lost because other companies stole customers who should by rights be
> theirs! Although such thinking can have some appeal, experience has
> indicated that allowing competition has far greater benefits to
society
> than does granting legal monopolies. Unfortunately the naive appeal of
> the former system has blinded people in the area of software.
There is nothing wrong with protecting the software. Producing good
software cost a lot of money!
The "Coffe bar" thing you describe above is a more subtle subject. What
would happen if I could register my new line of products: "Good
Morning", "Good evening" and "Good Night". Anyone that uses that words
on TV would have to pay me!! (not a bad idea at all :)
In my country (Argentina), a popular TV show copyrights the sentence "If
you want to cry, just cry". No body could say it (without paying!). I
think that inventions have to be "measured" in quality. How?
Regards,
Gabriel
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 14 Oct 1999 14:10:30 +0100
Bruce Schneier <[EMAIL PROTECTED]> wrote:
: * Using information about timing, power consumption, and radiation of
: a device when it executes a cryptographic algorithm, cryptanalysts
: have been able to break smart cards and other would-be secure tokens.
: These are called ``side-channel attacks.''
What kind of research is there into combatting side-channel attacks?
Granted, an adequate form of protection might be too un unwieldly for a smart
card, but it might help in other contexts.
: * By forcing faults during operation, cryptanalysts have been able to
: break even more smart cards. This is called ``failure analysis.''
: Similarly, cryptanalysts have been able to break other algorithms
: based on how systems respond to legitimate errors.
Similarly, what kind of defence is known against failure analysis, in
a broad sense, not just covering smart cards?
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: classifying algorithms
Date: Thu, 14 Oct 1999 14:19:26 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <7u1kjk$ckm$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (wtshaw) wrote:
> > > I
> > > refer to such cipher as *inductive* that can produce a plethora of
> > > different outputs for a single input block with the same user
> > > keys.
> >
> > There seem to be many dualistic dichotomies that are isomorphic
> > to the stream vs. block pardigm like deductive vs. inductive.
>
> Fair question. Inductive is going from the specific to the
> general, while deductive is going from the general to specific.
> These words came closest to the spirit of what I meant, a
> plaintext being able to give rise to many
> outputs as inductive, and the solution of varied equivalent
> ciphertexts as deductive.
That's an interesting way of putting it. Sort of a parametrization
of the plaintext. Is this an orthonormal projection ?
Can say one of the tomographic reconstructions be used
cyptoanalytically, like the Radon transform or maximum entropy,...?
Tomographic reconstruction:
http://www.strauss.lanl.gov/outgoing/Gedanken/introtomaxent/levineTutori
al.html
Radon transform (or more generally see Manfred Schroeder's book
Fractals, Chaos, Power Laws):
http://www.sns.ias.edu/~max/radon.html
Here I am reminded of a problem I have with functions and distributions.
We normally treat a function as if it were a stream with time
as its fundamental parameter. In physics for example x(t) is a
function of position parametrized by time. Similar functions
exist for electric fields amplitudes etc., all parametrized by
time. Many of these are continuous measures but some are modular,
like phase.
If we jump over the Fourier fence into the frequency domain,
there are analogous complementary "distributions" for those
"functions". For instance the complement of position(time) is
momentum(frequency). But more fundamentally, the distribution
is a parametrization over "space" in the frequency domain:
Interpretation of the distribution:
http://www.spd.eee.strath.ac.uk/~interact/FFT/fft/results.html
and this is in a sense true in terms of whether we view memory as space,
or the relative positions of frequencies in a spectrum as
distributed over space.
In general, histograms are arbitrarily orderable in terms of the
"spatial" parameter of these finite distributions. We get Zipf's law
for instance, by sorting a finite distribution on frequency to
get the rank.
But there are many cases where there is an implied ordering.
Particularly in the spectrum of colors (ROYGBIV), but also
in diffraction patterns (which are based not on continuous
parameters like frequency, but on modular parameters like phase).
Associative aliasing in dynamic time warping:
http://www-ict.its.tudelft.nl/html/education/courses/et10-38/hc/hc9/sld0
18.htm
These are the things I think about when you describe such an
encryption method, and I'm wondering whether the tools for
dealing with these seemingly related areas, are somewhat
the same.
Such things as primality are of great concerned for instance in
the reduction or tomography in a decimation:
http://www.eptools.com/tn/T0001/INDEX.HTM
> >
> > I'm not sure what you mean by different outputs here, are they
> > intermediary like recursive results ? Iterative vs. recursion
> > might also be an analog for stream vs. block ?
> >
> Think of the process in the algorithm yielding a spiral, not acting
> is a
> recursive circle; some lengthening is necessary from plaintext to
> ciphertext, but it is slight. No other equivalent ciphertext can be
> derived from another ciphertext.
>
> We have been down the road of trying to classify the thing
> before. Ritter
> and I agree that it is something different from the two categories as
> familiary defined, and exhibits special characteristics not in either
> simple definition. There are even old ciphers that have a
> limited ability
> to produce homologs in ciphertext, including the Granpre,
> amongst others.
> But, this creature is different.
>
> Pardon the example, but here is one using these words as plaintext:
>
> {($+/1C9Z$>;%<<%+64Z]?K$.)(@;%&^+F[E4M.2H/"IU[V?@S$;
> QS^`M|[220GSUCXPC([0BD#WJQ~ }
>
> {X+ZRH0AM]Y(&01####]8R1^VO`!5!`RAC_6|NM"<+R%';&X$!/U
> )':Q0GA!NV<R1^_]PRX,,NT6S"~ }
>
> {>="=!;2#&5)*Y:W<D&'^-+3G0(!^D=#6J^D-YMUK=M|?3&`$2^M
> %P!7\"E3N_2.|!ED$\&T,0QGA(~ }
>
> The above using one implementation represent only 3 of 2^54
> possible cipher texts. For quick results I used the same
> words hashed three different ways to make the keys. The
> maximum length of each output block
> is 200 characters from a 65 character set. It is a variable
> length block
> cipher, as I see it, with different blocks from the same message
> being entirely different problems.
Are these overlapping variable length blocks ? Here, I'm
wondering about orthogonality problems and how they relate
to entropy.
> There are two keys needed, one made of 200
> alphabets of 65 characters, and one of 1 to 8 characters from a 64
> character set.
> --
> Truth lies in your path for you to stumble over,
> even if you think you can easily sidestep it.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
