Subject: Re: draft-ietf-openpgp-rfc2440bis-03.txt

From: [email-masked] (Bodo Moeller)
Date: Mon, 22 Oct 2001 20:02:26 +0200 (CEST)

The "Security Considerations" of the OpenPGP specification should
contain the following item, or words to that effect.  (This was
initially pointed out in my 8 July 1999 message to this list.)

     * Public key packets in the current version 4 format do not
       contain a validity period.  It has been moved to the signature
       packet and appears in the optional key expiration time
       subpacket (section 5.2.3.5), which is to be used only in
       self-signatures.  Unlike with the version 3 public key packet
       format, certification signatures do not automatically cover the
       expiration time.

       When certifying a user ID and a public key given in version 4
       format that has an associated validity period, a signature
       expiration time subpacket (section 5.2.3.9) should be used to
       limit the validity of the certification according to the
       validity of the public key being certified.  Otherwise, if the
       certified key is compromised after it has expired, earlier
       certifications would still appear to be valid if the key is
       fraudulently published with a new self-signature giving an
       updated expiration date.

Probably some warning (or mandatory rule) should also appear earlier
in the text.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Mon, 22 Oct 2001 20:02:26 +0200 (CEST)
To: [email-masked]
From: [email-masked] (Bodo Moeller)
Subject: Re: draft-ietf-openpgp-rfc2440bis-03.txt
Sender: [email-masked]

The "Security Considerations" of the OpenPGP specification should
contain the following item, or words to that effect.  (This was
initially pointed out in my 8 July 1999 message to this list.)

     * Public key packets in the current version 4 format do not
       contain a validity period.  It has been moved to the signature
       packet and appears in the optional key expiration time
       subpacket (section 5.2.3.5), which is to be used only in
       self-signatures.  Unlike with the version 3 public key packet
       format, certification signatures do not automatically cover the
       expiration time.

       When certifying a user ID and a public key given in version 4
       format that has an associated validity period, a signature
       expiration time subpacket (section 5.2.3.9) should be used to
       limit the validity of the certification according to the
       validity of the public key being certified.  Otherwise, if the
       certified key is compromised after it has expired, earlier
       certifications would still appear to be valid if the key is
       fraudulently published with a new self-signature giving an
       updated expiration date.

Probably some warning (or mandatory rule) should also appear earlier
in the text.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

To: IETF-Announce: ;
Subject: RFC 3156 on MIME Security with OpenPGP
Cc: [email-masked], [email-masked]
Date: Fri, 19 Oct 2001 15:16:46 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3156

        Title:	    MIME Security with OpenPGP
        Author(s):  M. Elkins, D. Del Torto, R. Levien, T. Roessler 
        Status:     Standards Track
	Date:       August 2001
        Mailbox:    [email-masked], [email-masked],
                    [email-masked] 
        Pages:      15
        Characters: 26809
        Updates:    RFC 2015

        I-D Tag:    draft-ietf-openpgp-mime-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3156.txt

This document describes how the OpenPGP Message Format can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC 1847.

This document is a product of the An Open Specification for Pretty
Good Privacy Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3156

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3156.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

To: [email-masked]
Subject: Re: separation of signed and encrypted messages
From: Florian Weimer <[email-masked]>
Date: 19 Oct 2001 12:52:30 +0200
Lines: 30
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

> On 17 Oct 2001 10:05:47 +0200, Florian Weimer said:
> 
> > (That's not Werner's fault, the FSF is not interested in contributions
> > from the University of Stuttgart in general.)
> 
> That is a bit too simplistic view.

It's the view most favorable for the FSF. ;-)

The contributions which had already been written were relatively minor
(a fraction of a man month, I think, at least if you exclude the
problem isolation phase and all the testing), so they weren't worth
the extra trouble an individual assignment contract would involve.  Of
course, this has stifled further development, but the FSF should not
be surprised by this.

> For reasons German lawyers - specialized on Free Software issues -
> can't agree with, that university does not want to sign such papers.

However, the FSF still has to tell the university the result of their
consultations. :-/

(We should take this to private mail, I think.)

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

To: IETF-Announce: ;
Subject: RFC 3156 on MIME Security with OpenPGP
Cc: [email-masked], [email-masked]
From: RFC Editor <[email-masked]>
Date: Wed, 17 Oct 2001 14:42:13 -0400
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 3156

        Title:	    MIME Security with OpenPGP
        Author(s):  M. Elkins, D. Del Torto, R. Levien, T. Roessler 
        Status:     Standards Track
	Date:       August 2001
        Mailbox:    [email-masked], [email-masked],
                    [email-masked] 
        Pages:      15
        Characters: 26809
        Updates:    RFC 2015

        I-D Tag:    draft-ietf-openpgp-mime-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3156.txt

This document describes how the OpenPGP Message Format can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC 1847.

This document is a product of the An Open Specification for Pretty
Good Privacy Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

----- End Included Message -----

----------
X-Sun-Data-Type: Multipart
X-Sun-Content-Length: 490
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 22

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3156

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3156.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Subject: Re: separation of signed and encrypted messages
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 17 Oct 2001 10:42:36 +0200
Lines: 23
Sender: [email-masked]

On 17 Oct 2001 10:05:47 +0200, Florian Weimer said:

> (That's not Werner's fault, the FSF is not interested in contributions
> from the University of Stuttgart in general.)

That is a bit too simplistic view.  The fact is that the FSF requires
copyright assignment for all core GNU software (see
http://www.gnu.org/copyleft/why-assign.html).  For reasons German
lawyers - specialized on Free Software issues - can't agree with, that
university does not want to sign such papers.

One of the reasons to found the FSF-Europe ist to tackle such legal
problems.  Eben Moglen is now working with European lawyers to get these
things solved. 

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

To: [email-masked]
Subject: Re: separation of signed and encrypted messages
From: Florian Weimer <[email-masked]>
Date: 17 Oct 2001 10:05:47 +0200
Lines: 18
Sender: [email-masked]

"Michael Young" <[email-masked]> writes:

> >but is there any way to do it, short of rewriting gpg, pgp to include a -d
> > > command similar to the -d command of 2.6.3?
> 
> It doesn't appear that GnuPG has such a switch now.  But it would
> be easy to build.

The diff is a couple of lines.  I can provide details if someone wants
to work on it.  We've got a working patch for 1.0.3 or so, but chances
are minuscule that it will appear in the official GnuPG distribution.
(That's not Werner's fault, the FSF is not interested in contributions
from the University of Stuttgart in general.)

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Date: Tue, 16 Oct 2001 19:40:45 +0100
From: Matthew Byng-Maddick <[email-masked]>
To: vedaal <[email-masked]>
Cc: [email-masked]
Subject: Re: separation of signed and encrypted messages
Organization: Colondot.net
Sender: [email-masked]

On Tue, Oct 16, 2001 at 01:08:23PM -0400, vedaal wrote:
> for an rsa key,
> if one has the session key, ciphertext and plaintext,
> and, at some point, 
> *if*
> md5 is 'fully' broken,
> would it not be possible to retrieve the secret key and passphrase?

Erm. No.

Think about the encryption process in the first place.

MBM

-- 
Matthew Byng-Maddick         <[email-masked]>           http://colondot.net/

From: "vedaal" <[email-masked]>
To: <[email-masked]>, "Michael Young" <[email-masked]>
Subject: Re: separation of signed and encrypted messages
Date: Tue, 16 Oct 2001 14:17:59 -0400
Sender: [email-masked]

- ----- Original Message ----- 
From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 16, 2001 1:31 PM
Subject: Re: separation of signed and encrypted messages

> I think you may have two different uses of symmetric keys mixed up.
> A symmetric key protects the private part of your public/private keypair;
> it is the one generated from your passphrase (using a hash, such as MD5).
> Another "session key" protects the contents of a message; for messages
> encrypted to a public key, it is random, and involves no hashing or
> passphrase.

yes,
am sorry,
did indeed confuse this and thought it was the 'same' symmetric key as the
session key,

thanks for clearing it up,

vedaal

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: separation of signed and encrypted messages
Date: Tue, 16 Oct 2001 13:31:17 -0400
Sender: [email-masked]

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

vedaal wrote:
> for an rsa key,
> if one has the session key, ciphertext and plaintext,
> and, at some point, 
> *if*
> md5 is 'fully' broken,
> would it not be possible to retrieve the secret key and passphrase?

I think you may have two different uses of symmetric keys mixed up.
A symmetric key protects the private part of your public/private keypair;
it is the one generated from your passphrase (using a hash, such as MD5).
Another "session key" protects the contents of a message; for messages
encrypted to a public key, it is random, and involves no hashing or
passphrase.

An "attacker" can already generate any number of session keys and
ciphertexts to go with your plaintext and signature (once you're
willing to reveal that).  They can encrypt those session keys with
your public key.  Giving out the one session key for a particular
ciphertext does no harm, unless that session key is (improperly)
related to others.

If you were considering encrypting directly to a passphrase, and the
hash were *badly* broken (such that you could generate pre-images of a
constrained pattern from an end hash), then indeed, this could be
a concern.  From the session key and salt, you might be able to
back-compute the passphrase.  If it were used elsewhere, then you
could be in trouble.  Still a little far-fetched.  Moreover,
you said "RSA", so I don't think this is what you meant.

From: "vedaal" <[email-masked]>
To: <[email-masked]>, "Michael Young" <[email-masked]>
Subject: Re: separation of signed and encrypted messages
Date: Tue, 16 Oct 2001 13:08:23 -0400
Sender: [email-masked]

- ----- Original Message ----- 
From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 16, 2001 11:29 AM
Subject: Re: separation of signed and encrypted messages

> If you're willing to show the plaintext, why do you care about
> protecting the session key?  Are you reusing it?  This might be an
> issue for a PGPdisk, for example, where one symmetric key protects the
> entire contents...  you can't reveal+prove selected parts.  

for an rsa key,
if one has the session key, ciphertext and plaintext,
and, at some point, 
*if*
md5 is 'fully' broken,
would it not be possible to retrieve the secret key and passphrase?

vedaal

To: "Michael Young" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: separation of signed and encrypted messages
From: Derek Atkins <[email-masked]>
Date: 16 Oct 2001 11:40:18 -0400
Lines: 30
Sender: [email-masked]

Actually, revealing the encrypted-session-key for an OpenPGP message
should give you sufficient information to link the plaintext to the
encrypted message without actually giving away your private key or
passphrase.  Considering that PGP implementations should be choosing
random session keys, this implies that session keys should not be
re-used.

-derek

"Michael Young" <[email-masked]> writes:

> No.  The message(+signature) contents are symmetrically encrypted.
> There is no way to prove that the plaintext generates that specific
> ciphertext without giving up the session key.  Demonstrating
> a decrypted signature or MDC shouldn't convince anyone that the
> full plaintext matches that ciphertext.
> 
> If you're willing to show the plaintext, why do you care about
> protecting the session key?  Are you reusing it?  This might be an
> issue for a PGPdisk, for example, where one symmetric key protects the
> entire contents...  you can't reveal+prove selected parts.  It
> shouldn't be for ordinary OpenPGP uses.  Are you afraid that
> your randomness source has been compromised, such that other
> session keys could be deduced?  If so, you have a serious problem.

-- 
       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
       [email-masked]                        PGP key available

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: separation of signed and encrypted messages
Date: Tue, 16 Oct 2001 11:29:06 -0400
Sender: [email-masked]

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

>but is there any way to do it, short of rewriting gpg, pgp to include a -d
> > command similar to the -d command of 2.6.3?

It doesn't appear that GnuPG has such a switch now.  But it would
be easy to build.

> one could simply {from a remote area, without anyone needed to 'witness'
> the decryption process}
> separate it into the armored signed file, and release that to the
> 'authorities', and show that it had to have come from
> the specific signed and encrypted e-mail in question.

No.  The message(+signature) contents are symmetrically encrypted.
There is no way to prove that the plaintext generates that specific
ciphertext without giving up the session key.  Demonstrating
a decrypted signature or MDC shouldn't convince anyone that the
full plaintext matches that ciphertext.

If you're willing to show the plaintext, why do you care about
protecting the session key?  Are you reusing it?  This might be an
issue for a PGPdisk, for example, where one symmetric key protects the
entire contents...  you can't reveal+prove selected parts.  It
shouldn't be for ordinary OpenPGP uses.  Are you afraid that
your randomness source has been compromised, such that other
session keys could be deduced?  If so, you have a serious problem.

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: re: separation of signed and encrypted messages
Date: Tue, 16 Oct 2001 10:01:57 -0400
Sender: [email-masked]

David Hopwood wrote:

>vedaal wrote:
> is there any way to separate a message that was signed and encrypted
> to a dh key, into a free-standing verifiable signed message?

>If-and-only-if the private encryption key is known, yes. This is no
>different to 'sign and RSA-encrypt'

yes,
but is there any way to do it, short of rewriting gpg, pgp to include a -d
command similar to the -d command of 2.6.3?

on a related note:

the separation that can be done now, is from 2.6.x using the command:
  pgp -da (filename).pgp
which (after giving the correct passphrase), produces
 filename.asc
which is a free-standing armored signed file, verifiable, and displaying the
text of the original message,
but,
is clearly different from an intentional armored signature file, which
usually begins with 'ow' as the first two characters
of the pgp block,

so,

would it be possible to somehow link such a separated signed file, and show
that it had to be from a specific
signed and encrypted file?  {possibly through an mdc tag on the armor}

if it 'could' be done,

then, one would 'not' have to surrender a session key or secret key, to
decrypt a signed and encrypted e-mail,

one could simply {from a remote area, without anyone needed to 'witness' the
decryption process}
separate it into the armored signed file, and release that to the
'authorities', and show that it had to have come from
the specific signed and encrypted e-mail in question.

vedaal

Date: Mon, 15 Oct 2001 04:03:07 +0100
From: David Hopwood <[email-masked]>
To: vedaal <[email-masked]>, [email-masked]
Subject: Re: separation of signed and encrypted messages into free-standing  signed messages -- revisited
Sender: [email-masked]

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

vedaal wrote:
> is there any way to separate a message that was signed and encrypted
> to a dh key, into a free-standing verifiable signed message?

If-and-only-if the private encryption key is known, yes. This is no
different to 'sign and RSA-encrypt'.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

Date: Mon, 15 Oct 2001 03:29:57 +0100
From: David Hopwood <[email-masked]>
To: [email-masked]
Subject: Re: Comments on ECC draft
Sender: [email-masked]

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

"Jivsov, Andrey" wrote:
> [email-masked] wrote:
> > (Note that the FIPS recommended curves over prime fields all are based
> > on pseudo-Mersenne primes.  Of course applications that want to use
> > optimized modular arithmetic for these primes can do so, whether or
> > not special field descriptors are used.)
> 
> US patents 5,159,632, 5,463,690 and 5,271,061 "Method and apparatus for
> public key exchange in a cryptographic system" cover 2^m-C prime field with
> NeXT as an assignee. While there are some patents with J. Solinas as an
> inventor and NSA as an assignee covering Koblitz curves, there are no
> similar patents for the 2^m-C.

<http://cr.yp.to/patents/us/5159632.html> says that there is prior art
for all the interesting claims of this patent, in a CRYPTO '89 article
published more than one year before the patent was filed.
5,271,061 and 5,463,690 are continuations of 5,159,632.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

Date: Mon, 15 Oct 2001 16:02:32 +0200
From: Bodo Moeller <[email-masked]>
To: "Jivsov, Andrey" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on ECC draft
Sender: [email-masked]

On Wed, Oct 03, 2001 at 01:24:36PM -0500, Jivsov, Andrey wrote:

>> From: [email-masked]

>>> Our concern with the special primes 1-2 is that this area seems 
>>> to be covered by patents.

>> What patents?  These should be patents applied for by the NSA (the
>> optimizations for pseudo-Mersenne primes are due to Jerry Solinas).
>> I'm not sure how they'd handle licensing -- the patents for Jerry's
>> algorithms for Koblitz curves have already been issued earlier this
>> year, and presumably licensing would be similar to that, whatever this
>> means.  (Hopefully no restrictions, as for DSA, which is also
>> patented.)
>>
>> (Note that the FIPS recommended curves over prime fields all are based
>> on pseudo-Mersenne primes.  Of course applications that want to use
>> optimized modular arithmetic for these primes can do so, whether or
>> not special field descriptors are used.)

> US patents 5,159,632, 5,463,690 and 5,271,061 "Method and apparatus for
> public key exchange in a cryptographic system" cover 2^m-C prime field with
> NeXT as an assignee. [...]

Thanks for the pointers.

> The 1999 paper "Generalized Mersenne Numbers" by J. Solinas has
> abovementioned patent 5,159,632 in a reference section.

Solinas cites Knuth for efficient arithmetic modulo Mersenne numbers
(m = 2^k - 1) and writes (in the introduction to his 1999 Technical
Report "Generalized Mersenne Numbers")

    "It is [...] of interest to generalize the above technique to
    families of numbers containing primes.

    One such family is due to Richard Crandall [2], namely, the
    integers  2^k - c  for  c  positive and small enough to fit into
    one word.  In this paper, we generalize in a different direction.
    Although there is some overlap, many of the generalized Mersenne
    numbers presented here are not Crandall numbers."

([2] is Crandall's patent 5,159,632.)

So while there are patent issues with efficient arithmetic for
Crandall's pseudo Mersenne prime fields, it seems there is no known
patent affecting Solinas' generalized Mersenne prime fields.

>                                                         This paper describes
> primes in the form 2^m+B_n+...+B_0 instead, where B_n+...+B_0=C is not small
> (applicable to NIST curves). Therefore, group types 1 and 2 from the draft
> can only be used to describe patented fields. 

... where the types applicable to prime fields are defined as follows
(in draft-scherkl-openpgp-ecc-00.txt):

    0: Named curve (followed by curve_name)
    1: Pseudo mersenne prime field F(p) (followed by r and c.
       p = 2^r - c, "below some twopower")
    2: Pseudo mersenne prime field F(p) (followed by r and c.
       p = 2^r + c, "above some twopower")
    3: Prime field F(p) (followed by p)

Type 3 obviously covers any finite prime field, but does not indicate
what optimizations may apply.  Types 1 and 2 also cover any finite
prime field because the definition does not impose limits on  c;
in the case of the Crandall patents you cited above,  c  would
be very small (usually a single processor word), whereas in the case
of NIST curves and similar curves, it would be quite long, but
shorter than  p.  So not *all* curves using on type 1 or 2 fields
would be covered by the Crandall patents.  But maybe a field type
more suitable for generalized Mersenne numbers should be defined.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: separation of signed and encrypted messages into free-standing signed messages -- revisited
Date: Mon, 15 Oct 2001 14:00:50 -0400
Sender: [email-masked]

is there any way to separate a message that was signed and encrypted to a
dh key, into a free-standing verifiable signed message?

am aware that rfc 2440 requires this, but has it actually been 'tested'
with dh keys to see if it is so?

{do 'not' mean to criticize dh keys,
on the contrary, would find it a security 'benefit' of a dh key if it could
'not' be done, even if it required reconsideration of this aspect of the
rfc-2440 }

so far, have been able to separate messages signed and encrypted to an rsa
key, both for rsa and dh/dss signatures

tia,

vedaal

From: "Jivsov, Andrey" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Comments on ECC draft
Date: Wed, 3 Oct 2001 13:24:36 -0500 
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, September 10, 2001 12:50 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Comments on ECC draft
...
> > Our concern with the special primes 1-2 is that this area seems 
> > to be covered by patents.
...
> What patents?  These should be patents applied for by the NSA (the
> optimizations for pseudo-Mersenne primes are due to Jerry Solinas).
> I'm not sure how they'd handle licensing -- the patents for Jerry's
> algorithms for Koblitz curves have already been issued earlier this
> year, and presumably licensing would be similar to that, whatever this
> means.  (Hopefully no restrictions, as for DSA, which is also
> patented.)
>
> (Note that the FIPS recommended curves over prime fields all are based
> on pseudo-Mersenne primes.  Of course applications that want to use
> optimized modular arithmetic for these primes can do so, whether or
> not special field descriptors are used.)

US patents 5,159,632, 5,463,690 and 5,271,061 "Method and apparatus for
public key exchange in a cryptographic system" cover 2^m-C prime field with
NeXT as an assignee. While there are some patents with J. Solinas as an
inventor and NSA as an assignee covering Koblitz curves, there are no
similar patents for the 2^m-C.

The 1999 paper "Generalized Mersenne Numbers" by J. Solinas has
abovementioned patent 5,159,632 in a reference section. This paper describes
primes in the form 2^m+B_n+...+B_0 instead, where B_n+...+B_0=C is not small
(applicable to NIST curves). Therefore, group types 1 and 2 from the draft
can only be used to describe patented fields. 

In contrast with Mersenne prime fields, binary fields were around for a long
time, patent-free for software implementation, sufficiently fast for
software and superior for hardware implementations, allow Koblitz curve
optimizations and are the only current choice for IKE ECC DH groups.

Date: Tue, 2 Oct 2001 14:45:37 -0700
To: Jan Petranek <[email-masked]>, <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: (slight) Error in rfc2440
Sender: [email-masked]

Thanks. I've massaged that paragraph. The new one reads:

OpenPGP combines symmetric-key encryption and public key encryption to
provide confidentiality. When made confidential, first the object is
encrypted using a symmetric encryption algorithm.  Each symmetric key is
used only once. A new "session key" is generated as a random number for
each message. Since it is used only once, the session key is bound to the
message and transmitted with it.  To protect the key, it is encrypted with
the receiver's public key. The sequence is as follows:

Date: Tue, 2 Oct 2001 17:55:46 +0200 (CEST)
From: Jan Petranek <[email-masked]>
To: <[email-masked]>
Subject: (slight) Error in rfc2440
Sender: [email-masked]

Hello out there,

I just read the rfc2440 (on OpenPGP), dated from November 1998 and it seems,
there is an error in it.

In section  2.1. "Confidentiality via Encryption", it says:

"With public-key encryption, the object is encrypted using a symmetric
encryption algorithm."

I believe, it should read

"With symmetric-key encryption, the object is encrypted using a symmetric
      ^^^^^^^^^^^^^
encryption algorithm."

I believe, the author intended to talk about the symmetric encryption here,
because in the next sentences, he discusses the role of symmetric  encryption
used in OpenPGP.
Furthermore, if the key of a symmetric encryption would be public, as the
original text suggests, it would render the encryption completely worthless.

As I'm already messing with the rfc, I just as well may add this
suggestion: In the section describing the paket lenghts, the lenghts in
the text are written in decimal, where they are written in octal in the
examples (of course). It might improve readability, if in the text both
notations would be used, like
"100 (0x64) pakets will follow"

With my best whishes,

Jan Petranek