Subject: Re: Low-level question about OpenPGP - why CFB mode?

From: "Hal Finney" <[email-masked]>
Date: Wed, 30 Apr 2003 14:46:04 -0700

Mike Markowitz writes:
> At 12:43 PM 4/30/2003 -0700, Hal Finney wrote:
> >CFB has two advantages over CBC that might have led to its choice.
>
> Hal: While we're on the subject of CFB can you possibly share with us the 
> argument
> you used to convince NIST the method is good?
>
> In http://cert.uni-stuttgart.de/archive/ietf-openpgp/1999/05/msg00005.html
> you wrote:
>
> "The "pseudo IV" we have now is hard to explain. I had to go to some 
> lengths in
> getting our FIPS 140 certification (a standard security certification) to show
> that our way was just as good as the regular way."

The problem was that PGP uses a fixed IV of 0 and then prepends some
random data to the plaintext.  Basically anything non-standard like this
had to be justified.

The way FIPS 140 certification works, you don't deal directly with NIST
or NSA.  Instead there are a few companies which are authorized to do
a sort of pre-screening of your application and who then present it for
certification.  In practice you have to hire one of these companies to
work with you and help you get your application into shape.  There was
a consultant who was assigned to our case and who reviewed it and worked
with us.  He was the one we had to convince about any questionable issues.
So he brought up this issue about the IV, and we basically had to show
that the purpose of the IV was satisfied by our approach.

In CFB or CBC, the point of the IV is to make sure that the first block of
the ciphertext will be different even though the first block of plaintext
is the same.  We get the same effect because for us, the first block of
ciphertext comes out to be Enc(0) ^ randomddata.  This then acts as a
de facto IV, as it is then encrypted and xored with the first block of
true plaintext.  Basically our random data prefix acts as an IV, except it
gets xored with the encryption of zero, which won't hurt its randomness.

Anyway, our consultant was knowledgeable enough that after some extended
discussion about this, drawing some diagrams on the whiteboard and showing
how it worked, he was convinced that it was as good as the regular IV.

BTW, this reminds me of another advantage of CFB over CBC.  In CBC,
the IV gets XOR'd with the plaintext and then encrypted.  This means that
there is a greater chance that IV and plaintext changes can cancel each
other out.

For example, if you do something simple with the IV like increment it
for each message, only a few bits change each time.  Half the time, only
the low order bit of the IV changes.  It might happen that the plaintext
changed in a similar small way, say with just the low order bit changing.
Like, if the plaintext changed from "Dear Casper" to "Dear Cathy", that is
a change of just the low order bit in the first block of 8 bytes.  If you
sent these two messages consecutively using CBC, with the IV incrementing
between them, and it happened to be even for the first block, then the
first ciphertext blocks would be identical, thereby leaking information.

In CFB the IV gets encrypted and then XOR'd, so in general half the bits
will change each time, and it is exceedingly unlikely that this would
produce any patterns in the ciphertext.

Hal Finney

P.S. Here is a list I made a couple of years ago illustrating some
similarities and differences between CBC and full-width CFB:

 - With CFB if you flip a bit in block N of ciphertext, the same bit gets
   flipped in block N of the plaintext, but block N+1 of the plaintext
   becomes garbage.

 - With CBC if you flip a bit in block N of ciphertext, the same bit gets
   flipped in block N+1 of the plaintext, but block N of the plaintext
   becomes garbage.

 - With CFB you can flip a bit in the last block of the ciphertext and
   have the same bit get flipped in the last block of plaintext, without
   producing any garbage.

 - With CBC you can flip a bit in the IV and have the same bit get flipped
   in the first block of plaintext, without producing any garbage.

 - With CFB you can handle messages that are an uneven multiple of block
   size without using padding, by truncating the last block of ciphertext.

 - With CBC you can handle messages that are an uneven multiple of block
   size without using padding, by doing ciphertext stealing.

 - With CFB you can handle messages that are shorter than one block without
   using padding, by truncating the one block of ciphertext.

 - With CBC you can handle messages that are shorter than one block without
   using padding, by involving the IV in the ciphertext stealing algorithm.
   This requires altering the IV in the encryption phase.

 - With CFB decryption runs the base cipher in its encrypting direction.

 - With CBC decryption runs the base cipher in its decrypting direction.

 - With CFB encrypting does the following steps in order: encrypt the IV,
   XOR plaintext block 1, encrypt the result, XOR plaintext block 2,
   encrypt the result, XOR plaintext block 3, ....  The ciphertext is
   what results after each encrypt step.

 - With CBC encrypting does the following steps in order: start with IV,
   XOR plaintext block 1, encrypt the result, XOR plaintext block 2,
   encrypt the result, XOR plaintext block 3, ....  The ciphertext is
   what results after each XOR step.

In many ways CFB and CBC are very similar.  It follows from the last
two points that except for the first block, a CBC ciphertext stream can
be turned into CFB mode (and vice versa) by XORing the plaintext into
the ciphertext.

---

From: "Hal Finney" <[email-masked]>
Date: Wed, 30 Apr 2003 16:40:34 -0700

Jon Callas writes:
> The downside is that there are attacks on CFB mode that don't exist on CBC
> mode. The Jallal/Katz/Schneier attack of last summer is really an attack on
> CFB mode. It's possible there are interesting CBC attacks (one was published
> at last year's Crypto), but no one's made anything practical with it yet.
> (But heck, the JKS attack is almost impractical.)

I think that attack will work on CBC mode as well.  Basically that paper
is an implementation of Katz and Schneier, http://www.counterpane.com/chotext.html.
That earlier paper described attacks on both CFB and CBC mail systems.

Let's consider a simple full-shift-width CFB message, not including any of
PGP's peculiarities like resynching or using a 0 IV:

Encryption:

IV  P1  P2
->  C1  C2

CFB:
C1 = E(IV) ^ P1
C2 = E(C1) ^ P2

CBC:
C1 = E(IV ^ P1)
C2 = E(C1 ^ P2)

Decryption:

IV  C1  C2
->  P1  P2

CFB:
P1 = E(IV) ^ C1
P2 = E(C1) ^ C2

CBC:
P1 = D(C1) ^ IV
P2 = D(C2) ^ C1

For CFB, to recover P2 using a chosen ciphertext attack, supply IV C1 R,
and you will get P2' = E(C1) ^ R.  You want P2 = E(C1) ^ C2, which is
P2' ^ R ^ C2.

For CBC, to recover P2 using a chosen ciphertext attack, supply IV R C2,
and you will get P2' = D(C2) ^ R.  You want P2 = D(C2) ^ C1, which is
P2' ^ R ^ C1.

Notice how similar the descriptions are.  It's exactly the same attack,
with the roles of C1 and C2 interchanged.

Of course in practice the PGP attack had to deal with the complexities of
PGP, but they were still able to make it work.  I don't think it would
have been much different if PGP used CBC, although I have not thought
that through in detail.

Hal Finney

Date: Thu, 1 May 2003 05:53:40 +0100
From: Adam Back <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], Adam Back <[email-masked]>
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Sender: [email-masked]

I seem to remeber some comments in the 2.x code tree from Colin Plumb
discussing the merits of the CFB resync.

Here we go:

 * That is, the last 4 bytes of a 12-byte field are en/decrypted using
 * the first 4 bytes of IDEA(previous 8 bytes of ciphertext), but then
 * the last 4 bytes of that IDEA computation are thrown away, and the
 * first 8 bytes of the next field are en/decrypted using
 * IDEA(last 8 bytes of ciphertext).  This is equivalent to using a
 * shorter feedback length (if you're familiar with the general CFB
 * technique) briefly, and doesn't weaken the cipher any (using shorter
 * CFB lengths makes it stronger, actually), it just makes it a bit unusual.

from idea.c; actually it looks to be just a comment about the security
of different feedback lengths in CFB mode.

On use of CFB instead of CBC, I think this is actually goos because
it avoids the whole padding issue which people frequently get wrong
with bad security implications.  Plus it's simpler to not have to pad.
Error recovery is a phantom property, as in no mode is it secure.

Adam

On Thu, May 01, 2003 at 04:18:47PM +1200, Peter Gutmann wrote:
> 
> "Hal Finney" <[email-masked]> writes:
> 
> >I think this may have been the reason that Phil chose CFB.  As for the non-
> >standard "sync" operation, I don't remember why he did that. Probably it just
> >seemed to be a natural way of handling CFB given his understanding of its
> >rationale in terms of the way it interfaced with the underlying cipher.
> 
> I believe it was an implementation bug/quirk, not a deliberate design
> decision.
> 
> Peter.
> 

Date: Thu, 1 May 2003 16:18:47 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Sender: [email-masked]

"Hal Finney" <[email-masked]> writes:

>I think this may have been the reason that Phil chose CFB.  As for the non-
>standard "sync" operation, I don't remember why he did that. Probably it just
>seemed to be a natural way of handling CFB given his understanding of its
>rationale in terms of the way it interfaced with the underlying cipher.

I believe it was an implementation bug/quirk, not a deliberate design
decision.

Peter.

Date: Wed, 30 Apr 2003 16:40:34 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Sender: [email-masked]

Jon Callas writes:
> The downside is that there are attacks on CFB mode that don't exist on CBC
> mode. The Jallal/Katz/Schneier attack of last summer is really an attack on
> CFB mode. It's possible there are interesting CBC attacks (one was published
> at last year's Crypto), but no one's made anything practical with it yet.
> (But heck, the JKS attack is almost impractical.)

I think that attack will work on CBC mode as well.  Basically that paper
is an implementation of Katz and Schneier, http://www.counterpane.com/chotext.html.
That earlier paper described attacks on both CFB and CBC mail systems.

Let's consider a simple full-shift-width CFB message, not including any of
PGP's peculiarities like resynching or using a 0 IV:

Encryption:

IV  P1  P2
->  C1  C2

CFB:
C1 = E(IV) ^ P1
C2 = E(C1) ^ P2

CBC:
C1 = E(IV ^ P1)
C2 = E(C1 ^ P2)

Decryption:

IV  C1  C2
->  P1  P2

CFB:
P1 = E(IV) ^ C1
P2 = E(C1) ^ C2

CBC:
P1 = D(C1) ^ IV
P2 = D(C2) ^ C1

For CFB, to recover P2 using a chosen ciphertext attack, supply IV C1 R,
and you will get P2' = E(C1) ^ R.  You want P2 = E(C1) ^ C2, which is
P2' ^ R ^ C2.

For CBC, to recover P2 using a chosen ciphertext attack, supply IV R C2,
and you will get P2' = D(C2) ^ R.  You want P2 = D(C2) ^ C1, which is
P2' ^ R ^ C1.

Notice how similar the descriptions are.  It's exactly the same attack,
with the roles of C1 and C2 interchanged.

Of course in practice the PGP attack had to deal with the complexities of
PGP, but they were still able to make it work.  I don't think it would
have been much different if PGP used CBC, although I have not thought
that through in detail.

Hal Finney

Date: Wed, 30 Apr 2003 15:59:59 -0700
Subject: Re: Low-level question about OpenPGP - why CFB mode?
From: Jon Callas <[email-masked]>
To: <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 4/30/03 11:54 AM, "[email-masked]" <[email-masked]>
wrote:

> Why does OpenPGP use a custom CFB mode instead of CBC mode?  CFB with the
> slide equal to the blocksize is basically different from CBC in that the
> encryption is done before combining, rather than after.
> 
> I presume its simply always been that way, and it's not a problem so it was
> never changed in an update.  But why was that chosen initially, if anybody
> knows, and are there any propblems with CBC that this avoids?

It has, in fact, always been that way.

The reason is that CFB mode doesn't require padding.

The resync is there so you can easily tell if you have (most likely -- 1 in
64K chance of a miss) decrypted properly with the right key.

The downside is that there are attacks on CFB mode that don't exist on CBC
mode. The Jallal/Katz/Schneier attack of last summer is really an attack on
CFB mode. It's possible there are interesting CBC attacks (one was published
at last year's Crypto), but no one's made anything practical with it yet.
(But heck, the JKS attack is almost impractical.)

    Jon

To: [email-masked]
Cc: [email-masked], [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Date: 30 Apr 2003 18:20:45 -0400
Lines: 38
Sender: [email-masked]

[email-masked] writes:

> An issue with the document (I'm reading bis-07): step 12 includes "the
> process is repeated...".  It doesn't say "this process" means steps 10
> through 12 (only 10 must contain n*BS+3 etc instead of BS+3, etc.).  And is
> that really part of step 12?

Having just looked at -07, I agree that step 12 should be re-worded
to make it more clear.  Right now it says:

  11.  FR is encrypted to produce FRE.

  12.  FRE is xored with the next BS octets of plaintext, to produce
       the next BS octets of ciphertext.  These are loaded into FR and
       the process is repeated until the plaintext is used up.

I would suggest:

  12.  FRE is xored with the next BS (or fewer) octets of plaintext,
       to produce the next BS (or fewer) octets of ciphertext.  If
       this step has used all the remaining plaintext, the process is
       complete.  Otherwise, the BS octets of ciphertext are loaded
       into FR and the process is repeated (go back to step 11).

Is this more clear?  It makes it clear that the final block can be
smaller than BS octets, and it's explicit about what part of the
process is repeated (for those who couldn't intuit it from what to do
after 'these are loaded into FR' ;).

> --John

-derek

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

To: [email-masked]
Cc: [email-masked], [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Date: 30 Apr 2003 18:10:30 -0400
Lines: 63
Sender: [email-masked]

[email-masked] writes:

> I know that CFB can encode one byte (or even one bit) at a time, rather
> than waiting for the whole block or requiring a multiple of the blocksize.
> But in PGP the step is performed on a size that's equal to the block size.
> Are you saying that for the last block, you can change that to a size equal
> to how much you have left?  I don't think that was clear in the OpenPGP
> spec section 12.  It says it loads BlockSize at a time until the plaintext
> is used up, implying that the "given plaintext" is a multiple of the
> blocksize.

I think you've got it backwards.  Due to the way PGP uses the IV,
you've always got a full blocksize of pre-encrypted (ready to X-OR)
data waiting for your plaintext.  In other words, the IV is used to
seed the CFB pipeline with enough data so you don't have to wait for
plaintext before you turn the crypto-crank that first time.

And I see no such implication in the text.  It does load the CFB
buffer a full blocksize at a time when it needs to turn the crank, but
the final "block" of plaintext does not need to be a blocksize.
That's because the crank is never turned at that point.  Think about
it this way for a plaintext that is > 2 blocksizes but < 3:

IV --+   +----+   +----+
     |   |    |   |    |
    Ciph |   Ciph |   Ciph
     |   |    |   |    |
   P0+---+  P1+---+  P2+
     |        |        |
     C0       C1       C2

Note that you do perform 3 cipher cycles, but they are performed BEFORE
you feed the plaintext into the cipher.  In other words:

        Ci = Pi XOR Ciph(Ci-1)  where C-1 = IV

so
        C0 = P0 XOR Ciph(IV)
        C1 = P1 XOR Ciph(C0)
        C2 = P2 XOR Ciph(C1)

> I see that it will work, though: step 12 consumes the remainder of the
> plaintext if there are ferwer than BS octets remaining, and it never has to
> encode again so the truncation doesn't matter when decoding.

Or when ENCODING.  Remember, the CFB chain works the exact same way
when encoding or decoding.

> An issue with the document (I'm reading bis-07): step 12 includes "the
> process is repeated...".  It doesn't say "this process" means steps 10
> through 12 (only 10 must contain n*BS+3 etc instead of BS+3, etc.).  And is
> that really part of step 12?

I need to look at the document again to answer this question

> --John

-derek

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

Date: Wed, 30 Apr 2003 14:46:04 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Cc: [email-masked]
Sender: [email-masked]

Hal Finney

From: Steve Bellovin <[email-masked]>
To: [email-masked]
Subject: new chair
Date: Wed, 30 Apr 2003 17:33:24 -0400
Sender: [email-masked]

As most of you know, John Noerenberg has asked to step down as chair of 
OpenPGP.  I've asked Derek Atkins to take over as chair, to get the 
remaining work finished.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

Subject: Re: Low-level question about OpenPGP - why CFB mode?
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Wed, 30 Apr 2003 16:26:44 -0500
Sender: [email-masked]

> The second advantage of CFB relates to block padding.  It is easy and
> natural in CFB to handle messages which are not a multiple of the cipher
> block length (8 bytes for the early ciphers).  You simply truncate the
> ciphertext so it is the same length as the plaintext, and apply the same
> rule in reverse for decryption.

I know that CFB can encode one byte (or even one bit) at a time, rather
than waiting for the whole block or requiring a multiple of the blocksize.
But in PGP the step is performed on a size that's equal to the block size.
Are you saying that for the last block, you can change that to a size equal
to how much you have left?  I don't think that was clear in the OpenPGP
spec section 12.  It says it loads BlockSize at a time until the plaintext
is used up, implying that the "given plaintext" is a multiple of the
blocksize.

I see that it will work, though: step 12 consumes the remainder of the
plaintext if there are ferwer than BS octets remaining, and it never has to
encode again so the truncation doesn't matter when decoding.

An issue with the document (I'm reading bis-07): step 12 includes "the
process is repeated...".  It doesn't say "this process" means steps 10
through 12 (only 10 must contain n*BS+3 etc instead of BS+3, etc.).  And is
that really part of step 12?

--John

Date: Wed, 30 Apr 2003 15:26:08 -0500
To: "Hal Finney" <[email-masked]>
From: Mike Markowitz <[email-masked]>
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Cc: [email-masked]
Sender: [email-masked]

Thanks.

-mjm 

To: [email-masked]
Cc: OpenPGP <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Date: 30 Apr 2003 16:05:49 -0400
Lines: 25
Sender: [email-masked]

One benefit of using CFB is that you don't need to pad your plaintext.
As for why it was chosen...  I think that answer is probably lost in
the mystery of time (read: it was like that in PGP 2.0 and nobody had
a good reason to change it).

-derek

[email-masked] writes:

> Why does OpenPGP use a custom CFB mode instead of CBC mode?  CFB with the
> slide equal to the blocksize is basically different from CBC in that the
> encryption is done before combining, rather than after.
> 
> I presume its simply always been that way, and it's not a problem so it was
> never changed in an update.  But why was that chosen initially, if anybody
> knows, and are there any propblems with CBC that this avoids?
> 
> --John
> 
> 

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

Date: Wed, 30 Apr 2003 12:43:16 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Sender: [email-masked]

First, it only requires the underlying cipher to be run in one direction.
Even in the decryption mode, CFB runs the cipher in encryption mode.
This means that you don't need to implement decryption in the cipher.
However I believe that the first ciphers used in PGP, Bassomatic and IDEA,
had both encryption and decryption implementations.

This is more of an advantage with ciphers which have asymmetric speed
in one direction, but I don't think either of those early ciphers had
that property.

The second advantage of CFB relates to block padding.  It is easy and
natural in CFB to handle messages which are not a multiple of the cipher
block length (8 bytes for the early ciphers).  You simply truncate the
ciphertext so it is the same length as the plaintext, and apply the same
rule in reverse for decryption.

At the time, I don't think we were aware of an analogous technique
for CBC.  Most people then (and many now) pad the CBC message to a
multiple of 8 bytes, encrypt, and then remove the padding upon decryption.

Since then we have become aware of the "ciphertext stealing" technique
which lets you truncate CBC messages.  But it is a bit complicated, and
does not apply very readily to messages shorter than the block length.
Given these disadvantages, ciphertext stealing is not very widely used
for CBC encryption, rather padding is still used instead.

I think this may have been the reason that Phil chose CFB.  As for
the non-standard "sync" operation, I don't remember why he did that.
Probably it just seemed to be a natural way of handling CFB given his
understanding of its rationale in terms of the way it interfaced with
the underlying cipher.

Hal Finney

Subject: Low-level question about OpenPGP - why CFB mode?
To: OpenPGP <[email-masked]>
From: [email-masked]
Date: Wed, 30 Apr 2003 13:54:16 -0500
Sender: [email-masked]

Why does OpenPGP use a custom CFB mode instead of CBC mode?  CFB with the
slide equal to the blocksize is basically different from CBC in that the
encryption is done before combining, rather than after.

I presume its simply always been that way, and it's not a problem so it was
never changed in an update.  But why was that chosen initially, if anybody
knows, and are there any propblems with CBC that this avoids?

--John

Date: Wed, 16 Apr 2003 17:38:37 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Signature targets and where they should be used
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Apr 16, 2003 at 03:40:24PM -0400, Michael Young wrote:
> 
> From: "David Shaw" <[email-masked]>

> > In the case of notary signatures, there is no "C" to specify.  It is
> > merely signature A (the 0x50 signature), on data B (the signature to
> > be notarized).  There is no benefit in specifying B twice as the data
> > to be signed and then again as an additional subpacket.
> 
> I'd agree that the benefit is slight at best.  I suppose if
> you had "B" and the material it covered (so that you could generate
> B's hash), and you had a disorganized bunch of notary signatures,
> then you could pick out the matching ones faster if they had
> target subpackets.  This doesn't seem like a compelling scenario. :-)

There is actually another reason why using targets for notary
signatures is not really good: one of the nice features of notary
signatures is that the notarizer doesn't need the original signer's
public key or the material the original signature covered.  All the
notarizer needs is the signature packet.  Unfortunately, to use a
signature target in the notary signature, the notarizer needs the
original signer's public key to extract the hash from the original
signature packet...

I suppose we could solve that problem by defining a signature target
to be the canonical hash of the signature being targeted, but even
then there is still no good reason why using a target for notary
signatures needs to be a SHOULD.

David

Date: Wed, 16 Apr 2003 17:38:37 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Signature targets and where they should be used
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Apr 16, 2003 at 03:40:24PM -0400, Michael Young wrote:
> 
> From: "David Shaw" <[email-masked]>

> > In the case of notary signatures, there is no "C" to specify.  It is
> > merely signature A (the 0x50 signature), on data B (the signature to
> > be notarized).  There is no benefit in specifying B twice as the data
> > to be signed and then again as an additional subpacket.
> 
> I'd agree that the benefit is slight at best.  I suppose if
> you had "B" and the material it covered (so that you could generate
> B's hash), and you had a disorganized bunch of notary signatures,
> then you could pick out the matching ones faster if they had
> target subpackets.  This doesn't seem like a compelling scenario. :-)

There is actually another reason why using targets for notary
signatures is not really good: one of the nice features of notary
signatures is that the notarizer doesn't need the original signer's
public key or the material the original signature covered.  All the
notarizer needs is the signature packet.  Unfortunately, to use a
signature target in the notary signature, the notarizer needs the
original signer's public key to extract the hash from the original
signature packet...

I suppose we could solve that problem by defining a signature target
to be the canonical hash of the signature being targeted, but even
then there is still no good reason why using a target for notary
signatures needs to be a SHOULD.

David

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Signature targets and where they should be used
Date: Wed, 16 Apr 2003 15:40:24 -0400
Sender: [email-masked]

From: "David Shaw" <[email-masked]>
>   Note that a notary signature SHOULD include a Signature Target
>   subpacket to give easy identification.
> 
> I disagree this is necessary.  As I see it, the point of a signature

The SHOULD language suggests best practice, not strict requirement.
For notary signatures, that's still quite a stretch, though.

On the other hand, I'd love to see a SHOULD clause for revocations.
The Target subpacket eliminates an ambiguity -- without it, the
revocation could refer to any original signature for the same
key/uid.  (There is no such ambiguity for notary packets, as
the whole original signature is hashed.)  I think that unambiguous
identification is surely a best practice.

So, could you simply move the SHOULD clause from the notary
signature section to revocations :-?

> In the case of notary signatures, there is no "C" to specify.  It is
> merely signature A (the 0x50 signature), on data B (the signature to
> be notarized).  There is no benefit in specifying B twice as the data
> to be signed and then again as an additional subpacket.

I'd agree that the benefit is slight at best.  I suppose if
you had "B" and the material it covered (so that you could generate
B's hash), and you had a disorganized bunch of notary signatures,
then you could pick out the matching ones faster if they had
target subpackets.  This doesn't seem like a compelling scenario. :-)

Date: Mon, 14 Apr 2003 20:13:58 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Signature targets and where they should be used
Mail-Followup-To: [email-masked]
Sender: [email-masked]

In section 5.2.1 of bis-07, in the paragraph about notary signatures,
the draft reads:

  Note that a notary signature SHOULD include a Signature Target
  subpacket to give easy identification.

I disagree this is necessary.  As I see it, the point of a signature
target subpacket is to identify a signature *when that identification
is not obvious from the new signature*.

A signature target can be necessary or useful when issuing a
certification revocation signature (i.e. 0x30).  This case is
signature A (the 0x30 signature), on data B (primary key + user ID),
referring to signature C (the original 0x10-0x13 signature).  In this
case, a signature target is required to specify which signature C is.

In the case of notary signatures, there is no "C" to specify.  It is
merely signature A (the 0x50 signature), on data B (the signature to
be notarized).  There is no benefit in specifying B twice as the data
to be signed and then again as an additional subpacket.

In the interest of simplicity, I would like to strike the sentence
above.  Note that this does not prevent someone from using a signature
target for notary signatures if they still choose to.  All I am
advocating is removing any requirement (even a SHOULD) that they do
so.

David

Date: Sat, 12 Apr 2003 17:39:12 -0700
Subject: Re: partial packet lengths in PGP 8
From: Jon Callas <[email-masked]>
To: Brian Smith <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 4/10/03 4:05 PM, "Brian Smith" <[email-masked]> wrote:

> What's the reason for requiring that the first partial length be so long?
> 512 octets is considerably more than the headers, IV, etc of any data
> packet would be.

It was to discourage its use for common things.

The partial length feature was created so you could use PGP as a streaming
protocol. Networks, tape backups, other things were all described to me as
hypothetical uses for them.

It's a cool thing, but you don't want to have to force everyone's decoder to
deal with the case were the first bytes of some packet are all delivered in
one-byte partials. So you want to have some minimum. You want it to be
longer than a block size of a cipher, and after that, it's all handwaving.
512 was picked because it's a reasonable size of buffer, even on a very
limited computer. 

    Jon

To: Derek Atkins <[email-masked]>
Cc: "Hal Finney" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: partial packet lengths in PGP 8
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 11 Apr 2003 21:55:07 +0200
Sender: [email-masked]

On 11 Apr 2003 11:39:19 -0400, Derek Atkins said:

> IIRC signature packets MUST use a determinate length and are limited
> to about 8192 bytes (unless this was changed somewhere along the

Right.  I had only the length headers of the subpackets in mind which
indeed would allow up to 2^32 bytes for a subpacket.  However, the
total length of all subpackets is limited to 2 * 2^16 bytes.

Sorry for the confusion,

Salam-Shalom,

   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

To: "Michael Young" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: partial packet lengths in PGP 8
From: Derek Atkins <[email-masked]>
Date: 11 Apr 2003 15:10:06 -0400
Lines: 30
Sender: [email-masked]

Perhaps it's my flakey memory, but I recall that when Colin and
I were working on PGP3/5, when we were designing what eventually
turned into 2440, we had some packets that required a 2-bit LoL
implementation due to compatibility reasons with PGP 2.x...  I
could be totally off my rocker, here -- this work was done 8 years
ago so it's been a while and I've tried to forget that part of my
life ;)

-derek

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

> From: "Derek Atkins" <[email-masked]>
> > IIRC signature packets MUST use a determinate length and are limited
> > to about 8192 bytes (unless this was changed somewhere along the
> > line).
> 
> The current draft does require that they be determinate, but I don't
> see a numeric limit.  There are hard limits to the hashed and unhashed
> subpackets (2^16-1 each) and (arguably) practical limits to the size of
> the MPIs that form the signature, but that comes to well more than 8192.
> 
> 
> 

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

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: partial packet lengths in PGP 8
Date: Fri, 11 Apr 2003 13:46:36 -0400
Sender: [email-masked]

From: "Derek Atkins" <[email-masked]>
> IIRC signature packets MUST use a determinate length and are limited
> to about 8192 bytes (unless this was changed somewhere along the
> line).

The current draft does require that they be determinate, but I don't
see a numeric limit.  There are hard limits to the hashed and unhashed
subpackets (2^16-1 each) and (arguably) practical limits to the size of
the MPIs that form the signature, but that comes to well more than 8192.

To: Werner Koch <[email-masked]>
Cc: "Hal Finney" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: partial packet lengths in PGP 8
From: Derek Atkins <[email-masked]>
Date: 11 Apr 2003 11:39:19 -0400
Lines: 21
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

> On Thu, 10 Apr 2003 16:27:10 -0700, Hal Finney said:
> 
> > A literal data packet could have up to a 256 byte long filename plus a
> > few more bytes for the other data, so you need it to be bigger than that.
> > And 512 is the next size up.
> 
> and signature packets can be of any size ...

IIRC signature packets MUST use a determinate length and are limited
to about 8192 bytes (unless this was changed somewhere along the
line).

-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: "Hal Finney" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: partial packet lengths in PGP 8
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 11 Apr 2003 10:29:07 +0200
Sender: [email-masked]

On Thu, 10 Apr 2003 16:27:10 -0700, Hal Finney said:

> A literal data packet could have up to a 256 byte long filename plus a
> few more bytes for the other data, so you need it to be bigger than that.
> And 512 is the next size up.

and signature packets can be of any size ...

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

To: "Brian Smith" <[email-masked]>
Cc: [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: partial packet lengths in PGP 8
Date: 10 Apr 2003 21:12:26 -0400
Lines: 45
Sender: [email-masked]

A better question to be asking yourself is why do you feel you
need to break the packet up any SMALLER than 512 bytes?

-derek

"Brian Smith" <[email-masked]> writes:

> What's the reason for requiring that the first partial length be so long?
>  512 octets is considerably more than the headers, IV, etc of any data
> packet would be.
> 
> Brian
> 
> On Wed, 09 Apr 2003 15:45:44 -0700 Jon Callas <[email-masked]> wrote:
> >
> >On 4/9/03 3:02 PM, "Hal Finney" <[email-masked]> wrote:
> >
> >> I suggest that the following text:
> >> 
> >>  An implementation MAY use Partial Body Lengths for data packets,
> > be
> >>  they literal, compressed, or encrypted. The first partial length
> >MUST
> >>  be at least 512 octets long. Partial Body Lengths MUST NOT be
> >used
> >>  for any other packet types.
> >> 
> >>  Note also that the last Body Length header can be a zero-length
> >header.
> >> 
> >> be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths.
> > Also I
> >> moved the "Note also" sentence to after the paragraph as you see.
> >
> >I moved them.
> >
> >    Jon
> >
> >
> >

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

Date: Thu, 10 Apr 2003 16:27:10 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: partial packet lengths in PGP 8
Sender: [email-masked]

Brian Smith writes:
> What's the reason for requiring that the first partial length be so long?
>  512 octets is considerably more than the headers, IV, etc of any data
> packet would be.

A literal data packet could have up to a 256 byte long filename plus a
few more bytes for the other data, so you need it to be bigger than that.
And 512 is the next size up.

Hal

Date: Thu, 10 Apr 2003 16:05:45 -0700
To: [email-masked]
Cc: 
Subject: Re: partial packet lengths in PGP 8
From: "Brian Smith" <[email-masked]>
Sender: [email-masked]

What's the reason for requiring that the first partial length be so long?
 512 octets is considerably more than the headers, IV, etc of any data
packet would be.

Brian

On Wed, 09 Apr 2003 15:45:44 -0700 Jon Callas <[email-masked]> wrote:
>
>On 4/9/03 3:02 PM, "Hal Finney" <[email-masked]> wrote:
>
>> I suggest that the following text:
>> 
>>  An implementation MAY use Partial Body Lengths for data packets,
> be
>>  they literal, compressed, or encrypted. The first partial length
>MUST
>>  be at least 512 octets long. Partial Body Lengths MUST NOT be
>used
>>  for any other packet types.
>> 
>>  Note also that the last Body Length header can be a zero-length
>header.
>> 
>> be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths.
> Also I
>> moved the "Note also" sentence to after the paragraph as you see.
>
>I moved them.
>
>    Jon
>
>
>

Date: Wed, 09 Apr 2003 15:45:44 -0700
Subject: Re: partial packet lengths in PGP 8
From: Jon Callas <[email-masked]>
To: Hal Finney <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 4/9/03 3:02 PM, "Hal Finney" <[email-masked]> wrote:

> I suggest that the following text:
> 
>  An implementation MAY use Partial Body Lengths for data packets, be
>  they literal, compressed, or encrypted. The first partial length MUST
>  be at least 512 octets long. Partial Body Lengths MUST NOT be used
>  for any other packet types.
> 
>  Note also that the last Body Length header can be a zero-length header.
> 
> be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths.  Also I
> moved the "Note also" sentence to after the paragraph as you see.

I moved them.

    Jon

Date: Wed, 9 Apr 2003 15:02:48 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: partial packet lengths in PGP 8
Sender: [email-masked]

Michael Young writes:

> The specification includes a stronger requirement, in section 4.2.3:
>     "The first partial length MUST be at least 512 octets long."

I hadn't noticed that.  I think that requirement is not in a very good
place, buried in section 4.2.3 which is titled "Packet Length Examples".
That's not where an implementor would expect to find MUST rules regarding
partial body lengths.

I suggest that the following text:

   An implementation MAY use Partial Body Lengths for data packets, be
   they literal, compressed, or encrypted. The first partial length MUST
   be at least 512 octets long. Partial Body Lengths MUST NOT be used
   for any other packet types.

   Note also that the last Body Length header can be a zero-length header.

be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths.  Also I
moved the "Note also" sentence to after the paragraph as you see.

I am using section numbers from RFC2440, I don't have the new version in
front of me at the moment, so they might have different numbers there.

Hal

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: partial packet lengths in PGP 8
Date: Wed, 9 Apr 2003 10:53:59 -0400
Sender: [email-masked]

"Hal Finney" <[email-masked]> answers "Brian Smith" <[email-masked]> with:
> So the work-around in this case is to make sure the first partial body
> length is at least 16 bytes, for 8 byte block ciphers, and 32 bytes,

The specification includes a stronger requirement, in section 4.2.3:
    "The first partial length MUST be at least 512 octets long."

Separately, I might suggest avoid using a zero-length packet at the
end, if you can.  It's not illegal, but it's the kind of thing that
might tickle a bug in another implementation.  I'd be conservative.

Date: Tue, 8 Apr 2003 20:19:35 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: partial packet lengths in PGP 8
Sender: [email-masked]

"Brian Smith" <[email-masked]> writes:
> It seems to me that PGP 8 does not support partial packet lengths for
> a a symmetrically encrypted data packet.  Is this a known bug, and if
> so is there a work-around?

I worked on predecessors to PGP 8, and based on your test data I can
confirm that there is a bug in the packet parsing code relating to
partial body lengths.  It's not specific to symmetrically encrypted data
packets, but rather to the "initial" portion of the packets.  Many of
the PGP data packets have an initial part which is of more or less fixed
length, followed by the rest of the body which can be of arbitrary length.
The parser first assembles the initial portion and extracts the data from
that, then falls into some relatively generic code which handles the rest
of the data.  There is a bug in the parser which won't work properly if
the initial portion spans two or more partial-body-length packets.

In the case of symmetrically encrypted data packets, the initial portion
is the first 10 bytes (for 8-byte ciphers; 18 bytes for 16-byte block
ciphers).  In your case you had a PBL of 8 followed by two PBL's of 1
each to fill out the first 10 bytes, but the code messes up and doesn't
assemble the packets correctly.  It doesn't do what you might think and
include the e0's in the packet, but it fails to update the buffer pointer
and so replicates the contents of the previous PBL, the 96 and 97 bytes,
as the 9th and 10th.

So the work-around in this case is to make sure the first partial body
length is at least 16 bytes, for 8 byte block ciphers, and 32 bytes,
for 16 byte block ciphers.  That will mean buffering up the first 16 or
32 bytes of your stream before emitting your first block.

Hal Finney

Date: Tue,  8 Apr 2003 19:12:25 -0700
To: OpenPGP <[email-masked]>
Cc: 
Subject: partial packet lengths in PGP 8
From: "Brian Smith" <[email-masked]>
Sender: [email-masked]

It seems to me that PGP 8 does not support partial packet lengths for
a a symmetrically encrypted data packet.  Is this a known bug, and if
so is there a work-around?  There are some situations where it would
be very useful for me to be able to generate messages from a stream where
I don't know the length ahead of time and have them still decrypt under
PGP 8.

Specifically, the following packet seems to break it:

c9e39697376314f4fbede026e0bae28397cc98e16881e0ece0f2e2095e6bfee12680e056e000e0cc00

Or broken down into lengths:

c9 (tag indicating symmetrically encrypted data packet)
e3 (partial length of 8)
9697376314f4fbed
e0 (partial length of 1)
26
e0 (partial length of 1)
ba
e2 (partial length of 4)
8397cc98
e1 (partial length of 2)
6881
e0 (partial length of 1)
ec
e0 (partial length of 1)
f2
e2 (partial length of 4)
095e6bfe
e1 (partial length of 2)
2680
e0 (partial length of 1)
56
e0 (partial length of 1)
00
e0 (partial length of 1)
cc
00 (final zero length tag)

Here's the actual message that was generated from.  It's just the message
"xx" encrypted with the password "test".  Decrypts fine with gpg.

Thanks,
Brian Smith

Date: Mon, 7 Apr 2003 10:10:07 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Please Help with OpenPGP's CFB Mode
Sender: [email-masked]

Daniel Fabian writes:
> ...
> - I load the FR with c2 - c17:
> 158;148;73;14;80;225;210;140;157;206;228;11;143;115;163;29;
> - Encrypt it: FRE: 121;156;77;216;12;149;25;199;12;206;220;6;43;173;198;65;
> - And get the WRONG plaintext block
> 200;53;1;59;109;82;194;192;200;192;192;16;146;145;170;224;
>
> This is definitly not the UTF-8 representation of "The MD5 hash alg".
> Could someone please tell me what I'm doing wrong?

You have done the decryption properly.  Your plaintext when expressed
in hex form is:

c8 35 01 3b 6d 52 c2 c0 c8 c0 c0 10 92 91 aa e0

You have to interpret this as PGP data per RFC2440.  C8 is the tag byte
for a Compressed Data Packet (see section 5.6).  35 is its length.  01 is
the type of compression, namely ZIP (see section 9.3).  The remaining
data is to be input to the decompression algorithm.  The output of that
will be a PGP Literal Data Packet, and the contents of that packet will
include your text.

Hal Finney

From: "Daniel Fabian" <[email-masked]>
To: <[email-masked]>
Subject: Please Help with OpenPGP's CFB Mode
Date: Mon, 7 Apr 2003 08:28:44 +0200
Importance: Normal
Sender: [email-masked]

Hi,

I'm having some troubles implementing OpenPGP's CFB Mode. It seems I got the
resync step wrong. Could someone perhaps be so kind and check this?

I'm trying to decrypt the following message:

This is the line "The MD5 hash algorithm has been found to have " from the
RFC, symmetrically encrypted with the passphrase "test".

This should be the ciphertext

191;83;158;148;73;14;80;225;210;140;157;206;228;11;143;115;163;29;177;169;76
;227;97;199;219;7;196;14;28;22;185;60;108;161;241;182;124;159;14;163;116;32;
194;186;211;137;126;169;182;73;94;122;202;242;160;45;50;134;222;231;62;46;15
8;116;186;144;236;18;90;187;91;12;122

encrypted with the symmetrical key

165;250;150;68;115;173;70;173;212;104;208;113;241;231;223;29;28;118;235;208;
188;166;157;28;51;170;81;64;96;73;144;105

and the AES256 cipher.

Here's what I do:

- I load FR 0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0 with all 0's
- I encrypt to get FRE:
67;169;145;216;194;226;251;238;246;15;184;187;87;67;190;101;
- This gives me the Plaintext:
252;250;15;76;139;236;171;15;36;131;37;117;179;72;49;22;
- Load C0-C15 into the FR:
191;83;158;148;73;14;80;225;210;140;157;206;228;11;143;115;
- FRE: 146;11;98;243;113;121;142;86;23;188;60;49;76;14;194;225;
- Plaintext: 49;22

So this part should have worked fine, because as stated in the rfc, the
bytes c14 and c15 are the same as c16 and c17. However here comes the
trouble:

- I load the FR with c2 - c17:
158;148;73;14;80;225;210;140;157;206;228;11;143;115;163;29;
- Encrypt it: FRE: 121;156;77;216;12;149;25;199;12;206;220;6;43;173;198;65;
- And get the WRONG plaintext block
200;53;1;59;109;82;194;192;200;192;192;16;146;145;170;224;

This is definitly not the UTF-8 representation of "The MD5 hash alg".
Could someone please tell me what I'm doing wrong?

Thanks in advance,
Daniel

Date: Tue,  1 Apr 2003 06:46:28 -0800
To: [email-masked]
Cc: 
Subject: gnupg/pgp symmetric encryption incompatibility report
From: <[email-masked]>
Sender: [email-masked]

the following demonstration of an incompatiblity in symmetric encryption
was reported in alt.security.pgp:

----- Original Message ----- 
From: "Falissard" <[email-masked]>
Newsgroups: alt.security.pgp,comp.security.pgp.tech
Sent: Monday, March 31, 2003 4:24 PM
Subject: GnuPG (good) and PGP (bad) encryption

> For specialists only...
> Here is one case where PGP is not as clever as GnuPG...
> The following conventionally encrypted data
> decrypts well with GnuPG, ** not ** with PGP ("bad packet").
> The passphrase is "test".
> Nothing special here regarding algorithms (Cast5 + MD5).
> The thing that I suspect is that PGP does not always
> accept packets with indeterminate length, while
> it's OK for GnuPG.
> (I deliberately encrypted a compressed
> packet with indeterminate length.)
> 

is the 'indeterminate packet length' issue a contrived exception, that
would not be expected to occur with ordinary use,
or is it something that needs to be addressed?

tia,

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2 

Big $$$ to be made with the HushMail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427