Cryptography-Digest Digest #297, Volume #9 Mon, 29 Mar 99 14:13:03 EST
Contents:
Re: How do I determine if an encryption algorithm is good enough? (Patrick Juola)
Re: How do I determine if an encryption algorithm is good enough? (Patrick Juola)
Re: My factorising algorithm ([EMAIL PROTECTED])
Re: Is initial permutation in DES necessary? (Casey Sybrandy)
Re: Live from the Second AES Conference (Matthias Bruestle)
Re: IDEA Encryption (Norbert Hanke)
Re: Live from the Second AES Conference (wtshaw)
Re: Live from the Second AES Conference (John Savard)
Re: Is initial permutation in DES necessary? (John Savard)
Re: True Randomness & The Law Of Large Numbers (Jim Felling)
Re: RNG quality in browsers? (Mika Niemi)
Re: Random Walk (Jim Felling)
Re: Methods of exchanging Secret Keys ... (Robert G. Durnal)
Re: Is initial permutation in DES necessary? (John Savard)
Re: Prof Shamir, was: Live from the Second AES Conference (Reuben Sumner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: How do I determine if an encryption algorithm is good enough?
Date: 29 Mar 1999 08:55:45 -0500
In article <[EMAIL PROTECTED]>,
Ludvig Strigeus <[EMAIL PROTECTED]> wrote:
>Hi!
>
>> <<How can I test if this algorithm is easily crackable?>>
>> General rule: if you don't have years of experience making
>> cryptographic systems, then it is definitely easily crackable. (Even
>> then, odds are not so good. :-D )
>
>Maybe this one I've created is hard to crack, even though I have no
>cryptographic experience.
>
>You can't assume that it's bad, without examining it first.
Nor can I assume that hitting keys on a typewriter at random will
produce gibberish instead of clear, coherent, English prose.
But the odds are similar.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: How do I determine if an encryption algorithm is good enough?
Date: 29 Mar 1999 08:58:09 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Fri, 26 Mar 1999 15:44:37 -0800, Andrew Carol <[EMAIL PROTECTED]>
>wrote:
>
>>The odds greatly favor that people with experience in a field will
>>typically do better than those who have none.
>
>I agree with you in principle, but disagree with you in practice.
>
>Science has progressed only on the basis of disagreement with those
>who claim experience.
Re-read your Kuhn. The vast majority of scientific development
occurs in periods of "normal science" by skilled people refining
the existing paradigm. And for every successful new paradigm
proposed, there are literally thousands that don't stand up because
they can't account for the facts.
The gadflies lose. Every so often, one gets lucky and is remembered.
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My factorising algorithm
Date: Mon, 29 Mar 1999 12:08:20 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Martin Sykes) wrote:
> Hmm, looks like my algorithm isn't as fast as others for finding
> factors. I've got a load of numbers to test with now but does anyone
> have numbers which have been factorised with the quickest
> factorisation times for them so that I know what I need to aim for?
>
A better approach would be to analyze the complexity of your "method".
You did not give a full description, but if indeed it is a direct search or
difference of squares approach (using exclusion moduli) then it will be
strictly exponential time. Much better methods are known.
> Is my algorithm any good for proving that numbers are prime?
No. Once again, compare its complexity with that of ECPP or APR-Cl.
> Also, can anyone recommend a good sirte which explains what the basic
> problems people are trying to crack are. Factorising large numbers is
> one but I'm guessing there are others.
See:
R. Guy
Solved and Unsolved Problems in Number Theory
Springer-Verlag
>
> Comments?
May I suggest you read up on the subject of factoring algorithms?
In particular, read the chapter in Knuth Vol 2 as a starting point.
Until you do, you are probably just wasting your time.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Casey Sybrandy <[EMAIL PROTECTED]>
Subject: Re: Is initial permutation in DES necessary?
Date: Mon, 29 Mar 1999 09:11:20 -0500
The purpose of the initial and final permutations was to make it more efficient in
hardware. It does nothing for security at all. You can look in Applied
Cryptography on page 271 for a more detailed description
Casey
Christoph Haenle wrote:
> [EMAIL PROTECTED] wrote:
> : Hello cryptographers,
>
> : It seems to me that initial permutation in DES is unnecessary since everyone
> : knows exactly what the permutation is. Does anybody know the reason why DES
> : specify a known permutation? Is the initial permutation there to permute a
> : certain bit pattern that can cause DES to reveal the key?
>
> : Thanks a lot,
>
> : -galaknight.
>
> : -----------== Posted via Deja News, The Discussion Network ==----------
> : http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>
> The permutation is not done for security reasons. Rather, it is
> supposed to make DES implementation slower in software. However, when
> using 3DES, it could make a difference (in security) whether EDE or
> EEE is used, even when using three different keys (when using EDE, the
> permutations between E and D and between D and E won't disappear as
> opposed to the EEE scheme). As far as I know, nobody has ever proven
> whether of not the permutations strenghens 3DES.
>
> -Chris.
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: Live from the Second AES Conference
Date: Mon, 29 Mar 1999 14:06:11 GMT
Mahlzeit
Bruce Schneier ([EMAIL PROTECTED]) wrote:
> I agree with this, and I suspect that most cryptographers would.
> While it cannot be proven that a cascade of A B is no more secure than
> A, and could possibly be weaker than A, in realilty that just won't
> happen. Your analysis is sound.
If A/B is weaker than A alone, doesn't that mean, that an attacker can
weaken something which is encrypted by A by encrypting it again with B?
Then A/B would again be at least as secure as A.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
Take my mind
All the way
The darkside calls
I shan't resist
------------------------------
From: [EMAIL PROTECTED] (Norbert Hanke)
Subject: Re: IDEA Encryption
Date: Mon, 29 Mar 1999 13:47:13 GMT
On Thu, 25 Mar 1999 23:03:56 +0100, Curious George
<[EMAIL PROTECTED]> wrote:
>Where can I find a source code of IDEA Encryption? Is IDEA the
>strongest encryption right now?
try http://www.ascom.ch/infosec/downloads.html
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Live from the Second AES Conference
Date: Mon, 29 Mar 1999 07:30:46 -0600
In article <[EMAIL PROTECTED]>, "Lassi Hippeläinen"
<[EMAIL PROTECTED]> wrote:
> Bruce Schneier wrote:
>
> > <...>
> > While it cannot be proven that a cascade of A B is no more secure than
> > A, and could possibly be weaker than A, in realilty that just won't
> > happen. <...>
>
> I have a pragmatic proof (i.e. good enough for an engineer):
>
> Assumption: A and B are secure ciphers.
> Claim: Chained A & B is at least as safe as A or B alone.
> Proof: If not, A is a crack of B or vice versa, which violates the
> assumption.
>
If the two are used with the key in common, than you are only testing the
one common key, not nessarilly the mutual security of the algorithms with
different keys. Key structure might make one key equivalent to another
one with the other algorithm, so then, a single key might act like
separate keys.
--
Ethnic clensing does not appear to be a response to a high moral calling.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Live from the Second AES Conference
Date: Mon, 29 Mar 1999 16:26:28 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>The 6805 came out *after* both the 6809, which I helped design, and
>the 68000, which started the 16-bit era for Mot. Thus, the 6805 never
>was "an expensive processor," and as far as I know, nobody was foolish
>enough to use it as the heart of a desktop computer.
Doubtless, Bruce just had a slip of memory, and he meant "6502", which was
used in a number of famous desktop computers.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is initial permutation in DES necessary?
Date: Mon, 29 Mar 1999 16:10:14 GMT
[EMAIL PROTECTED] (Richard Outerbridge) wrote, in part:
>In article <7dnkfn$[EMAIL PROTECTED]>, Christoph Haenle <[EMAIL PROTECTED]> wrote:
>>However, when
>>using 3DES, it could make a difference (in security) whether EDE or
>>EEE is used, even when using three different keys (when using EDE, the
>>permutations between E and D and between D and E won't disappear as
>>opposed to the EEE scheme).
>They can be completely dispensed with. All that changes between
>E and D is the key schedule. IP-1((IP(x)) = IP(IP-1(x)) = x.
You are correct. Since the final permutation is the exact inverse of the
initial permutation - that's why the final permutation is called the
"inverse initial permutation" - as you say, only the subkeys are reversed
in going from DES encryption to DES decryption, and both permutations
remain the same - and cancel out in either form of triple-DES.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Mon, 29 Mar 1999 12:42:57 -0600
"R. Knauer" wrote:
> As Professor William Feller of Princeton University states in his book
> on probability theory (op. cit), p.152ff:
>
> [emphasis his]
>
> +++++
> *Warning*: It is usual to read into the law of large numbers things
> which it definitely does not imply. If Peter and Paul toss a perfect
> coin 10,000 times, it is customary to expect that Peter will be in the
> lead roughly half the time. *This is not true*. In a large number of
> *different* coin-tossing games it is reasonable to expect that at any
> *fixed* moment heads will be in the lead in roughly half of all cases.
> But it is quite likely that the player who ends at the winning side
> has been in the lead for practically the whole duration of the game.
> Thus, contrary to widespread belief, the time average for any
> individual game has nothing to do with the ensemble average at any
> given moment.
> +++++
>
> That last sentence gives the fundamental reason why I claim that
> statistical testing is not valid for deciding either true randomness
> or non-randomness of a TRNG process. Consider this example.
>
> You build a TRNG and output an n-bit sequence. According to what is
> being claimed, you cannot submit that sequence to statistical tests to
> determine if the TRNG is either truly random or not truly random. The
> best that you can hope for is that such statistical tests will give
> you a diagnostic warning that the TRNG *might* be random or
> non-random.
>
> Here is what the law of large numbers is all about. It is not about
> any one particular sequence from one particular TRNG - that is the
> time average as the number of bits increases. The ensemble average, on
> the other hand, which the law of large numbers addresses, is obtained
> by outputting n-bit sequences from N separate but identical TRNGs.
>
> Here is an experiment to illustrate that point: Imagine a piece of
> square tubing with one side removed, which is much longer than the
> dimension of the sides. IOW, you have a long narrow U-shaped trough.
> Seal off the ends and put water in it. Now place a tiny drop of ink at
> the center of the trough, and observe as the ink diffuses thru the
> water.
>
> Each ink molecule undergoes a random walk caused by the many random
> collisions of water molecules. After a large number of steps the ink
> has spead out - so stop the experiment when ink just is about to reach
> the ends (you have to do that because otherwise the ink will "reflect"
> off the ends and confuse the results prior to that event).
>
> Now consider the equence of steps for one given ink molecule to be the
> same as the output sequence of one particular TRNG, and the collection
> of all ink molecules as the ensemble of many TRNGs. Here are two
> observations:
>
> 1) Most individual sequences (i.e., random walk paths) end up a
> considerable distance from the origin. IOW, the spatial distribution
> is relatively flat although it is really a Gaussian. IOW, most
> individual paths are "abnormal" in terms of the mean behavior of the
> ensemble.
>
> 2) There is a symmety to the distribution about the mean, namely the
> center where you placed the initial drop of ink. For each "abnormal"
> path on the left, there is an identical "abnormal" path on the right,
> which together give an ensemble average at the mean, i.e., the center.
>
> In terms of random number generation, statisitical tests based on the
> law of large numbers cannot tell you anything about any particular
> sequence. All they can relate to is the ensemble average taken from
> sequences of a large emsemble of identical TRNGs.
>
> As a specific example, consider a TRNG that generates a run of 100
> zeros. If you apply statistical tests to that run you might conclude
> that the TRNG is not truly random, because there is only a 1/2^100
> chance for that to happen. But such thinking is incorrect.
That statement of probability is correct in the overall ( ensamble) view,
but in the view of what actually happened it is in error.
However, If such a string came out of my TRNG I would immediately and
thoroughly check my machine, because the odds of my machine having visited
that corner of sample space by chance are substantially lower than the
odds that somehow somewhere there is a glitch in my machine's physical
componentry or my implementation of a TRNG.
>
>
> The correct thinking is as follows. If you were to generate N
> sequences of 100 bits each using N identical TRNGs, the probability
> that there is a run of 100 ones which balance a corresponding run of
> 100 zeros will tend to unity as N becomes large. That does not say
> that there will be NO runs of 100 zeros (or 100 ones), it just says
> that there will be an equal number of runs of each type as N gets
> large.
>
> That's the same as saying that the ink will spread out to the left as
> much as it will be spread out to the right. It does not say that the
> ink will stay close to the origin for all time.
>
> Since for even 100 bit runs, the minimum ensemble is astromomically
> large - of order 2^100, and since it is literally impossible to apply
> statistical tests to that many sequences, I conclude that statistical
> testing for randomness or non-randomness for a TRNG is impossible, and
> the best we can hope for is to use statistical tests as diagnostic
> warnings.
>
> I realize that the Strong Law Of Large Numbers puts quantitative
> limits on the confidence one can assume for given ensemble size. But
> that does not preclude the existence of a large fraction of "abnormal"
> sequences in that ensemble. All it tells you about is the
> pseudorandomness of an ensemble, not the true randomness or
> non-randomness.
>
> Even for 10 bit sequences, where runs of 10 zeros is not all that
> unlikely, emsemble averages to test for true randomness requires of
> order 1 million sequences of 10 bits. And 10 bits is not very many
> bits for a typical keystream in crypto.
>
> Using statistical tests to characterize either the true randomness or
> non-true-randomness of a true random number generator is snake oil for
> any reasonably sized keystream.
>
> I welcome any civilized comments on this. Flames will be ignored.
>
> Bob Knauer
>
> "What right does Congress have to go around making laws just because
> they deem it necessary?"
> - Marion Barry, Mayor of Washington DC
------------------------------
From: Mika Niemi <[EMAIL PROTECTED]>
Crossposted-To: comp.infosystems.www.browsers.misc
Subject: Re: RNG quality in browsers?
Date: Mon, 29 Mar 1999 10:33:16 -0600
Sassa wrote:
>
> hi
>
> > For browsers, we can assume that the RNG algorithm itself is not secret.
> > If a 32-bit seed is used, it is easy enough for an attacker to generate
> > a dictionary of all the 128-bit keys that the browser can create, by
> > going through all the 2^32 seeds.
>
> if browser uses the only RNG, then yes.
>
> but if it uses a "battery" of RNGs - then hardly yes...
>
> > Mika Niemi
Sorry, I am probably still not able to get your point. I have some
observation on your description though:
If we take the set of 128-bit blocks generated by a pRNG, these might
cover the whole 2^128 keyspace, even if there is less randomness initially
input into the system. This will take at least 2^128 uses of the pRNG,
however, which is not practical. Even 2^30 uses of a browser is unlikely
in a person's lifetime (and even more unlikely in a browser's lifetime),
so the initial values ouput from the pRNG are the ones that matter.
Your RNG (which uses 5 RNGs in it its implementation) has a "state" of
160 bits. Is this state to be stored on the user's harddisk, so the
pseudo-random sequence continues between uses of the browser?
How this 160 bits of state is derived from physical sources of randomness
(such as the system clock) is important as well. This seed should not be
taken from the system clock directly, relying on the algorithm to make it
random. Since the pRNG algorithm (essentially a deterministic process)
cannot be assumed to be secret, the attacker can narrow down the space of
his search, by assuming some accuracy on the clock used.
What I am saying here is that key generation and management is nowadays
one of the most important, if not the most important, issues of practical
cryptography. We have known for decades that crypto algorithms proven to
be unbreakable exist, if it weren't for key management. Generating a
128-bit key should not be done with a pRNG at all, if a source of
hardware randomness is available.
Mika
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Random Walk
Date: Mon, 29 Mar 1999 10:57:46 -0600
"R. Knauer" wrote:
> On Fri, 26 Mar 1999 15:55:39 -0600, Jim Felling
> <[EMAIL PROTECTED]> wrote:
>
> >I want to cull as seldom as possible without having some inherent weakness in my
>output.
>
> I believe what you are saying is that you would not let statistical
> tests determine whether a TRNG is malfunctioning or not.
> ]
> I concur with that correct judgement.
I would allow them to determine when my TRNG is malfunctioning -- however, they would
not be
the sole piece of evidence considered, and would also not be regarded as being 100%
authoritative.
>
>
> True randomness is a concept that is intimately tied up with the
> concept of the infinite - where it is perfect. The fact that it is
> manifest in the finite is something that is not easily explained away
> with probability theory.
>
> The transition from the finite to the infinite is not smooth, but
> discontinuous. Yet the finite shares properties with the infinite.
> Truly amazing, eh.
>
> >Another thing is if a long run or other bad data
>
> Why would you consider a long run as "bad data"? There is nothing
> "bad" with a long run. In many ways, we humans are "bad data" - data
> which defy the odds.
Bad data is any data that just due to its nature provides some possible point of
weakness. As
I have said any tool that allows a successful attack -- no mater how unfounded that
attack is
-- is useful against the encryption.
>
>
> I just finished watching some incredible golf. I am not a fan of golf
> but that does not mean I will overlook the results of the game when I
> see them.
>
> I saw a hole in one - an absolutely incredible occurance. When I
> studied statistical mechanics in grad school, I calculated the
> probability that all the molecules of air would be in the corner of a
> room - it is astronomically small.
>
> A hole in one is also astronomically small when you calculate it, yet
> I saw one (not the first) and not only that, I saw two other golfers
> put the ball within a foot of the hole in one stroke. Yes, I realize
> that such occurances are rare. But still these events are not possible
> on the basis of traditional probability theory - they have
> "vanishingly small" probability, just like the unicorn that does not
> exist when the size of the herd gets "large".
>
> Clearly something is going on here that we do not understand based on
> traditional probability theory. I have no clue what it is. But
> whatever it is, it is very real as can be seen from direct
> observation. And it is at the very heart of quantum mechanics.
>
> >I cannot rule out the incidental
> >leaking ("Gee you won't believe this-- our TRNG just spit out 1000 1's in a row - I
> >diagnosed it and its working perfectly") thereby providing a potential targetable
>weak
> >spot in the TRNG stream.
>
> Is it really that weak?
>
> Here is the ciphertext: "ATTACK AT DAWN"
>
> Yet the real message is: "ATTACK AT DUSK"
>
> The key is the XOR of those two sequences.
>
> Which is the intended message?
That is a very specific situation. Versus a OTP the ability to recognize 7-bit ASCII
vs
8-bit binary data is a successful attack -- it allows some knowledge of what the
channel is
used for and can lead to further potential attacks such as -- this is probably ASCII
data so
apply the standard frequency tables to the data -- which could lead to the possibility
of
some limited data compromise.
Say it is a 60/40 bias-- then one has a good indication as to whether it is full
spectrum
data( in which case the high order bits will be distributed close to evenly) or ASCII
in
which case a definite bias to high order bits. This will allow an analyst to say that
this
data is ASCII with some confidence. Knowing this they can conceivably perform analysis
to
indicate the likelihood that the message is Message X vs. message Y. This while not a
full
break is a perfectly valid cryptoanalytic attack.
>
>
> I leave you with the fact that mathematicians onced proved that bumble
> bees could not fly, and also tried to legislate the value of pi =
> 3.10.
(Errr... Victorian era physicists performed the former (not mathematicians), and the
legislative measure -- which may or may not have been proposed by a math educator --
was
ruthlessly criticized by the math community.
( How is this related to the topic? )
>
>
> Greg Chaitin, a mathematician himself, has it right - mathematicians
> do not have a sense of humor - whereas physicists do. Maybe that is
> why I chose to be a physicist instead of a mathematican. I find a hole
> in one quite humorous because it is "improbable".
>
>
> Existence is improbable. Does that make it unreal?
>
No. On the other hand the facts of our existence do provide a very good attack toward
determining the physical nature of the space-time and physical law in our region.;)
>
> Bob Knauer
>
> "I am clearly more popular than Reagan. I am in my third term.
> Where's Reagan? Gone after two! Defeated by George Bush and
> Michael Dukakis no less."
> -- Marion Barry, Mayor of Washington DC
------------------------------
From: [EMAIL PROTECTED] (Robert G. Durnal)
Subject: Re: Methods of exchanging Secret Keys ...
Date: 29 Mar 1999 19:03:46 GMT
In <7dmso0$2qi$[EMAIL PROTECTED]>, "John" <[EMAIL PROTECTED]>
wrote:
: Hi
: Besides the obvious method in exchanging secret keys i.e. A tells B password
: or Public Key methodology for secret key exchange, are there any other ways
: that secret keys can be exchanged.
: Thanks in advance.
: John
See the description of the Shamir Three-Pass Protocol in AC2. I have coded
this in a 32-bit version (of course, that handles only 4 bytes at a time) and
have been working for about a year now on a multi-precision integer library
which would allow extension to more workable key sizes. You can D/L this as
3pass.pgp from my site(s), but will need to send me your PGP public key and
a statement of residence and citizenship in order for me to send you the
decryption key.
=============
My home page URL=http://members.tripod.com/~afn21533/ Robert G. Durnal
Hosting HIDE4PGP, HIDESEEK v5.0, PGE, TinyIdea (link) [EMAIL PROTECTED]
and BLOWFISH in both Windows and mini-DOS versions. [EMAIL PROTECTED]
EAR may apply, so look for instructions.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is initial permutation in DES necessary?
Date: Mon, 29 Mar 1999 18:32:58 GMT
Casey Sybrandy <[EMAIL PROTECTED]> wrote, in part:
>The purpose of the initial and final permutations was to make it more efficient in
>hardware.
The only way that would be true is if the hardware implementation worked
like the nonlinear S-boxes in 3-Way or SERPENT. Doing the DES S-boxes that
way would be really complicated; and, in hardware, the order of bits is
irrelevant.
I think that both the IP and IIP on the one hand, and Permuted Choice 1 on
the other (PC-2 is real) are there for a "conspiracy theorist" reason: the
NSA (and perhaps IBM) did *not* originally realize that the DES algorithm
would be made public, and they were there to obfuscate the algorithm.
Even though the _other_ charges levelled against DES have not been borne
out (except the one about the key being too short), that the NSA would not
have wished to comment on the security of an algorithm to be made public
doesn't seem like too fantastical a notion, and there is some anecdotal
evidence to that effect.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Reuben Sumner)
Subject: Re: Prof Shamir, was: Live from the Second AES Conference
Date: 29 Mar 1999 16:25:02 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 23 Mar 1999 01:19:57 GMT,
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The first paper was presented by Adi Shamir. I don't know whether
> Shamir is a teacher, but if he is then he must be a very good one
> indeed. First he explained about Paul Kocher's power attacks
Indeed I can assure you that Prof Shamir is an excellent teacher.
I have taken two one semester courses in algorithms taught by him
and am now taking the second of his one semester courses in
cryptography. He is faculty at the Weizmann Institute of Science
together with Professors Oded Goldreich, Shafi Goldwasser,
and Moni Naor. All very accomplished cryptographers, together
with other fields of research.
The Weizmann Institute of Science is located in Rehovot, Israel,
about a half hour's drive in clear traffic (rare) from Tel Aviv.
The institute is the home of the Feinberg Graduate School with about
700 MSc and PhD students from around the globe.
Courses and seminars at the Weizmann Institute are given
in English. All applicants accepted as full time students are given
housing plus a generous stipend. Application forms and other information
can be found at
http://www.weizmann.ac.il/feinberg/appforms.html
Further information about research in computer science taking place at
the institute can be found at
http://www.wisdom.weizmann.ac.il/~naor/foundation.html
Reuben
------------------------------
** 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
******************************
