Subject: Id 10 for Twofish

From: Werner Koch <[email-masked]>
Date: Fri, 29 Jan 1999 20:32:49 +0100

Hi,

just a short poll:

 1) Did we agree on using the algorithm id 10 for Twofish?  And
    can I create preference lists with 10 in it.

 2) What is the conclusion about the keysize: 128, 196 or 256 bit.

The first point is quite important for me.

Thanks,

    Werner

-- 
ceterum censeo RSA esse delendam

---

From: Max Inux <[email-masked]>
Date: Fri, 29 Jan 1999 15:50:53 -0800 (PST)

> 2) What is the conclusion about the keysize: 128, 196 or 256 bit.

I believe our conjecture was 
id: 10, keysize: 256

Sorry about the cross-post, but it is valuable for both lists.
Max <[email-masked]> New PGP Keys Available
       If crypto is outlawed only outlaws will have crypto.
1960 Ford Falcon Tudor Daily Driver, Dont you just wish you had one?

Date: Fri, 29 Jan 1999 15:50:53 -0800 (PST)
From: Max Inux <[email-masked]>
To: Werner Koch <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Id 10 for Twofish
Sender: [email-masked]

> 2) What is the conclusion about the keysize: 128, 196 or 256 bit.

I believe our conjecture was 
id: 10, keysize: 256

Sorry about the cross-post, but it is valuable for both lists.
Max <[email-masked]> New PGP Keys Available
       If crypto is outlawed only outlaws will have crypto.
1960 Ford Falcon Tudor Daily Driver, Dont you just wish you had one?

Date: Fri, 29 Jan 1999 20:32:49 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Id 10 for Twofish
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

just a short poll:

Thanks,

    Werner

From: "Masahiro Morita" <[email-masked]>
To: <[email-masked]>
Subject: RE: Secure mailing list service using OpenPGP
Date: Thu, 28 Jan 1999 15:00:11 +0900
Importance: Normal
Sender: [email-masked]

I wrote:
> One problem in this implementation is authentication of the original
message
> sender. The server removes original sender's signature attached to an
> encrypted message when replacing an original message with the re-encrypted
> message. This is because PGP decrypt program, pgpv, strips the signature
> when it decrypts the message.

Many people advised me about this issue. Thanks > everyone.
I think that the best way is modifying pgpv to stop the decryption process
after finding an encrypted message and re-encrypting the message with the
original signature.

Is this modification easy?

> Another problem is comformance to OpenPGP/MIME specification proposed by
> K.Yamamoto[OpenPGP/MIME]. For example, if an original message is using
> 'Encrypted-then-Signed' service, the current implementation replace the
> inner multipart/encrypted MIME object and this makes impossible to verify
> the signature in the outer multipart/signed MIME object.

I think that this issue needs to define standard processes of this kind of
mailing list agents.
I mean, for example, if a signed-then-encrypted message is posted to a
mailing list, the mailing list agent should decrypt and re-encrypt to the
members, then the agent may sign to it. Or, if a encrypted-then-signed
message, the agent can eliminate the signature and decrypt&re-encrypt, and
so on.

In S/MIME, an I-Draft, "Enhanced Security Services for S/MIME" describes
secure mailing list services and defines the standerd process of mailing
list agents. We need the definitions like it for OpenPGP, don't we? --hiro

From: "=?iso-8859-1?B?kFiTYyCPuY1H?=" <[email-masked]>
To: <[email-masked]>
Subject: RE: Secure mailing list service using OpenPGP
Date: Thu, 28 Jan 1999 13:19:14 +0900
Importance: Normal
Sender: [email-masked]

I wrote:
> One problem in this implementation is authentication of the original
message
> sender. The server removes original sender's signature attached to an
> encrypted message when replacing an original message with the re-encrypted
> message. This is because PGP decrypt program, pgpv, strips the signature
> when it decrypts the message.

Many people advised me about this issue. Thanks > everyone.
I think that the best way is modifying pgpv to stop the decryption process
after finding an encrypted message and re-encrypting the message with the
original signature.

Is this modification easy?

> Another problem is comformance to OpenPGP/MIME specification proposed by
> K.Yamamoto[OpenPGP/MIME]. For example, if an original message is using
> 'Encrypted-then-Signed' service, the current implementation replace the
> inner multipart/encrypted MIME object and this makes impossible to verify
> the signature in the outer multipart/signed MIME object.

I think that this issue needs to define standard processes of this kind of
mailing list agents.
I mean, for example, if a signed-then-encrypted message is posted to a
mailing list, the mailing list agent should decrypt and re-encrypt to the
members, then the agent may sign to it. Or, if a encrypted-then-signed
message, the agent can eliminate the signature and decrypt&re-encrypt, and
so on.

In S/MIME, an I-Draft, "Enhanced Security Services for S/MIME" describes
secure mailing list services and defines the standerd process of mailing
list agents. We need the definitions like it for OpenPGP, don't we? --hiro

From: "Manuel Vargas" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: LEE ESTE MENSAJE Y MANDASELO A TUS OTROS AMIGOS
Date: Wed, 27 Jan 1999 18:29:50 PST
Sender: [email-masked]

Que el señor derrame ricas y abundantes bendiciones para
usted y su familia en este año 1999.

El propósito de este e-mail  es de darle a conocer la Nueva
Version De Mi Página Cristiana "Jesus Me Ama",
http://members.xoom.com/Stalin1/Jesusmeama.html
en ella encontrará una gama de Innovaciones, como son:

1.- Una Seccion de Caricaturas 
http://members.xoom.com/Stalin1/caricaturas.html
http://members.xoom.com/Stalin1/estafuetuvida.htm

2.- Musica Cristiana, En en la que puedes deleirtar tus
oidos con 2 tipos de formatos, como son: midis y wavs.

3.- Curso De la Biblia Gratuitamente, via e-mail. Puedes
recibir a la comodidad de tu hogar distintos cursos de la
Biblia  Gratuitamente, Solo llenas tus datos y te lo
enviaremos!!!!

4.- Algo Nunca Visto, Una Seccion Verdaderamente
impactante!!!
http://members.xoom.com/Stalin1/cristovienepronto.html

5.- Una seccion de Links de Diversas Páginas Cristianas, y
Otra de Banners.

6.- Y para finalizar una Seccion de Visitas.

7.- Al entrar a mi pagina encontrarás un banner en la parte
de Superior . Haciendo click en el , Contribuirás
Gratuitamente a la expanción del evangelio
de Nuestro Señor Jesucristo por todo el Mundo. Por Favor
Ayúdame en eso.

La Direccion de mi pagina es: 
http://members.xoom.com/Stalin1/Jesusmeama.html
PD. Por Favor manda este e-mail a Tus amigos y Hermanos en
Cristo, para que me apoyes, con este ministerio!!!

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From: Edwin Cremer <[email-masked]>
Subject: Re: Secure mailing list service using OpenPGP
To: [email-masked]
Date: Wed, 27 Jan 1999 21:40:37 +0100 (MET)
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Hi ????, you wrote:
> 
> I have developed a secure mailing list service by extending an existing
> mailing list server, FML 2.2 (see
> http://www.sapporo.iij.ad.jp/staff/fukachan/href/fml/index-e.html). The
> patch to the original source code will be released in a few weeks.

view month ago I do the same with a patch for "tulp" listserver.
 
> One problem in this implementation is authentication of the original message
> sender. The server removes original sender's signature attached to an
> encrypted message when replacing an original message with the re-encrypted
> message. This is because PGP decrypt program, pgpv, strips the signature
> when it decrypts the message.
> 
> Another problem is comformance to OpenPGP/MIME specification proposed by
> K.Yamamoto[OpenPGP/MIME]. For example, if an original message is using
> 'Encrypted-then-Signed' service, the current implementation replace the
> inner multipart/encrypted MIME object and this makes impossible to verify
> the signature in the outer multipart/signed MIME object.
> 
> Currently, I don't have the solutions for these problems. I'm just starting
> to grapple with them. I will welcome to your comments.

I have the same problem :-(

my solution is:
the server check the signatur and decrypt the message.
if both ok the server write a new footer with the output of the 
signcheck and then sign and encrypt the new message.
if you have a trusted server, the sigcheck is trust ;-)
and the members of the list don't need all the key's of all other members.
it work's fine with (nearly) all of pgp version.

	Eddy

- -- 
- ------------------------------------------------------------------------
Edwin Cremer
[email-masked]   PGP-Key-ID: 3AF75CD9
PGP-Key-fingerprint:  22 D7 06 43 3E 04 3F FA   D4 7A 67 EA 6B 70 60 25
- ------------------------------------------------------------------------
"Only wimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it."
                                          Linus Torvalds:

Date: Wed, 27 Jan 1999 11:47:35 -0600
To: [email-masked]
From: Keith Michael Ray <[email-masked]>
Subject: ElGamal Source Code
Sender: [email-masked]

	Does anyone have any links to some public domain ElGamal implementations
(pref in C)?  I haven't been able to find things like test vectors,
documentation, etc.

---------------------------------------------------------------------
Keith Michael Ray <[email-masked]>

PGP Key DH      : http://people.tamu.edu/~kmr2938/0x7E9175B4
PGP Key RSA     : http://people.tamu.edu/~kmr2938/0xB774EBED
---------------------------------------------------------------------

Date: Wed, 27 Jan 1999 08:08:22 -0800
From: [email-masked]
To: [email-masked]
Subject: RE: Secure mailing list service using OpenPGP
Sender: [email-masked]

I suggest you patch your pgpv so that it stops the decryption process
after finding an encrypted message.  Handling a message is a recursive
process, involving a series of stages: decrypting, decompressing,
signature-verifying, removing literal packets.  You can make it stop the
process after any desired stage; the code is designed to make this easy.

This way the output of your pgpv will be an OpenPGP compatible signed
message, suitable for further encryption.

Hal

> That's right.
>
> I've read OpenPGP Message Format specification and I think that it is
> logically possible to decrypt a signed&encrypted message and to extract the
> message together with the signature. Is this correct?
>
> If this is true, we can build a program to do this process and to re-encrypt
> to recipients of a ML.
>
> However, which approach should we take in? Geiger's two step approach with
> prohibiting the usual one step sign&encrypt process, or my approach
> described above? --hiro

Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 27 Jan 1999 10:28:31 +0100 (MET)
From: "CMS'99" <[email-masked]>
To: [email-masked]
Subject: CFP: Communications and Multimedia Security '99
Sender: [email-masked]

[Apologies if you receive this more than once.]

------------------------------------------------------------------------
           International Federation for Information Processing

                                 CMS '99
                  Communications and Multimedia Security        

                Joint working conference IFIP TC6 and TC11

                          September 20-21, 1999
                  Katholieke Universiteit Leuven, Belgium

------------------------------------------------------------------------
                              Call For Papers
 
------------------------------------------------------------------------

GOALS and TOPICS of INTEREST

CMS '99 is the fourth in a series of international conferences which aim 
at reviewing state-of-the-art issues as well as practical experiences
and new trends in the areas of communications and multimedia systems
security.

It is the intention of the organisers to focus the attention of the
conference presentations and discussions on issues which combine
innovative research work with a highly promising application potential.

Topics of interest include, but are not limited to
   * communications systems security
   * mobile communications security
   * Internet, intranet and extranet security
   * security of mobile code
   * multimedia systems security
   * applied cryptography
   * electronic commerce and digital signatures
   * security in distributed systems
   * secure teleworking, telecooperation, telemedicine
   * legal, social and ethical aspects of communication systems security
   * standards for communication and multimedia systems security

SUBMISSION DETAILS

Authors are strongly encouraged to submit their papers electronically.
Please email your submission in postscript (or pdf) format to:
[email-masked]
Electronic submissions must be received by March 15, 1999, 23:00 GMT in
order to be considered.

Authors unable to submit electronically are invited to send a cover
letter and 5 (five) copies of an anonymous paper (double-sided copies
preferred) to the Program Chair at the postal address below. Submissions
must be received by the Program Chair on or before March 15, 1999.

The cover letter should contain the paper's title and the names and
affiliations of the authors, and should identify the contact author
including e-mail and postal addresses.

Submissions must not substantially duplicate work that any of the
authors have published elsewhere or have submitted in parallel to any
other conference or workshop that has proceedings. The paper must be
anonymous, with no author names, affiliations, acknowledgments, or
obvious references. It should begin with a title, a short abstract, and
a list of key words, and its introduction should summarise the 
contributions of the paper at a level appropriate for a non-specialist
reader. The paper should be at most 5000 words long.  A full page figure
is 500 words. It is anticipated that the proceedings will be published by
Kluwer Academic Publishers. Therefore authors are encouraged to use for
their submissions the Kluwer IFIP templates for LaTeX or Word (see
http://www.wkap.com/IFIP).

All submitted papers will be refereed by at least three members of the
International Program Committee according to the standard blind
refereeing procedures. The Conference Proceedings will be published by
an international publisher; copies of the proceedings will be available
at the conference.

Notification of acceptance or rejection will be sent to authors by April
30, 1999. Authors of accepted papers must guarantee that their paper
will be presented at the conference.

Important dates:

   * Submission Deadline: March 15, 1999
   * Notification: April 30, 1999
   * Final camera-ready version: May 21, 1999
   * Conference: September 20-21, 1999

To submit a paper, or for further details, please contact:

  Prof. Bart Preneel,
  Program Committee Chair CMS'99
  Katholieke Universiteit Leuven
  Dept. Electrical Engineering-ESAT/COSIC
  K. Mercierlaan 94, B-3001 Heverlee, BELGIUM

  Email: [email-masked]
  Tel +32 16 32 10 50    Fax: +32 16 32 19 86
  For further details see http://www.esat.kuleuven.ac.be/cosic/cms99/

Program Committee Chair:
  B. Preneel, Katholieke Universiteit Leuven, Belgium

Program Committee:
  P. Ashley, Queensland University of Technology, Australia
  A. Casaca, Inesc, Portugal
  S. Fischer-Huebner, Hamburg University, Germany
  W. Fumy, Siemens Research, Germany
  D. Gollmann, Microsoft Research, UK
  D. Gritzalis, Athens University of Economics and Business, Greece
  P. Horster, University of Klagenfurt, Austria
  S. Katsikas, University of the Aegean, Greece
  L.R. Knudsen, University of Bergen, Norway
  C. Mitchell, Royal Holloway, University of London, UK
  D. Naccache, Gemplus, France
  R. Oppliger, BFI, Switzerland
  G. Pernul, University of Essen, Germany
  R. Posch, TU Graz, Austria
  G. Quirchmayr, University of Vienna, Austria
  J.-J. Quisquater, Université Catholique de Louvain, Belgium
  M. Reiter, Bell Labs, USA
  D. Tygar, University of California at Berkeley, USA
  P. van Oorschot, Entrust Technologies, Canada
  S.H. von Solms, Rand Afrikaans University, South Africa
  L. Yngstrom, Stockholm University and Royal Institute of Technology,
Sweden
  L Strous, De Nederlandsche Bank NV, The Netherlands, advisory member

Organising Committee Chair:
  J. Vandewalle, Katholieke Universiteit Leuven

Organising Committee:
  Joris Claessens,  Katholieke Universiteit Leuven
  Jorge Nakahara,  Katholieke Universiteit Leuven
  Péla Noë,  Katholieke Universiteit Leuven
  Vincent Rijmen,  Katholieke Universiteit Leuven
  Mark Vandenwauver,  Katholieke Universiteit Leuven

Main Organiser:
  IFIP TC 11 and TC 6
 
------------------------------------------------------------------------

Date: Wed, 27 Jan 1999 09:44:29 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: Secure mailing list service using OpenPGP
Sender: [email-masked]

On 1999-01-27 15:54:04 +0900, ?$B?9ED?(B ?$B>;9(?(B wrote:

> However, which approach should we take in? Geiger's two step
> approach with prohibiting the usual one step sign&encrypt process,
> or my approach described above? --hiro

As long as you don't want to use "clearsigning", you can try to
extract the signature from the "signed+encrypted" stuff.  Anyway,
doing this will require some patches to the PGP version you are
using.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1
> Hi!  I'm Signature Virus 99!  Copy me into your signature and join the fun!

From: "=?iso-2022-jp?B?GyRCPzlFRBsoQiAbJEI+OzkoGyhC?=" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Secure mailing list service using OpenPGP
Date: Wed, 27 Jan 1999 15:54:04 +0900
Importance: Normal
Sender: [email-masked]

William H. Geiger III wrote:
> Unfortunately few mailers/plugins are designed to use this approach when
> singing & encrypting a message. Instead they use the sign & encrypt
> approach (one step process) which signature retention is not possible
> after decryption.

That's right.

I've read OpenPGP Message Format specification and I think that it is
logically possible to decrypt a signed&encrypted message and to extract the
message together with the signature. Is this correct?

If this is true, we can build a program to do this process and to re-encrypt
to recipients of a ML.

However, which approach should we take in? Geiger's two step approach with
prohibiting the usual one step sign&encrypt process, or my approach
described above? --hiro

--- Morita Masahiro, NTT Information Sharing Platform Laboratories.

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 27 Jan 1999 00:37:28 -0500
To: " X c    G" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Secure mailing list service using OpenPGP
Sender: [email-masked]

In <[email-masked]>, on 01/27/99 
   at 01:37 PM, " X c    G" <[email-masked]> said:

>Another problem is comformance to OpenPGP/MIME specification proposed by
>K.Yamamoto[OpenPGP/MIME]. For example, if an original message is using
>'Encrypted-then-Signed' service, the current implementation replace the
>inner multipart/encrypted MIME object and this makes impossible to verify
>the signature in the outer multipart/signed MIME object.

>Currently, I don't have the solutions for these problems. I'm just
>starting to grapple with them. I will welcome to your comments.

Signature retention is a big issue that I have been involved with on both
the PGP/MIME and now the OpenPGP working groups. Basically there are two
ways to accomplish this:

NON-MIME Approach:

The original sender of the message clearsigns the message then encrypts
the message (a two step process). This way the server decrypts &
re-encrypts the message and the signature is retained.

MIME Approach:

The original sender OpenPGP/MIME signs the message then OpenPGP/MIME
encrypts the message (again a two step process).

Unfortunately few mailers/plugins are designed to use this approach when
singing & encrypting a message. Instead they use the sign & encrypt
approach (one step process) which signature retention is not possible
after decryption.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------

From: "=?iso-8859-1?B?kFiTYyCPuY1H?=" <[email-masked]>
To: <[email-masked]>
Subject: Secure mailing list service using OpenPGP
Date: Wed, 27 Jan 1999 13:37:11 +0900
Importance: Normal
Sender: [email-masked]

Hi,

I want to discuss about secure mailing list service using OpenPGP.

I have developed a secure mailing list service by extending an existing
mailing list server, FML 2.2 (see
http://www.sapporo.iij.ad.jp/staff/fukachan/href/fml/index-e.html). The
patch to the original source code will be released in a few weeks.

Using this extention, a member of a secure mailing list service can sends a
message encrypted to the public key of the server, and the destribution of
the message is also encrypted. The server decrypts the message and encrypts
to the all public keys of the members of the list. Then the server delivers
the re-encrypted message to the members.

In the current implementaiton, the server clips a message from an armor
header line, BEGIN PGP MESSAGE to an armor trailer line, END PGP MESSAGE,
and pipes the clipped message to decrypt and encrypt programs, then replaces
the original message with the re-encrypted one. The server also adds a
signature when re-encrypting to identify the mailing list server.

One problem in this implementation is authentication of the original message
sender. The server removes original sender's signature attached to an
encrypted message when replacing an original message with the re-encrypted
message. This is because PGP decrypt program, pgpv, strips the signature
when it decrypts the message.

Another problem is comformance to OpenPGP/MIME specification proposed by
K.Yamamoto[OpenPGP/MIME]. For example, if an original message is using
'Encrypted-then-Signed' service, the current implementation replace the
inner multipart/encrypted MIME object and this makes impossible to verify
the signature in the outer multipart/signed MIME object.

Currently, I don't have the solutions for these problems. I'm just starting
to grapple with them. I will welcome to your comments.

[OpenPGP/MIME] K.Yamamoto. MIME Security with OpenPGP. Internet Draft. Dec,
1998.

--- Masahiro Morita, NTT Information Sharing Platform Laboratories.

Date: Tue, 26 Jan 1999 22:49:33 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: to be done
Sender: [email-masked]

Since things don't look like we are ever getting the minutes from
the IETF meeting, I'd like to give a push for some work which should
be done by this WG.

- Revise RFC 2015.  I'm hearing that the agreement in Orlando was to
  do some small changes.  While this isn't interesting or anything,
  it should be done.

- Define a multiple signature protocol. There are essentially two
  possible paths to go.  On the one hand, we may define a
  multipart/mixed protocol as suggested by Michael Elkins, or we may
  just extend the current multipart/signed.  Personally, I'm in
  favor of the fist approach.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1
> Hi!  I'm Signature Virus 99!  Copy me into your signature and join the fun!

From: "Manuel Vargas" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: LEE ESTE MENSAJE Y MANDASELO A TUS OTROS AMIGOS
Date: Tue, 26 Jan 1999 11:42:46 PST
Sender: [email-masked]

Que el señor derrame ricas y abundantes bendiciones para 
usted y su familia en este año 1999.

El propósito de este e-mail  es de darle a conocer la Nueva 
Version De Mi Página Cristiana "Jesus Me Ama", 
http://jesusmeama.cjb.net
en ella encontrará una gama de Innovaciones, como son:

1.- Una Seccion de Caricaturas http://cariaturas.cjb.net

2.- Musica Cristiana, En en la que puedes deleirtar tus 
oidos con 2 tipos de formatos, como son: midis y wavs.

3.- Curso De la Biblia Gratuitamente, via e-mail. Puedes 
recibir a la comodidad de tu hogar distintos cursos de la 
Biblia  Gratuitamente, Solo llenas tus datos y te lo 
enviaremos!!!!

4.- Algo Nunca Visto, Una Seccion Verdaderamente 
impactante!!!

5.- Una seccion de Links de Diversas Páginas Cristianas, y 
Otra de Banners.

6.- Y para finalizar una Seccion de Visitas.

7.- Al entrar a mi pagina encontrarás un banner en la parte 
de Superior . Haciendo click en el , Contribuirás 
Gratuitamente a la expanción del evangelio
de Nuestro Señor Jesucristo por todo el Mundo. Por Favor 
Ayúdame en eso.

La Direccion de mi pagina es: http://jesusmeama.cjb.net

PD. Por Favor manda este e-mail a Tus amigos y Hermanos en 
Cristo, para que me apoyes, con este ministerio!!!

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From: Andrew Bromage <[email-masked]>
Subject: Re: Twofish
To: [email-masked] (Jon Callas)
Date: Wed, 20 Jan 1999 13:30:54 +1100 (EST)
Cc: [email-masked]
Sender: [email-masked]

G'day all.

Jon Callas wrote:

> I discussed our previous conversation, and he said that his doubt is merely
> that he is not convinced that the 256-bit keys are fully exponentially
> stronger than 128. I think this is reasonable, and have the same doubts
> myself about all the present generation 256 bit cyphers.

Quite.  We have a precedent in our requirement of 3DES which is
vulnerable to a meet-in-the-middle attack, so we don't expect it to
be fully exponentially stronger than a modern 128 bit cipher.

Cheers,
Andrew Bromage

Date: Mon, 18 Jan 1999 23:59:42 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Twofish
Sender: [email-masked]

I spoke to Bruce today about what key length to use. I asked him because a
few months ago we had a casual conversation and he said he was more
confident of Twofish at 128 bits than 256 bits. I brought it up again,
mentioning we're discussing putting it in OpenPGP (and he is delighted
about that).

Anyway, he first said to do it at 128 bits and then said, "Wait a minute --
it doesn't cost you anything to go to the full 256?" and I said it didn't.
"Then do 256" he replied.

I discussed our previous conversation, and he said that his doubt is merely
that he is not convinced that the 256-bit keys are fully exponentially
stronger than 128. I think this is reasonable, and have the same doubts
myself about all the present generation 256 bit cyphers. So no biggie, really.

Does anyone *not* want to do 256? Send me private mail if you don't want to
be seen as a party-pooper, but have concerns. I launder information real well.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Fri, 15 Jan 1999 08:43:45 -0800 (PST)
From: List Manager of ietf-open-pgp <[email-masked]>
To: [email-masked]
Subject: How to be removed from this list
Sender: [email-masked]

Greetings again. Occasionally, people will sign up for a mailing list and
forget how to be removed. This message is a reminder for those folks.

First off, when you subscribe to a mailing list, you almost always get a
first message from the list owner telling you about the mailing list, and
explaining how to unsubscribe. It is always a good idea to keep those
messages, since you never know when you will need to unsubscribe. This is
particularly useful when you change email addresses, because it is difficult
to unsubscribe from a list after you have a different mailing address.

In the case of this list, the method to unsubscribe is to send a message
to:
     [email-masked]
with the single word:
     unsubscribe
in the body of the message. This is the same as it always has been.

To make this easier for you, I have crafted this message so that you should
be able to simply reply to this message, and the reply address should be
[email-masked] (although some mail clients screw this up...).
Remove everything from the body of the reply, and put in the single word:
     unsubscribe

If you have tried this method, and the mailing list software won't let you
unsubscribe, it is probably because your address has changed. In that case,
please send a message to [email-masked] stating which list (or lists) you
want to unsubscribe from, and what you think your previous address was.
There is a human (that's me!) who will then try to take care of your
request, often within a few days.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 14 Jan 1999 14:43:35 -0800
To: Max Inux <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Twofish
Sender: [email-masked]

At 07:08 PM 1/13/99 -0800, Max Inux wrote:
   
   Upon greater light being shed on the subject, I vote that identifier 10 be
   TwoFish and 11 be whatever wins AES, if it is TwoFish it will be
   un-needed.
   
We already reserved three for AES in 2440, for 128, 192, and 256 bit key
lengths, so we're already covered.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 13 Jan 1999 19:08:10 -0800 (PST)
From: Max Inux <[email-masked]>
To: [email-masked]
Subject: Re: Twofish
Sender: [email-masked]

Upon greater light being shed on the subject, I vote that identifier 10 be
TwoFish and 11 be whatever wins AES, if it is TwoFish it will be
un-needed.

Now the problem is the bit size, looking at how we have other stuff done
(Block size = 64 bit, key size = 128), it seems fitting that if Block size
=128 we have key size = 256

Max <[email-masked]> New PGP Keys Available
       If crypto is outlawed only outlaws will have crypto.
1960 Ford Falcon Tudor Daily Driver, Dont you just wish you had one?

From: Andrew Bromage <[email-masked]>
Subject: Re: Twofish
To: [email-masked] (Jon Callas)
Date: Thu, 14 Jan 1999 10:19:30 +1100 (EST)
Cc: [email-masked]
Sender: [email-masked]

G'day all.

At 07:28 PM 1/12/99 -0500, uri wrote:

>    So, Twofish is a logical successor for Blowfish - and let's treat it
>    like that. If people have Blowfish-encrypted stuff already (which I
>    doubt, but you never know) - they can do a one-time move. Better
>    than to carry unnecessary baggage.

Jon Callas wrote:

> I'm uncomfortable with re-declaring an identifier. It's just not good
> engineering practice to my mind.

I have to agree.

RFC 2440, the current "standard", is published.  If we were looking at
an error, I'd say "fix it".  But we are not The Evil Software Empire(tm),
and can't move the ground out from under people.  This kind of ambiguity
will only cause confusion at best and put people off PGP at worst.

> I think it is much better use another
> identifier. This would only put us up to 10, and that includes four
> identifiers that are presently only reserved.

...and one would be deprecated.

Cheers,
Andrew Bromage

Date: Wed, 13 Jan 1999 20:10:45 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Twofish - details, details...
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> 10 would be better.  I already have blowfish in my implmentation even if
> no one uses it.

GnuPG uses Blowfish too.

> Does anyone have an implementation, or at least what calls they are using
> if they are using the counterpane reference source?

Actually GnuPG has a Twofish (128 bit key) implemenation as
experimental algorithm.

  Werner 

Date: Wed, 13 Jan 1999 13:22:08 -0500
From: [email-masked]
To: [email-masked]
Subject: Re: Twofish - details, details...
Sender: [email-masked]

On Tue, 12 Jan 1999, Jon Callas wrote:

> At 07:28 PM 1/12/99 -0500, uri wrote:
> 
>    So, Twofish is a logical successor for Blowfish - and let's treat it
>    like that. If people have Blowfish-encrypted stuff already (which I
>    doubt, but you never know) - they can do a one-time move. Better
>    than to carry unnecessary baggage.
> 
> I'm uncomfortable with re-declaring an identifier. It's just not good
> engineering practice to my mind. I think it is much better use another
> identifier. This would only put us up to 10, and that includes four
> identifiers that are presently only reserved. If 2440 were not out, I'd
> have no problem. But it is out there, and it just bugs me to redeclare an
> identifier if it inconveniences even a single user.
> 
> By the bye, an inconvenient page break in 2440 made me say something stupid
> in my last message. The identifier should be 10, not 8. 

10 would be better.  I already have blowfish in my implmentation even if
no one uses it.

Also, as someone else pointed out, we need to have established key lengths
AND I assume that it will be in the ECB mode with the PGP cfb with reset
at 10 bytes like everything else?

Does anyone have an implementation, or at least what calls they are using
if they are using the counterpane reference source?

Date: Wed, 13 Jan 1999 13:17:15 -0500 (EST)
From: Tony Mione <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Twofish
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 13 Jan 1999 [email-masked] wrote:

> Tony Mione, <[email-masked]>, writes:
> > I would like to (if it is agreeable) add the concept of parameters for
> > symmetric algorithms to my v1.1 laundry list. It should probably be handled
> > in a similar fashion to the public-key parameters (for DSA, etc). This
> > would probably mean specifying an 'Enhanced symmetric-key encrypted
> > session-key packet' to replace the existing one but I will leave that up to
> > the group to hash out.
> >
> > Does this sound reasonable to people?

> OK, but as I said, there are three places (at least) where symmetric
> key algorithms are specified.  In addition to the SKESK which you propose
> to enhance, there is the public-key ESK, and also there is the secret
> key packet where they are used to specify what algorithm encrypts the
> secret key data.  So we would need perhaps three new packet formats.

I agree. I picked out the SKESK as an example but meant to state that all
places where symmetric keys are used would have to be reviewed and
enhanced. Thanks for clarifying that.

> Hal

Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[email-masked]                 W3: http://www-ns.rutgers.edu/~mione/
PGPFP:E2252CCD28733C5B  0B918A4E22BAFA9F     ***** Important: Rom 10:9-11 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR

Date: Wed, 13 Jan 1999 09:45:46 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Twofish
Cc: [email-masked]
Sender: [email-masked]

Tony Mione, <[email-masked]>, writes:
> I would like to (if it is agreeable) add the concept of parameters for
> symmetric algorithms to my v1.1 laundry list. It should probably be handled
> in a similar fashion to the public-key parameters (for DSA, etc). This
> would probably mean specifying an 'Enhanced symmetric-key encrypted
> session-key packet' to replace the existing one but I will leave that up to
> the group to hash out.
>
> Does this sound reasonable to people?

OK, but as I said, there are three places (at least) where symmetric
key algorithms are specified.  In addition to the SKESK which you propose
to enhance, there is the public-key ESK, and also there is the secret
key packet where they are used to specify what algorithm encrypts the
secret key data.  So we would need perhaps three new packet formats.

Hal

Date: Wed, 13 Jan 1999 07:31:24 -0800 (PST)
From: [email-masked]
To: [email-masked]
Subject: Re: Twofish
Sender: [email-masked]

[email-masked] wrote:
>128 bits
>is really very strong still, but if we do want to go up, 192 seems more
>reasonable to me than 256.  That would be my recommendation.

What would be the *disadvantage* of choosing 256 bits? I can see the 
potential advantage if quantum computing does become feasible in the next
decade or so, but I can't see any real disadvantage; as far as I'm aware
we'd just have a slightly larger data size and a slightly longer key setup 
time.

If that's the case and we only have one key size, I'd say go for 256 bits
because it has potential advantages which could significantly outweigh the 
minor disadvantages.

    Mark

Date: Wed, 13 Jan 1999 08:41:44 -0500 (EST)
From: Tony Mione <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Twofish
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 12 Jan 1999 [email-masked] wrote:

> One question is key size.  PGP key algorithm values have defined key
> sizes.  Twofish, like the other AES candidates, can be used with key
> sizes of 128, 192, or 256 bits.  (Actually the cipher allows use of any
> smaller size key as well.)

> In some contexts where symmetric key algorithm values are used, the
> key size can be determined from the message format.  For example,
> Public-Key Encrypted Session Key Packets use PKCS-1 encoding for the
> encrypted session key, and that encoding implicitly determines the
> key size (at least to a multiple of eight bytes).

> However, this is not always the case.  Symmetric-Key ESK packets
> encrypt one key with another, and the two keys' lengths are allowed
> to be different.  Only the encrypted key has its length determined by
> context, not the encrypting key.  Symmetric key algorithm values are
> also used in secret key packets, and there, too, the key lengths cannot
> be determined from context.

I think we should deal with this issue reasonably soon. We probably cannot
deal with it until the v1.1 spec. However, with the number of symmetric key
algorithms that are being designed with variable key lengths and other
parameters, it will become prohibitive to assign identifiers for
each. Picking a specific key length may be too limiting (a user may WANT
256 bit keys) and this does not handle other variables of the
algorithm. Take, for instance rc6 (another AES candidate) which allows
variable rounds and blocksizes as well. rc6 as specified for the AES the
way I read it will be RC6-32/20/{16,24,32}. The first number is the number
of bits in a block. The second is the number of rounds. The third is the
key size in bytes (it will handle 128,192,and 256 bit keys). Just because
this is the definition for AES does not mean that we should not allow it to
be run with alternate word sizes or rounds.

I would like to (if it is agreeable) add the concept of parameters for
symmetric algorithms to my v1.1 laundry list. It should probably be handled
in a similar fashion to the public-key parameters (for DSA, etc). This
would probably mean specifying an 'Enhanced symmetric-key encrypted
session-key packet' to replace the existing one but I will leave that up to
the group to hash out.

Does this sound reasonable to people?

> To deal with this, we have always defined symmetric key algorithm
> values to represent both a cipher and a key length.  Blowfish was a
> variable-key-length algorithm, but the Blowfish cipher algorithm byte
> was defined to represent a 128-bit key version.

>...
> computing which nobody really expects to happen.  192 bits is more
> than enough strength for any reasonable cryptographic attack.  128 bits
> is really very strong still, but if we do want to go up, 192 seems more
> reasonable to me than 256.  That would be my recommendation.

We should probably choose a single size for the time being. Later, if the
above recommendation gets implemented in the v1.1 OpenPGP spec, we would
define newer algorithm identifiers with variable parameters.

> Hal

Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[email-masked]                 W3: http://www-ns.rutgers.edu/~mione/
PGPFP:E2252CCD28733C5B  0B918A4E22BAFA9F     ***** Important: Rom 10:9-11 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR

Date: Wed, 13 Jan 1999 11:16:30 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Twofish
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> To deal with this, we have always defined symmetric key algorithm
> values to represent both a cipher and a key length.  Blowfish was a

Another way to handle this is to specify a new version for these
packets (5) which carry more information than just the algorithm.

A standard key length (192 for Twofish?) should then be used with
v4 packets.

I know that this is not covered by rfc2440 but we might consider it
for a new release.

  Werner  

Date: Tue, 12 Jan 1999 17:10:13 -0800
From: [email-masked]
To: [email-masked]
Subject: Re: Twofish
Sender: [email-masked]

One question is key size.  PGP key algorithm values have defined key
sizes.  Twofish, like the other AES candidates, can be used with key
sizes of 128, 192, or 256 bits.  (Actually the cipher allows use of any
smaller size key as well.)

In some contexts where symmetric key algorithm values are used, the
key size can be determined from the message format.  For example,
Public-Key Encrypted Session Key Packets use PKCS-1 encoding for the
encrypted session key, and that encoding implicitly determines the
key size (at least to a multiple of eight bytes).

However, this is not always the case.  Symmetric-Key ESK packets
encrypt one key with another, and the two keys' lengths are allowed
to be different.  Only the encrypted key has its length determined by
context, not the encrypting key.  Symmetric key algorithm values are
also used in secret key packets, and there, too, the key lengths cannot
be determined from context.

To deal with this, we have always defined symmetric key algorithm
values to represent both a cipher and a key length.  Blowfish was a
variable-key-length algorithm, but the Blowfish cipher algorithm byte
was defined to represent a 128-bit key version.

In adding Twofish, we should probably either add three values, for
128-, 192-, and 256-bit versions, or we should settle on a single
size.

If we choose a single size, it would probably make sense to have the
Twofish key size be bigger than the 128 bits used by most of our current
keys.  Unlike the other ciphers, Twofish has a 128 bit block size.
(Keep in mind that the block size bears no necessary relation to the
key size, except that bigger is better in both cases.)  All our other
ciphers use a 64 bit block size.  Given this increase in size, we should
probably consider 192 or 256 bits as the Twofish key size.

Either one of these would probably be OK.  Personally, I feel that 256
bits is awfully big for a key.  There is some speculation that the AES
required such a large key to protect against exotic advances in quantum
computing which nobody really expects to happen.  192 bits is more
than enough strength for any reasonable cryptographic attack.  128 bits
is really very strong still, but if we do want to go up, 192 seems more
reasonable to me than 256.  That would be my recommendation.

Hal

From: William Lewis <[email-masked]>
Date: Tue, 12 Jan 99 17:08:02 -0800
To: [email-masked]
Subject: Re: Twofish
Sender: [email-masked]

Max Inux <[email-masked]> wrote:
> I dont know about NAI, but from what Werner has said on the GPG list he
> intends to remove Blowfish, which makes sense, I dont know about anyone
> else but I have yet to see anyone use Blowfish, so why not just pretend it
> was not there and just go with twofish?  after AES is done, it surely will
> have been proven.

It's asking for trouble to have an ambiguous assigned number. If there were  
a shortage of available numbers, reusing Blowfish's might make sense; but  
there isn't, and if someday there is, Blowfish's number can be reused then.

The argument that Twofish is Blowfish's successor doesn't hold water, IMHO.  
Twofish won't decrypt a message encrypted with Blowfish, so they're different  
algorithms, despite sharing authorship or structure.

Date: Tue, 12 Jan 1999 16:49:27 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Twofish
Sender: [email-masked]

At 07:28 PM 1/12/99 -0500, uri wrote:

   So, Twofish is a logical successor for Blowfish - and let's treat it
   like that. If people have Blowfish-encrypted stuff already (which I
   doubt, but you never know) - they can do a one-time move. Better
   than to carry unnecessary baggage.

I'm uncomfortable with re-declaring an identifier. It's just not good
engineering practice to my mind. I think it is much better use another
identifier. This would only put us up to 10, and that includes four
identifiers that are presently only reserved. If 2440 were not out, I'd
have no problem. But it is out there, and it just bugs me to redeclare an
identifier if it inconveniences even a single user.

By the bye, an inconvenient page break in 2440 made me say something stupid
in my last message. The identifier should be 10, not 8. 

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

From: uri <[email-masked]>
Subject: Re: Twofish
To: [email-masked] (Max Inux)
Date: Tue, 12 Jan 1999 19:28:17 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Max Inux says:
> >Both Werner Koch and his GNUPG team and the NAI PGP team are planning on
> >putting Twofish (256-bit key) in versions of their respective OpenPGP
> >programs.............. Comments? Discussion?
>
> I dont know about NAI, but from what Werner has said on the GPG list he
> intends to remove Blowfish, which makes sense, I dont know about anyone
> else but I have yet to see anyone use Blowfish, so why not just pretend it
> was not there and just go with twofish?  after AES is done, it surely will
> have been proven.

I second this. How many ciphers do we need, after all? We aren't in the
contest "who can support more", right?

So, Twofish is a logical successor for Blowfish - and let's treat it
like that. If people have Blowfish-encrypted stuff already (which I
doubt, but you never know) - they can do a one-time move. Better
than to carry unnecessary baggage.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Tue, 12 Jan 1999 16:03:36 -0800 (PST)
From: Max Inux <[email-masked]>
To: [email-masked]
Subject: Re: Twofish
Sender: [email-masked]

On Tue, 12 Jan 1999, Jon Callas wrote:
>Both Werner Koch and his GNUPG team and the NAI PGP team are planning on
>putting Twofish (256-bit key) in versions of their respective OpenPGP
>programs. Consequently, we need to agree on a constant for it. I propose we
>use 8 (eight) as it's the next one in line.
>
>Comments? Discussion?
>
>	Jon

I dont know about NAI, but from what Werner has said on the GPG list he
intends to remove Blowfish, which makes sense, I dont know about anyone
else but I have yet to see anyone use Blowfish, so why not just pretend it
was not there and just go with twofish?  after AES is done, it surely will
have been proven.

-MaxInux aka William Tiemann
Max <[email-masked]> New PGP Keys Available
       If crypto is outlawed only outlaws will have crypto.
1960 Ford Falcon Tudor Daily Driver, Dont you just wish you had one?

Date: Tue, 12 Jan 1999 12:23:20 -0800
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Twofish
Sender: [email-masked]

Both Werner Koch and his GNUPG team and the NAI PGP team are planning on
putting Twofish (256-bit key) in versions of their respective OpenPGP
programs. Consequently, we need to agree on a constant for it. I propose we
use 8 (eight) as it's the next one in line.

Comments? Discussion?

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Fri, 8 Jan 1999 16:14:09 +0800 (SGT)
From: Jianying Zhou <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: ACM CCS'99 CFP 
Sender: [email-masked]

I apology for sending a large attachment in an early message.

Sorry.

Jianying Zhou

Date: Mon, 04 Jan 1999 12:27:09 -0500
To: [email-masked]
From: "David M. Balenson" <[email-masked]>
Subject: REMINDER: Jan 6th Early Bird Deadline for NDSS '99
Cc: [email-masked]
Sender: [email-masked]

--=====================_915488829==_
Content-Type: text/plain; charset="us-ascii"

--=====================_915488829==_
Content-Type: text/plain; charset="us-ascii"

S A V E   $ 7 0   O F F   R E G I S T R A T I O N   F E E ! !
R E G I S T E R   B Y   J A N U A R Y   6 ,   1 9 9 9 

THE INTERNET SOCIETY'S
1999 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 3-5, 1999
Catamaran Resort Hotel
San Diego, California
General Chair:   Steve Welke, Trusted Computer Solutions
Program Chairs:  Steve Kent, BBN Technologies
                 Gene Tsudik, USC/Information Sciences Institute

ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss99

KEYNOTE SPEAKER: Whitfield Diffie, Sun Microsystems.  Co-author of
"Privacy on the Line: The Politics of Wiretapping and Encryption."

THIS YEAR'S TOPICS INCLUDE:
- Secure Password-Based Protocol for Downloading a Private Key
- A Real-World Analysis of Kerberos Password Security
- Secure Remote Access to an Internal Web Server
- Security and the User
- Experimenting with Shared Generation of RSA Keys
- Addressing the Problem of Undetected Signature Key Compromise
- Practical Approach to Anonymity in Large Scale Electronic Voting Schemes
- Securing the Internet's Exterior Routing Infrastructure
- Distributed Policy Management for Java 1.2
- Distributed Execution with Remote Audit
- An Algebra for Assessing Trust in Certification Chains
- A Network Security Research Agenda
- PGRIP: PNNI Global Routing Infrastructure Protection
- A Cryptographic Countermeasure Against Connection Depletion Attacks
- IPSec: Friend or Foe?

EXPANDED PRE-CONFERENCE TECHNICAL TUTORIALS:
- Principles of Network Security (Dr. Stephen T. Kent, BBN  Technologies)
- Optical Network Security (Jeff Ingle and Dr. Eric Harder, NSA)
- Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI)
- Windows NT Security (Dominique Brezinski, Secure Computing Corp.)
- Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI)
- JAVA Security (Dr. Gary McGraw, Reliable Software Technologies)
Full details and biographies at http://www.isoc.org/ndss99/technical.shtml

--=====================_915488829==_
Content-Type: text/plain; charset="us-ascii"

----------------------------------------------------------------------
David M. Balenson, Publicity Chair, NDSS '99
TIS Labs at Network Associates, Inc.
3060 Washington Road, Suite 100, Glenwood, MD 21738  USA
[email-masked]; 443-259-2358; fax 301-854-4731
--=====================_915488829==_--