Subject: Re: Suggestion for the signing subkey problem

From: "Hal Finney" <[email-masked]>
Date: Wed, 25 Jun 2003 12:26:37 -0700

One other point, although I hesitate to mention it, is that we could
consider using this sign-the-topkey trick for encryption subkeys as well
as signature subkeys.  Now, there are two immediate objections to this.
First, as discussed earlier, the fraud does not seem nearly as serious
for encryption subkeys, amounting to tricking someone into encrypting
a message to someone else's key instead of your own.  And second, it
seems impossible anyway, as encryption subkeys can't issue signatures,
so they can't sign the top level key.

However, the impossibility is actually not so bad: RSA encryption subkeys
can issue signatures just fine, even if they don't usually do so; and the
same with ElGamal encryption subkeys.  We have loaded up the spec with
warnings about ElGamal signatures, but in fact those warnings mostly
relate to chosen plaintext attacks.  In this case it is the key owner
who is choosing what to sign, hence those attacks don't apply.  It should
be perfectly safe for an ElGamal or RSA encryption subkey to issue an
appropriate signature on its top-level key.

The first objection still holds, that all this work may not be worth it
(and it is a lot of work for those implementations which don't support
ElGamal signatures) since we don't seem to be able to come up with
much of a fraud by putting someone else's subkey under your own topkey.
Nevertheless there is considerable appeal to being able to verify that
all master-slave key-to-key relationships were fully consensual.

Hal Finney

---

From: Werner Koch <[email-masked]>
Date: Thu, 26 Jun 2003 08:18:30 +0200

> relate to chosen plaintext attacks.  In this case it is the key owner

A practical problem with ElGamal signatures is that verification is
really slow.

-- 
Werner Koch                                      <[email-masked]>
The GnuPG Experts                                http://g10code.com
Free Software Foundation Europe	                 http://fsfeurope.org

---

From: David Shaw <[email-masked]>
Date: Thu, 26 Jun 2003 16:47:22 -0400

> A practical problem with ElGamal signatures is that verification is

True.  I rather like Hal's suggestion to do back-signatures for all
keys, but I wouldn't make it a requirement.  We MUST do it for signing
subkeys to avoid the security problem, but why not make it a MAY for
any other key that someone cares to use it on.

David

---

From: Bill Frantz <[email-masked]>
Date: Mon, 30 Jun 2003 18:57:14 -0700

At 12:26 PM -0700 6/25/03, Hal Finney wrote:
>... since we don't seem to be able to come up with

There doesn't seem to be much difference operationally between putting
someone else's subkey under your topkey, and giving away the secret
component of your own subkey.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz           | "A Jobless Recovery is | Periwinkle -- Consulting
(408)356-8506         | like a Breadless Sand- | 16345 Englewood Ave.
[email-masked] | wich." -- Steve Schear | Los Gatos, CA 95032, USA

Date: Mon, 30 Jun 2003 18:57:14 -0700
To: "Hal Finney" <[email-masked]>, [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: Suggestion for the signing subkey problem
Sender: [email-masked]

At 12:26 PM -0700 6/25/03, Hal Finney wrote:
>... since we don't seem to be able to come up with

There doesn't seem to be much difference operationally between putting
someone else's subkey under your topkey, and giving away the secret
component of your own subkey.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz           | "A Jobless Recovery is | Periwinkle -- Consulting
(408)356-8506         | like a Breadless Sand- | 16345 Englewood Ave.
[email-masked] | wich." -- Steve Schear | Los Gatos, CA 95032, USA

From: Ian Brown <[email-masked]>
To: "'Imad R. Faiad'" <[email-masked]>, ietf-openpgp <[email-masked]>
Subject: RE: Suggestion for the signing subkey problem
Date: Sun, 29 Jun 2003 23:01:26 +0100
Importance: Normal
Sender: [email-masked]

> >I am amazed that this thread is still running several weeks 
> after you 
> >started it, with virtually every response refuting your arguments...
> >
> And what amazes me, is that you have yet to grasp what we are 
> talking about!  Please re-read the thread, some issues have 
> been addressed.  I sincerely hope that you re-read each and 
> every message in that thread, because, you are taylor made 
> for the kind of attacks which can be inflicted to your OpenPGP keys.

I've read all the messages. Your request that subkey capability be
essentially removed has been rejected by all of them.

> >RFC 2440 was published five years ago. I look forward to your draft 
> >removing multiple subkey capability from it.
> I am no paper pusher, and do not have the funding or 
> time/ability to publish RFC's

So I guess this thread is at an end then, with the capability remaining.

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: Suggestion for the signing subkey problem
Date: Sun, 29 Jun 2003 19:14:36 +0200
Sender: [email-masked]

Hello Ian,

On Sat, 28 Jun 2003 00:30:08 +0100, you wrote:

>
>I am amazed that this thread is still running several weeks after you
>started it, with virtually every response refuting your arguments...
>
And what amazes me, is that you have yet to grasp what we are
talking about!  Please re-read the thread, some issues have
been addressed.  I sincerely hope that you re-read each and
every message in that thread, because, you are taylor made
for the kind of attacks which can be inflicted to your
OpenPGP keys.
>>>One person's eccentricity is another person's operational requirement. 
>
>>>OpenPGP should be flexible enough to accomodate both.
>>>
>>Exactly, it's an operational requirement, therefore, please 
>>by all means exclude such requirements from a standard,
>
>You seem unable to understand the difference between enabling
>functionality through a standard and mandating it. RFC 2440 has allowed
>subkeys for several years now. You need to make the case to remove this
>functionality better than you have done so far.
>
No problems, I mean what can I say???
>> If on the other hand you feel that these operational 
>> requirement are the best thing since sliced bread, than by 
>> all means, spawn another RFC to standardize them.
>
>RFC 2440 was published five years ago. I look forward to your draft
>removing multiple subkey capability from it. 
I am no paper pusher, and do not have the funding or time/ability
to publish RFC's

And no offence,

Best Regards

Imad R. Faiad

From: Ian Brown <[email-masked]>
To: "'Imad R. Faiad'" <[email-masked]>
Cc: ietf-openpgp <[email-masked]>
Subject: RE: Suggestion for the signing subkey problem
Date: Sat, 28 Jun 2003 00:30:08 +0100
Importance: Normal
Sender: [email-masked]

I am amazed that this thread is still running several weeks after you
started it, with virtually every response refuting your arguments...

>>One person's eccentricity is another person's operational requirement.

>>OpenPGP should be flexible enough to accomodate both.
>>
>Exactly, it's an operational requirement, therefore, please 
>by all means exclude such requirements from a standard,

You seem unable to understand the difference between enabling
functionality through a standard and mandating it. RFC 2440 has allowed
subkeys for several years now. You need to make the case to remove this
functionality better than you have done so far.
  
> If on the other hand you feel that these operational 
> requirement are the best thing since sliced bread, than by 
> all means, spawn another RFC to standardize them.

RFC 2440 was published five years ago. I look forward to your draft
removing multiple subkey capability from it. 

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: Suggestion for the signing subkey problem
Date: Sat, 28 Jun 2003 01:45:46 +0200
Sender: [email-masked]

Hello David,

On Fri, 27 Jun 2003 10:03:58 -0400, you wrote:

>
>[818D9699]*** PGP SIGNATURE VERIFICATION ***
>[818D9699]*** Hash: SHA1
>[818D9699]*** Status: Good Signature from Invalid Key
>[818D9699]*** Alert: NEVER TRUST A V4 KEY.
>[818D9699]*** Signer: David M. Shaw <[email-masked]>
>[818D9699]*** Note: Signing Key is a Sub-Key!
>[818D9699]*** Key ID: 0xE2665C8749E1CBC9
>[818D9699]*** Fingerprint: FC2A 0E9B 5122 7D7B 5923  2CE6 E266 5C87 49E1
>CBC9 [818D9699]*** Signed: 6/27/2003 4:03:58 PM
>[818D9699]*** Verified: 6/27/2003 11:58:15 PM
>[818D9699]*** BEGIN PGP VERIFIED MESSAGE ***
>
>On Thu, Jun 26, 2003 at 04:56:43PM +0200, Imad R. Faiad wrote:
>
>> As I understand it, sub keys are only justified in the following
>> circumstances:-
>> 1) When the public key algorithm does not support encryption (e.g. DSA).
>> 2) In agreement with a school of thought, which recommends that
>>    it is good practice not to use the same key for signing and
>>    encryption.
>> 
>> Any other arguments beyond the above, are just eccentricities,
>> and will be better addressed by creating another key.
>
>One person's eccentricity is another person's operational requirement.
>OpenPGP should be flexible enough to accomodate both.
>
Exactly, it's an operational requirement, therefore, please by all
means exclude such requirements from a standard, which as I understand
it, defines OpenPGP packet formats.  Operational requirement, depends
on one's taste.  And needless to say, tastes differ, so please do not
burden that standard with one's groups view of what these operational
requirement should be...  I am sure, with some thoughts, you or anyone
for that matter can come up with something, to meet those requirements,
with just the humblest of OpenPGP keys.  If on the other hand
you feel that these operational requirement are the best thing
since sliced bread, than by all means, spawn another RFC
to standardize them.

I do not share your view that OpenPGP should be flexible when that
flexibility leads to complexity. OpenPGP should be as simple as possible,
without compromising security that is, it should be easily implemented,
unambiguous, and understood by it's users.

A lot of users have a hard time as it is, understanding the concepts
of Public Key Encryption. We are creating barriers for users,
and implementors.  As I understand it, OpenPGP is supposed to be
a standard whose end users are supposed to be the masses.
I cannot see how the masses can be served with the operational
requirements of paranoids, I mean those of us who feel impelled
to have off and on line boxes, super duper master keys to be
used in a super duper secure environments, with lesser sub keys which
expire on the hour...  Hey what are you guys protecting? Nukes?
If that is the case, maybe you guys need something more that
Pretty Good Privacy...
>> Therefore, for the sake of simplicity, please permit me to propose
>> that an OpenPGP key be a Master Key of an OpenPGP public key algorithm
>> suitable for signing, and ONE optional encryption sub key of an
>> OpenPGP public key algorithm suitable for encryption (and / or signing
>> if the owner so desires), PERIOD.
>
>I guess I don't really see how this helps.  Remember that both
>multiple subkeys and signing subkeys are from 2440.  These are not new
>inventions in 2440bis, and are already widely supported in the field.
>All versions of PGP (5+) and GnuPG support multiple subkeys.  All
>versions of GnuPG and PGP 8 support signing subkeys.
>
The reason that I have proposed the above, is because I am very concerned
about v4 keys in general, and in particular sub keys.  Also, I do
believe in the principle that less is better, especially so
for crypto software.
>What is under discussion here is a simple fix for a design weakness in
>signing subkeys.  Forcing all v4 keys to have one and only one subkey
>would effectively declare every current OpenPGP implementation
>noncompliant, and even then not solve the problem at hand with
>sign+encrypt subkeys.
>
The problem is a lot more than that.  V4 keys are flowed to begin
with.  Please re-read what I stated in my previous message,
in particular the sections which you sniped.
I think, that this is an problem which should be addressed.
>David
No offense,
and with all respect,

Best Regards

Imad R. Faiad
>[818D9699]*** END PGP VERIFIED MESSAGE ***

Date: Fri, 27 Jun 2003 10:03:58 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Suggestion for the signing subkey problem
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Jun 26, 2003 at 04:56:43PM +0200, Imad R. Faiad wrote:

> As I understand it, sub keys are only justified in the following
> circumstances:-
> 1) When the public key algorithm does not support encryption (e.g. DSA).
> 2) In agreement with a school of thought, which recommends that
>    it is good practice not to use the same key for signing and
>    encryption.
> 
> Any other arguments beyond the above, are just eccentricities,
> and will be better addressed by creating another key.

One person's eccentricity is another person's operational requirement.
OpenPGP should be flexible enough to accomodate both.

> Therefore, for the sake of simplicity, please permit me to propose
> that an OpenPGP key be a Master Key of an OpenPGP public key algorithm
> suitable for signing, and ONE optional encryption sub key of an
> OpenPGP public key algorithm suitable for encryption (and / or signing
> if the owner so desires), PERIOD.

I guess I don't really see how this helps.  Remember that both
multiple subkeys and signing subkeys are from 2440.  These are not new
inventions in 2440bis, and are already widely supported in the field.
All versions of PGP (5+) and GnuPG support multiple subkeys.  All
versions of GnuPG and PGP 8 support signing subkeys.

What is under discussion here is a simple fix for a design weakness in
signing subkeys.  Forcing all v4 keys to have one and only one subkey
would effectively declare every current OpenPGP implementation
noncompliant, and even then not solve the problem at hand with
sign+encrypt subkeys.

David

Date: Thu, 26 Jun 2003 16:47:22 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Suggestion for the signing subkey problem
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

Subject: Re: AES-256 vs AES-128
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Thu, 26 Jun 2003 09:37:05 -0500
Sender: [email-masked]

And, I just picked up Bruce Schnier's new book, and he recomends AES-256 to
get 128-bit actual strength in light of birthday attacks and
meet-in-the-middle attacks.

                      Mike Markowitz                                                                                              
                      <markowitz@infosecco         To:      [email-masked] (Bodo Moeller)                 
                      rp.com>                      cc:      [email-masked]                                                  
                      Sent by:                     Subject: Re: AES-256 vs AES-128                                                
                      owner-ietf-openpgp@m                                                                                        
                      ail.imc.org                                                                                                 

                      06/24/2003 03:54 PM                                                                                         

At 03:10 PM 5/31/2003 +0200, Bodo Moeller wrote:

>Of course arguably 128 bits are by far enough so that you don't really
>have to worry about anything of this -- unless you think that quantum
>attacks might become realistic.

Just when you thought this thread was dead... <g>

Here NSA's current view of the matter (from the recent "CNSS Policy No. 15,

FS-1"
document: http://csrc.nist.gov/cryptval/CNSS15FS.pdf):

"(6) The design and strength of all key lengths of the AES algorithm (i.e.,

128, 192
and 256) are sufficient to protect classified information up to the SECRET
level.
TOP SECRET information will require use of either the 192 or 256 key
lengths."

-mjm

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: Suggestion for the signing subkey problem
Date: Thu, 26 Jun 2003 16:56:43 +0200
Sender: [email-masked]

Hello David,

We are opening a can of worms, and there
will be many more in the future as a result.

Please let me re-iterate:-

As I understand it, sub keys are only justified in the following
circumstances:-
1) When the public key algorithm does not support encryption (e.g. DSA).
2) In agreement with a school of thought, which recommends that
   it is good practice not to use the same key for signing and
   encryption.

Any other arguments beyond the above, are just eccentricities,
and will be better addressed by creating another key.

Therefore, for the sake of simplicity, please permit me to propose
that an OpenPGP key be a Master Key of an OpenPGP public key algorithm
suitable for signing, and ONE optional encryption sub key of an
OpenPGP public key algorithm suitable for encryption (and / or signing
if the owner so desires), PERIOD.

Should the above not be adopted, then, I would like to propose
that subkeys be treated just like any other key.
That is, they ought to be signed by their consumer(s).
After all, when you sign a check, you state the amount, among
other things, no one signs a blank check!
Also, when one signs a contract, one signs the pages
containing the terms of that contract, one does
not append to the later signed blank pages
(to use the analogy of signing OpenPGP v4 keys,
a Power or Attorney to append as many pages),
to be filled in by the other the other party, as,
when, and with whatever, he deems fit.

What you suggested below maybe an acceptable solution as far
as the key owner is concerned, but, what about the consumer?

- From what I could gather, subkeys are attractive, because
they inherit the trust/validity of the master key.
But, isn't that inheritance in breach of the OpenPGP
trust model?

my 2c,

Best regards

Imad R. Faiad

On Tue, 24 Jun 2003 22:57:03 -0400, you wrote:

>
>Hi everyone,
>
>I was thinking about the "stolen signing subkey" problem, and a
>slightly different solution popped up:
>
>What if we create a new "signature in a signature" subpacket that is
>defined as a regular signature contained in a subpacket?  All signing
>subkeys MUST contain such a subpacket in their binding self-signature.
>The "subpacket signature" in this case is made by the signing subkey,
>and on the primary key, hashed as if for a 1F signature.  The end
>result is that the signing subkey has a binding self-signature issued
>by the primary key as we do now, and that binding self-signature has
>an embedded 1F signature on the primary key data issued by the signing
>subkey itself.
>
>One of the nice benefits of using a subpacket here, rather than some
>other scheme is that we can set the critical bit of the subpacket if
>we want to "break" the signing subkey on older implementations, but at
>the same time, we don't have to.
>
>I was considering suggesting a single-purpose subpacket that could
>only be used for making a back-signature from a signing subkey on the
>primary key data, but it started to look like reinventing the wheel.
>We have a good, working, signature format.  If we just stick it in a
>subpacket, we can leverage all that work.
>
>Yes, it is a little odd to contemplate the idea that a subpacket can
>contain a signature that contains subpackets which contains a
>signature...  "Great fleas have little fleas upon their backs to bite
>'em, And little fleas have lesser fleas, and so ad infinitum."
>
>Is this overkill for the exact problem at hand?  Probably.  On the
>brighter side, is certainly a more general solution that could be
>useful elsewhere.  For example, it might replace the (as yet unused)
>signature target subpacket: since we can just stick the target
>signature in this proposed subpacket, we don't need the current target
>subpacket anymore.  It also enables interesting possibilities for the
>notary signature.
>
>David

To: "Hal Finney" <[email-masked]>
Cc: [email-masked]
Subject: Re: Suggestion for the signing subkey problem
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 26 Jun 2003 08:18:30 +0200
Sender: [email-masked]

Date: Thu, 26 Jun 2003 00:39:28 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Suggestion for the signing subkey problem
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Jun 25, 2003 at 12:24:34PM -0700, Hal Finney wrote:

> As far as David's proposal, as I understand it, when a new subkey is
> created, it signs the main key, along the lines we have been
> discussing.  However, rather than putting that signature on the main
> key, we instead put it into a subpacket of the subkey binding
> signature issued by the main key.  Since the subkey creation process
> has access to the private parts of both keys, there is of course no
> difficulty in creating the signatures in this order and putting them
> in these places.

Exactly.  Note, however, that there is no need for the subkey
generation process to have access to the private part of the primary
key.  Since this subkey-on-primary signature does not need to be part
of (i.e. hashed into) the subkey binding signature, and is just
located on the binding signature for convenience, there is no reason
why it can't be in the unhashed section of the binding signature.  The
subpacket should work equally well in either the hashed or unhashed
section.

> The main advantage I see would be that we would not have a new
> signature sitting on the main key, which some old software might
> choke on if it were particularly particular.  Instead we have a new
> kind of subpacket in the subkey binding signature, which hopefully
> most software will ignore if it is non-critical.

[..]

> This proposal does depend on old software ignoring non-critical
> subpackets, in order for newly created subkeys to still be used by
> old software (at least, old software that allowed the use of signing
> subkeys).

Yes.  I suppose it comes down to which is less likely to cause a
problem: a new signature subpacket, or a new signature class (as
suggested below).  I lean towards a signature subpacket for the
various reasons given in this thread thus far.  There is also a minor
advantage in key maintenance.  If a subkey is deleted, the
back-signature goes with it automatically, and the implementation
doesn't have to search for and delete back signatures elsewhere on the
key.

> One concern I have is the rather generic "1F" signature type proposed
> for the subkey-on-key signatures.  It would probably be better to
> use a new signature type specific for this purpose.  We use "18"
> for the topkey-on-subkey signature, so maybe we could use "19" for the
> subkey-on-topkey.  That would reduce the possibility of an existing "1F"
> signature somehow being put to a new and malicious use.  Introducing a
> new signature type would increase the chance of an implementation choking
> when it finds the signature on the top level key, which would be another
> point in favor of David's suggestion to hide the new sig in a subpacket
> of the topkey-on-subkey.

I think this is an excellent suggestion.

David

Date: Wed, 25 Jun 2003 13:34:03 -0700
From: Trevor Perrin <[email-masked]>
Subject: Re: Suggestion for the signing subkey problem
To: Hal Finney <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:24 PM 6/25/2003 -0700, Hal Finney wrote:

>Derek Atkins writes:
> > Hmm, can subkeys have subkeys?
>
>Subkeys, unlike David's fleas, are not presently afflicted in this way.
>However, if they ever suffered such a transformation, we could probably
>link each top and child key in the same way we are proposing to link
>our single level of parenthood.

With a chain of N subkeys, this requires N back-signatures (so 2N total 
signatures).  You could do it with zero or one back-signatures.  Since PGP 
only has N=1, this may not be useful, but I'll point it out anyways:

An alternative to back-signatures was to include the primary key ID as a 
hashed subpacket in a signature produced by the subkey.  David didn't like 
this for subkeys because it would have to be repeated for every signature 
the subkey produced.  But if you have a chain of subkeys, for every subkey 
except the last, you *have* a signature that the subkey produced.

So if you added the primary key ID into subkey-on-subkey signatures, you'd 
only have to do something different for the last key, such as a 
back-signature, or adding the primary key ID into the signatures it produced.

On a separate point, I think subkeys having subkeys could be 
useful[1].  For example, Alice is going on vacation for a month, and 
doesn't want to bring her primary key.  However, she doesn't want to give 
her cellphone a month-long subkey, in case it gets stolen.  So she issues a 
month-long subkey to an online service that she trusts, and then every day 
uses her cellphone to authenticate to the service and get an 8-hour subkey 
under the service's subkey.

[1] http://www.imc.org/ietf-openpgp/mail-archive/msg05262.html

Trevor 

Date: Wed, 25 Jun 2003 12:26:37 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: Suggestion for the signing subkey problem
Sender: [email-masked]

Hal Finney

Date: Wed, 25 Jun 2003 12:24:34 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: Suggestion for the signing subkey problem
Sender: [email-masked]

Derek Atkins writes:
> Hmm, can subkeys have subkeys?

Subkeys, unlike David's fleas, are not presently afflicted in this way.
However, if they ever suffered such a transformation, we could probably
link each top and child key in the same way we are proposing to link
our single level of parenthood.

As far as David's proposal, as I understand it, when a new subkey is
created, it signs the main key, along the lines we have been discussing.
However, rather than putting that signature on the main key, we instead
put it into a subpacket of the subkey binding signature issued by the
main key.  Since the subkey creation process has access to the private
parts of both keys, there is of course no difficulty in creating the
signatures in this order and putting them in these places.

The main advantage I see would be that we would not have a new signature
sitting on the main key, which some old software might choke on if it
were particularly particular.  Instead we have a new kind of subpacket in
the subkey binding signature, which hopefully most software will ignore
if it is non-critical.

David suggests that it could in fact be made critical, but I don't see
any advantage to doing that.  It would not stop the fraud from being
perpetrated on old software, since of course the fraudster would not be
in a position to create the new subpacket and certainly would not create
a bogus one and mark it critical, since that would defeat his purpose.

For a good subkey, all marking it critical would accomplish is to create
an artificial backwards incompatibility, so that this very valid subkey
was spuriously rejected by old software, which would not accomplish
anything useful that I can see.

This proposal does depend on old software ignoring non-critical subpackets,
in order for newly created subkeys to still be used by old software (at
least, old software that allowed the use of signing subkeys).

One concern I have is the rather generic "1F" signature type proposed
for the subkey-on-key signatures.  It would probably be better to
use a new signature type specific for this purpose.  We use "18"
for the topkey-on-subkey signature, so maybe we could use "19" for the
subkey-on-topkey.  That would reduce the possibility of an existing "1F"
signature somehow being put to a new and malicious use.  Introducing a
new signature type would increase the chance of an implementation choking
when it finds the signature on the top level key, which would be another
point in favor of David's suggestion to hide the new sig in a subpacket
of the topkey-on-subkey.

Hal Finney

David Shaw <[email-masked]> writes:
> Hi everyone,
> 
> I was thinking about the "stolen signing subkey" problem, and a
> slightly different solution popped up:
> 
> What if we create a new "signature in a signature" subpacket that is
> defined as a regular signature contained in a subpacket?  All signing
> subkeys MUST contain such a subpacket in their binding self-signature.
> The "subpacket signature" in this case is made by the signing subkey,
> and on the primary key, hashed as if for a 1F signature.  The end
> result is that the signing subkey has a binding self-signature issued
> by the primary key as we do now, and that binding self-signature has
> an embedded 1F signature on the primary key data issued by the signing
> subkey itself.
> 
> One of the nice benefits of using a subpacket here, rather than some
> other scheme is that we can set the critical bit of the subpacket if
> we want to "break" the signing subkey on older implementations, but at
> the same time, we don't have to.
> 
> I was considering suggesting a single-purpose subpacket that could
> only be used for making a back-signature from a signing subkey on the
> primary key data, but it started to look like reinventing the wheel.
> We have a good, working, signature format.  If we just stick it in a
> subpacket, we can leverage all that work.
> 
> Yes, it is a little odd to contemplate the idea that a subpacket can
> contain a signature that contains subpackets which contains a
> signature...  "Great fleas have little fleas upon their backs to bite
> 'em, And little fleas have lesser fleas, and so ad infinitum."
> 
> Is this overkill for the exact problem at hand?  Probably.  On the
> brighter side, is certainly a more general solution that could be
> useful elsewhere.  For example, it might replace the (as yet unused)
> signature target subpacket: since we can just stick the target
> signature in this proposed subpacket, we don't need the current target
> subpacket anymore.  It also enables interesting possibilities for the
> notary signature.
> 
> David

To: David Shaw <[email-masked]>
Cc: [email-masked]
Subject: Re: Suggestion for the signing subkey problem
From: Derek Atkins <[email-masked]>
Date: 25 Jun 2003 14:29:37 -0400
Lines: 52
Sender: [email-masked]

Hmm, can subkeys have subkeys?

-derek

David Shaw <[email-masked]> writes:

> Hi everyone,
> 
> I was thinking about the "stolen signing subkey" problem, and a
> slightly different solution popped up:
> 
> What if we create a new "signature in a signature" subpacket that is
> defined as a regular signature contained in a subpacket?  All signing
> subkeys MUST contain such a subpacket in their binding self-signature.
> The "subpacket signature" in this case is made by the signing subkey,
> and on the primary key, hashed as if for a 1F signature.  The end
> result is that the signing subkey has a binding self-signature issued
> by the primary key as we do now, and that binding self-signature has
> an embedded 1F signature on the primary key data issued by the signing
> subkey itself.
> 
> One of the nice benefits of using a subpacket here, rather than some
> other scheme is that we can set the critical bit of the subpacket if
> we want to "break" the signing subkey on older implementations, but at
> the same time, we don't have to.
> 
> I was considering suggesting a single-purpose subpacket that could
> only be used for making a back-signature from a signing subkey on the
> primary key data, but it started to look like reinventing the wheel.
> We have a good, working, signature format.  If we just stick it in a
> subpacket, we can leverage all that work.
> 
> Yes, it is a little odd to contemplate the idea that a subpacket can
> contain a signature that contains subpackets which contains a
> signature...  "Great fleas have little fleas upon their backs to bite
> 'em, And little fleas have lesser fleas, and so ad infinitum."
> 
> Is this overkill for the exact problem at hand?  Probably.  On the
> brighter side, is certainly a more general solution that could be
> useful elsewhere.  For example, it might replace the (as yet unused)
> signature target subpacket: since we can just stick the target
> signature in this proposed subpacket, we don't need the current target
> subpacket anymore.  It also enables interesting possibilities for the
> notary signature.
> 
> David

-- 
       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

Date: Tue, 24 Jun 2003 22:57:03 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Suggestion for the signing subkey problem
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi everyone,

I was thinking about the "stolen signing subkey" problem, and a
slightly different solution popped up:

What if we create a new "signature in a signature" subpacket that is
defined as a regular signature contained in a subpacket?  All signing
subkeys MUST contain such a subpacket in their binding self-signature.
The "subpacket signature" in this case is made by the signing subkey,
and on the primary key, hashed as if for a 1F signature.  The end
result is that the signing subkey has a binding self-signature issued
by the primary key as we do now, and that binding self-signature has
an embedded 1F signature on the primary key data issued by the signing
subkey itself.

One of the nice benefits of using a subpacket here, rather than some
other scheme is that we can set the critical bit of the subpacket if
we want to "break" the signing subkey on older implementations, but at
the same time, we don't have to.

I was considering suggesting a single-purpose subpacket that could
only be used for making a back-signature from a signing subkey on the
primary key data, but it started to look like reinventing the wheel.
We have a good, working, signature format.  If we just stick it in a
subpacket, we can leverage all that work.

Yes, it is a little odd to contemplate the idea that a subpacket can
contain a signature that contains subpackets which contains a
signature...  "Great fleas have little fleas upon their backs to bite
'em, And little fleas have lesser fleas, and so ad infinitum."

Is this overkill for the exact problem at hand?  Probably.  On the
brighter side, is certainly a more general solution that could be
useful elsewhere.  For example, it might replace the (as yet unused)
signature target subpacket: since we can just stick the target
signature in this proposed subpacket, we don't need the current target
subpacket anymore.  It also enables interesting possibilities for the
notary signature.

David

Date: Tue, 24 Jun 2003 15:54:49 -0500
To: [email-masked] (Bodo Moeller)
From: Mike Markowitz <[email-masked]>
Subject: Re: AES-256 vs AES-128
Cc: [email-masked]
Sender: [email-masked]

At 03:10 PM 5/31/2003 +0200, Bodo Moeller wrote:

>Of course arguably 128 bits are by far enough so that you don't really
>have to worry about anything of this -- unless you think that quantum
>attacks might become realistic.

Just when you thought this thread was dead... <g>

Here NSA's current view of the matter (from the recent "CNSS Policy No. 15, 
FS-1"
document: http://csrc.nist.gov/cryptval/CNSS15FS.pdf):

"(6) The design and strength of all key lengths of the AES algorithm (i.e., 
128, 192
and 256) are sufficient to protect classified information up to the SECRET 
level.
TOP SECRET information will require use of either the 192 or 256 key lengths."

-mjm

Date: Tue, 17 Jun 2003 16:20:57 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: David Shaw <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key flag for authentication
Sender: [email-masked]

On Sun, 15 Jun 2003, David Shaw wrote:

> It doesn't need much documentation.  This is similar to the "This key
> may be used to encrypt communications" or "This key may be used to
> encrypt storage" flags: a usage hint.
>
> I think the proposed flag is a good idea.

Agreed.

Date: Tue, 17 Jun 2003 16:07:38 -0700
From: Trevor Perrin <[email-masked]>
Subject: augmenting subkeys
To: [email-masked]
Sender: [email-masked]

People were discussing the value of subkeys.  I'm kind of a newcomer here, 
and I'm not an implementor, so my opinion doesn't count for much.  But I 
think subkeys are cool.  In fact, PGP could add features to support some 
advanced uses of subkeys.  A few arguments in favor of subkeys, and of 
extending them in a couple ways:

An obvious use of subkeys is to keep the primary key in a more secure/less 
convenient environment, and the subkeys in a less secure/more convenient 
environment, but give them short validity periods to mitigate compromise.

Also, if PGP keys are used for things besides email (TLS, SSH, etc..), then 
the user may want to use his key with multiple devices and applications 
(laptops, desktops, PDAs, cellphones, etc.), so by getting his primary key 
certified, or by giving someone his primary key fingerprint, he can then 
certify subkeys in all these different devices.  This is more convenient 
that getting all his subkeys certified individually, and is more secure 
than sharing the same key with all these devices, since transferring keys 
is risky, using the same key with different protocols isn't a good idea, 
and a compromise/revocation of one subkey won't affect the others.

PKIX is looking at a similar thing with "Proxy Certificates"[1].  So in a 
sense, both PKIX and PGP are exploring a 2-tiered system, where the first 
tier uses TTP certificates to convince Alice of Bob's "primary" key, and 
the second tier is short-lived certificates that Bob issues from his 
primary key to different devices, applications, and services, so he can 
manage validity intervals, limit compromises, and keep the primary key in a 
safer place.

This safer place might be a smartcard, a USB token, the user's main 
computer, or even a network service.    You could imagine some elaborate 
things.  For example, you might split your primary key into shares for use 
with some "proactive threshold signature scheme" and store these shares in 
different places around your home.  Periodically you would bring the shares 
together, "refresh them", so that an attacker would have to steal the 
shares within a single period, and sign your subkeys.

Or you could bring the shares together (say once a week or month) and sign 
a subkey possessed by an intermediary server.  Then every day when your 
fire up your email client, cellphone, etc., you could authenticate to the 
server and get a sub-subkey with, say, an 8 hour lifetime.  Maybe you could 
even give your primary key shares to different online servers, which you 
would choose to be independent so it's unlikely they would all be 
compromised simultaneously.  They would automatically contact each other 
and refresh their shares once a week, and certify the intermediary's subkey.

Anyways, not that anyone should start designing protocols for this, or that 
this should go in the next draft.  But a few additions to the OpenPGP 
format might allow someone to do these types of things, if they wanted to:
  - a better way of binding a subkey to an application protocol, to 
compartmentalize the damage from a compromise - so if your OpenPGP/TLS key 
is compromised, the attacker couldn't turn around and use this key for 
OpenPGP/SSH.  Discussed a bit here [2].
  - sub-subkeys (and sub-sub-subkeys, etc.).  So you can have 
"intermediaries" like above.

Just curious if people think that would be an interesting direction for PGP 
to grow in..

Trevor

[1] http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-06.txt
[2] http://www.imc.org/ietf-openpgp/mail-archive/msg05092.html

Date: Tue, 17 Jun 2003 13:05:04 -0700
From: Trevor Perrin <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
To: David Shaw <[email-masked]>, [email-masked]
Sender: [email-masked]

At 08:30 AM 6/17/2003 -0400, David Shaw wrote:

>On Mon, Jun 16, 2003 at 09:47:59PM -0700, Trevor Perrin wrote:
> > [...]
> > The problem is that there's a forward-linkage from a primary key to a
> > subkey, but no back-linkage from a signing subkey to the primary key.  Hal
> > suggested having the signing subkey also certify the primary key.  I
> > suggested having the signatures produced by the signing subkey have the
> > primary key's ID as a hashed subpacket.
>
>Yes.  There are pros and cons, but on balance I like Hal's solution a
>bit better as it only needs to be done once, presumably at key
>generation time.  The subpacket solution needs to be done every time
>the signing subkey issues a signature.
>
>The subpacket solution does have a nice side effect in that it becomes
>possible to always know the primary key when looking at a subkey
>signature.  Since most keyservers don't support search-by-subkey yet,
>this could be handy. [...]

Another slight advantage is that the relying party doesn't have to verify 
an extra signature.  Also, pre-existing keys with signing subkeys wouldn't 
have to be modified, they could just start issuing signatures with this new 
subpacket.  (On the other hand, with the solution you and Hal advocate, if 
you *do* modify the key by adding a back-signature, then pre-existing 
message signatures can take advantage of it, so maybe this is a wash).

Either solution seems fine.  You also mentioned requiring self-signatures 
on user IDs, which seems like a good thing to insist on, and pretty much 
takes care of the proof-of-possession concern I was raising, I think.

Trevor 

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP Sub Keys
Date: Tue, 17 Jun 2003 22:45:07 +0200
Sender: [email-masked]

Hello Werner,

On Mon, 16 Jun 2003 18:38:08 +0200, you wrote:

>
>On Mon, 16 Jun 2003 18:29:06 +0200, Imad R Faiad said:
>
>> You are assuming that law enforcers are inept morons!
>
>It is a matter of the law and the loopholes it has.  IIRC, the British
>RIP act does not allow to seize a computer but allow a police officer
>to demand the decryption key for a message they have intercepted of
>somehow else got access to.  There is even no need to pass them the
>entire PGP key over including the passphrase, there must be simply a
>mechanism to decrypt a message they "own".  This is also the reason
>GnuPG provides the --{show,override}-session-key options.
>
>> Do yourself a favor, and don't ever use this technique
>> again, it is now public knowledge!
>
>I am pretty sure that Ian - who is FIPR director and co-author of the
>PFS draft - knows very well what is doing.
>
I think you are need of some education, so I am going to take some
time to broaden your perspective...

Haven't you ever heard of the following:-

We are all sprung from the same stock, partakers of the same
nature, and sharers in the same hope;  and although distinctions
among men are necessary to preserve subordination, yet ought
no eminence of situation make us forget that we are all
in the same boat, for he who is placed on the lowest spoke of
fortune's wheel is equally entitled to our regards, as time
will come, and wisest of us knows not how soon, when all
distinctions, save those of goodness and virtue, shall cease,
and death, the grand leveler of all human greatness, reduce
us to the same state.

I do sincerely hope that you will be inspired by the above
and apply it forthwith ;)

Best regards

Imad R. Faiad
>Salam-Shalom,
>   Werner

Date: Tue, 17 Jun 2003 15:32:23 -0400
From: David Shaw <[email-masked]>
To: "Imad R. Faiad" <[email-masked]>
Cc: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Mail-Followup-To: "Imad R. Faiad" <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Jun 17, 2003 at 07:26:24PM +0200, Imad R. Faiad wrote:

> I am afraid that signing subkeys are going to be very
> expensive to implement.  The whole of the keyserver
> infrastructure needs to retro fitted to deal with them.
> You are right that 2440 defined signing master keys years
> ago, however, to be honest with you, this is my second
> encounter with them, and I consider myself a heavy
> PGP user.  TIGER192, SHA1x, & HAVAL-5-160, had more
> widespread use than signing subkeys, if you ask me.
> Yet, we had no qualms about dropping them.

Yes, and I agreed with dropping them, but I don't see a real
inconsistency here.  There is a substantial difference between
dropping hash algorithms that were either unused (MD2), or unusable
(TIGER192 and HAVAL-5-160 had no OID, double-SHA was experimental),
and dropping a used feature from a widely deployed implementation.

As it happens, some keyservers (the LDAP ones) support subkey searches
today.  The newer HKP servers (SKS, ONAK) plan to add support soon.
To be sure, PKS doesn't support it, but frankly, PKS also eats keys on
a regular basis.  If we were going to restrict OpenPGP based on what
some of the PKSes out there could handle without choking, we'd have to
throw away v4 RSA and any key with more than one subkey as well. ;)

I think it is poor practice to restrict OpenPGP based on what a single
broken keyserver can handle, especially since there are many
alternatives, including a few fixed versions of PKS.

If you are very concerned about old keyservers not being able to
retrieve a key given a subkey ID, then I would certainly support an
(optional) subpacket or signature notation to be used on signatures
issued by a signing subkey.  The subpacket would contain the keyid of
the primary key, just to make it easier to find on a keyserver.

(I saw you were unable to verify my message with PGP 8.  For some
reason, signing subkeys only work with the "pgpmail" interface and not
the plugins in PGP 8.  I assume it's a bug, and hopefully it'll be
fixed in the next update.)

David

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Date: Tue, 17 Jun 2003 19:26:24 +0200
Sender: [email-masked]

On Tue, 17 Jun 2003 10:05:30 -0400, you wrote:

>
>[2F17AC17]*** PGP SIGNATURE VERIFICATION ***
>[2F17AC17]*** Hash: SHA1
>[2F17AC17]*** Status: Signing Algorithm Not Supported
>[2F17AC17]*** Signer: David M. Shaw <[email-masked]>
>*** Note: Signing Key is a Sub-Key!
>[2F17AC17]*** Key ID: 0xE2665C8749E1CBC9
>[2F17AC17]*** Fingerprint: FC2A 0E9B 5122 7D7B 5923  2CE6 E266 5C87 49E1
>CBC9 [2F17AC17]*** Signed: 6/17/2003 4:05:30 PM
>[2F17AC17]*** Verified: 6/17/2003 6:55:28 PM
>[2F17AC17]*** BEGIN PGP VERIFIED MESSAGE ***
>
<snip>
>
>With regards to signing subkeys in general, I'd much rather fix the
>problem than drop signing subkeys.  2440 defined signing subkeys years
>ago, and they are already in use today (this message is signed by
>one).  They are very useful in a good number of situations.  To remove
>them now seems like a step backwards.
>
David, I don't think that signing subkeys are a good idea.
Please look at the above verification block.  Furthermore,
I had problems retrieving the signing key from the servers.
So, I grabbed all the keys out there with "David Shaw" as UID.
You probably consider me thick, but there are OpenPGP users
out there who are a lot thicker than I am.
The irony is that, you can achieve the same thing with
a signing master key if you think about it.
I am afraid that signing subkeys are going to be very
expensive to implement.  The whole of the keyserver
infrastructure needs to retro fitted to deal with them.
You are right that 2440 defined signing master keys years
ago, however, to be honest with you, this is my second
encounter with them, and I consider myself a heavy
PGP user.  TIGER192, SHA1x, & HAVAL-5-160, had more
widespread use than signing subkeys, if you ask me.
Yet, we had no qualms about dropping them.
The same should be done for signing subkeys.
The less, the simpler the better.

>David
Best Regards

Imad R. Faiad
>[2F17AC17]*** END PGP VERIFIED MESSAGE ***

To: David Shaw <[email-masked]>
Cc: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
From: Derek Atkins <[email-masked]>
Date: 17 Jun 2003 11:02:15 -0400
Lines: 28
Sender: [email-masked]

Sure, this is fine... Theoretically the real key owner should have
access to both private keys at the same time, so this shouldn't be an
issue.  Using a subpacket is fine.  I still belive this is a MUST ;)

-derek

David Shaw <[email-masked]> writes:

> > I think this is exactly where a notary-style double-signature is
> > useful (and should be required as a MUST).
> 
> So, the primary signs the subkey as before and then the subkey
> notarizes (0x50 sig) this signature?  That sounds good, but we'll end
> up with two signature packets after the signing subkey.  I'm afraid it
> would be likely to confuse pre-2440bis implementations which don't
> expect to see that extra signature there.
> 
> If we put the subkey-on-primary signature IN the original
> primary-on-subkey signature (as a new subpacket), then it won't break
> older implementations.
> 
> David

-- 
       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

Date: Tue, 17 Jun 2003 10:37:15 -0400
From: David Shaw <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Mail-Followup-To: Derek Atkins <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Jun 17, 2003 at 10:13:58AM -0400, Derek Atkins wrote:
> David Shaw <[email-masked]> writes:
> 
> > Yes.  Hal suggested something similar, but to have the signing subkey
> > certify the primary.
> 
> That's not sufficient..  We need both signature keys to cross-certify.
> The attack without cross-certification is that I could generate a
> signing key and then certify that it's a signing subkey of
> [email-masked].

Sorry, I wasn't clear.  I should have said "... in addition to the
current subkey certification from the primary".

> > Does anyone have any thoughts on the details of this?  We already have
> > all the parts needed to have a signing subkey certify the primary
> > (just have the subkey issue a 1F signature).  I like your suggestion
> > to put it in the subkey self-signature since that will avoid the
> > inevitable messiness when a subkey is deleted, but leaves behind the
> > 1F signature.  Putting it in the subkey self-signature keeps things
> > neat.
> 
> I think this is exactly where a notary-style double-signature is
> useful (and should be required as a MUST).

So, the primary signs the subkey as before and then the subkey
notarizes (0x50 sig) this signature?  That sounds good, but we'll end
up with two signature packets after the signing subkey.  I'm afraid it
would be likely to confuse pre-2440bis implementations which don't
expect to see that extra signature there.

If we put the subkey-on-primary signature IN the original
primary-on-subkey signature (as a new subpacket), then it won't break
older implementations.

David

To: David Shaw <[email-masked]>
Cc: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
From: Derek Atkins <[email-masked]>
Date: 17 Jun 2003 10:13:58 -0400
Lines: 39
Sender: [email-masked]

David Shaw <[email-masked]> writes:

> Yes.  Hal suggested something similar, but to have the signing subkey
> certify the primary.

That's not sufficient..  We need both signature keys to cross-certify.
The attack without cross-certification is that I could generate a
signing key and then certify that it's a signing subkey of
[email-masked].

> Does anyone have any thoughts on the details of this?  We already have
> all the parts needed to have a signing subkey certify the primary
> (just have the subkey issue a 1F signature).  I like your suggestion
> to put it in the subkey self-signature since that will avoid the
> inevitable messiness when a subkey is deleted, but leaves behind the
> 1F signature.  Putting it in the subkey self-signature keeps things
> neat.

I think this is exactly where a notary-style double-signature is
useful (and should be required as a MUST).

> With regards to signing subkeys in general, I'd much rather fix the
> problem than drop signing subkeys.  2440 defined signing subkeys years
> ago, and they are already in use today (this message is signed by
> one).  They are very useful in a good number of situations.  To remove
> them now seems like a step backwards.

Fair enough..  I don't like it, but we can at least fix the
certification problems.

> David

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

Date: Tue, 17 Jun 2003 10:05:30 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Jun 17, 2003 at 09:48:31AM -0400, Derek Atkins wrote:
> David Shaw <[email-masked]> writes:
> 
> > On Mon, Jun 16, 2003 at 10:36:58PM -0400, Derek Atkins wrote:
> > > 
> > > Trevor Perrin <[email-masked]> writes:
> > > 
> > > > Bob emails Charlie and says "Hi, I'm your old friend Bob.  Where did
> > > > you bury that treasure we stole?"  Charlie replies "If you're really
> > > > Bob, what's our codeword?  And send it to me signed and encrypted, so
> > > > I'll know which public key is yours."  So Bob does.  But Alice now
> > > > slips Charlie a primary key that has Bob's public key as a signing
> > > > subkey, and Alice's public key as an encryption subkey.  Charlie
> > > > decrypts and verifies the message, and is satisfied that the owner of
> > > > this primary key knows the codeword, and is "Bob".  So he encrypts the
> > > > treasure map to Alice's public key.
> > > 
> > > Except that Alice's subkey wouldn't have a self-signature by Bob's
> > > primary key, so it shouldn't be accepted by Charlie as a valid subkey.
> > 
> > I think Trevor was referring to Alice generating a brand new primary
> > signing key and encryption subkey, and then using the new primary to
> > self-sign Bob's signing subkey (or transform Bob's primary into a
> > subkey and self-sign that).  Alice then is in posession of a key that
> > will correctly verify Bob's signatures, but someone encrypting to the
> > key will encrypt to Alice.
> > 
> > Alice can't issue signatures as Bob, but can attempt to claim existing
> > Bob signatures as her own.
> 
> Well, the obvious fix for this attack is to require all signing keys
> to be authoritative.  If we're going to allow signature subkeys (as
> opposed to just encryption subkeys), then the self-signature on that
> subkey should be a two-factor signature, requiring BOTH secret keys.

Yes.  Hal suggested something similar, but to have the signing subkey
certify the primary.

Does anyone have any thoughts on the details of this?  We already have
all the parts needed to have a signing subkey certify the primary
(just have the subkey issue a 1F signature).  I like your suggestion
to put it in the subkey self-signature since that will avoid the
inevitable messiness when a subkey is deleted, but leaves behind the
1F signature.  Putting it in the subkey self-signature keeps things
neat.

With regards to signing subkeys in general, I'd much rather fix the
problem than drop signing subkeys.  2440 defined signing subkeys years
ago, and they are already in use today (this message is signed by
one).  They are very useful in a good number of situations.  To remove
them now seems like a step backwards.

David

To: David Shaw <[email-masked]>
Cc: [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
Date: 17 Jun 2003 09:48:31 -0400
Lines: 47
Sender: [email-masked]

David Shaw <[email-masked]> writes:

> On Mon, Jun 16, 2003 at 10:36:58PM -0400, Derek Atkins wrote:
> > 
> > Trevor Perrin <[email-masked]> writes:
> > 
> > > Bob emails Charlie and says "Hi, I'm your old friend Bob.  Where did
> > > you bury that treasure we stole?"  Charlie replies "If you're really
> > > Bob, what's our codeword?  And send it to me signed and encrypted, so
> > > I'll know which public key is yours."  So Bob does.  But Alice now
> > > slips Charlie a primary key that has Bob's public key as a signing
> > > subkey, and Alice's public key as an encryption subkey.  Charlie
> > > decrypts and verifies the message, and is satisfied that the owner of
> > > this primary key knows the codeword, and is "Bob".  So he encrypts the
> > > treasure map to Alice's public key.
> > 
> > Except that Alice's subkey wouldn't have a self-signature by Bob's
> > primary key, so it shouldn't be accepted by Charlie as a valid subkey.
> 
> I think Trevor was referring to Alice generating a brand new primary
> signing key and encryption subkey, and then using the new primary to
> self-sign Bob's signing subkey (or transform Bob's primary into a
> subkey and self-sign that).  Alice then is in posession of a key that
> will correctly verify Bob's signatures, but someone encrypting to the
> key will encrypt to Alice.
> 
> Alice can't issue signatures as Bob, but can attempt to claim existing
> Bob signatures as her own.

Well, the obvious fix for this attack is to require all signing keys
to be authoritative.  If we're going to allow signature subkeys (as
opposed to just encryption subkeys), then the self-signature on that
subkey should be a two-factor signature, requiring BOTH secret keys.

It was unclear from the proposed attack that this was using signature
sub-keys.  I personally believe that signature subkeys are a bad idea,
but if the working group seems to feel otherwise I think we should put
some strong language about the pitfalls.

> David

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

Date: Tue, 17 Jun 2003 08:30:02 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Jun 16, 2003 at 09:47:59PM -0700, Trevor Perrin wrote:
> 
> At 11:36 PM 6/16/2003 -0400, David Shaw wrote:
> 
> >On Mon, Jun 16, 2003 at 03:53:11PM -0700, Trevor Perrin wrote:
> >> But here's another angle: suppose Alice gets someone to sign her
> >> legitimate primary signing key.  Then she signs Bob's public key as
> >> a subkey of her primary key.  So even if you've done a
> >> Proof-of-Possession check on Alice's primary key, she can possibly
> >> evade that by introducing a subkey.
> >
> >At least one of the challenge policies (mine) requires that the
> >challenge response comes from the primary key.  The primary is the one
> >that I got a fingerprint for, and the primary is the one I'm signing
> >when I certify the key, so the primary is the one I require the
> >challenge response from.
> 
> Right, but after you've done this, and checked that Alice really possesses 
> her primary private key, Alice can certify a subkey whose private key she 
> doesn't really possess.

Right, but if/when we fix this problem, then all of the certifications
I've made already are still correct (as I ensured it was a primary
that signed the challenge).

> The problem is that there's a forward-linkage from a primary key to a 
> subkey, but no back-linkage from a signing subkey to the primary key.  Hal 
> suggested having the signing subkey also certify the primary key.  I 
> suggested having the signatures produced by the signing subkey have the 
> primary key's ID as a hashed subpacket.

Yes.  There are pros and cons, but on balance I like Hal's solution a
bit better as it only needs to be done once, presumably at key
generation time.  The subpacket solution needs to be done every time
the signing subkey issues a signature.

The subpacket solution does have a nice side effect in that it becomes
possible to always know the primary key when looking at a subkey
signature.  Since most keyservers don't support search-by-subkey yet,
this could be handy.  Still, having the subkey sign the primary seems
cleaner.

David

Date: Mon, 16 Jun 2003 21:47:59 -0700
From: Trevor Perrin <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
To: David Shaw <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:36 PM 6/16/2003 -0400, David Shaw wrote:

>On Mon, Jun 16, 2003 at 03:53:11PM -0700, Trevor Perrin wrote:
> > But here's another angle: suppose Alice gets someone to sign her
> > legitimate primary signing key.  Then she signs Bob's public key as
> > a subkey of her primary key.  So even if you've done a
> > Proof-of-Possession check on Alice's primary key, she can possibly
> > evade that by introducing a subkey.
>
>At least one of the challenge policies (mine) requires that the
>challenge response comes from the primary key.  The primary is the one
>that I got a fingerprint for, and the primary is the one I'm signing
>when I certify the key, so the primary is the one I require the
>challenge response from.

Right, but after you've done this, and checked that Alice really possesses 
her primary private key, Alice can certify a subkey whose private key she 
doesn't really possess.

The problem is that there's a forward-linkage from a primary key to a 
subkey, but no back-linkage from a signing subkey to the primary key.  Hal 
suggested having the signing subkey also certify the primary key.  I 
suggested having the signatures produced by the signing subkey have the 
primary key's ID as a hashed subpacket.

Trevor 

Date: Mon, 16 Jun 2003 23:36:11 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Jun 16, 2003 at 03:53:11PM -0700, Trevor Perrin wrote:

> >> Is there a risk that Alice could trick someone into certifying
> >> that Bob's public key belongs to her?  Then someone receiving a
> >> signed message from Bob might incorrectly think it came from
> >> Alice.
> >
> >Not really, since when Charlie certifies key X, he isn't certifying
> >that it belongs to anyone other than the string in the user ID.
> >Assuming Bob doesn't have a user ID "A-L-I-C-E", this shouldn't be
> >a problem ;)
> >
> >Of course, it is possible for Alice to attach her own name to Bob's
> >key as a second user ID, but that user ID wouldn't be selfsigned
> >and so it would be difficult to get someone else to sign it.
> 
> Probably Alice would first ditch Bob's self-signed user ID, then add
> her own name as an unsigned user ID.  How software would display
> that, and whether users would recognize the danger signs and not
> sign that, I dunno.

PGP shows such user IDs as revoked (not sure why) and refuses to sign
them.

GnuPG shows such user IDs as unsigned, and warns the user before
signing them.  I may go ahead and make the warning even stronger or
just flat out refuse to sign like PGP.

This raises a 2440bis question: given all the recent deprecation of
PGP 2.x stuff, is it worth requiring self-signatures on user IDs now?
If I recall, the only reason that user ID self-signatures are not
currently required was for 2.x compatibility.  Certainly every modern
implementation (5.0+, any GnuPG) generates user ID self-signatures
automatically when a user ID is created.

> But here's another angle: suppose Alice gets someone to sign her
> legitimate primary signing key.  Then she signs Bob's public key as
> a subkey of her primary key.  So even if you've done a
> Proof-of-Possession check on Alice's primary key, she can possibly
> evade that by introducing a subkey.

At least one of the challenge policies (mine) requires that the
challenge response comes from the primary key.  The primary is the one
that I got a fingerprint for, and the primary is the one I'm signing
when I certify the key, so the primary is the one I require the
challenge response from.

David

Date: Mon, 16 Jun 2003 20:22:07 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Sender: [email-masked]

Trevor Perrin wrote:

> Bob emails Charlie and says "Hi, I'm your old friend Bob.  Where did you 
> bury that treasure we stole?"  Charlie replies "If you're really Bob, 
> what's our codeword?  And send it to me signed and encrypted, so I'll know 
> which public key is yours."  So Bob does.  But Alice now slips Charlie a 
> primary key that has Bob's public key as a signing subkey, and Alice's 
> public key as an encryption subkey.  Charlie decrypts and verifies the 
> message, and is satisfied that the owner of this primary key knows the 
> codeword, and is "Bob".  So he encrypts the treasure map to Alice's public key.

This illustrates a problem with signature subkeys.  When a top-level key
is used to sign a message, it is also used to sign the encryption subkeys.
So your message is signed by the same key that said "use one of these
subkeys to encrypt to me".  You have assurance in that case that you
are encrypting the reply to a key endorsed by the person who signed the
original message.

But with signature subkeys, there is no such guarantee.  The subkey is
just dangling.  It isn't making any statements about the other encryption
subkeys or the top-level master key.  That is why this fraud works in
that case.

I seem to recall that many years ago we discussed this problem, or
something similar.  We talked about requiring signature subkeys to
sign the top level key.  That way the two keys, master key and subkey,
would each sign the other.  They would in effect endorse each other as
belonging to the same key holder.

Doing this would eliminate your fraud, as there would be no signature
from Bob's "stolen" key on Alice's master key where she planted it.
This would indicate that the subkey did not belong there, hence that
the encryption subkeys didn't go with it.

Hal Finney

Date: Mon, 16 Jun 2003 23:20:35 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: Derek Atkins <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
Mail-Followup-To: [email-masked], Derek Atkins <[email-masked]>
Sender: [email-masked]

On Mon, Jun 16, 2003 at 10:36:58PM -0400, Derek Atkins wrote:
> 
> Trevor Perrin <[email-masked]> writes:
> 
> > Bob emails Charlie and says "Hi, I'm your old friend Bob.  Where did
> > you bury that treasure we stole?"  Charlie replies "If you're really
> > Bob, what's our codeword?  And send it to me signed and encrypted, so
> > I'll know which public key is yours."  So Bob does.  But Alice now
> > slips Charlie a primary key that has Bob's public key as a signing
> > subkey, and Alice's public key as an encryption subkey.  Charlie
> > decrypts and verifies the message, and is satisfied that the owner of
> > this primary key knows the codeword, and is "Bob".  So he encrypts the
> > treasure map to Alice's public key.
> 
> Except that Alice's subkey wouldn't have a self-signature by Bob's
> primary key, so it shouldn't be accepted by Charlie as a valid subkey.

I think Trevor was referring to Alice generating a brand new primary
signing key and encryption subkey, and then using the new primary to
self-sign Bob's signing subkey (or transform Bob's primary into a
subkey and self-sign that).  Alice then is in posession of a key that
will correctly verify Bob's signatures, but someone encrypting to the
key will encrypt to Alice.

Alice can't issue signatures as Bob, but can attempt to claim existing
Bob signatures as her own.

David

Date: Mon, 16 Jun 2003 20:12:32 -0700
From: Trevor Perrin <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
To: Derek Atkins <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

At 10:36 PM 6/16/2003 -0400, Derek Atkins wrote:

>Trevor Perrin <[email-masked]> writes:
>
> > Bob emails Charlie and says "Hi, I'm your old friend Bob.  Where did
> > you bury that treasure we stole?"  Charlie replies "If you're really
> > Bob, what's our codeword?  And send it to me signed and encrypted, so
> > I'll know which public key is yours."  So Bob does.  But Alice now
> > slips Charlie a primary key that has Bob's public key as a signing
> > subkey, and Alice's public key as an encryption subkey.  Charlie
> > decrypts and verifies the message, and is satisfied that the owner of
> > this primary key knows the codeword, and is "Bob".  So he encrypts the
> > treasure map to Alice's public key.
>
>Except that Alice's subkey wouldn't have a self-signature by Bob's
>primary key, so it shouldn't be accepted by Charlie as a valid subkey.

It would have a self-signature by Alice's primary key, but Charlie wouldn't 
know this was Alice's primary key and not Bob's.  In this example, I was 
assuming there's no web of trust, and Charlie doesn't otherwise know Bob's 
primary key.  Charlie is trying to authenticate Bob and determine Bob's 
keys, and knows that if Bob sends him (Charlie) a signed and encrypted 
message containing a "codeword" they both know, then the signing key must 
belong to Bob.

Charlie then makes the reasonable but wrong assumption that the primary key 
and the encryption subkey that he found associated with this signing subkey 
must also belong to Bob.

If the signature on the actual message contained the primary key ID, as a 
hashed subpacket, then an attacker wouldn't be able to associate her own 
primary key with Bob's signing key, so then Charlie's assumption would be 
correct.  I think.

Trevor 

To: Trevor Perrin <[email-masked]>
Cc: [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
Date: 16 Jun 2003 22:36:58 -0400
Lines: 43
Sender: [email-masked]

Trevor Perrin <[email-masked]> writes:

> Bob emails Charlie and says "Hi, I'm your old friend Bob.  Where did
> you bury that treasure we stole?"  Charlie replies "If you're really
> Bob, what's our codeword?  And send it to me signed and encrypted, so
> I'll know which public key is yours."  So Bob does.  But Alice now
> slips Charlie a primary key that has Bob's public key as a signing
> subkey, and Alice's public key as an encryption subkey.  Charlie
> decrypts and verifies the message, and is satisfied that the owner of
> this primary key knows the codeword, and is "Bob".  So he encrypts the
> treasure map to Alice's public key.

Except that Alice's subkey wouldn't have a self-signature by Bob's
primary key, so it shouldn't be accepted by Charlie as a valid subkey.

> In the "riddle" case, Charlie assumed a relation between the signing
> key and Alice's name which Alice could falsify.  In the "treasure"
> case, Charlie assumed a relation between the signing subkey and
> encryption subkey which Alice could falsify.

Except Alice cannot falsify without the help of Bob.  Why would
bob sign Alice's subkey as her own?

> Before, I suggested adding the "Signer's User ID" subpacket into
> message signatures.  This would work in the "riddle" case, where Alice
> falsifies the name, but not in the "treasure" case, where Alice
> falsifies the relation between subkeys.  Maybe a message signature
> produced by a subkey should also contain a subpacket that gives the
> primary key ID, so an attacker can't present his primary key and
> someone else's subkey to verify someone else's signature.  Haven't
> really thought this through, though..

Without a self-signature on the subkey, how would ie be accepted
as valid?

> Trevor

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

Date: Mon, 16 Jun 2003 18:50:36 -0700
From: Trevor Perrin <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
To: [email-masked]
Sender: [email-masked]

At 04:22 PM 6/16/2003 -0700, Hal Finney wrote:

>How bad is it to make someone else think that a key is yours, when it
>actually is not?  I.e. you have no idea what the private part is.
>[...]
>This could mean that a message signed by someone else might appear to be
>signed by you.  But that's not so significant, as you could have achieved
>the same effect just by copying the plaintext of the message to be signed
>and signing it with one of your own keys.

If you have access to the plaintext - but if Bob sends Charlie a signed and 
encrypted message, and Charlie receives what looks like a signed and 
encrypted message from Alice, that's a neat trick on Alice's part, since 
she'll have effectively signed something she never saw.

For example, Charlie says "I'll give twenty bucks to whoever answers my 
riddle".  Alice doesn't know the answer, but makes Bob's signed and 
encrypted answer appear to come from her.

Something similar: what if Alice's signature subkey belongs to a primary 
key that also has an encryption subkey?  Suppose the signature subkey is 
really Bob's key, but the encryption subkey is legitimately Alice's.  Then 
if Charlie receives a message signed by Bob's signature key and containing 
corroborating info, so Charlie is convinced it really came from Bob, 
Charlie might leap to the false conclusion that Alice's encryption public 
key is also associated with Bob.  I.e.:

Bob emails Charlie and says "Hi, I'm your old friend Bob.  Where did you 
bury that treasure we stole?"  Charlie replies "If you're really Bob, 
what's our codeword?  And send it to me signed and encrypted, so I'll know 
which public key is yours."  So Bob does.  But Alice now slips Charlie a 
primary key that has Bob's public key as a signing subkey, and Alice's 
public key as an encryption subkey.  Charlie decrypts and verifies the 
message, and is satisfied that the owner of this primary key knows the 
codeword, and is "Bob".  So he encrypts the treasure map to Alice's public key.

In the "riddle" case, Charlie assumed a relation between the signing key 
and Alice's name which Alice could falsify.  In the "treasure" case, 
Charlie assumed a relation between the signing subkey and encryption subkey 
which Alice could falsify.

Before, I suggested adding the "Signer's User ID" subpacket into message 
signatures.  This would work in the "riddle" case, where Alice falsifies 
the name, but not in the "treasure" case, where Alice falsifies the 
relation between subkeys.  Maybe a message signature produced by a subkey 
should also contain a subpacket that gives the primary key ID, so an 
attacker can't present his primary key and someone else's subkey to verify 
someone else's signature.  Haven't really thought this through, though..

Trevor

Date: Mon, 16 Jun 2003 16:22:44 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Sender: [email-masked]

How bad is it to make someone else think that a key is yours, when it
actually is not?  I.e. you have no idea what the private part is.

As Trevor points out, with subkeys especially, that's exactly the
situation.  The only key/person vouching for the ownership of the
subkey(s) is the master key and its owner.  Third-party certification
doesn't cover subkeys, and in fact subkeys can be added even after third
parties sign and certify the master key.

So what can you do with this?  If you claim someone else's encryption
key as your own, it would mean (A) you can't decrypt messages sent to
that key, and (B) someone else could.  (The important point is that it
does not allow the obvious attack of letting you read messages intended
for that person.)

I suppose this could be damaging to the sender in some contrived
scenarios: if the government monitored his outgoing email, they might
find him sending a message encrypted to Osama bin Laden's public key.
He would be the victim of a prank; someone else gave him a key which
had a match to ObL's encryption key on it.  But that's pretty far-fetched.

For signatures, it would mean that (A) you could not sign messages with
that key, and (B) someone else could.

This could mean that a message signed by someone else might appear to be
signed by you.  But that's not so significant, as you could have achieved
the same effect just by copying the plaintext of the message to be signed
and signing it with one of your own keys.  And this also might work to
your detriment, as you could be harmed by some signed statement issued
by someone else, on a key you claimed as your own.

So I don't think that either of these attacks is all that serious,
as long as people understand what they mean and don't draw unwarranted
conclusions.

Hal Finney

Date: Mon, 16 Jun 2003 15:53:11 -0700
From: Trevor Perrin <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
To: David Shaw <[email-masked]>, [email-masked]
Sender: [email-masked]

At 06:08 PM 6/16/2003 -0400, David Shaw wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Mon, Jun 16, 2003 at 02:34:26PM -0700, Trevor Perrin wrote:
>
> > I could be wrong, but it seems like PGP keysigning often happens without
> > Proof-of-Possession of the corresponding private key.  For example, at PGP
> > keysigning parties, I think it's common for people to attest that a
> > fingerprint really belongs to them, but not have to produce signatures 
> with
> > the corresponding private key.
>
>That is true.  Some people (like me) send a challenge to the email
>address in the user ID, and require that the key owner sign the
>challenge before I'll sign the key.  There are a few variations on
>this basic idea, some more rigorous than others.
>
> > Is there a risk that Alice could trick someone into certifying that Bob's
> > public key belongs to her?  Then someone receiving a signed message from
> > Bob might incorrectly think it came from Alice.
>
>Not really, since when Charlie certifies key X, he isn't certifying
>that it belongs to anyone other than the string in the user ID.
>Assuming Bob doesn't have a user ID "A-L-I-C-E", this shouldn't be a
>problem ;)
>
>Of course, it is possible for Alice to attach her own name to Bob's
>key as a second user ID, but that user ID wouldn't be selfsigned and
>so it would be difficult to get someone else to sign it.

Probably Alice would first ditch Bob's self-signed user ID, then add her 
own name as an unsigned user ID.  How software would display that, and 
whether users would recognize the danger signs and not sign that, I dunno.

But here's another angle: suppose Alice gets someone to sign her legitimate 
primary signing key.  Then she signs Bob's public key as a subkey of her 
primary key.  So even if you've done a Proof-of-Possession check on Alice's 
primary key, she can possibly evade that by introducing a subkey.

I'm too lazy to spend a nice summer day testing this, but from the draft it 
seems like it might work.  So I still like encouraging use of the "Signer's 
User ID" subpacket in the Security Considerations.

Trevor 

Date: Mon, 16 Jun 2003 18:08:23 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Jun 16, 2003 at 02:34:26PM -0700, Trevor Perrin wrote:

> I could be wrong, but it seems like PGP keysigning often happens without 
> Proof-of-Possession of the corresponding private key.  For example, at PGP 
> keysigning parties, I think it's common for people to attest that a 
> fingerprint really belongs to them, but not have to produce signatures with 
> the corresponding private key.

That is true.  Some people (like me) send a challenge to the email
address in the user ID, and require that the key owner sign the
challenge before I'll sign the key.  There are a few variations on
this basic idea, some more rigorous than others.

> Is there a risk that Alice could trick someone into certifying that Bob's 
> public key belongs to her?  Then someone receiving a signed message from 
> Bob might incorrectly think it came from Alice.

Not really, since when Charlie certifies key X, he isn't certifying
that it belongs to anyone other than the string in the user ID.
Assuming Bob doesn't have a user ID "A-L-I-C-E", this shouldn't be a
problem ;)

Of course, it is possible for Alice to attach her own name to Bob's
key as a second user ID, but that user ID wouldn't be selfsigned and
so it would be difficult to get someone else to sign it.

David

Date: Mon, 16 Jun 2003 14:34:26 -0700
From: Trevor Perrin <[email-masked]>
Subject: PoP & Signer's User ID subpacket?
To: [email-masked]
Sender: [email-masked]

I could be wrong, but it seems like PGP keysigning often happens without 
Proof-of-Possession of the corresponding private key.  For example, at PGP 
keysigning parties, I think it's common for people to attest that a 
fingerprint really belongs to them, but not have to produce signatures with 
the corresponding private key.

Is there a risk that Alice could trick someone into certifying that Bob's 
public key belongs to her?  Then someone receiving a signed message from 
Bob might incorrectly think it came from Alice.

Maybe, as a Security Consideration, the "Signer's User ID" subpacket should 
always be included in signatures.  If Bob always included this subpacket in 
his signatures, then no-one could be tricked into thinking Bob's signed 
messages really came from Alice.

Trevor 

To: "Imad R. Faiad" <[email-masked]>
Cc: [email-masked]
Subject: Re: OpenPGP Sub Keys
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Mon, 16 Jun 2003 18:38:08 +0200
Sender: [email-masked]

On Mon, 16 Jun 2003 18:29:06 +0200, Imad R Faiad said:

> You are assuming that law enforcers are inept morons!

It is a matter of the law and the loopholes it has.  IIRC, the British
RIP act does not allow to seize a computer but allow a police officer
to demand the decryption key for a message they have intercepted of
somehow else got access to.  There is even no need to pass them the
entire PGP key over including the passphrase, there must be simply a
mechanism to decrypt a message they "own".  This is also the reason
GnuPG provides the --{show,override}-session-key options.

> Do yourself a favor, and don't ever use this technique
> again, it is now public knowledge!

I am pretty sure that Ian - who is FIPR director and co-author of the
PFS draft - knows very well what is doing.

Salam-Shalom,

   Werner

From: Ian Brown <[email-masked]>
To: "'Imad R. Faiad'" <[email-masked]>
Cc: ietf-openpgp <[email-masked]>
Subject: RE: OpenPGP Sub Keys (Was: key flag for authentication)
Date: Mon, 16 Jun 2003 17:12:57 +0100
Importance: Normal
Sender: [email-masked]

> You are assuming that law enforcers are inept morons!

Nope. But if you no longer have a specific private key yourself, it
can't be seized no matter what rubber-hose cryptanalysis is applied.
Therefore any ciphertext that has previously been captured on-the-wire
cannot be decrypted.

Any message that you still have stored can be requisitioned. As I said,
I don't keep the majority of messages for any length of time.

>The mere fact that they are being discussed in a public forum 
>such as this makes them useless.

You obviously didn't read them carefully enough.

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP Sub Keys (Was: key flag for authentication)
Date: Mon, 16 Jun 2003 18:29:46 +0200
Sender: [email-masked]

Dear Ian,

Now, this defeats the purpose of your "short-lifetime encryption
subkeys"!

You are assuming that law enforcers are inept morons!

This is a false sense of security.

Unless you can outsmart them, which very few can indeed,
never contemplate to circumvent the law by resorting
to such naive tricks.  The mere fact that they are being
discussed in a public forum such as this makes them useless.
I am sure that those authorized to seize Keys would
have been trained to spot all sorts of techniques that
a key holder will resort to in order to frustrate their effort.

Do yourself a favor, and don't ever use this technique
again, it is now public knowledge!

my 2c

Best Regards

Imad R. Faiad

On Mon, 16 Jun 2003 14:38:25 +0100, you wrote:

>
>> You clearly don't archive your encrypted email...
>
>Indeed -- I decrypt messages before saving them (and use separate
>storage encryption to protect the mail store.) Nor do I save every
>message sent and received (which I know some people do).
>

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP Sub Keys (Was: key flag for authentication)
Date: Mon, 16 Jun 2003 18:29:06 +0200
Sender: [email-masked]

Dear Ian,

Now, this defeats the purpose of your "short-lifetime encryption
subkeys"!

You are assuming that law enforcers are inept morons!

This is a false sense of security.

Unless you can outsmart them, which very few can indeed,
never contemplate to circumvent the law by resorting
to such naive tricks.  The mere fact that they are being
discussed in a public forum such as this makes them useless.
I am sure that those authorized to seize Keys would
have been trained to spot all sorts of techniques that
a key holder will resort to in order to frustrate their effort.

Do yourself a favor, and don't ever use this technique
again, it is now public knowledge!

my 2c

Best Regards

Imad R. Faiad

On Mon, 16 Jun 2003 14:38:25 +0100, you wrote:

>
>> You clearly don't archive your encrypted email...
>
>Indeed -- I decrypt messages before saving them (and use separate
>storage encryption to protect the mail store.) Nor do I save every
>message sent and received (which I know some people do).
>

Date: Mon, 16 Jun 2003 16:12:35 +0100
From: Adam Back <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: Ian Brown <[email-masked]>, "'ietf-openpgp'" <[email-masked]>, Adam Back <[email-masked]>
Subject: Re: OpenPGP Sub Keys (Was: key flag for authentication)
Sender: [email-masked]

The format of your mail storage encryption is an orthoganl issue.  (If
you prefer it there is nothing stopping you protecting your mailbox as
a whole, or mails within it with pgp formats).  Just decrypt with the
communications private key and re-encrypt with the storage public key,
or symmetric key (it is after all a message to your self where public
key is not necessarily needed).

In this way you have separated the key management of storage keys vs
communications keys vs signing keys.  Storage keys and signing keys it
is usually convenient to have long lived.  Encryption keys it is more
secure to have short lived.  (Think forward secrecy.)

The fact that your storage key is necesarrily long lived presents a
much leser risk: to make use of storage decryption keys, the attacker
first has to seize your machine (or in your case ask the university /
ISP for the encrypted mailbox).  Encrypted emails on the other hand
can be eavesdropped by the ISP, hackers and law-enforcement.  There
are many people who use their PGP keys only on systems they control.

There are at least 3 different ways to achieve storage encryption:
store the mailbox in an encrypted filesystem (convenient on linux,
windows etc); decrypt and re-encrypt (with a storage key) each mail as
you read it storing the modified re-encrypted mail back in the
mailbox; find or patch a mail client to automatically work from PGP
(or otherwise) storage key encrypted mail box.

If on the other hand you rely on message encryption to protect your
mail, you have to retain the corresponding private key esentially
indefinately which is a long term security risk.  Were the key you
have since 2.0 days compromised and someone were out to get you,
they'd get every mail you ever received since 91 or 92.  I'd argue
that this is a bad idea, but I guess it depends on your perceived
threats.  For me at least I intentionally revoked and deleted the
private key of my older key to achieve forward secrecy.  (First I had
to re-encrypt a few things encrypted with it).

Adam

On Mon, Jun 16, 2003 at 10:21:57AM -0400, Derek Atkins wrote:
> 
> Ian Brown <[email-masked]> writes:
> 
> > > You clearly don't archive your encrypted email...
> > 
> > Indeed -- I decrypt messages before saving them (and use separate
> > storage encryption to protect the mail store.) Nor do I save every
> > message sent and received (which I know some people do).
> 
> I've still got messages encrypted with PGP 2.0 sitting in my
> mail storage.  The pgp encryption is better than any disk
> encryption I could get -- especially considering that I dont
> maintain my disk storage or backups myself. ;)
> 
> The wonders of "distributed computing"...

To: Ian Brown <[email-masked]>
Cc: "'Imad R. Faiad'" <[email-masked]>, "'ietf-openpgp'" <[email-masked]>
Subject: Re: OpenPGP Sub Keys (Was: key flag for authentication)
From: Derek Atkins <[email-masked]>
Date: 16 Jun 2003 10:21:57 -0400
Lines: 22
Sender: [email-masked]

Ian Brown <[email-masked]> writes:

> > You clearly don't archive your encrypted email...
> 
> Indeed -- I decrypt messages before saving them (and use separate
> storage encryption to protect the mail store.) Nor do I save every
> message sent and received (which I know some people do).

I've still got messages encrypted with PGP 2.0 sitting in my
mail storage.  The pgp encryption is better than any disk
encryption I could get -- especially considering that I dont
maintain my disk storage or backups myself. ;)

The wonders of "distributed computing"...

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

To: "Imad R. Faiad" <[email-masked]>
Cc: [email-masked]
Subject: Re: OpenPGP Sub Keys
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Mon, 16 Jun 2003 15:58:40 +0200
Sender: [email-masked]

On Mon, 16 Jun 2003 14:30:08 +0200, Imad R Faiad said:

> Let me add, and no offence of course, from the fact that you are
> relegating those short-lifetime signing sub keys to a less secure
> environment, I infer that you have no confidence in them, so how

There is a huge difference in chances to get compromised between a
networked and daily used box and a non-networked box somewhere else
used only for certification.  You can't remotely attack that
certification box as long as you take simple precautions like
transferring the data on a floppy etc.

All software has bugs and there are almost always known or not yet
known exploits.  Cutting the connection between a possible attacker by
manually transferring data is a sound precaution against most exploits
- it would be a bit annoying for the bulk of everydays work, though.

From: Ian Brown <[email-masked]>
To: "'Derek Atkins'" <[email-masked]>
Cc: "'Imad R. Faiad'" <[email-masked]>, "'ietf-openpgp'" <[email-masked]>
Subject: RE: OpenPGP Sub Keys (Was: key flag for authentication)
Date: Mon, 16 Jun 2003 14:38:25 +0100
Importance: Normal
Sender: [email-masked]

> You clearly don't archive your encrypted email...

Indeed -- I decrypt messages before saving them (and use separate
storage encryption to protect the mail store.) Nor do I save every
message sent and received (which I know some people do).

To: Ian Brown <[email-masked]>
Cc: "'Imad R. Faiad'" <[email-masked]>, ietf-openpgp <[email-masked]>
Subject: Re: OpenPGP Sub Keys (Was: key flag for authentication)
From: Derek Atkins <[email-masked]>
Date: 16 Jun 2003 09:31:26 -0400
Lines: 17
Sender: [email-masked]

Ian Brown <[email-masked]> writes:

> Another "eccentricity" I am fond of is short-lifetime encryption subkeys
> that can be deleted once they have expired, reducing the impact of the
> above-mentioned key seizure powers. I currently (manually) generate such
> keys valid for one month; if I ever got round to automating this, I
> would go for a week or less...
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA127BBD5

You clearly don't archive your encrypted email...

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

From: "Richard Laager" <[email-masked]>
To: "'Imad R. Faiad'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OpenPGP Sub Keys (Was: key flag for authentication)
Date: Mon, 16 Jun 2003 08:27:40 -0500
Organization: Wikstrom Telecom Internet
Importance: Normal
Sender: [email-masked]

> Let me add, and no offence of course, from the fact that you are
> relegating those short-lifetime signing sub keys to a less secure
> environment, I infer that you have no confidence in them, so how
> do you expect others to trust such keys, or signatures generated
> by them for that matter?  You might as well not sign at all.

Less secure = less confidence != no confidence. Here's an example
(fictional, but this is what I would do if I could):

I store my long term primary key on a floppy. When I need the primary key
(to create a new subkey or to sign another key), I do that signing on a
secure stand-alone workstation. When I'm not using that floppy, I store the
key off-site in a safe-deposit box. The less secure subkeys are stored on a
laptop. Now, I believe my laptop is secure, but it's subject to theft. If
it's stolen, I can simply revoke that signing subkey. Now, what happens if
I leave for a lunch break and someone steals my signing subkey? If I notice
it, I can revoke the subkey. By having short-term subkeys, I can limit the
number of legitimate signatures that are invalidated by this. Also, if the
subkey expires in a week or month, the attacker will have to repeat the
subkey theft. This increases their chances of getting caught.

This is no worse than people who keep their primary key on said laptop and
use it for signing. It's quite obviously more secure.

Richard Laager

From: Ian Brown <[email-masked]>
To: "'Imad R. Faiad'" <[email-masked]>, ietf-openpgp <[email-masked]>
Subject: RE: OpenPGP Sub Keys (Was: key flag for authentication)
Date: Mon, 16 Jun 2003 13:35:21 +0100
Importance: Normal
Sender: [email-masked]

> If you are so paranoid, why don't you keep all your PGP keys
> in a "more secure offline machine" and use PGP solely on it? 

Because for the vast majority of messages that I send, the increased
security would not be worth the extra effort. Whereas the compromise of
a key used to certify other keys has a much greater effect, and so to
many people it would.

> Should you have a need for shorter-lifetime signing keys, 
> just generate master keys explicitly for that purpose.

The point of the master key/subkey structure is that you shouldn't have
to do this, with the Web of Trust complications it introduces -- as
Werner said.

> If indeed you have such needs, there is nothing to preclude 
> from generating two distinct keys, one for signing and the 
> other for encryption.

Nor is there anything to preclude me using the existing master
key/subkey structure to do this.

> Let me add, and no offence of course, from the fact that you 
> are relegating those short-lifetime signing sub keys to a 
> less secure environment, I infer that you have no confidence 
> in them,

Confidence is not a binary issue. I trust the environment they are used
in less; therefore I would give them a shorter lifetime, so that their
compromise would have a smaller impact.

Ian.

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP Sub Keys (Was: key flag for authentication)
Date: Mon, 16 Jun 2003 14:30:08 +0200
Sender: [email-masked]

Hello Ian,

On Mon, 16 Jun 2003 09:18:09 +0100, you wrote:

>Imad R. Faiad wrote:
>> I would like to propose that signing sub keys be disallowed 
>> in OpenPGP.
>
>This would stop people keeping their master signing key on a more secure
>offline machine, and using it to sign shorter-lifetime signing subkeys
>which can be used on a day-to-day basis to sign messages :(
>
Let me add, and no offence of course, from the fact that you are
relegating those short-lifetime signing sub keys to a less secure
environment, I infer that you have no confidence in them, so how
do you expect others to trust such keys, or signatures generated
by them for that matter?  You might as well not sign at all.

my 2c

Best Regards

Imad R. Faiad

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP Sub Keys (Was: key flag for authentication)
Date: Mon, 16 Jun 2003 14:20:42 +0200
Sender: [email-masked]

Greetings,

On Mon, 16 Jun 2003 09:18:09 +0100, you wrote:

>Imad R. Faiad wrote:
>> I would like to propose that signing sub keys be disallowed 
>> in OpenPGP.
>
>This would stop people keeping their master signing key on a more secure
>offline machine, and using it to sign shorter-lifetime signing subkeys
>which can be used on a day-to-day basis to sign messages :(
>
If you are so paranoid, why don't you keep all your PGP keys
in a "more secure offline machine" and use PGP solely on it?
Should you have a need for shorter-lifetime signing keys,
just generate master keys explicitly for that purpose.
>> As I understand it, sub keys are only justified in the following
>> circumstances:-
>> 1) When the public key algorithm does not support encryption 
>> (e.g. DSA).
>> 2) In agreement with a school of thought, which recommends that
>>    it is good practice not to use the same key for signing and
>>    encryption.
>
>(2) is vital in countries where decryption but not signature keys can be
>seized by law enforcement agencies and others:
>http://www.acsac.org/2000/papers/47.pdf
>
If indeed you have such needs, there is nothing to preclude from generating
two distinct keys, one for signing and the other for encryption.
>> Any other arguments beyond the above, are just 
>> eccentricities, and will be better addressed by creating another key.
>
>Another "eccentricity" I am fond of is short-lifetime encryption subkeys
>that can be deleted once they have expired, reducing the impact of the
>above-mentioned key seizure powers. I currently (manually) generate such
>keys valid for one month; if I ever got round to automating this, I
>would go for a week or less...
>http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA127BBD5
>
I think there is a very serious flaw in the OpenPGP WOT when
it comes to v4 keys, sub keys literally have blown a hole in it,
and created a nice backdoor resulting in what I call a Web of Mistrust...

Whatever one feels about sub keys, I think that this WOT
issue ought to be addressed.

my 2c

Best Regards

Imad R. Faiad

To: Ian Brown <[email-masked]>
Cc: "'Imad R. Faiad'" <[email-masked]>, ietf-openpgp <[email-masked]>
Subject: Re: OpenPGP Sub Keys
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Mon, 16 Jun 2003 11:56:08 +0200
Sender: [email-masked]

On Mon, 16 Jun 2003 09:18:09 +0100, Ian Brown said:

> This would stop people keeping their master signing key on a more secure
> offline machine, and using it to sign shorter-lifetime signing subkeys
> which can be used on a day-to-day basis to sign messages :(

That is exactly what I would like to do.  Today I still use a separate
certification key but it is a problem WoT wise and annoying to tell
people how to send me encrypted mail, because they usually have
problems with the sign-only certification key.

From: Ian Brown <[email-masked]>
To: "'Imad R. Faiad'" <[email-masked]>, ietf-openpgp <[email-masked]>
Subject: RE: OpenPGP Sub Keys (Was: key flag for authentication)
Date: Mon, 16 Jun 2003 09:18:09 +0100
Importance: Normal
Sender: [email-masked]

Imad R. Faiad wrote:
> I would like to propose that signing sub keys be disallowed 
> in OpenPGP.

This would stop people keeping their master signing key on a more secure
offline machine, and using it to sign shorter-lifetime signing subkeys
which can be used on a day-to-day basis to sign messages :(

> As I understand it, sub keys are only justified in the following
> circumstances:-
> 1) When the public key algorithm does not support encryption 
> (e.g. DSA).
> 2) In agreement with a school of thought, which recommends that
>    it is good practice not to use the same key for signing and
>    encryption.

(2) is vital in countries where decryption but not signature keys can be
seized by law enforcement agencies and others:
http://www.acsac.org/2000/papers/47.pdf

> Any other arguments beyond the above, are just 
> eccentricities, and will be better addressed by creating another key.

Another "eccentricity" I am fond of is short-lifetime encryption subkeys
that can be deleted once they have expired, reducing the impact of the
above-mentioned key seizure powers. I currently (manually) generate such
keys valid for one month; if I ever got round to automating this, I
would go for a week or less...
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA127BBD5

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: OpenPGP Sub Keys (Was: key flag for authentication)
Date: Mon, 16 Jun 2003 10:21:57 +0200
Sender: [email-masked]

On Fri, 06 Jun 2003 10:39:30 +0200, you wrote:

>
>Hi!
>
>I know that we are short of releasing a new RFC and bis-08 looks
>really good.  Due to the project I am currently working on I'd like to
>suggest a small enhancement:
>
> 5.2.3.21. Key Flags
>
>     [...]   
>
>     0x20 - This key may be used for authentication.
>
>Usage notes are not necessary and it should be left to an
>implementation on how to handle this key flag.
>
>There are drafts and actual implementations to use OpenPGP keys with
>TLS and ssh.  Thus, having a subkey specially for this purpose seems
>to be a good idea.  A key with key flag 0x02 (sign data) could be used
>for authentication too but this has the problem than there would be no
>easy way to select the appropriate subkey for data signing or
>authentication purposes.  As a workaround an implementation could use
>notation data but this would be implementation dependend and a kind of
>hack.
>
>What do you think?
>
Hello Werner,

This is what I think:-

Why not just create a key dedicated for the purposes of TLS or SSH.

I would like to propose that signing sub keys be disallowed in OpenPGP.

While an encryption key concerns the key holder, a signing key is
of concern to others.  PGP users identify keys and publicize theirs
by the master key ID and fingerprint.  These are also the primary keys
used by key servers.

As I understand it, sub keys are only justified in the following
circumstances:-
1) When the public key algorithm does not support encryption (e.g. DSA).
2) In agreement with a school of thought, which recommends that
   it is good practice not to use the same key for signing and
   encryption.

Any other arguments beyond the above, are just eccentricities,
and will be better addressed by creating another key.

Therefore, for the sake of simplicity, please permit me to propose
that an OpenPGP key be a Master Key of an OpenPGP public key algorithm
suitable for signing, and ONE optional encryption sub key of an
OpenPGP public key algorithm suitable for encryption PERIOD.

It is evident that sub keys seem to be evolving beyond their
intended use.  Let's clean up that mess before it is too late.

What do you think?
>  Werner

Best Regards

Imad R. Faiad

Date: Sun, 15 Jun 2003 17:11:11 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: key flag for authentication
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, Jun 15, 2003 at 11:53:44AM -0400, Michael Young wrote:

> But, new flags can be structured to disambiguate new revisions
> from old.  For example, here we can add two bits:
>        0x20 - This key may be used for authentication.
>        0x40 - (Bit 0x20 is explicitly set.)
> Old signatures would have a zero in 0x40, so a new application
> can apply its own default (rather than having one imposed by
> the specification).  New signatures that actively decide on the
> value for the 0x20 bit must set 0x40.  (A new signer could also
> choose to accept the viewer's default by leaving 0x40 zero.)

I don't think this is really necessary.  The lack of a given flag
being set doesn't necessarily mean that the key *isn't* used for the
respective action.  The draft even uses the phrase "...stating a
preference...".

If anyone cares enough, they can certainly re-issue the signature with
the flag set.

David

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: key flag for authentication
Date: Sun, 15 Jun 2003 11:53:44 -0400
Sender: [email-masked]

This discussion raises another concern I've had regarding new flags.

The description (in draft 7, anyway) reads:
>    This subpacket contains a list of binary flags that hold information
>    about a key. It is a string of octets, and an implementation MUST
>    NOT assume a fixed size. This is so it can grow over time. If a list
>    is shorter than an implementation expects, the unstated flags are
>    considered to be zero.
...

In fact, the list of flags can grow *without* increasing the length.
we're contemplating adding new flags to the first octet.

I think it's inappropriate to change the meaning of an old signature
by adding flags to the specification.

Here, we're considering adding exactly one bit:
>      0x20 - This key may be used for authentication.

An old signature didn't contemplate the meaning of this bit.
The key might be intended for authentication; it might not.
New software that looks at this bit can't tell whether: the
signer explicitly chose not to allow authentication; or, the
signer was using an old revision of the specification.

But, new flags can be structured to disambiguate new revisions
from old.  For example, here we can add two bits:
       0x20 - This key may be used for authentication.
       0x40 - (Bit 0x20 is explicitly set.)
Old signatures would have a zero in 0x40, so a new application
can apply its own default (rather than having one imposed by
the specification).  New signatures that actively decide on the
value for the 0x20 bit must set 0x40.  (A new signer could also
choose to accept the viewer's default by leaving 0x40 zero.)

I don't know whether this is the right time to start adopting this
sort of policy for new flags -- do implementations make use of
the existing key flags already?  If they do, then I strongly
encourage including disambiguation for new flags.

To: Mauricio Junqueira <[email-masked]>
Cc: <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Using all zeros for IV means that..
Date: 15 Jun 2003 11:29:31 -0400
Lines: 62
Sender: [email-masked]

Hi,

first, this is probably not the apprpriate forum for
general cryptographic help (unless of course you
are looking for a security consulting to come help
you, in which case you can look at my personal website
and retain my services ;)

Having said that....

Mauricio Junqueira <[email-masked]> writes:

> .. a cipher text encoded in CFB mode could be decrypted in CBC ?

No.  CFB and CBC are completely different crypto modes.

[snip]

> But it only operates on 16bytes each time, what makes it
> a CBC mode ( I guess ).

No.  It has a 16-byte block size, but that does not make it CBC.

> My solution was to complete with spaces the remain bytes to have
> an entire block, but what about the IV?

You should read Applied Cryptography.  This is "not the way".  There
are a number of standard padding techniques, but you do not need
them if you use CFB mode.  CFB mode always gives you the "exact"
amount of ciphertext that you need.

> I will lose some quality if I drop the IV and CFB mode in the
> server or is there a way to use the IV in CBC mode like pre-pending
> the IV or using all zeros IV in CFB...

This question does not make sense.

> I hope I have found the right place to post this and I was encouraged
> in doing so after reading some messages from this mail list.

Not really, as this list is for discussion of the OpenPGP
specification, not about cryptography in general.

> Thank you for your time in reading this and
> who knows if some one could enlightenment me
> in the right direction.

As I said, I recommend you read Applied Cryptograhy, or
engage the services of a Security Consultant to help you
understand all the issues...

Good Luck,

> Mauricio Junqueira
> [email-masked]

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

Date: Sun, 15 Jun 2003 09:19:46 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: key flag for authentication
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 15, 2003 at 12:08:38PM +0200, Adrian 'Dagurashibanipal' von Bid=
der wrote:
> > authentication purposes.  As a workaround an implementation could use
> > notation data but this would be implementation dependend and a kind of
> > hack.
>=20
> Hmm. Using a flag which is not documented (except in that it exists) seem=
s=20
> kind of a hack, too. If the correct behaviour of openpgp software is to b=
e=20
> left to implementors, why not use a notation - which is more flexible tha=
n a=20
> one-bit flag anyway?

It doesn't need much documentation.  This is similar to the "This key
may be used to encrypt communications" or "This key may be used to
encrypt storage" flags: a usage hint.

I think the proposed flag is a good idea.

David

--XsQoSWH+UP9D9v3l
Content-Type: application/pgp-signature
Content-Disposition: inline

--XsQoSWH+UP9D9v3l--

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Subject: Re: key flag for authentication
Date: Sun, 15 Jun 2003 12:08:38 +0200
Sender: [email-masked]

--Boundary-02=_qWE7+JXt2jWT7eF
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Friday 06 June 2003 10:39, Werner Koch wrote:

>  5.2.3.21. Key Flags
>
>      [...]
>
>      0x20 - This key may be used for authentication.
>
> Usage notes are not necessary and it should be left to an
> implementation on how to handle this key flag.

At least a note that handling of this flag should be implementation defined=
=20
should go in. Somebody implementing OpenPGP software needs to know at least=
=20
that he needn't worry what to do with such keys (or perhaps that he should=
=20
ignore such [sub]keys in most cases?)

> authentication purposes.  As a workaround an implementation could use
> notation data but this would be implementation dependend and a kind of
> hack.

Hmm. Using a flag which is not documented (except in that it exists) seems=
=20
kind of a hack, too. If the correct behaviour of openpgp software is to be=
=20
left to implementors, why not use a notation - which is more flexible than =
a=20
one-bit flag anyway?

greets
=2D- vbi

=2D-=20
featured link: http://fortytwo.ch/smtp

--Boundary-02=_qWE7+JXt2jWT7eF
Content-Type: application/pgp-signature
Content-Description: signature

Signature policy: http://fortytwo.ch/legal/gpg/email.20020822?version=1.4&md5sum=81630baabe9a0670bb19c1fa8527a7ab

--Boundary-02=_qWE7+JXt2jWT7eF--

Date: Sat, 14 Jun 2003 11:32:27 -0300
Subject: Using all zeros for IV means that..
From: Mauricio Junqueira <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

.. a cipher text encoded in CFB mode could be decrypted in CBC ?

That question may be a silly one, but here's the point:

I am a Brazilian engineer who are in charge of a
system development that needs to send critical data over
the internet and other means.

Being new to cryptography but with some past experience
coding the DES algorithm for TEF I decided to do a little
research for new encryption methods. Then I decided for
twofish 128bits and implemented the server side of the
system using C and mcrypt in the CFB.
So I decided a very special convection for the IV bytes and
also had hash the IV prior his use.
To test the server, we have coded some clients in PHP and
everything works just fine.

Well, now we are developing for the real client: a 16mhz Hitachi H300
that has its own c libraries.
I found the implement mcrypt then twofish was not an option and
went to code twofish only.

When Looking for some examples showing how to implement twofish, I found
a Twofish source for PGP and used that as the basis for
the H300 implementation. Aside from differences in what a
unsigned char means, I now have it working.

But it only operates on 16bytes each time, what makes it
a CBC mode ( I guess ).

My solution was to complete with spaces the remain bytes to have
an entire block, but what about the IV?

I will lose some quality if I drop the IV and CFB mode in the
server or is there a way to use the IV in CBC mode like pre-pending
the IV or using all zeros IV in CFB...

I hope I have found the right place to post this and I was encouraged
in doing so after reading some messages from this mail list.

Thank you for your time in reading this and
who knows if some one could enlightenment me
in the right direction.

Mauricio Junqueira
[email-masked]

AMERICA - SOUTH AMERICA - BRASIL - GOIAS - GOIANIA

To: [email-masked]
Cc: [email-masked]
Subject: Re: key flag for authentication
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 06 Jun 2003 19:56:56 +0200
Sender: [email-masked]

On Fri, 06 Jun 2003 11:28:37 -0400, Ian Grigg said:

> To identify keys and their roles, we stick the following
> into the keyId textual tag:

>    [role]

That used to be the only way during PGP 2 times.  A German ISP with an
associated CA created pgp 2.63in to formalize their conventions on how
to encode more attributes in the User ID.  This made it even possible
to use separate signing and encryption keys as well as expiration
dates.

In contrast OpenPGP provides a more general way to encode more
information with a key.  Most notably notation data can be used
instead of tags encoded in the User ID.

> (And, thinking about it some more, I can see that the issue
> you might have there is that once you have your authentication
> bit in place, how do you show that the key is to be used for
> SSH authentication and not TLS?)

That is not the question I want to address.  The problem stems from
this:

If you have more than one encryption subkey, the most useful way is to
use the newest encryption subkey which has not been created in the
future.  This allows for an automatic key rollover.  Although it does
not make that much sense, the scheme can also be used for signing
subkeys.  To figure out what subkey to use, the implementation
computes the key capabilities from the used algorithm and the key
flags and decided on this.  If you add a subkey for authentication,
this one is probably the newest one and would be used for signing -
that is probably not what you want.

Shalom-Salam,

   Werner

Date: Fri, 06 Jun 2003 11:28:37 -0400
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: key flag for authentication
Sender: [email-masked]

Werner Koch wrote:
> 
> Hi!
> 
> I know that we are short of releasing a new RFC and bis-08 looks
> really good.  Due to the project I am currently working on I'd like to
> suggest a small enhancement:
> 
>  5.2.3.21. Key Flags
> 
>      [...]
> 
>      0x20 - This key may be used for authentication.
> 
> Usage notes are not necessary and it should be left to an
> implementation on how to handle this key flag.
> 
> There are drafts and actual implementations to use OpenPGP keys with
> TLS and ssh.  Thus, having a subkey specially for this purpose seems
> to be a good idea.  A key with key flag 0x02 (sign data) could be used
> for authentication too but this has the problem than there would be no
> easy way to select the appropriate subkey for data signing or
> authentication purposes.  As a workaround an implementation could use
> notation data but this would be implementation dependend and a kind of
> hack.
> 
> What do you think?

Not that I disagree with you, but I'd like to point out
alternative practice.

We (Systemics/Ricardo/SOX/WebFunds) have been using PGP keys
for authentication purposes for years (8, if anyone's counting,
with a couple of years gap where we got blindsided into
x.509).  (Something betwee 100k and a million transactions.)

To identify keys and their roles, we stick the following
into the keyId textual tag:

   [role]

where role could be one of certification, operator, server,
contract, ...

This appears to be much more flexible than looking for bits
in the key, as it allows lots of roles.  When one gets into
bigger protocols, one ends up with dozens of different keys
at different places in the PKI.  And they all need to have
their roles and characteristics encoded in them.

So, whilst I wouldn't necessarily disagree with the bit
being there, I'm not sure I see the need.

(And, thinking about it some more, I can see that the issue
you might have there is that once you have your authentication
bit in place, how do you show that the key is to be used for
SSH authentication and not TLS?)

Just some thoughts!

-- 
iang

To: [email-masked]
Subject: key flag for authentication
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 06 Jun 2003 10:39:30 +0200
Sender: [email-masked]

Hi!

I know that we are short of releasing a new RFC and bis-08 looks
really good.  Due to the project I am currently working on I'd like to
suggest a small enhancement:

 5.2.3.21. Key Flags

     [...]   

     0x20 - This key may be used for authentication.

Usage notes are not necessary and it should be left to an
implementation on how to handle this key flag.

There are drafts and actual implementations to use OpenPGP keys with
TLS and ssh.  Thus, having a subkey specially for this purpose seems
to be a good idea.  A key with key flag 0x02 (sign data) could be used
for authentication too but this has the problem than there would be no
easy way to select the appropriate subkey for data signing or
authentication purposes.  As a workaround an implementation could use
notation data but this would be implementation dependend and a kind of
hack.

What do you think?

  Werner

-- 
  Nonviolence is the greatest force at the disposal of
  mankind. It is mightier than the mightiest weapon of
  destruction devised by the ingenuity of man. -Gandhi

Date: Wed, 4 Jun 2003 21:27:38 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-08.txt
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Jun 04, 2003 at 07:56:54AM -0400, [email-masked] wrote:

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-08.txt

I'm quite pleased with this draft.  I'm going to give it a more
in-depth read, but I did notice a few very minor (mostly language)
nits:

***************

In section 5.2.1 ("Signature Types"): In the description of the 0x50
signature, there is a sentance that reads "such a a blind party that
only sees the signature, not the key nor source document".  That first
"a" was probably intended as an "as".

In the same section, "It is a notary seal on the signed data", could
probably be better as "It is analogous to a notary seal on the signed
data".  This should also help Ian Grigg's concerns about misuse of the
word "notary".

***************

In section 14 ("Implementation Nits") one of the items mentions:

     * PGP 2.0 through 2.5 generated V2 Public Key Packets. These are
       identical to the deprecated V3 keys except for the version
       number. An implementation may accept or reject them as it sees
       fit.

It might be good to change this a bit to:

     * PGP 2.0 through 2.5 generated V2 Public Key Packets and V2
       signatures. These are identical to the deprecated V3 keys and
       signatures except for the version number. An implementation may
       accept or reject them as it sees fit.

***************

I understood that the "keyserver preferences" and "features"
subpackets contain a collection of single-bit flags, but it isn't
completely clear from the text.  Maybe a sprinkling of the word "bit"
would help here.

***************

In section 5.2.4 ("Computing Signatures"), a sentance reads "A V3
certification hashes the contents of the name packet, without any
header."  Instead of "name packet", I suggest "user ID or attribute
packet".

***************

In section 10.1 ("Transferable Public Keys"), subkeys are followed by
"After each Subkey packet, one signature packet, optionally a
revocation."  I think the word "plus", as in "... plus optionally a
revocation" would be helpful here.  A revocation does not take the
place of the original binding signature.

***************

David

Date: Wed, 4 Jun 2003 20:53:03 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-08.txt
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Jun 05, 2003 at 02:18:31AM +0200, Imad R. Faiad wrote:
> 
> Hello Mr. Callas,
> 
> And while we are hacking, by hacking, I mean
> chopping with an axe.  Let us spruce the
> compression algorithms.
> 
> The zlib compression algorithm seems to be only
> implemented in the GnuPG variants, and
> is causing a lot of inter-operability problems.
> The compression function is breaking inter
> operability, therefore, we ought to state what is a
> "MUST" and what isn't, so that the issue may be resolved,
> once and for all.

I think the text in the draft is pretty clear on this point.  To my
reading, it says:

* You MUST support uncompressed data.

* You SHOULD support ZIP.

* You MAY support ZLIB.

* If a key states compression preferences, they MUST be followed at
  least to the point of knowing when to send uncompressed.  An easy
  way to do this is to to always send uncompressed data since it is
  known to always be supported.

* If a key does not state compression preferences, they are assumed
  to be "ZIP, Uncompressed".

It all seems pretty clear-cut to me.

I have seen a few interoperability problems between GnuPG and PGP due
to ZLIB, but each and every one falls into one of two groups:

1) A GnuPG user who insists on forcing the use of ZLIB when
   communicating with a PGP user, and ignores the "forcing compression
   algorithm ZLIB violates recipient preferences" error message.  This
   is depressingly common, but still is not a problem that the OpenPGP
   design can solve.

2) A key is generated in GnuPG, then later the user switches over to
   using PGP.  Since the ZLIB preference still exists on the key,
   a correspondant using GnuPG will naturally use ZLIB when encrypting
   to that key.  This is a problem that OpenPGP addresses in section
   5.2.3.3 ("Notes on Self-Signatures"):

       Since a self-signature contains important information about the
       key's use, an implementation SHOULD allow the user to rewrite
       the self-signature, and important information in it, such as
       preferences and key expiration.

> Especially so, when, forgive
> my expression, some implementors, default to zilb,
> while others seem to be unwilling to implement it.

Which implementation is that?  Both GnuPG and PGP default to ZIP.

The problem here is actually wider than the ZIP/ZLIB issue.  The same
thing happens with any two OpenPGP programs that support any different
cipher or hash algorithms.  The answer is not to force all
implementations to have the exact same algorithms.  The answer is to
properly use the preference lists.  That's what they are there for.

David

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-08.txt
Date: Thu, 05 Jun 2003 02:18:31 +0200
Sender: [email-masked]

Hello Mr. Callas,

And while we are hacking, by hacking, I mean
chopping with an axe.  Let us spruce the
compression algorithms.

The zlib compression algorithm seems to be only
implemented in the GnuPG variants, and
is causing a lot of inter-operability problems.
The compression function is breaking inter
operability, therefore, we ought to state what is a
"MUST" and what isn't, so that the issue may be resolved,
once and for all.  Especially so, when, forgive
my expression, some implementors, default to zilb,
while others seem to be unwilling to implement it.

my 2c,

Best Regards

Imad R. Faiad

On Wed, 04 Jun 2003 07:56:54 -0400, you wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories. This draft is a work item of the An Open Specification for
>Pretty Good Privacy Working Group of the IETF.  
>
>	Title		: OpenPGP Message Format
>	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
>	Filename	: draft-ietf-openpgp-rfc2440bis-08.txt
>	Pages		: 71
>	Date		: 2003-6-3
>	
>This document is maintained in order to publish all necessary
>information needed to develop interoperable applications based on
>the OpenPGP format. It is not a step-by-step cookbook for writing an
>application. It describes only the format and methods needed to
>read, check, generate, and write conforming packets crossing any
>network. It does not deal with storage and implementation questions.
>It does, however, discuss implementation issues necessary to avoid
>security flaws.
>OpenPGP software uses a combination of strong public-key and
>symmetric cryptography to provide security services for electronic
>communications and data storage.  These services include
>confidentiality, key management, authentication, and digital
>signatures. This document specifies the message formats used in
>OpenPGP.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-08.txt
>
>To remove yourself from the IETF Announcement list, send a message to 
>ietf-announce-request with the word unsubscribe in the body of the
>message.  
>
>Internet-Drafts are also available by anonymous FTP. Login with the
>username "anonymous" and a password of your e-mail address. After logging
>in,
>type "cd internet-drafts" and then
>	"get draft-ietf-openpgp-rfc2440bis-08.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-08.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-08.txt
Date: Wed, 04 Jun 2003 07:56:54 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-rfc2440bis-08.txt
	Pages		: 71
	Date		: 2003-6-3
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--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]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-rfc2440bis-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Mon, 02 Jun 2003 16:59:09 -0700
Subject: Bis-08 submitted
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

It contains all the things I think we've agreed to, plus a first stab at the
normative/non-normative reference separation, which will no doubt be a
subject of debate.

    Jon

Date: Mon, 2 Jun 2003 01:31:33 +0100
From: Adam Back <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: John Wilkinson <[email-masked]>, OpenPGP <[email-masked]>, Adam Back <[email-masked]>
Subject: Re: AES-256 vs AES-128 (Re: Suggested DER Prefixes)
Sender: [email-masked]

Not sure if this is what you were referring to about their comments in
Practical Cryptography, but in that book they argue for use of 256-bit
keys on the basis that protocols and algorithms more frequently than
we'd like fall victim to variants of the meet-in-the-middle attack
where the key space ends up being half as many bits as you thought it
might.

So personally I'm not sure I buy that particular argument, but I
happen to share the conclusion: 256-bit keys are a good idea.

Also I'd think the most suspect aspect of a 256-bit keyed cipher is
whether it truly achieves 256-bits of strength.  I'd say it's much
less controversial however to say 256-bit AES provides a better margin
of security than 128-bit AES.

Adam

On Sun, Jun 01, 2003 at 03:27:24AM -0700, Jon Callas wrote:
> Now Ferguson and Schneier have a new book out, "Practical Cryptography" and
> their opinions are well worth paying close attention to, even if you don't
> completely agree. 
> 
> Personally, I stick with 128-bit keys, but that's because I think too many
> people want more bits in their keys without understanding what's going on.
> 
> The question, "Will a key with more bits give me better security?" is a lot
> like the question, "Will more cylinders in my car engine make me go faster?"
> The answer to both is, "Ummm, well, maybe. Usually yes, but too many can
> actually cause all sorts of troubles." It's not what people want to hear.
> 
>     Jon
> 

Date: Sun, 01 Jun 2003 03:27:24 -0700
Subject: Re: AES-256 vs AES-128 (Re: Suggested DER Prefixes)
From: Jon Callas <[email-masked]>
To: John Wilkinson <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 5/30/03 4:48 PM, "John Wilkinson" <[email-masked]> wrote:

> 
> With all due respect, Jon, I would like to see a quote from a recognized
> crypto expert who feels that AES-128 is "safer" than AES-256.

I think you misunderstand what I'm saying.

In crypto circles, there's a subtle difference between being conservative
and being insecure. Safety is like wine. It ages over years. We tend to use
the word "safe" informally.

What I said was that the 256 bit ciphers make two changes, and that makes
them daring. I did say that I did not share the concerns I've heard, but I
still value them as the opinions of colleagues.

As for "recognized crypto experts" -- well, there are a lot of them here,
even if a number of us crypto experts aren't cipher designers. You've heard
from recognized crypto experts, and note that there's a variation of
opinion, and some of them say that yes, AES-256 is more daring than AES-128.

When I was at Counterpane, we used Blowfish over either AES or Twofish,
despite the fact that we thought that AES and Twofish both were better
designs. It was all a matter of aging, and it was at that time that
Schneier, Ferguson, and Kelsey (all Twofish designers) opined precisely what
I said -- that all of the AES candidates should be used in 128-bit mode, as
that was better understood.

Now Ferguson and Schneier have a new book out, "Practical Cryptography" and
their opinions are well worth paying close attention to, even if you don't
completely agree. 

Personally, I stick with 128-bit keys, but that's because I think too many
people want more bits in their keys without understanding what's going on.

The question, "Will a key with more bits give me better security?" is a lot
like the question, "Will more cylinders in my car engine make me go faster?"
The answer to both is, "Ummm, well, maybe. Usually yes, but too many can
actually cause all sorts of troubles." It's not what people want to hear.

    Jon