Cryptography-Digest Digest #410, Volume #10 Thu, 14 Oct 99 09:13:04 EDT
Contents:
Re: where to put the trust (wtshaw)
Re: where to put the trust ([EMAIL PROTECTED])
Re: where to put the trust (wtshaw)
Re: classifying algorithms (wtshaw)
Re: A Question About DC-nets (David A Molnar)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Roger
Schlafly")
Re: crypto papers (again) (Gurripato)
Academic position in Switzerland (Serge Vaudenay)
Re: RSA Algorithm (Bo D�mstedt)
HELP on Kerberos and SSH (Adam Karaszewski)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Brian
Gladman")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Brian
Gladman")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: where to put the trust
Date: Wed, 13 Oct 1999 23:18:38 -0600
In article <7u1nvn$erj$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Looking for expertise which cannot exist seems a rather
> futile exercise, even if we collect as many opinions as we
> can. Reality is not a vote.
>
Reality as some speak means something objective and true. Too many wish
to surplant it with some form of politically defined smoke and mirrors
sort of reality, forgetting the other kind.
--
Truth lies in your path for you to stumble over,
even if you think you can easily sidestep it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: where to put the trust
Date: Thu, 14 Oct 1999 04:54:41 GMT
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.
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.
The degree of trust we can have that a cryptographic primitive will
fulfil its basic purpose during its lifetime is really not comparable
to the degree of trust, based on basic testing, we do have about most
other machines we build. I think there is a legitimate problem here,
but I also think there are practical ways to solve it:
In the future networked world we do need standard primitives, but we
can also have standards in place that allow us to "instantly"
substitute a primitive that is about to suffer catastrophic failure
with another more robust standard. In this way we can have "variable"
standards that can be changed quickly if necessary. Basically, the idea
is to convert encrypted data into objects that include pointers to the
methods needed for their processing. We can then build a menu of
different primitives and keep them in reserve. If a new type of attack
is announced (but not yet published) that renders a current standard
useless, then NIST (or whatever other standards body we have then) can
quickly check our menu against this new attack, find which primitive
works best, and simply replace the old standard. All new messages will
point to the new standard and future communications will be secure. No
world wide loss of confidence. (By the way, if we build a standard
designed to quickly replace a standard cryptographic primitive, we
could actually test to see if it works.)
Of course, this is not a perfect solution. Systems based on hardware
will be left out (or maybe chips could have security primitives
implemented in loadable microcode?). Old messages will be compromised.
Saved data will have to re-encrypted (but again automatic contingency
plans can exist to simplify this). Maybe there are better solutions
than the one I propose. Anyhow, instead of insisting that there is no
problem at all with the basic strength of our standard primitives, I
think it would be best to prepare for the worst case scenario.
Catastrophic failure of a standard primitive is not really that
unlikely to happen, and if it does and we are unprepared then the cost
of the Y2K error will look like a trifle. After all, standard
cryptographic primities may very well be the most common algorithms
executed in the future.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: where to put the trust
Date: Wed, 13 Oct 1999 23:38:12 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> Patrick Juola wrote:
> > ... Yes, chemists make mistakes. But that doesn't mean
> > that it's foolish to believe the results of chemical assay.
>
> That's because chemistry is solid science, whereas expert
> public cryptographer opinion is very mushy science at best.
> If a chemist said such things as "I don't know what's in
> that vial, but I guess it's amyl nitrate because nobody has
> yet published any paper saying otherwise," you'd think he
> was incompetent.
They are not all as careful as a Quincy. How many here have actually made
it through a course something qualitative analysis? I have. Scales for
obscure qualities, turning them into quantities, look impossible until you
learn to get down to the basics, learn to get precision and accuracy. I
apply the same techniques any way that I can.
--
Truth lies in your path for you to stumble over,
even if you think you can easily sidestep it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: classifying algorithms
Date: Wed, 13 Oct 1999 23:38:40 -0600
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.
>
> 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. 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.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: A Question About DC-nets
Date: 14 Oct 1999 07:12:57 GMT
I remember some people on the cypherpunks mailing list were involved in
creating a DC client which worked over IRC a few years back. I do not know
what happened to it. You could try the Cypherpunks archive to see if
anything pops up (hotbot tends to hit it fairly well)
-David
Aaron Swartz <[EMAIL PROTECTED]> wrote:
> Are there any good sources for information on DC-nets? I've read all the
> usual suspects: The Chaum Paper; Dining Cryptographers at the Disco; Applied
> Cryptography. Has there been any work done on creating one? Any information
> you can provide would be greatly appreciated.
> Thanks,
> Aaron Swartz <[EMAIL PROTECTED]>|<http://swartzfam.com:81/go/echelon>
> <http://www.swartzfam.com/aaron/>|Digital Nuclear Bomb to hit Echelon
> <http://www.notabug.com/aaron/> |Inciting Crypto Anarchy with DigiCash
> ICQ: 33158237 | AIM: Jedi of Pi |Tapping civilian communications
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 00:40:48 -0700
Sundial Services <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Seems to me that being an AES finalist makes yours a pretty darn good
> crypto-system, worthy of consideration, and that being selected as
> "numero uno" means only that "if you HAVE to choose just one ..."
Yes, that's right. Those who subscribe to the theory that
it is better to use your own homebrew combination of
ciphers can just use the AES finalists. Everyone else will
just use the AES winner.
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Subject: Re: crypto papers (again)
Date: Thu, 14 Oct 1999 07:18:39 GMT
On Wed, 13 Oct 1999 18:17:48 GMT, Tom St Denis
<[EMAIL PROTECTED]> wrote:
>Ok so going thru email is slow.... just get this 22mb zip if you want lots of
>cryptopapers....
>
>http://www.cell2000.net/security/pb/papers/crypto_papers.zip
>
>It contains almost 200 papes (in PS and PDF format) describing mainly block
>ciphers, cryptanalysis, but there are a few number theory discussions.
>
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
------------------------------
From: Serge Vaudenay <[EMAIL PROTECTED]>
Subject: Academic position in Switzerland
Date: Thu, 14 Oct 1999 12:14:20 +0200
EPFL is currently hiring researchers working on security and cryptology.
It
is mainly looking for short term postdocs (one or two years) but can
also
consider hiring senior researchers. Salaries for postdoc in EPFL are
quite
competitive, but highly depend on the background.
EPFL is a Swiss federal school with about 8,000 people including 4,500
students. (See www.epfl.ch.) Its location is in Lausanne, the Olympic
Capital, which is located in French-speaking Switzerland by the Leman
lake, on the feet of the Alps (see www.lausanne.ch as well as
www.lake-geneva-region.ch). Since EPFL is quite international, speaking
French is not mandatory.
The purpose of these positions is to make a new research group on
security
and cryptography in an academic environment. Involvement in research
projects and industrial cooperations will be required. The group will
first
consist in 5 positions including Prof. Vaudenay. It is included in the
new
Department of Communication Systems which will birth on January 1st,
2000
(see sscwww.epfl.ch). This forthcoming department currently includes a
dozen of professors specialized on network protocols, distributed
systems,
multimedia, circuits, mobile communications, electromagnetics,
information
theory, communication theory, ...
All candidates shall send motivation and curriculum vitae by email to
Serge Vaudenay at [EMAIL PROTECTED] after November 1st, 1999, or at
[EMAIL PROTECTED] before. The positions are to be taken immediately,
but it takes two or three months to go through the visa process for
foreigners.
------------------------------
From: [EMAIL PROTECTED] (Bo D�mstedt)
Subject: Re: RSA Algorithm
Reply-To: [EMAIL PROTECTED]
Date: Thu, 14 Oct 1999 11:53:53 GMT
[EMAIL PROTECTED] (Francois Grieu) wrote:
>IMHO the trend is opposite.
>
>In the early 1980's (before elliptic curve, MPQS and GNFS factoring
>algorithms) small keys, like 384 bits, seemed reasonably safe in
>the short term, as long as special generation techniques where used
>to guard against special factoring techniques, suceeding for example
>if one of the factor p is such that p-1 or p+1 is smooth.
[...etc...]
>reference: Robert D. Silverman, the requirement for strong
>primes in RSA encyption, RSA laboratories.
>at <ftp://ftp.rsa.com/pub/ps/primes.ps>
>or <ftp://ftp.rsa.com/pub/ps/primes.zip>
>[caution: strange Postscript dialect, view with Ghostscript]
>
> Francois Grieu
Thank you very much for the reference. It is not very
surprising though finding an RSA Laboratories employee
ridiculing special factoring methods.
One thing puzzles me - shift registers was used for various
applications a long time ago when hardware was still very
expensive. The properties of a shift register can be found
by factoring the number (2^n)-1. Published tables exist with
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 ?
How large is the largest number (2^n)-1 factored today?
Bo D�mstedt
Protego Information AB
------------------------------
From: Adam Karaszewski <[EMAIL PROTECTED]>
Subject: HELP on Kerberos and SSH
Date: Thu, 14 Oct 1999 13:27:37 +0200
I would appreciate any data on attempted attacks on Kerberos system or
SSH protocol. (From mathematical point of view they are believed to be
quite secure.) I'm both interested in 'practical' methods used and math
theory hidden beneath, as I'm gathering materials for presentation of use
of Theory of Numbers in modern day cryptography. (for Cryptography seminary
of which I'm a participant).
Successfull results are, of course, most interesting, even if the key to
success depended more on intrusion into system then math analysis - the
theory shound not wander too far from application.
If you are in possession of other interesting materials regarding
cryptology or cryptography, please let me know.
Adam Karaszewski
Student of math division
Warsaw university
e-mail: [EMAIL PROTECTED]
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 12:33:11 +0100
Roger Schlafly <[EMAIL PROTECTED]> wrote in message
news:7u41at$[EMAIL PROTECTED]...
> Sundial Services <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> Yes, that's right. Those who subscribe to the theory that
> it is better to use your own homebrew combination of
> ciphers can just use the AES finalists. Everyone else will
> just use the AES winner.
The arguments for multiple AES winners cannot be dismissed so easily. There
are at least three reasons for wanting more than one winner: (1) to provide
a degree of choice in dedicated, closed applications, (2) to provide a
degree of diversity in open applications (a well established practice), and
(3) to meet requirements that benefit from the sequential application of
different encryption algortithms (again an established practice).
Brian Gladman
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 14 Oct 1999 12:36:39 +0100
Sundial Services <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
> >
> > If they do that, the AES program will be a collossal failure.
> > They would have to rename it from Advanced Encryption Standard
> > to Advanced Encryption Removal Of Excessive Diversity Of Choice.
> > AEROEDOC, for short.
> >
>
> Seems to me that being an AES finalist makes yours a pretty darn good
> crypto-system, worthy of consideration, and that being selected as
> "numero uno" means only that "if you HAVE to choose just one ..."
I think that there are (at least) two potential problems with this approach.
The first is that we have five finalists and I am inclined to believe that
this would be an excessive number in terms of meeting the diversity
requirement. Too much diversity and too little diversity both have to be
avoided but exactly where to draw the line is a matter of judgement. My own
inclination is towards a maximum of three algorithms, not five.
Secondly, MARS and RC6 might not be free of IPR constraints if they are not
chosen as winners and this means that we may well remove some of the
contenders if we adopt an 'informal multiple winners' approach.
OTOH, Rijndael, Serpent and Twofish would get us down from five to three, so
maybe it would be no bad thing if MARS and RC6 ruled themselves out on IPR
grounds :-)
Brian Gladman
------------------------------
** 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
******************************
