Cryptography-Digest Digest #277, Volume #11 Wed, 8 Mar 00 12:13:01 EST
Contents:
Encryption (poss blowfish) ("Rob Kings")
c++ and java encryption libraries (Michael Burrows)
Re: Universal Language ("Lassi Hippeläinen")
Re: why xor?(look out,newbie question! :) ("Lassi Hippeläinen")
Re: Encryption (poss blowfish) (Tom St Denis)
Re: Crypto Speeds... (Runu Knips)
Re: Want to poke holes in this protocol? (Runu Knips)
Re: Want to poke holes in this protocol? ([EMAIL PROTECTED])
Cheating in co-operative open-source games, how can we protect from it? ("Peter
Henningsen")
DES Permutation ("DX")
Re: Cheating in co-operative open-source games, how can we protect from it? (David A
Molnar)
Re: NIST, AES at RSA conference (Bo Dömstedt)
des des3 for hp-ux c++ (Michael Burrows)
Re: DES Permutation (Doug Stell)
Re: DES Permutation (Stephen Houchen)
Where do I get it? (John)
Re: Security Features of Pokerspot.com (Lincoln Yeoh)
Re: Crypto Speeds... (Runu Knips)
Re: Cyberrella (John Savard)
Re: DES Permutation (John Savard)
Re: Cheating in co-operative open-source games, how can we protect from it? (John
Savard)
CONFERENCE ON NATURALISM -- FINAL NOTICE (Michael Polanyi Center)
Re: brute force attack on a 128 bit SSL key? (Richard Herring)
Some information security publications ... http://csrc.nist.gov/nissc/ ("Markku J.
Saarelainen")
----------------------------------------------------------------------------
From: "Rob Kings" <[EMAIL PROTECTED]>
Subject: Encryption (poss blowfish)
Date: Wed, 8 Mar 2000 11:23:56 -0000
All
I'm putting together some encryption routines, to hide medical data from
prying eyes. I was looking at Blowfish. I need to write in C as I want the
code to work on both a PC and on various Unix variants (DG-UX, AIX, etc.)
I've a number of questions.
1. When I look around the net, I find lots of examples of algorithms, but no
larger examples of how to encrypt a file. Anyone got any? (Must be pretty
'bog-standard' ANSI C)
2. Will the 'bit-ness' of the differing computers affect an algorithm? eg.
The file could be encrypted on a 64bit Unix box, and decrypted on a PC?
3. Same as 2 but with respect to the endion differences between most
non-intel machines and PC's
Thanks for reading this far.
Cheers
Rob
------------------------------
From: Michael Burrows <[EMAIL PROTECTED]>
Crossposted-To: alt.comp.freeware,comp.security.misc
Subject: c++ and java encryption libraries
Date: Wed, 08 Mar 2000 11:34:36 +0000
Hi
Please tell me if you know of convenient c++ and java cryptography
libraries that allow encryption in one language and decryption from the
other. The c++ will run on HP-UX.
Thanks
Mike
------------------------------
From: "Lassi Hippeläinen" <"lahippel$does-not-eat-canned-food"@ieee.org>
Subject: Re: Universal Language
Date: Wed, 08 Mar 2000 11:39:27 GMT
Mok-Kong Shen wrote:
>
> Tony T. Warnock wrote:
> >
>
> > music videos, and ugly rotating jewelry.) Those like Esparanto reflect
> > the tastes and more importantly the vocabulary of the creator. Esparanto
> > is very Euro-centric. This is not bad per se, but it makes Esparanto no
> > easier than Spanish, English, German, Deutch, French, etc. Learning one [snip]
>
> I agree with you. However, I think that it is possible to design,
> first of all, a grammar that is simple, i.e. rational and without
> exception rules, redundancies etc. etc. That could save much time
> of the learner.
But isn't Esperanto just like that?
> The vocabulary should also be well designed,
> making use e.g. of the knowledge of the AI people in dealing with
> classification of concepts etc. Then the words should be fairly
> short, to save writing efforts.
That's a tall order. The current spoken languages seem to disagree about
all possible models, and still have enough expressive power to cope with
the world. In English you can produce a verb out of everything
(including abbreviations...), whereas in Finnish you can derive a name
out of anything (including actions). And Chinese seems to be a
written-only language with several mutually incompatible phonetic
systems.
> Of course, phonetics is also
> important; a spoken word should not sound almost the same as
> another, thus creating ambiguity.
Add to that the requirement that pronunciation should have a one-to-one
mapping to spelling. Like Esperanto.
> I think that this is possible,
> though nobody is likely to have the willingless, funds, time,
> and other resources to undertake/join such project which does not
> create personal profits.
Zamenhof didn't get any money for developing Esperanto. (Hey - this is
getting like a philippic for Linux...)
> A universal language in this sense could
> to be easier to learn than any current natural language by
> foreigners by a substantial factor, I believe. On the other hand,
> creation of such as a 'standard' language for intercourse of all
> people having different native languages is probably next to
> impossiblity, if one recalls that in computer programming everyone
> has his favourite (so-called 'standard') language, despite the fact
> that the programming languages are very much simpler than natural
> languages and are designed from the very beginning to have conscise,
> rigorous and straightforward rules in aspects of syntax and
> semantics and consequently it would be relatively easily possible
> to create one universal programming langauge to substitute them all.
>
> M. K. Shen
Maybe the European Union will some day decide to use some artificial
language as the official language. That would cut the cost of
translations to a fraction. The more members (languages) join the EU,
the closer that date gets. Of course the official language would be just
a mediator layer, but if it were also useful in a spoken form it would
have an existence of its own.
Curiously enough, Esperanto rather than XML fits the bill. It even mixes
in nice proportions words from Germanic, Romanic, and Slavic languages.
-- Lassi (not an Esperantist)
P.S. That still isn't a Universal language. Not even global. Due to its
vocabulary, Esperanto is easier for indoeuropeans that for any other
people.
------------------------------
From: "Lassi Hippeläinen" <"lahippel$does-not-eat-canned-food"@ieee.org>
Subject: Re: why xor?(look out,newbie question! :)
Date: Wed, 08 Mar 2000 11:51:11 GMT
Mike Rosing wrote:
...
> Today bus width is the same or larger than the register width. So
> endianness doesn't matter.
...
...unless you are dealing with communications. The Internet, for
example, defines a "network order" that is always used to describe data
structures like protocol fields. And encryption keys and ...
-- Lassi
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Encryption (poss blowfish)
Date: Wed, 08 Mar 2000 12:02:37 GMT
In article <8a5dbi$drn$[EMAIL PROTECTED]>,
"Rob Kings" <[EMAIL PROTECTED]> wrote:
> All
>
> I'm putting together some encryption routines, to hide medical data
from
> prying eyes. I was looking at Blowfish. I need to write in C as I
want the
> code to work on both a PC and on various Unix variants (DG-UX, AIX,
etc.)
> I've a number of questions.
>
> 1. When I look around the net, I find lots of examples of algorithms,
but no
> larger examples of how to encrypt a file. Anyone got any? (Must be
pretty
> 'bog-standard' ANSI C)
>
> 2. Will the 'bit-ness' of the differing computers affect an
algorithm? eg.
> The file could be encrypted on a 64bit Unix box, and decrypted on a
PC?
>
> 3. Same as 2 but with respect to the endion differences between most
> non-intel machines and PC's
>
> Thanks for reading this far.
>
> Cheers
>
> Rob
For the purposes of endianess and bitness, you may want to consider a
stream cipher instead. They are much simpler and easier to use in this
respect.
As for encrypting a file, depends on whether your are using PK or have
agreed upon keys. In either case make sure you salt your key *each*
time you encrypt a file. Then you just fopen the file, read blocks,
encrypt, write and fclose both. Not too hard.
Tom
--
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 08 Mar 2000 13:17:38 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Crypto Speeds...
"D. J. Bernstein" schrieb:
> Um, do you realize who you're talking to? Eric's BN library (from
> OpenSSL 0.9.3) is faster than GMP 2.0.2 for 512-bit multiplication on
> both of the major Pentium lines.
Fine.
------------------------------
Date: Wed, 08 Mar 2000 13:20:15 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Want to poke holes in this protocol?
[EMAIL PROTECTED] wrote:
> Uh, I hate to tell you this, but it's not the small block size that is
> the reason DES can be brute-forced, it's DES's 56 bit key size.
> Blowfish does not neccessarily have this weakness because you can have
> keys up to 448 bits, thought typically seen using 128 bit keys.
Ouch. Hmm, somebody told me that blowfish isn't that secure. But I
can't remember who and why ... anybody ?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Want to poke holes in this protocol?
Date: Wed, 08 Mar 2000 13:23:25 GMT
In article <38c5afe1$0$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Edward A. Falk) wrote:
> I felt a little funny about the generation of the random session
> key at Alice's computer. I'd feel a little better if the bank
> threw in some randomness too. Why not D-H key exchange?
>
With DH you just have 1 secret key to use, or you have to keep
exchanging public keys, which can be even more vulnerable to attacks ?
Maybe if Alice adds the time and some random id to her first message,
and the bank keeps some logs, with a short-term replay attack the id
will show up in the log, otherwise the bank can check the time. The
bank could also send these back encrypted with K, so Alice knows she is
talking to the bank.
Mike
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Peter Henningsen" <[EMAIL PROTECTED]>
Subject: Cheating in co-operative open-source games, how can we protect from it?
Date: Wed, 08 Mar 2000 13:44:43 GMT
We would like to ask for your help in developing a cryptological protocol
that can be used to protect files from tampering by the user in co-operative
open source games/virtual worlds. Specific ways of cheating that we want to
guard against are falsifying of game scores, creating God-characters by
hacking code instead of earning similar status in the game world, or
tainting an evolutionary process in a virtual world by falsely propagating
and promoting artificial life entities. In all these cases, files on the
user's computer must be protected from tampering by the user himself. Since
we are developing free games, and cannot afford to do much processing on
central servers, it is not an option either to run the code on a server for
protection.
We simply do not see a way to protect such files if the source code is
accessible to the user. If you do, please respond directly to
<[EMAIL PROTECTED]>. The best solution we have come up with is to encrypt
the files in the following manner, keeping the code for the encryption
process in a separate module for which source code is not released.
1. There is an encryption algorithm and a fixed, constant key.
2. When the user registers his registration number, this number is used to
generate an individual key, which is encrypted using the constant key, and
hidden somewhere in a data file.
3. When the program is run and a sensitive data file is changed, the program
appends a hash value (generated using the individual key) and encrypts the
file using the individual key.
4. Before the files can be accepted as authentic by a server or peer, they
must be validated by a server, which will generate the individual key based
on the registration number of the user, decrypt the file and check the hash
value to either accept or reject the file.
We believe that the simplest way to break this process would be to
decompile the object code and retrieve the source for the encryption
process, and we believe that any form of protection we could come up with
could be defeated by the same form of attack, so the process would be
optimal in that sense. However, nobody here is an expert in cryptology, and
if you see something we do not, please respond.
Dr. Peter Henningsen
alifegames.com
------------------------------
From: "DX" <[EMAIL PROTECTED]>
Subject: DES Permutation
Date: Wed, 8 Mar 2000 22:17:34 +0800
To all the cryptoreaders out there, can you help me with my problem. It is
regarding the permutations in DES. When Bruce Schneier said move bit 58 to
bit 1, does he mean overwrite whatever bit was in bit position 1? Or does he
mean swap bits 58 and 1? Also, does the final permutation undo the initial
permutation (disregarding the rounds)?
Thanks for any help.
Ericson Yu
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Cheating in co-operative open-source games, how can we protect from it?
Date: 8 Mar 2000 14:29:11 GMT
Peter Henningsen <[EMAIL PROTECTED]> wrote:
> open source games/virtual worlds. Specific ways of cheating that we want to
> guard against are falsifying of game scores, creating God-characters by
> hacking code instead of earning similar status in the game world, or
> tainting an evolutionary process in a virtual world by falsely propagating
> and promoting artificial life entities. In all these cases, files on the
> user's computer must be protected from tampering by the user himself. Since
> we are developing free games, and cannot afford to do much processing on
> central servers, it is not an option either to run the code on a server for
> protection.
Can you consider your games in terms of a state to which users apply
some kind of transition to evolve it to the next state?
How about something like this :
1. When starting, store a hash of the current game state.
2. The client transmits its claim to
(previous game state, transition, new game state)
3. The server hashes the "previous game state" and compares it to
the hash. Then it checks to see that the transition is consistent
with the new game state -- this may be too expensive for you, unless
there is a nice way to check consistency faster than actually
computing the new state?
4. If it checks, the server stores a hash of the new game state to
compare against next time.
Storage requirement : 1 hash value (160 bits)
Computation requirements : 2 hash evaluations + consistency checking.
As stated, this doesn't account for multiple players. You might be
able to do something in which you take the states of some random
set of players and then see if they are somehow consistent with each
other. That way you can exploit the fact that lots of people are
connecting to your server.
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (Bo Dömstedt)
Subject: Re: NIST, AES at RSA conference
Reply-To: [EMAIL PROTECTED]
Date: Wed, 08 Mar 2000 15:05:08 GMT
Mars 08, 2000
Terry Ritter has shown that it makes sense to alter the
cipher algorithm. Crypto AG is a comercial company that
actually do this.
There are people simply cannot understand the point.
Jon Haugsand <[EMAIL PROTECTED]> wrote:
>
>Is this wrong posted? I mean rec.humor.funny seems to be the
>appropriate place...
>
>:)
Terry Ritter has presented a whole bunch of convincing
arguments. Not even a formal mathematical proof
would convince some people.
Bo Dömstedt
Chief Cryptographer
Protego Information AB
Secure encryption right now, run an OTP system!
SG100 Hardware Random Number Generator.
http://www.protego.se/sg100_en.htm
------------------------------
From: Michael Burrows <[EMAIL PROTECTED]>
Crossposted-To: alt.comp.freeware,comp.security.misc
Subject: des des3 for hp-ux c++
Date: Wed, 08 Mar 2000 15:19:06 +0000
Hi
Please could you let me know where I could get des or des3 for hp-ux c++
Thanks
Mike
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: DES Permutation
Date: Wed, 08 Mar 2000 15:11:34 GMT
On Wed, 8 Mar 2000 22:17:34 +0800, "DX" <[EMAIL PROTECTED]> wrote:
>To all the cryptoreaders out there, can you help me with my problem. It is
>regarding the permutations in DES. When Bruce Schneier said move bit 58 to
>bit 1, does he mean overwrite whatever bit was in bit position 1? Or does he
>mean swap bits 58 and 1?
Neither. The 58'th bit in is the 1'st bit out and some other bit, 55 I
believe, is the 58'th bit out.
Think of the IP as an 8_X_8 matrix. Bits are loaded in horizontally,
row by row, with the rows in order. Bits are read out vertically,
column by column, with the columns NOT in order. (The columns do have
an order, which is 5, 1, 6, 2, 7, 3, 8, 4.)
The fastest implementations use a lookup table for the IP and IP-1.
> Also, does the final permutation undo the initial
>permutation (disregarding the rounds)?
Yes. Bruce says that in the first sentence of his description of the
final permutation.
------------------------------
From: Stephen Houchen <[EMAIL PROTECTED]>
Subject: Re: DES Permutation
Date: Wed, 08 Mar 2000 09:42:51 -0600
> To all the cryptoreaders out there, can you help me with my problem. It is
> regarding the permutations in DES. When Bruce Schneier said move bit 58 to
> bit 1, does he mean overwrite whatever bit was in bit position 1? Or does he
> mean swap bits 58 and 1? Also, does the final permutation undo the initial
> permutation (disregarding the rounds)?
Don't perform the operation on the same buffer. Use an in-buffer and
an out-buffer. Set out-buffer's bit 1 to in-buffer's bit 58, etc.
Then you don't need in-buffer anymore.
S
[EMAIL PROTECTED]
------------------------------
Subject: Where do I get it?
From: John <[EMAIL PROTECTED]>
Date: Wed, 08 Mar 2000 08:01:23 -0800
How do I go about getting source and/or algorithms for RSA and
the other well-known encryption methods? How much will it cost
me? Are these available on the Net?
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To: rec.gambling.poker
Subject: Re: Security Features of Pokerspot.com
Date: Wed, 08 Mar 2000 16:26:08 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 06 Mar 2000 12:22:35 -0600, Mike Rosing
<[EMAIL PROTECTED]> wrote:
>Tony L. Svanstrom wrote:
>> - All user passwords are stored in encrypted form (using DES encryption) in
>> our databases.
>
>They ought to change it to one of the AES candidates. DES is crackable
>by brute force in 2 days by EFF's specialized machine.
Well, do they have a reason to store the password in encrypted form rather
than just hashing them?
If reversible crypto is needed then DES may be good enough, because anyone
with access to the stuff in the database, usually has enough access to get
at the crypto keys or the passwords. They're not sending the passwords
anywhere right? So it's probably to prevent trivial viewing of passwords if
anything.
Also assuming a typical webserver cgi setup:
1) The relevant scripts need the password to decrypt the keys.
2) The webserver needs to be able to read the scripts.
3) An intruder coming in by exploiting the webserver can gain the
webserver's rights.
Unless you want to type in a password everytime you start up the webserver,
and ensure that your scripts/applications actually persist (e.g. FastCGI),
improving things is not going to be easy. If your scripts have to be
restarted when you're not around you're screwed...
Then again, what if the backup tapes are not secured properly... Heh, well
I figure they'll have other problems.
In one system I use reversible crypto for some passwords, however these
passwords are randomly generated and used by an app to access a server.
They're not created by anyone. Not going to be so easy to crack from backup
tapes I figure ;). Pity they have to be "proper" passwords and so the high
bit ain't set. Grrr. Furthermore I believe the server only cares about 8
characters... <sigh>. Is there really any point going more than DES here?
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
Date: Wed, 08 Mar 2000 17:28:25 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Crypto Speeds...
Runu Knips schrieb:
>
> Eric Young wrote:
> > For most crypto using non-standard constructs, hand coding is a big win.
> > Most CPUs give a 2x speedup for RSA/DSA/DH etc [...]
> > For General algorithms like RC4/SHA-1/MD5, for most modern OOO CPUs,
> > it is normal for good C code, loop unrolled, to be about %70-90 of
> > what the ASM programmer can get. [...]
>
> But in practice I would use the GNU MP libary for code like this.
> Then you have assembly for the important computations - at least
> for all important and most not-so-important architectures. Plus,
> GMP ist L-GPL - so you can use it anwhere. So your RSA/ElGamal
> etc. will be - okay, still not really EASY - but far easier 8-)
> This way you can use assembly without even knowing a single
> opcode of the machine you're working on.
Okay, again: I just wanted to say that I wouldn't use C
multiplications anyway. I would take GMP or Eric Young's
BN lib and if there isn't already an assembly implementation
for bignums in them, THEN I would think of writing my own :)
I.e. I consider the main performance hole of RSA/DSA/DH/ElGamal
being not that important in practice.
Btw, why do all these people curse about the L-GPL ? Hmm but
thats off-topic in this NG...
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cyberrella
Date: Wed, 08 Mar 2000 09:31:21 GMT
"Nasser Ismaily" <[EMAIL PROTECTED]> wrote, in part:
>Does anyone know how I can get hold of encryption software written by
>Cyberella?
You may be thinking of Romana Machado, whose Stego program is
available at
http://www.fqa.com/romana/
or more directly at
http://www.stego.com/
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DES Permutation
Date: Wed, 08 Mar 2000 09:34:40 GMT
"DX" <[EMAIL PROTECTED]> wrote, in part:
>To all the cryptoreaders out there, can you help me with my problem. It is
>regarding the permutations in DES. When Bruce Schneier said move bit 58 to
>bit 1, does he mean overwrite whatever bit was in bit position 1? Or does he
>mean swap bits 58 and 1? Also, does the final permutation undo the initial
>permutation (disregarding the rounds)?
It doesn't mean either. Move bit 58 of the old 64-bit block to bit 1
of the result, and then continue the same way with all the other
numbered bits.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cheating in co-operative open-source games, how can we protect from it?
Date: Wed, 08 Mar 2000 09:46:54 GMT
"Peter Henningsen" <[EMAIL PROTECTED]> wrote, in part:
>Since
>we are developing free games, and cannot afford to do much processing on
>central servers, it is not an option either to run the code on a server for
>protection.
I suppose that one option you do have, though, is this:
actions performed by one user's computer could be verified, not by a
central server, but by one of the other computers of users playing the
game (selected at random by the server).
Hey, here's an idea:
The files on a user's computer giving the state of his character are
small...and encrypted by a key the user is not given.
When something needs to be changed in those files, the file is sent to
the server, and sent by the server to two other users, whose programs
are sent the key to the file, and a command to make the appropriate
change. The changed files are sent back to the server, and if they
match, a copy is sent to the user.
Processing remains distributed, but tampering with the user's program
can only affect the data files of other users, taken at random - and
that is blocked by double-checking.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Michael Polanyi Center <[EMAIL PROTECTED]>
Subject: CONFERENCE ON NATURALISM -- FINAL NOTICE
Date: Wed, 08 Mar 2000 10:32:23 -0800
CONFERENCE ON NATURALISM -- FINAL NOTICE
(www.baylor.edu/~polanyi/natconf.htm)
FEATURED SPEAKERS: Steven Weinberg, Simon Conway Morris, Christian de
Duve, Alan Guth, Alvin Plantinga, John Searle, Michael Behe, Mark
Ptashne, William Lane Craig, Howard Van Till, Nancey Murphy, Horace
Freeland Judson, Everett Mendelsohn, Ronald Numbers, and more.
Title: THE NATURE OF NATURE
Subtitle: An Interdisciplinary Conference on the Role of Naturalism in
Science
Date: April 12-15, 2000
Place: Baylor University
OVERVIEW: Is the universe self-contained or does it require something
beyond itself to explain its existence and internal function?
Philosophical naturalism takes the universe to be self-contained, and it
is widely presupposed throughout science. Even so, the idea that nature
points beyond itself has recently been reformulated with respect to a
number of issues. Consciousness, the origin of life, the unreasonable
effectiveness of mathematics at modeling the physical world, and the
fine-tuning of universal constants are just a few of the problems that
critics have claimed are incapable of purely naturalistic explanation.
Do such assertions constitute arguments from incredulity -- an
unwarranted appeal to ignorance? If not, is the explanation of such
phenomena beyond the pale of science? Is it, perhaps, possible to offer
cogent philosophical and even scientific arguments that nature does
point beyond itself? The aim of this conference is to examine such
questions.
CALL FOR PAPERS: Concurrent sessions on Thursday and Saturday of the
conference are intended to give scholars an opportunity to present their
views on the topic of this conference. Please submit an abstract of the
talk you would like to give as well as a current CV and a paper
representative of your work in the area of naturalism (preferably the
paper you would like to present at the conference). Please send these
three items to The Michael Polanyi Center, Baylor University, P.O. Box
97130, Waco, TX 76798-7130, Attn.: Conference Submission. These items
must be received no later than
March 1st.
REGISTRATION: The conference registration fee is $95 for non-students,
$55 for students if received before March 10th. Thereafter add another
$10 to the registration fee. Please make out a check or money order to
Baylor University and address it to The Michael Polanyi Center, Baylor
University, P.O. Box 97130, Waco, TX 76798-7130, Attn.: Conference
Registration. Information about meals will be made available on this
page shortly. Except for the banquet lecture Friday evening (4.14.2000),
Baylor students, faculty, and staff may attend the conference without
charge.
***WEDNESDAY, APRIL 12, 2000***
Conferees arrive late afternoon. Buffet dinner served.
EVENING PLENARY 7:00-9:30pm: The Nature of Nature
Moderator: Alvin Plantinga, University of Notre Dame (confirmed)
Michael Williams, Northwestern University (confirmed)
Michael Tooley, University of Colorado, Boulder (confirmed)
Robert Koons, University of Texas, Austin (confirmed)
***THURSDAY, APRIL 13, 2000***
PLENARY SESSION 8:00-10:00am: Metaphysics: Are Evolution and Naturalism
Incompatible?
Moderator: Bruce Gordon, Baylor University (confirmed)
Alvin Plantinga, University of Notre Dame (confirmed)
William Talbott, University of Washington, Seattle (confirmed)
BREAK 10:00-10:30am
PLENARY SESSION 10:30am-12:30pm: Naturalism and the History of Science
Moderator: Stuart Rosenbaum, Baylor University (confirmed)
Everett Mendelsohn, Harvard University (confirmed)
Ronald Numbers, University of Wisconsin, Madison (confirmed)
Ernan McMullin, University of Notre Dame (confirmed)
LUNCH 12:30-1:30pm
CONCURRENT SESSIONS 1:30-3:30pm
BREAK 3:30-4:00pm
PLENARY SESSION 4:00-6:00pm: Does Science Support Naturalism?
Moderator: Robert Koons, UT Austin (confirmed)
Henry F. Schaefer III, University of Georgia, Athens (confirmed)
Steven Weinberg, University of Texas, Austin (confirmed)
DINNER 6:00-7:30pm
***FRIDAY, APRIL 14, 2000***
PLENARY SESSION 8:00-9:00am: Biological Complexity I
Simon Conway Morris, Cambridge University (confirmed)
BREAK 9:00-9:30am
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: brute force attack on a 128 bit SSL key?
Date: 8 Mar 2000 16:42:28 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
> Paul Koning wrote:
> > That doesn't clarify anything (for me anyway). Does it produce
> > inaccurate answers? If so, why? And in what direction? What
> > approach would you use instead, and why?
> If you want a much better estimate of the actual limits, check
> out Feynman's exposition in the book "The Pleasure of Finding
> Things Out".
It also appears in his "Lectures on Computing" which have recently
been reissued in book form.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
comp.security.misc,alt.politics.org.cia,soc.culture.russian,soc.culture.nordic,soc.culture.ukrainian,alt.security
Subject: Some information security publications ... http://csrc.nist.gov/nissc/
Date: Wed, 08 Mar 2000 17:03:28 GMT
http://csrc.nist.gov/nissc/
------------------------------
** 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
******************************
