Re: Encoding of hash in El-Gamal signatures

["L. Sassaman" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You are aware of the insecurities in ElGamal signatures, correct? And that
they are deprecated in GnuPG, and have never been implemented in PGP?

See: ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps for
the dangers of ElGamal signatures.

I'd hate to see more of these keys being created. Not only would you then
be relying on the "other party" to properly verify signatures and to
create strong keys using an algorithm that is easy to mis-implement, you
would also be creating keys that have never really been used or supported
in the PGP world. Causing further incompatibility between the OpenPGP
programs is not beneficial.

Also, Werner Koch recently discovered GnuPG had problems its ElGamal
signatures (which he fixed in GnuPG 1.0.2) involving the hash encoding.
Now, signatures made by GnuPG cannot be verified by earlier versions.

Thankfully, this isn't much of a problem, since very few people use
ElGamal signature keys. Please think if you really need these keys before
you add support for them.


- --Len.


On Wed, 29 Nov 2000 [e-mail] wrote:

> In section 5.2 of rfc2440, the process of calculating signatures is outlined.
> However, it
> is not specified how to convert from the hash to algorithm-specific signature
> input for
> all algorithms. It is for RSA (PKCS#1 padding +  DER -encoding of an ASN.1
> DigestInfo)
> and DSA (trivial). For El-Gamal, it doesn't say. I know that GnuPG uses
> an aproach similar
> to RSA.
>
> What is the story? How do I convert the hash to El-Gamal input?
>
> Regards
> /Bo


__

L. Sassaman

Security Architect             |  "The world's gone crazy,
Technology Consultant          |   and it makes no sense..."
                               |
http://sion.quickie.net        |                   --Sting



-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE6JuTFPYrxsgmsCmoRAh9JAKDkNrrVf7QMmNgl25/i4j75jl9SSgCfed5Y
JDz7xSpzxGfjhoECVLT6pVk=
=itPy
-----END PGP SIGNATURE-----




Received: by ns.secondary.com (8.9.3/8.9.3) id PAA23996 for ietf-openpgp-bks; Thu, 30 Nov 2000 15:36:28 -0800 (PST)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA23992 for <[e-mail]>; Thu, 30 Nov 2000 15:36:24 -0800 (PST)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id PAA14010; Thu, 30 Nov 2000 15:37:42 -0800
Date: Thu, 30 Nov 2000 15:37:32 -0800 (PST)
From: "L. Sassaman" <[e-mail]>
X-Sender:  <[e-mail]>
To: <[e-mail]>
cc: <[e-mail]>, <[e-mail]>
Subject: Re: Encoding of hash in El-Gamal signatures
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You are aware of the insecurities in ElGamal signatures, correct? And that
they are deprecated in GnuPG, and have never been implemented in PGP?

See: ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps for
the dangers of ElGamal signatures.

I'd hate to see more of these keys being created. Not only would you then
be relying on the "other party" to properly verify signatures and to
create strong keys using an algorithm that is easy to mis-implement, you
would also be creating keys that have never really been used or supported
in the PGP world. Causing further incompatibility between the OpenPGP
programs is not beneficial.

Also, Werner Koch recently discovered GnuPG had problems its ElGamal
signatures (which he fixed in GnuPG 1.0.2) involving the hash encoding.
Now, signatures made by GnuPG cannot be verified by earlier versions.

Thankfully, this isn't much of a problem, since very few people use
ElGamal signature keys. Please think if you really need these keys before
you add support for them.


- --Len.


On Wed, 29 Nov 2000 [e-mail] wrote:

> In section 5.2 of rfc2440, the process of calculating signatures is outlined.
> However, it
> is not specified how to convert from the hash to algorithm-specific signature
> input for
> all algorithms. It is for RSA (PKCS#1 padding +  DER -encoding of an ASN.1
> DigestInfo)
> and DSA (trivial). For El-Gamal, it doesn't say. I know that GnuPG uses
> an aproach similar
> to RSA.
>
> What is the story? How do I convert the hash to El-Gamal input?
>
> Regards
> /Bo


__

L. Sassaman

Security Architect             |  "The world's gone crazy,
Technology Consultant          |   and it makes no sense..."
                               |
http://sion.quickie.net        |                   --Sting



-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE6JuTFPYrxsgmsCmoRAh9JAKDkNrrVf7QMmNgl25/i4j75jl9SSgCfed5Y
JDz7xSpzxGfjhoECVLT6pVk=
=itPy
-----END PGP SIGNATURE-----



Received: by ns.secondary.com (8.9.3/8.9.3) id NAA19253 for ietf-openpgp-bks; Thu, 30 Nov 2000 13:55:15 -0800 (PST)
Received: from smtp-server.tampabay.rr.com (cflsmtp.cfl.rr.com [65.32.2.68] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19246 for <[e-mail]>; Thu, 30 Nov 2000 13:55:14 -0800 (PST)
Received: from heidikay.kayconcepts.com (24161229hfc245.tampabay.rr.com [24.161.229.245]) by smtp-server.tampabay.rr.com (8.9.3/8.9.3) with ESMTP id QAA17515 for <[e-mail]>; Thu, 30 Nov 2000 16:56:50 -0500 (EST)
Message-Id: <4.3.2.7.2.20001130164534.00c106d0@pop-server>
X-Sender: hkay1@pop-server
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 30 Nov 2000 16:49:37 -0500
To: [e-mail]
From: Heidi Kay <[e-mail]>
Subject: please help in my search
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hello,

I apologize in advance for intruding on this technical forum, but I was 
hoping someone here could help me.
I am a technical recruiter looking for a software engineer with PKI and 
other security background.   My client is in the midwest and is an 
excellent employer.    I have placed 80 people with them.

Does anyone know, either who might be looking or where I might legitimately 
post such a job description?

Here is the opening so that you know what I need.   Thank you in 
advance.  I will not post to this group again.

Heidi Kay, President, Kay Concepts, Inc.

------------------------------------------------

Job Location:
    Akron/Canton, OH

Job Summary:

We are on retainer with a premier Fortune high technology manufacturing 
company that manufacturers self-service terminals for financial 
applications  (Automated Teller Machines)

Our client is growing and as a result has a need for a talented, Software 
Engineer who has some expertise in Software Security and Cryptography.

This is a senior level software and systems engineering position. The 
individual will be responsible for the investigation and implementation of 
such software and hardware components that ensure the secure transfer and 
storage of sensitive financial institution and individual customer data. 
This will include, but not be limited to, transfer and holding of customer 
PIN's cryptography keys and algorithms. The individual will provide input, 
such as software algorithms, information on current industry trends, to 
various internal software groups. Will ensure that algorithms and 
techniques used for data security meet government and industry standards 
specifications.

    Qualifications
*       A BSEE or BSCS or equivalent degree with 5 to 7 years of 
programming experience
*       Experience in cryptography and other PC security projects
*       Experience with data communications standards and trends
*       Experience with C, C++ and general software and system development 
practices
*       Experience in Windows NT, Windows 98, OS/2 required, Linux and Unix 
helpful
>
Compensation/Benefits:
    Salaries based on candidates experience level. Full
    relocation and interview expenses provided.




Heidi Kay, CPC

Kay Concepts, Inc.
PO Box 4825,   Palm Harbor,  FL  34685
"Making the most of what you've made of yourself"
E-mail address:  [e-mail]
URL:  www.kayconcepts.com
PH:    [phone]    Local: [phone]
FAX:  [phone]    Toll:  [phone]



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA13958 for ietf-openpgp-bks; Wed, 29 Nov 2000 13:47:03 -0800 (PST)
Received: from bbs.ht.net.cn (IDENT:root@[202.103.160.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13948 for <[e-mail]>; Wed, 29 Nov 2000 13:46:57 -0800 (PST)
From: [e-mail]
Received: from h809 (1Cust82.tnt1.mia5.da.uu.net [63.30.194.82]) by bbs.ht.net.cn (8.8.7/8.7.3) with SMTP id GAA06999; Thu, 30 Nov 2000 06:07:59 +0800
Date: Thu, 30 Nov 2000 06:07:59 +0800
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Lady V:  The Pleasure Pill for Women!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

LADY V: The Pleasure Pill for Women!

Men Have Their Viagra®! Finally, A Pill for Women! 

It's Here! The Revolutionary Woman's Sexual Sensation is Now
                           Available.

Researchers are calling Lady V the greatest breakthrough
for women since the Birth Control Pill. And you don't even need
a prescription to get it!

               Welcome to the New Sexual Revolution!

It's no secret that men have been having the time of their
lives since the wonder pill Viagra® was made available. But,
women were left out in the cold with no pill... nothing! 
Well now thanks to an all-star team of medical researchers 
who have been working around the clock, those days are finally
over. The perfect female "pleasure pill" has been created and
you don't even need a prescription. You can now get it from
Lion Sciences!

Lady V is the world's first pleasure pill scientifically 
designed for women. Lady V is an all-natural proprietary 
herbal blend of prosexual nutrients from around the world
synergistically blended to naturally stimulate neurotransmitter
endorphin signals. This magical combination increases targeted
blood flow, unleashes natural stimulator for maximum stimulation,
triggering pleasure responses quickly. Lady V is safe, natural
and doctor-recommended.
Since its introduction Lady V has been taking the world by storm!
>From Malibu to Miami women are enjoying the most intense pleasure
of their lives! 

• 100% Natural
• Safe
• The Highest Quality Pharmaceutical Pure Nutraceuticals
• Guaranteed Potency
• Certified Purity

                     Lady V is Sweeping the Nation!

Women are going crazy over Lady V. Suddenly couples are falling
in love all over again. The passion and pleasure that women are
reporting is off the charts! Lady V has an incredible 88% success
rate. Best of all, while Viagra costs $10 a pill, Lady V costs
less than $1 a pill! It's not just a man's world anymore!

Just look at what a few women have to say:

"I thought my love life was good before, but now it is out of
this world! Lady V is remarkable." — Mary J., Interior Designer

"I haven't smiled like this in a long time. My husband and I 
feel like a couple of 19 year olds again!" — Debra T, Assistant Buyer

"Imagine what it would feel like to have incredible passion
and pleasure anytime you want." — Jennifer C., Film Editor

"Suddenly my husband and I are spending more time in the bedroom
instead of the TV room." — Angie R., Realtor

Ingredients: Vitamin D, Niacin, Vitamin B6, Folic Acid,
Vitamin B12, Avena Sativa, Kava Kava, Guarana, White Willow Extract,
Mura Puama, St. John's Wort, Siberian Ginseng, Cordyceps, Damiana,
and L-Taurine.

Each bottle of Lady V contains 30 tablets.
Take three capsules one hour before romantic activity
as a dietary supplement. 

Risk Free: Double Your Money Back Guarantee

If Lady V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked! 

Order Now: Safe, Fast, Secure, Private

Lady V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Lady V contains 30 tablets.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Lady V  $24


______ 2 Bottles of Lady V $44


______ 3 Bottles of Lady V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ]

International Orders
Please add $18 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       273 S. State Rd. 7, #193
                       Margate, FL 33068-5727               


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Lady V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Lady V helps provide herbal and nutritional support
for female sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.



Received: by ns.secondary.com (8.9.3/8.9.3) id IAA22843 for ietf-openpgp-bks; Wed, 29 Nov 2000 08:04:25 -0800 (PST)
Received: from user3.hushmail.com (user3.hushmail.com [64.40.111.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22837 for <[e-mail]>; Wed, 29 Nov 2000 08:04:23 -0800 (PST)
From: [e-mail]
Received: (from root@localhost) by user3.hushmail.com (8.9.3/8.9.3) id IAA00432; Wed, 29 Nov 2000 08:04:15 -0800
Message-Id: <[e-mail]>
Date: Wed, 29 Nov 2000 15:47:11 -0800 (PST)
Cc: 
To: [e-mail]
Mime-version: 1.0
Content-type: multipart/mixed; boundary="Hushpart_boundary_YKUmQPspBSyfCeLeNMoHurvXpdxiLUho"
Subject: Encoding of hash in El-Gamal signatures
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--Hushpart_boundary_YKUmQPspBSyfCeLeNMoHurvXpdxiLUho
Content-type: text/plain

In section 5.2 of rfc2440, the process of calculating signatures is outlined. 
However, it
is not specified how to convert from the hash to algorithm-specific signature 
input for
all algorithms. It is for RSA (PKCS#1 padding +  DER -encoding of an ASN.1 
DigestInfo) 
and DSA (trivial). For El-Gamal, it doesn't say. I know that GnuPG uses 
an aproach similar
to RSA.

What is the story? How do I convert the hash to El-Gamal input?

Regards
/Bo
--Hushpart_boundary_YKUmQPspBSyfCeLeNMoHurvXpdxiLUho--


IMPORTANT NOTICE:  If you are not using HushMail, this message could have been read easily by the many people who have access to your open personal email messages.
Get your FREE, totally secure email address at http://www.hushmail.com.





Received: by ns.secondary.com (8.9.3/8.9.3) id DAA29047 for ietf-openpgp-bks; Wed, 29 Nov 2000 03:12:37 -0800 (PST)
Received: from pheasantcigar.com (221-host52.summerlin.hs.earthlink.net [206.107.221.52]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA29039 for <[e-mail]>; Wed, 29 Nov 2000 03:12:32 -0800 (PST)
Message-Id: <[e-mail]>
From: "Paul Kent" <[e-mail]>
To: <[e-mail]>
Subject: Best Cigar Prices on the Internet
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Wed, 29 Nov 2000 03:06:51 -0800
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Happy Holidays from WWW.PHEASANTCIGAR.COM

At Pheasant, you will find some of the very best prices
to be found anywhere on the Internet. Most of the time
you will find we have the BEST prices around. If you or
someone you know smokes cigars, check out some of these
prices and compare them to anyone:

Ashton Aged Maduro                     $150.00

CAO Anniversaire Maduro Churchill      $ 95.00

Perdomo 2 Millenario                   $131.00

Pheasant Bundles Churchill (25)        $ 32.27 (!!!)

Puros Indios Toro Especial Maduro      $ 65.00

     That's just a small sample of the cigars we have in
stock right now so come on by and check out
WWW.PHEASANTCIGAR.COM We've been in the wholesale and
retail business for over 5 years now. We have a variety
of shipping options and orders are shipped within
24 hours of your order. While your at our website be sure
to take a photographic tour of one of the finest cigar
establishments in the country! We'll see you there. Thanks.


Received: by ns.secondary.com (8.9.3/8.9.3) id PAA23420 for ietf-openpgp-bks; Wed, 15 Nov 2000 15:09:25 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA23410 for <[e-mail]>; Wed, 15 Nov 2000 15:09:22 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA25096; Wed, 15 Nov 00 18:01:47 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45]) by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id RAA06630; Wed, 15 Nov 2000 17:56:51 -0500 (EST)
Received: from indiana.mit.edu (INDIANA.MIT.EDU [18.18.1.138]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id RAA01100; Wed, 15 Nov 2000 17:56:51 -0500 (EST)
Received: (from warlord@localhost) by indiana.mit.edu (8.9.3) id RAA14051; Wed, 15 Nov 2000 17:56:47 -0500 (EST)
To: "Michael Young" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Iterated and Salted S2K - weakness or unclear specification?
References: <00b301c04f56$4b4b9440$[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 15 Nov 2000 17:56:47 -0500
In-Reply-To: "Michael Young"'s message of "Wed, 15 Nov 2000 17:49:20 -0500"
Message-Id: <[e-mail]>
Lines: 29
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

"Michael Young" <[e-mail]> writes:

> I don't find the spec that hard to understand, but I've now seen
> postings from several people who did (in different ways).
> 
> Conceptually, for segment N (starting with N=0):
>     Create a buffer of size (N + min(count,passphrase.length+salt.length)).

Um, this should be max(), not min(), as if count < passphrase.length +
salt.length, you still use all of the passphrase + length

>     Fill the first N bytes with zeroes.
>     Fill the rest with the salt and passphrase bytes until you run out.
>     Hash this entire buffer.
> In practice, you use a hashing gadget that lets you feed it incrementally,
> and you use as many as you need in parallel.
> 
> At no point do you use the hash output as input.  Yes, the hash
> function itself may do something similar with hash lines internally,
> but that is a carefully-considered aspect of the hash function
> design.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17044 for ietf-openpgp-bks; Wed, 15 Nov 2000 14:45:01 -0800 (PST)
Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17030 for <[e-mail]>; Wed, 15 Nov 2000 14:44:59 -0800 (PST)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA08736; Wed, 15 Nov 2000 17:25:19 -0500 (EST)
Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id RAA11924; Wed, 15 Nov 2000 17:51:52 -0500 (EST)
Message-ID: <00b301c04f56$4b4b9440$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Iterated and Salted S2K - weakness or unclear specification?
Date: Wed, 15 Nov 2000 17:49:20 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I don't find the spec that hard to understand, but I've now seen
postings from several people who did (in different ways).

Conceptually, for segment N (starting with N=0):
    Create a buffer of size (N + min(count,passphrase.length+salt.length)).
    Fill the first N bytes with zeroes.
    Fill the rest with the salt and passphrase bytes until you run out.
    Hash this entire buffer.
In practice, you use a hashing gadget that lets you feed it incrementally,
and you use as many as you need in parallel.

At no point do you use the hash output as input.  Yes, the hash
function itself may do something similar with hash lines internally,
but that is a carefully-considered aspect of the hash function
design.




Received: by ns.secondary.com (8.9.3/8.9.3) id NAA08997 for ietf-openpgp-bks; Wed, 15 Nov 2000 13:52:00 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA08993 for <[e-mail]>; Wed, 15 Nov 2000 13:51:58 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id NAA13493; Wed, 15 Nov 2000 13:26:51 -0800
Date: Wed, 15 Nov 2000 13:26:51 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Iterated and Salted S2K - weakness or unclear specification?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Bo Baldersson writes:
> Have I interpreted the spec wrong when I assume that the text ( sec 3.6.1.3)
> 	
> 	"Then the salt, followed by the passphrase data is repeatedly hashed
> 	until the number of octets specified by the octet count has been hashed"
> 	
> means tha exact 'count'  bytes should be hashed? 

When we say the data is "repeatedly hashed", we mean that it is repeatedly
passed into the same hash context.  So it is hash (salt, passphrase, salt,
passphrase, salt, passphrase, ...) where the part in parentheses has a
length of "count" bytes (or length of salt+passphrase if that is greater).

Hal Finney
PGP Security


Received: by ns.secondary.com (8.9.3/8.9.3) id MAA07373 for ietf-openpgp-bks; Wed, 15 Nov 2000 12:59:13 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA07367 for <[e-mail]>; Wed, 15 Nov 2000 12:59:09 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA23960; Wed, 15 Nov 00 16:06:08 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45]) by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id QAA28848; Wed, 15 Nov 2000 16:06:29 -0500 (EST)
Received: from indiana.mit.edu (INDIANA.MIT.EDU [18.18.1.138]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id QAA19487; Wed, 15 Nov 2000 16:06:21 -0500 (EST)
Received: (from warlord@localhost) by indiana.mit.edu (8.9.3) id QAA13993; Wed, 15 Nov 2000 16:06:21 -0500 (EST)
To: [e-mail]
Cc: [e-mail]
Subject: Re: Iterated and Salted S2K - weakness or unclear specification?
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 15 Nov 2000 16:06:20 -0500
In-Reply-To: [e-mail]'s message of "Wed, 15 Nov 2000 19:34:12 -0800 (PST)"
Message-Id: <[e-mail]>
Lines: 38
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

[e-mail] writes:

> Have I interpreted the spec wrong when I assume that the text ( sec 3.6.1.3)
> 	
> 	"Then the salt, followed by the passphrase data is repeatedly hashed
> 	until the number of octets specified by the octet count has been hashed"
> 	
> means tha exact 'count'  bytes should be hashed? 
> 
> The specification is very unclear in this section.
> 
> Regards
> /Bo

I believe you have interpreted it incorrectly.  The algorithm for each
key-block is, basically:

  HashInit()
  for (i=0; i < key-block#; i++)
    HashUpdate(zero-byte)
  for (i=0; i < byte_count; i += length(salt+passphrase))
    HashUpdate(salt)
    HashUpdate(passphrase)
  HashFinal()

Note that this pseudo-code does not handle the truncation properly for
rounds >= 1.  However, the piece that you are confused about is that
you do NOT finalize the hash at every round through the count.  You
finalize it for each key-block.  So, the whole passphrase is used, and
theoretically can be used many many times in the hash.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00327 for ietf-openpgp-bks; Wed, 15 Nov 2000 12:02:28 -0800 (PST)
Received: from user3.hushmail.com (user3.hushmail.com [64.40.111.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00320 for <[e-mail]>; Wed, 15 Nov 2000 12:02:27 -0800 (PST)
From: [e-mail]
Received: (from root@localhost) by user3.hushmail.com (8.9.3/8.9.3) id MAA29860; Wed, 15 Nov 2000 12:08:14 -0800
Message-Id: <[e-mail]>
Date: Wed, 15 Nov 2000 19:34:12 -0800 (PST)
Cc: 
To: [e-mail]
Mime-version: 1.0
Content-type: multipart/mixed; boundary="Hushpart_boundary_vxfwVdxNYttiRwtxVSFsPztysVqaaTAJ"
Subject: Iterated and Salted S2K - weakness or unclear specification?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--Hushpart_boundary_vxfwVdxNYttiRwtxVSFsPztysVqaaTAJ
Content-type: text/plain

As I have interpreted section 3.6.1.3 of rfc2440 the
iterated and salted S2k works as follows (using my
own worlds):

For each hash context:
zeros + salt + passphrase  is entered the hash-machine and the
hash is performed. The output of this operation becomes input to
it next time until we have hashed exactly 'count' bytes. (The exactness
does not apply if  the length of zeros + salt +passphrase infact is
greater than 'count' though). To achive this, the last time we hash
the input is smaller than the digest-size. It may possibly be of length
1 or 2!!!!!

The attack:
Assume that the output of the hash-algorithm is greater or equal to
the blocksize, hence it will be only one hashcontext. Assume also that
there are passphrases of suitable length for an attacker, i.e. such that
the last round of the iteration has an input of one or two bytes say. This
mean that session keys being a hash (or part of) of these short input
are likely to be used. An attacker could just calculate all hashes of the
 one and two bytes  words (not too many) and try to use them as session
keys.

Have I interpreted the spec wrong when I assume that the text ( sec 3.6.1.3)
	
	"Then the salt, followed by the passphrase data is repeatedly hashed
	until the number of octets specified by the octet count has been hashed"
	
means tha exact 'count'  bytes should be hashed? 

The specification is very unclear in this section.

Regards
/Bo






   
--Hushpart_boundary_vxfwVdxNYttiRwtxVSFsPztysVqaaTAJ--


IMPORTANT NOTICE:  If you are not using HushMail, this message could have been read easily by the many people who have access to your open personal email messages.
Get your FREE, totally secure email address at http://www.hushmail.com.





Received: by ns.secondary.com (8.9.3/8.9.3) id HAA08861 for ietf-openpgp-bks; Fri, 10 Nov 2000 07:33:41 -0800 (PST)
Received: from monet.math.chalmers.se (monet.math.chalmers.se [129.16.167.74]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08835 for <[e-mail]>; Fri, 10 Nov 2000 07:33:37 -0800 (PST)
Received: from math.chalmers.se (localhost [127.0.0.1]) by monet.math.chalmers.se (8.8.5/8.8.5) with ESMTP id QAA02560; Fri, 10 Nov 2000 16:37:36 +0100 (MET)
Message-Id: <[e-mail]>
Date: Fri, 10 Nov 2000 16:40:24 +0100 (MET)
From: Martin Forssen <[e-mail]>
Subject: Re: kmail in KDE 2 implements  pgp/mime encoded / signed mails
To: [e-mail]
cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On  9 Nov, Florian Weimer wrote:
> Moritz Moeller-Herrmann <[e-mail]> writes:
>> I just wanted to inform you of this fact, as IMHO, there has not been
>> an abundance of free, excellent mail clients in the past that had
>> this feature.
>> (Only mutt and Eudora AFAIK)
> 
> Recent development versions of Gnus are supposed to support it, too.

TkRat has had pgp/mime support for some time (since april 1997 to be
more exact).

TkRat is available at http://www.dtek.chalmers.se/~maf/ratatosk

IMHO this is a free, excellent MUA. But I am probably pretty biased.

	/MaF (the author of TkRat)



Received: by ns.secondary.com (8.9.3/8.9.3) id AAA04468 for ietf-openpgp-bks; Fri, 10 Nov 2000 00:41:40 -0800 (PST)
Received: from merrymeet.com ([e-mail] [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04456 for <[e-mail]>; Fri, 10 Nov 2000 00:41:37 -0800 (PST)
Received: from [172.20.1.38] (63.73.97.189) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1); Fri, 10 Nov 2000 00:48:35 -0800
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p04320403b6315a3f60a1@[172.20.1.38]>
In-Reply-To: <5.0.0.25.1.20001110152313.00a7ac10@203.38.66.7>
References: <5.0.0.25.1.20001110152313.00a7ac10@203.38.66.7>
Date: Fri, 10 Nov 2000 00:22:19 -0800
To: Erron Criddle <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: signing & authentication sequences
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 3:30 PM +0800 11/10/00, Erron Criddle wrote:
>To all,
>
>Just wondering if there's a reference anywhere regarding the checking of
>signing keys when authenticating a signature (and for that matter when
>creating a signature), regarding expiry dates, revocation signatures (the
>validity of the same) etc etc.
>
>I thought this would be an implementation issue however I think that the
>Open PGP standard needs to lay down the rules regarding the sequence of
>events that need to take place when signing and authenticating a signature.
>

The OpenPGP standard specifically leaves that open. It provides mechanisms
for that, but the trust and validity model one uses is implementation
specific.

The working group explicitly decided that there would be no mandated trust
model. You can use any trust model you want with it. You can use a PKIX
one, you can use the Web of Trust, or anything in between.

We've encouraged people to write informational RFCs on trust models. Phil
Zimmermann had at one time expressed a desire to write one on the Web of
Trust, but has never done so. Other people have discussed other things.

>I have come up with a sequence of events that need to be checked if one is
>needed.
>

Feel free to write up such a document. The working group supports that. But
it will be a separate RFC from 2440 and descendants.

	Jon



Received: by ns.secondary.com (8.9.3/8.9.3) id XAA24734 for ietf-openpgp-bks; Thu, 9 Nov 2000 23:35:22 -0800 (PST)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA24721 for <[e-mail]>; Thu, 9 Nov 2000 23:35:20 -0800 (PST)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A86E24F0272; Fri, 10 Nov 2000 15:44:46 0800
Message-Id: <5.0.0.25.1.20001110153423.00a70578@203.38.66.7>
X-Sender: ejc@203.38.66.7
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 10 Nov 2000 15:35:29 +0800
To: [e-mail]
From: Erron Criddle <[e-mail]>
Subject: Re: 5.5.3 clarification
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 09:52 AM 6/11/2000 -0800, [e-mail] wrote:

<snip>

>We could also add, "and no resynchronization is used" to the end of
>the second paragraph, just to make that very clear.  This would give
>us:
>
>    Encryption/decryption of the secret data is done in CFB mode using
>    the key created from the passphrase and the Initial Vector from the
>    packet. A different mode is used with V3 keys (which are only RSA)
>    than with other key formats. With V3 keys, the MPI bit count prefix
>    (i.e., the first two octets) is not encrypted.  Only the MPI non-
>    prefix data is encrypted.  Furthermore, the CFB state is
>    resynchronized at the beginning of each new MPI value, so that the
>    CFB block boundary is aligned with the start of the MPI data.
>
>    With V4 keys, a simpler method is used.  All secret MPI values are
>    encrypted in CFB mode, including the MPI bitcount prefix, and no
>    resynchronization is used.
>
>    The 16-bit checksum that follows the algorithm-specific portion is
>    the algebraic sum, mod 65536, of the plaintext of all the algorithm-
>    specific octets (including MPI prefix and data).  With V3 keys, the
>    checksum is stored in the clear.  With V4 keys, the checksum is
>    encrypted like the algorithm-specific data.  Note that no CFB
>    resynchronization is done before the checksum encryption.  The checksum
>    value is used to check that the passphrase was correct.

That looks fine to me Hal.

Regards


Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: [phone]
Tel: + 61 8 9386 9534

http://www.comasp.com
[e-mail]













Received: by ns.secondary.com (8.9.3/8.9.3) id XAA23367 for ietf-openpgp-bks; Thu, 9 Nov 2000 23:29:48 -0800 (PST)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA23349 for <[e-mail]>; Thu, 9 Nov 2000 23:29:45 -0800 (PST)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A72B1610272; Fri, 10 Nov 2000 15:39:23 0800
Message-Id: <5.0.0.25.1.20001110152313.00a7ac10@203.38.66.7>
X-Sender: ejc@203.38.66.7
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 10 Nov 2000 15:30:05 +0800
To: [e-mail]
From: Erron Criddle <[e-mail]>
Subject: signing & authentication sequences
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

To all,

Just wondering if there's a reference anywhere regarding the checking of 
signing keys when authenticating a signature (and for that matter when 
creating a signature), regarding expiry dates, revocation signatures (the 
validity of the same) etc etc.

I thought this would be an implementation issue however I think that the 
Open PGP standard needs to lay down the rules regarding the sequence of 
events that need to take place when signing and authenticating a signature.

I have come up with a sequence of events that need to be checked if one is 
needed.

Regards


Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: [phone]
Tel: + 61 8 9386 9534

http://www.comasp.com
[e-mail]













Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25693 for ietf-openpgp-bks; Thu, 9 Nov 2000 03:41:24 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25688 for <[e-mail]>; Thu, 9 Nov 2000 03:41:21 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 13tq7B-0003UA-00 for [e-mail]; Thu, 09 Nov 2000 12:43:33 +0100
To: [e-mail]
Subject: Re: kmail in KDE 2 implements  pgp/mime encoded / signed mails
References: <00110821025901.24997@hippokrates>
From: Florian Weimer <[e-mail]>
Date: 09 Nov 2000 12:43:33 +0100
In-Reply-To: Moritz Moeller-Herrmann's message of "Wed, 8 Nov 2000 21:02:59 +0100"
Message-ID: <[e-mail]>
Lines: 12
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Moritz Moeller-Herrmann <[e-mail]> writes:

> I just wanted to inform you of this fact, as IMHO, there has not been an 
> abundance of free, excellent mail clients in the past that had this feature. 
> (Only mutt and Eudora AFAIK)

Recent development versions of Gnus are supposed to support it, too.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21751 for ietf-openpgp-bks; Wed, 8 Nov 2000 11:56:18 -0800 (PST)
Received: from rumms.uni-mannheim.de (rumms.uni-mannheim.de [134.155.50.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21738 for <[e-mail]>; Wed, 8 Nov 2000 11:56:15 -0800 (PST)
Received: from hippokrates.jura.uni-mannheim.de (hippokrates.jura.uni-mannheim.de [134.155.40.9]) by rumms.uni-mannheim.de (8.11.0/8.11.0) with ESMTP id eA8K36i13336 for <[e-mail]>; Wed, 8 Nov 2000 21:03:06 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by hippokrates.jura.uni-mannheim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id eA8K31D25139 for [e-mail]; Wed, 8 Nov 2000 21:03:01 +0100
From: Moritz Moeller-Herrmann <[e-mail]>
Organization: Uni Mannheim
Date: Wed, 8 Nov 2000 21:02:59 +0100
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain; charset="iso-8859-1"
To: [e-mail]
Subject: kmail in KDE 2 implements  pgp/mime encoded / signed mails
MIME-Version: 1.0
Message-Id: <00110821025901.24997@hippokrates>
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I just wanted to inform you of this fact, as IMHO, there has not been an 
abundance of free, excellent mail clients in the past that had this feature. 
(Only mutt and Eudora AFAIK)

I can really urge anyone with a  *NIX OS to check it out, it is an excellent 
open sourced (GPL) piece of software, that will work with pgp and gpg.

http://devel-home.kde.org/~kmail/

-- 
Moritz Moeller-Herrmann ICQ #3585990


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA11770 for ietf-openpgp-bks; Tue, 7 Nov 2000 02:29:34 -0800 (PST)
Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA11759 for <[e-mail]>; Tue, 7 Nov 2000 02:29:32 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin247.pg3-nt.dusseldorf.nikoma.de [213.54.98.247]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id LAA21041 for <[e-mail]>; Tue, 7 Nov 2000 11:36:19 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 819492ED46; Tue,  7 Nov 2000 11:07:00 +0100 (CET)
Date: Tue, 7 Nov 2000 11:07:00 +0100
From: Thomas Roessler <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Patenting certain digital signature practices.
Message-ID: <[e-mail]>
Mail-Followup-To: "[e-mail]" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA11764
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Some of you may wish to unleash their employers' legal counsels on
this.  It's quite obvious.

(However, for a change, this is a European and not a US patent.)

----- Forwarded message from PILCH Hartmut <[e-mail]> -----

From: PILCH Hartmut <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Date: Mon, 6 Nov 2000 23:39:04 +0100 (CET)
Subject: EPA-patent auf Extra-Info bei digitalen Signaturen
Comment: This message comes from the debate mailing list.

EP0328232 B1 
Public key/signature cryptosystem with enhanced digital signature certification. 
FISCHER ADDISON M


   Claims
   
   1. In a communications system having a plurality of terminal devices
   (Terminals A to N) coupled to an insecure communications channel (12)
   over which users of said terminal devices may exchange private
   messages, each of said user's having a public key (30) and an
   associated private key (32), an improved method of digitally signing
   and certifying a message to be transmitted characterized by the steps
   of:
   formulating at least a portion of a digital message (20);
   digitally signing said message (40); and
   including within said message an authorizing certificate (28, 116)
   which specifies the authority which has been granted to the signer of
   said message.
   2. A method according to claim 1, further including the step of
   providing at least one field in said message identifying the nature of
   the digital data being transmitted (22).
   3. A method according to claim 1, wherein the formulating step
   includes the step of providing a field allowing the user to insert a
   predetermined comment (26) regarding the data being transmitted.
   4. A method according to claim 1, further including the step of
   applying a hashing function (34) to at least a portion of the message
   to be transmitted to form a presignature hash (36); and wherein said
   digitally signing step includes the step of decrypting said
   presignature hash with said private decrypting key (32) to form said
   digital signature.
   5. A method according to claim 4, further including the step of
   forming a digital signature packet (42) comprising the digital
   signature and a representation of said at least a portion of the
   message to be transmitted.
   6. A method according to claim 1, wherein said authorizing certificate
   (116) defines the cosignature requirements which must accompany the
   signer's signature.
   7. A method according to claim 6, wherein a digital signature by a
   third party indicating approval of the user's signature is required
   (116) thereby defining a counter signature requirement.
   8. A method according to claim 7, wherein the third party countersigns
   (86) by digitally signing the sender's digital signature.
   9. A method according to claim 6, wherein the step of defining
   cosignature requirements includes the step of specifying at least one
   other digital signature which is required to appear in the digital
   message thereby defining a joint signature requirement (116).
   10. A method according to claim 1, wherein said authorizing
   certificate defines limitations as to the authority granted by the
   certificate (116).
   11. A method according to claim 10, further including the step of
   setting a monetary limit for the sender.
   12. A method according to claim 1, wherein said authorizing
   certificate includes at least one field indicative of the degree of
   responsibility delegated to the sender.
   13. A method according to claim 1, wherein said authorizing
   certificate defines a hierarchy of certificates within the transmitted
   message such that a recipient of the message can verify the authority
   of the signer based upon an analysis of the signed message.
     _________________________________________________________________
   
   Data supplied from the esp@cenet database - l2


_______________________________________________
Patents maillist  -  [e-mail]
http://liberte.aful.org/mailman/listinfo/patents



----- End forwarded message -----

-- 
Thomas Roessler                         <[e-mail]>


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA19835 for ietf-openpgp-bks; Mon, 6 Nov 2000 09:44:29 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA19829 for <[e-mail]>; Mon, 6 Nov 2000 09:44:26 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA07609; Mon, 6 Nov 2000 09:52:33 -0800
Date: Mon, 6 Nov 2000 09:52:33 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: 5.5.3 clarification
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Michael Young writes:
> If you're asking whether there is a CFB resync before the checksum, then
> the answer is no.
>
> Perhaps Hal would be willing to change the wording to something like:
>
>     With V4 keys, a simpler method is used.  All secret MPI values 
>     (including their MPI bitcount prefixes) and the checksum are
>     encrypted in CFB mode, without any resynchronization.

This might help, although I don't think it works in terms of the
current explanation, which is:

   Encryption/decryption of the secret data is done in CFB mode using
   the key created from the passphrase and the Initial Vector from the
   packet. A different mode is used with V3 keys (which are only RSA)
   than with other key formats. With V3 keys, the MPI bit count prefix
   (i.e., the first two octets) is not encrypted.  Only the MPI non-
   prefix data is encrypted.  Furthermore, the CFB state is
   resynchronized at the beginning of each new MPI value, so that the
   CFB block boundary is aligned with the start of the MPI data.

   With V4 keys, a simpler method is used.  All secret MPI values are
   encrypted in CFB mode, including the MPI bitcount prefix.

   The 16-bit checksum that follows the algorithm-specific portion is
   the algebraic sum, mod 65536, of the plaintext of all the algorithm-
   specific octets (including MPI prefix and data).  With V3 keys, the
   checksum is stored in the clear.  With V4 keys, the checksum is
   encrypted like the algorithm-specific data.  This value is used to
   check that the passphrase was correct.

I agree that the last sentence of the first paragraph, about CFB
resynchronization, is not clearly stated as only being for V3.  The
first sentence of the paragraph is for both V3 and V4, the next two
sentences are explicitly for V3, and the last is unstated.  It is
meant to only be for V3 but we could clarify that.

Unfortunately referring to checksum encryption in the second paragraph,
as you suggest, may be confusing because the checksum and its encryption
rules are not explained until the third paragraph.

Maybe we could instead add a sentence to that paragraph, after "With
V4 keys, the checksum is encrypted like the algorithm-specific data."
We could add, "Note that no CFB resynchronization is done before the
checksum encryption."

We could also add, "and no resynchronization is used" to the end of
the second paragraph, just to make that very clear.  This would give
us:

   Encryption/decryption of the secret data is done in CFB mode using
   the key created from the passphrase and the Initial Vector from the
   packet. A different mode is used with V3 keys (which are only RSA)
   than with other key formats. With V3 keys, the MPI bit count prefix
   (i.e., the first two octets) is not encrypted.  Only the MPI non-
   prefix data is encrypted.  Furthermore, the CFB state is
   resynchronized at the beginning of each new MPI value, so that the
   CFB block boundary is aligned with the start of the MPI data.

   With V4 keys, a simpler method is used.  All secret MPI values are
   encrypted in CFB mode, including the MPI bitcount prefix, and no
   resynchronization is used.

   The 16-bit checksum that follows the algorithm-specific portion is
   the algebraic sum, mod 65536, of the plaintext of all the algorithm-
   specific octets (including MPI prefix and data).  With V3 keys, the
   checksum is stored in the clear.  With V4 keys, the checksum is
   encrypted like the algorithm-specific data.  Note that no CFB
   resynchronization is done before the checksum encryption.  The checksum
   value is used to check that the passphrase was correct.

I don't know, that last sentence is now left dangling, don't you think?

Hal


Received: by ns.secondary.com (8.9.3/8.9.3) id HAA13317 for ietf-openpgp-bks; Mon, 6 Nov 2000 07:43:33 -0800 (PST)
Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13309 for <[e-mail]>; Mon, 6 Nov 2000 07:43:22 -0800 (PST)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA15194 for <[e-mail]>; Mon, 6 Nov 2000 10:23:17 -0500 (EST)
Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id KAA26394 for <[e-mail]>; Mon, 6 Nov 2000 10:49:31 -0500 (EST)
Message-ID: <006701c04808$e88459e0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
Subject: Re: 5.5.3 clarification
Date: Mon, 6 Nov 2000 10:47:45 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>Regarding the 2 octet checksum (that is encrypted), how do we encrypt:

If you're asking whether there is a CFB resync before the checksum, then
the answer is no.

Perhaps Hal would be willing to change the wording to something like:

    With V4 keys, a simpler method is used.  All secret MPI values 
    (including their MPI bitcount prefixes) and the checksum are
    encrypted in CFB mode, without any resynchronization.

>16 bit checksum = 16 most significant bits (sum of Secret MPI's ASCII 
>values MOD 65536)

Actually, it's mod 2^16, which means the *least* significant bits.
It's raw binary data; there is no character set involved.
The description of the checksum in the spec looks pretty airtight to me.

>this also assumes a big endian system.

The checksumming itself doesn't depend on the encoding system -- you're
adding individual octets (not 16-bit things).  The result is indeed
encoded most-significant-octet-first, like all other multi-octet numbers.




Received: by ns.secondary.com (8.9.3/8.9.3) id AAA28828 for ietf-openpgp-bks; Mon, 6 Nov 2000 00:04:18 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA28823 for <[e-mail]>; Mon, 6 Nov 2000 00:04:17 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id AAA06346; Mon, 6 Nov 2000 00:12:16 -0800
Date: Mon, 6 Nov 2000 00:12:16 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: 5.5.3 clarification
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Erron Criddle writes:
> Regarding the 2 octet checksum (that is encrypted), how do we encrypt:
>
> encrypt (Secret MPI's) + encrypt (2 octet checksum)
>
> or:
>
> encrypt (Secret MPI's + 2 octet checksum)

I'm not sure what distinction you are trying to draw here.  Presumably
"+" refers to concatenation?  With CFB mode you have the effect of a
stream cipher, hence there is no difference between encrypt(a+b) and
encrypt(a)+encrypt(b).

> Also, I am also assuming a 16 bit checksum is:
>
> 16 bit checksum = 16 most significant bits (sum of Secret MPI's ASCII 
> values MOD 65536)

I'm not sure what you mean by the 16 "most significant" bits of a value
which is mod 2^16.  That's just a 16 bit value.

These are not ASCII characters (ASCII is a mapping between typographic
symbols like letters, and binary values).  They are simple binary octets.

> this also assumes a big endian system.

Yes, the 16 bit value is taken in big endian form, i.e. high byte,
then low byte.  This is the general convention in OpenPGP, as noted in
section 3.1.

Hal Finney


Received: by ns.secondary.com (8.9.3/8.9.3) id WAA14159 for ietf-openpgp-bks; Sun, 5 Nov 2000 22:43:59 -0800 (PST)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA14155 for <[e-mail]>; Sun, 5 Nov 2000 22:43:56 -0800 (PST)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A65F110010C; Mon, 06 Nov 2000 14:53:19 0800
Message-Id: <[e-mail]>
X-Sender: ejc/[e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 06 Nov 2000 14:44:19 +0800
To: [e-mail]
From: Erron Criddle <[e-mail]>
Subject: 5.5.3 clarification
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

To all,

Regarding the 2 octet checksum (that is encrypted), how do we encrypt:

encrypt (Secret MPI's) + encrypt (2 octet checksum)

or:

encrypt (Secret MPI's + 2 octet checksum)


Also, I am also assuming a 16 bit checksum is:

16 bit checksum = 16 most significant bits (sum of Secret MPI's ASCII 
values MOD 65536)

this also assumes a big endian system.

Clarification on this would be great as 5.5.3 does not specify either of 
the above.

TIA.

Regards


Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: [phone]
Tel: + 61 8 9386 9534

http://www.comasp.com
[e-mail]













Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13147 for ietf-openpgp-bks; Fri, 3 Nov 2000 11:06:55 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA13143 for <[e-mail]>; Fri, 3 Nov 2000 11:06:53 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA07861; Fri, 3 Nov 2000 11:07:43 -0800
Date: Fri, 3 Nov 2000 11:07:43 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Subkey binding signatures
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> The signature type 0x18 is said to be calculated on the subkey itself and 
> no other
> packets. How can you then have tamper-proof siganture subpackets on that 
> key?
> For key-flags that sure would be needed.

It's not, it is calcualted on the key and then the subkey.  The wording
may not be completely clear, but in 5.2.4 the RFC reads:

   When a signature is made over a key, the hash data starts with the
   octet 0x99, followed by a two-octet length of the key, and then body
   of the key packet. (Note that this is an old-style packet header for
   a key packet with two-octet length.) A subkey signature (type 0x18)
   then hashes the subkey, using the same format as the main key.

The use of the phrase "then hashes the subkey" is meant to imply that
first it hashes the main key, then it hashes the subkey.

Hal


Received: by ns.secondary.com (8.9.3/8.9.3) id KAA10058 for ietf-openpgp-bks; Fri, 3 Nov 2000 10:09:58 -0800 (PST)
Received: from user3.hushmail.com (user3.hushmail.com [64.40.111.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10054 for <[e-mail]>; Fri, 3 Nov 2000 10:09:57 -0800 (PST)
From: [e-mail]
Received: (from root@localhost) by user3.hushmail.com (8.9.3/8.9.3) id KAA15949; Fri, 3 Nov 2000 10:15:38 -0800
Message-Id: <[e-mail]>
Date: Fri, 3 Nov 2000 18:07:35 -0800 (PST)
Cc: 
To: [e-mail]
Mime-version: 1.0
Content-type: multipart/mixed; boundary="Hushpart_boundary_TchgrFHZNalcpeJLomWwGJbdFKFrmwdq"
Subject: Subkey binding signatures
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--Hushpart_boundary_TchgrFHZNalcpeJLomWwGJbdFKFrmwdq
Content-type: text/plain

The signature type 0x18 is said to be calculated on the subkey itself and 
no other
packets. How can you then have tamper-proof siganture subpackets on that 
key?
For key-flags that sure would be needed.
--Hushpart_boundary_TchgrFHZNalcpeJLomWwGJbdFKFrmwdq--


IMPORTANT NOTICE:  If you are not using HushMail, this message could have been read easily by the many people who have access to your open personal email messages.
Get your FREE, totally secure email address at http://www.hushmail.com.





Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA10195 for ietf-openpgp-bks; Fri, 3 Nov 2000 02:42:07 -0800 (PST)
Received: from ns2.tencent.com (szptt103-190.szptt.net.cn [202.103.190.61] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10183 for <[e-mail]>; Fri, 3 Nov 2000 02:41:55 -0800 (PST)
From: [e-mail]
Received: from h809 (1Cust188.tnt3.mia5.da.uu.net [63.30.200.188]) by ns2.tencent.com  with SMTP id SAA05908; Fri, 3 Nov 2000 18:02:05 -0900
Date: Fri, 3 Nov 2000 18:02:05 -0900
Message-Id: <[e-mail]>
To: [e-mail]
Subject: At last, Herbal V, the all natural alternative to V----A!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Herbal V: An Incredible All-Natural Healthy Alternative 


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Herbal V  $28


______ 2 Bottles of Herbal V $48


______ 3 Bottles of Herbal V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.


Received: by ns.secondary.com (8.9.3/8.9.3) id KAA03149 for ietf-openpgp-bks; Thu, 2 Nov 2000 10:39:38 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA03145 for <[e-mail]>; Thu, 2 Nov 2000 10:39:37 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA18758; Thu, 2 Nov 2000 10:40:36 -0800
Date: Thu, 2 Nov 2000 10:40:36 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Forward Secrecy Extensions for OpenPGP
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Steve Coya wrote:
> What makes you think this document has expired? It is currently in the I-D
> directory.

I tried looking in the west coast mirror at ISI:
http://info.internet.isi.edu:80/in-drafts/files.  The draft is not
present there.

I also tried the URL I had used to reference the draft on August 3:
http://www.ietf.org/internet-drafts/draft-brown-pgp-pfs-00.txt.
Apparently, the draft has been updated since then so this URL is no
longer accurate.

I have since tried looking in our working group repository:
http://www.ietf.org/ids.by.wg/openpgp.html.  It's not there; apparently
it was not associated with this WG at the time it was created.

However I have now found the draft at
http://www.ietf.org/internet-drafts/draft-brown-pgp-pfs-01.txt.
Thanks very much for your assistance.

Hal Finney


Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02584 for ietf-openpgp-bks; Thu, 2 Nov 2000 10:20:58 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02580 for <[e-mail]>; Thu, 2 Nov 2000 10:20:56 -0800 (PST)
Received: from scoya.cnri.reston.va.us (scoya.cnri.reston.va.us [10.27.5.106]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10266; Thu, 2 Nov 2000 13:27:12 -0500 (EST)
Date: Thu, 2 Nov 2000 13:23:46 -0500 (Eastern Standard Time)
From: Steve Coya <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Forward Secrecy Extensions for OpenPGP
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

What makes you think this document has expired? It is currently in the I-D
directory.

On Thu, 2 Nov 2000 [e-mail] wrote:

>>The ID has expired, can you supply the URL for this document
>>again?  Thanks -
>>
>>Hal
>>
>>Ben Laurie writes:
>>> You may remember that this WG recommended that Forward Secrecy
>>> Extensions for
>>> OpenPGP <draft-brown-pgp-pfs-01.txt> be published as an Informational
>>> RFC. Well, the IESG rejected that, because they want the WG to review
>>> and ascertain whether this document should
>>> be on the standards track.
>>>
>>> It has come to my notice that for some reason the WG hasn't actually
>>> been told this. So, I'm telling you. Please consider whether this draft
>>> should become a standard.
>>



Received: by ns.secondary.com (8.9.3/8.9.3) id JAA00284 for ietf-openpgp-bks; Thu, 2 Nov 2000 09:41:29 -0800 (PST)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA00279 for <[e-mail]>; Thu, 2 Nov 2000 09:41:27 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA18494; Thu, 2 Nov 2000 09:42:01 -0800
Date: Thu, 2 Nov 2000 09:42:01 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Forward Secrecy Extensions for OpenPGP
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

The ID has expired, can you supply the URL for this document
again?  Thanks -

Hal

Ben Laurie writes:
> You may remember that this WG recommended that Forward Secrecy
> Extensions for
> OpenPGP <draft-brown-pgp-pfs-01.txt> be published as an Informational
> RFC. Well, the IESG rejected that, because they want the WG to review
> and ascertain whether this document should
> be on the standards track.
>
> It has come to my notice that for some reason the WG hasn't actually
> been told this. So, I'm telling you. Please consider whether this draft
> should become a standard.


Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02036 for ietf-openpgp-bks; Wed, 1 Nov 2000 10:23:26 -0800 (PST)
Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA02032 for <[e-mail]>; Wed, 1 Nov 2000 10:23:24 -0800 (PST)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id SAA22813; Wed, 1 Nov 2000 18:29:21 GMT
Message-ID: <[e-mail]>
Date: Wed, 01 Nov 2000 18:29:47 +0000
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
MIME-Version: 1.0
To: OpenPGP WG <[e-mail]>
CC: [e-mail], Steve Coya <[e-mail]>
Subject: Forward Secrecy Extensions for OpenPGP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

You may remember that this WG recommended that Forward Secrecy
Extensions for
OpenPGP <draft-brown-pgp-pfs-01.txt> be published as an Informational
RFC. Well, the IESG rejected that, because they want the WG to review
and ascertain whether this document should
be on the standards track.

It has come to my notice that for some reason the WG hasn't actually
been told this. So, I'm telling you. Please consider whether this draft
should become a standard.

Thanks.

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit."

Robert Woodruff