Subject: Phil Zimmermann's suggestion for large ciphers

From: [email-masked]
Date: Mon, 12 Apr 1999 14:59:59 -0700

I spoke with Phil Zimmermann on the phone about the issues raised by
moving to larger block ciphers, and he made the following proposal.

Phil suggests that we take advantage of the fact that when we go to large
block ciphers like Twofish, there are no backwards-compatibility issues.
We know that we need to make some adjustments to the spec with regard to
the large block size.  Rather than trying to tweak the current symmetric
encrypted data packet spec, let us define a new encrypted data packet
which would be used for large ciphers and would solve some of the concerns
people have had with our existing encrypted data packets.

These concerns include -

 - The non-standard sync operation after the check bytes are handled

 - The non-standard treatment of IV

 - The lack of detection of message modification unless the message is
   signed (many people don't like to sign their messages for legal reasons,
   but they don't want them altered).

We would define a new encrypted packet format which would be similar to
the current one but which would resolve these problems.

The first thing in the packet would be the IV, of a size equal to the
block size of the cipher.  It would be followed by the ciphertext, which
would be handled in CFB-n mode, where n is the block size of the cipher.
There would be no special shift or sync operations.

The plaintext would be prepended with a header consisting of check bytes
so that the proper key can be detected.  The check bytes could be two
random bytes, followed by the same two bytes, repeated.

The plaintext would be followed by a SHA-1 hash of the plaintext data.
This would be checked after decryption and detect message modification
attacks.

This gives us a standard CFB mode, with a standard IV; a simple form of
redundancy at the beginning to verify the correct key; and a SHA-1 hash
at the end to protect the integrity of the data.

With this approach, rather than patching the spec to deal with large
block ciphers in the existing packet format, we would say that the
existing packets should only be used for ciphers with 64 bit blocks.
Larger ciphers must use the new format.  Again, this is a perfect
opportunity to make this change because large ciphers won't be backwards
compatible, anyway.

We have talked about variants on this idea in the past.  Let me briefly
try to address some of the issues which have come up.

One question is whether to use a keyed MAC, like an HMAC, for integrity
protection.  A MAC is a Message Authentication Code, and is useful when
the two sides have authenticated themselves to each other.  They have
some shared secret and they use that to authenticate the data as having
originated with the other.  What we want is simple integrity protection.
For this purpose there is no need for a shared secret and it is
appropriate simply to use a hash to provide the protection.

Another issue is whether to use a fixed hash like SHA-1 rather than
allowing the specification of a hash algorithm in the header.  There is
no need for variable hash algorithms in this context.  The attacker does
not have access to the plaintext of the message.  The SHA-1 hash is being
used essentially as a complicated checksum.  There are certain limited
changes which an attacker can make to an encrypted message, and all we
need is that the hash function has a complex enough structure that the
attacker would not be able to alter the message and checksum to allow
it to continue to verify.  The threat model is very different from the
case of cryptographic signatures, and a fixed hash like SHA-1 should
be suitable.

Allowing the specification of a hash algorithm would actually allow
some new attacks, as an attacker could potentially modify the message
to change the hash algorithm specification, at the cost of damaging
some other parts of the message.  The recipient would then find that
the message had apparently been integrity-protected with an unknown
hash algorithm, and the integrity protection would be lost.

We have also discussed providing integrity protection via some
modification to the signature packet format rather than by a new form
of encrypted packet.  There would be a special kind of "signature" which
would just consist of a hash of the message to protect its integrity.

However, Phil argues that this kind of integrity protection is inherently
tied to the use of encryption.  It has no functional effect if not used
in conjunction with encryption.  This is unlike our other signatures,
which are cryptographically useful transformations even on their own.
Because of this close tie to the encryption functionality it makes most
sense to make it part of the encrypted packet.

One objection to this linkage is that if the message is both signed and
encrypted, there is redundancy, since we compute an integrity protection
hash in the encryption layer, and also a signature verification hash
in the signature layer.  The signature provides integrity protection as
well as authentication, and so it is wasteful to also provide integrity
protection as part of the encryption.

However, Phil points out that it is often the case that a signature
cannot be verified because the signing key is not available.  In that case
there is no integrity protection at all.  Putting integrity protection in
the encryption layer ensures that all encrypted messages have integrity
protection.

Summing up, we have an opportunity now to move to a new encrypted packet
format at the same time as we begin supporting new ciphers.  We can
fix some of the problems which people have been complaining about for
years, without facing backwards compatibility issues.

Hal Finney
NAI, Inc.

---

From: Jon Callas <[email-masked]>
Date: Mon, 12 Apr 1999 16:07:09 -0700

Is Phil suggesting that we *NOT* use Twofish with packet 9, that we hold
off on large blocks until the new encrypted data packet gets defined?

	Jon

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

---

From: uri <[email-masked]>
Date: Mon, 12 Apr 1999 19:21:13 -0400 (EDT)

[email-masked] says:
> ...................... Rather than trying to tweak the current symmetric

Good. About time.

>  - The non-standard sync operation after the check bytes are handled

Kill it.

>  - The non-standard treatment of IV

Later.

>    but they don't want them altered).

Fix it.

> There would be no special shift or sync operations.

I kinda like the idea of constant zero IV and plaintext prefixed with
128 random bits... Looks better than the "traditional" IV to me...

> random bytes, followed by the same two bytes, repeated.

Make the "pseudo-IV" prefix partially non-random - i.e. the last two 
bytes being checksum for the other 14. No big deal security-wise and
noticeable help in detecting the right key.

> This would be checked after decryption and detect message modification

Good enough.

> at the end to protect the integrity of the data.

Sure - but I still prefer "hidden" IV in the shape of plaintext prefix,
and "visible" IV all zeroized...

> the two sides have authenticated themselves to each other. 

Exactly. And this is not a MAC - it's an MDC at best (Modification
Detection Code). I do not think MAC is warranted here.

In short - IMnotsoHM no need for keyed MAC or MDC. Plain SHA-1.

> allowing the specification of a hash algorithm in the header. 

Shooting from the hip - no need for plenty of hashes. SHA-1 is 
good enough for this purpose.

> The threat model is very different from the

It is.

> would just consist of a hash of the message to protect its integrity.

Nah, IMNSHO isn't worth it.

> in the signature layer. 

So? Compared to cost of one RSA or DSA operation, one SHA-1 is negligible.
Who cares?

> The signature provides integrity protection as

"Penny-wise, pound-foolish". I'd rather not do things in dozens of
different ways. Phil is correct here - it is better to have that
extra "wasteful" protection.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: Adam Back <[email-masked]>
Date: Tue, 13 Apr 1999 00:41:53 +0100

I just spent a bit of time reviewing the previous discussions on fixes
for Gary Howland's message modification attack.

In general I like PRZs proposal, and it seems well thought out.
Starting from PRZs functionality list, I agree with the design.

However i think the functionality list has a gap: it doesn't cover
that many people will want to continue using IDEA, 3DES, blowfish.
There will remain no way to prevent message modification for unsigned
messages for these.

The point that PRZ made:

> cannot be verified because the signing key is not available.  In
> that case there is no integrity protection at all.

is important too, and I therefore think it would be quite useful to
have a MDC in signed and encrypted messages (as well as just encrypted
messages) for the non-large ciphers too.

Now if one adds to PRZs functionality list that we want this to be
backwards compatible so that non-large ciphers can use it, you need a
way to send a MDC inside an encryption envelope such that it won't
cause current implementations to barf.  For this the appended hash
method doesn't work (or at least I can see no elegant way to make it
work).

For this reason I would argue for a new signature type `symmetric
MDC', where you put a hash (or a MAC) in a signature packet.

in previous discussions Tom Zerucha made this point:
: a signature algorithm
: of 0 means the message digest is stored in the clear (maybe as a
: MPI), and leave the rest of the format alone.  Old implmentations
: should fail gracefully with "unknown signature algorithm".  The
: onepass signature header lets the "MAC" be at the end yet insures
: that someone can't just delete the "MAC".

Some additional benefits of a symmetric signature are that:

- the attacker is left guessing whether or not the recipient will
check the MDC, even for all existing pgp2.x, pgp5.x and pgp6.x
implementations

- if the recipient later upgrades he can at that later time check the
MDCs and detect the modification after the fact

I argue that these benefits make it worth favoring the new signature
type over appended hash approach.

I agree that the addition of large ciphers would be a good time to
phase in the other proposed changes.  Perhaps even, we could clean up
the length business at the same time, which would allow eventual
deprecation of sections 4.2.1, 4.2.2 and 4.2.3 The new-format packet
lengths (4.2.2, 4.2.3) are even more complicated than the old ones
(4.2.1).

Adam

---

From: uri <[email-masked]>
Date: Mon, 12 Apr 1999 20:06:09 -0400 (EDT)

> Starting from PRZs functionality list, I agree with the design.

(:-)

> There will remain no way to prevent message modification for unsigned

And there's absolutely no protection for those who continue
using unencrypted unsigned e-mail.

I say - the world is moving forward. 

It is bad enough to have to be compatible with the existing
"old" methods - it will be far worse to have to in addition
be compatible with "new old" methods. Enough is enough.

> messages) for the non-large ciphers too.

We agree here.

> method doesn't work (or at least I can see no elegant way to make it

A good enough reason for me to vote down the support for MDC in
"old" ciphers.

> MDC', where you put a hash (or a MAC) in a signature packet.

No MAC - as MAC will require yet another key.

> type over appended hash approach.

Let's say that we disagree here.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: Werner Koch <[email-masked]>
Date: Tue, 13 Apr 1999 09:48:14 +0200

> noticeable help in detecting the right key.

I aggree as this will help detecting bad keys for conventional-only
encrypted data.

> So? Compared to cost of one RSA or DSA operation, one SHA-1 is negligible.

Hashing 700 Mges takes a while and sometimes conventional only
encryption is used.  But IMHO it is worth this time.  If someone 
does not like it, he can still use packet type 9 and the specs 
shoudl say that an implemention SHOULD display a notice if a 
cipher >= 7 is used without a MDC. 

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

---

From: Werner Koch <[email-masked]>
Date: Tue, 13 Apr 1999 09:41:51 +0200

> block ciphers like Twofish, there are no backwards-compatibility issues.

Please note that the RFC already handles ciphers with different
blocksizes; the only problem ist that there are some glitches in the
specification.  

> The plaintext would be followed by a SHA-1 hash of the plaintext data.

To avoid the need to create new packet types in the future (maybe there will
be a demand for a larger sized digest algorithm or someone likes to
replace SHA-1 by RIPE-MD160) we should at least encode a version number
in the encrypted data packet. 
 
> redundancy at the beginning to verify the correct key; and a SHA-1 hash

Keep the Zero-IV and extend the current scheme.  Implementions must
already cope with this to be compatible with rfc2440 and there is no
security risk with this.

> Larger ciphers must use the new format.  Again, this is a perfect

  If a cipher with id >= 7 is listed in the preferences an
  implementations SHOULD use the new format.

I think there are no implementations which are yet using those
ciphers, so we can easily fix it without breaking rfc2440 too much.

> opportunity to make this change because large ciphers won't be backwards

But they are compatible with rfc2440 - despite the fact that we don't
have a cipher id for those official assigned (except the reserved ones
for AES).

> For this purpose there is no need for a shared secret and it is

Right.

> no need for variable hash algorithms in this context.  The attacker does

"There will never be the need for more than 640k of RAM" ;-)

We have already specified hash preferences which may be utilized to 
use a different hash algorithm.  So it would be wise to encrypt a 
version number, the type of MDC used and the hash algorithm with the
encrypted text.  We are already prefixing the message with some random
bytes and a kind of checksum; we can simple add those additional 
information and don't increase the risk of a known plaintext attack as
the structure of the data which follows is anyway known (literal data
packet or compressed data packet).

---

From: Paul Koning <[email-masked]>
Date: Tue, 13 Apr 1999 11:21:07 -0400

>>>>> "Werner" == Werner Koch <[email-masked]> writes:

 Werner> uri <[email-masked]> writes:
 >> So? Compared to cost of one RSA or DSA operation, one SHA-1 is
 >> negligible.  Who cares?

 Werner> Hashing 700 Mges takes a while and sometimes conventional
 Werner> only encryption is used. 

True, but compared to conventional crypto SHA-1 is still a small
component.   I've measured it at 4-5 times the speed of single DES.

	paul

---

From: Tom Zerucha <[email-masked]>
Date: Tue, 13 Apr 1999 13:13:31 -0400

> the current one but which would resolve these problems.

Note that what you are defining is a different "method" or processing
layer.  This is NOT best implemented using different cipher numbers, but
with a range of cipher numbers or some other key indicating the new usage.

The current structure could be described as follows:

Plaintext -> IV/CFB xor -> Ciphertext
                ^
                |
   Secret -> Cipher

(By secret I mean all material, both key and initial IV if nonzero, etc.).

The IV/CFB xor box resets at 10.

The new model becomes (please correct ommissions)

Plaintext -> MAC append -> IV/CFB xor -> Ciphertext
                               ^
                               |
                   Secret -> Cipher

The IV/CFB box is different.  So why not just define a new IV/CFB mode or
method instead of jamming this definition into the cipher?

For now, I would prefer looking at a way of specifying the new IV/CFB or
whatever *method* as different from specifying the underlying cipher.

Also the MAC gives me some indigestion.  There are uses of this for stream
processing, and the MAC in this format needs an OOB EOF and processing. 

And to ask a question, how do I know where the MAC is?  I have to decrypt
and hold back 20 bytes just in case I see the EOF?  The new stream format
might have EOF detect problems there, i.e. I don't know where the MAC is
until I am past it.  (This is easily addressed, so should be before
proceeding).

(See my comments following)

> opportunity to make this change because large ciphers won't be backwards

Is there a particular reason not to use the old ciphers with the new
format (if it is available)?  Other than backwards compatibility - which
you won't have anyway?

> would just consist of a hash of the message to protect its integrity.

Such as a signature with a "zero" encryption algorithm that would just
store the 20 bytes of the SHA-1 hash?  This could be easily added to the
existing code (with provisos that it doesn't display as a signature).

> sense to make it part of the encrypted packet.

Or simply encrypt the signature with the symmetric algorithm the message
was encrypted with (instead of the PK signature algorithms).  This leaves
all the existing hashing code where it is and only requires a mod to the
final stage (and perhaps preservation of the cipher state on EOF).

Doing a MAC within the encryption packet now adds a layer on the inside,
which will be there even for signed messages.

I really don't like extra layers if an existing layer can provide the
functionality.

> the encryption layer ensures that all encrypted messages have integrity

Since you can have multiple signature packets, adding the symmetric MAC
"non-signature" adds this function without the layer.

> years, without facing backwards compatibility issues.

Please fix the symmetrical encryption packet lack-of-checksum while you
are at it.  (This is when you have a pass phrase protecting more key
material - the second has no checksum so you can't tell if the key is good
without decrypting some of the ciphertext).

---

From: uri <[email-masked]>
Date: Tue, 13 Apr 1999 14:05:38 -0400 (EDT)

> Plaintext -> MAC append -> IV/CFB xor -> Ciphertext

It's not MAc - it's MDC. Otherwise your diagram looks correct to me.

> method instead of jamming this definition into the cipher?

I don't know - does it really matter how to define "this" new way
of processing?

> processing, and the MAC in this format needs an OOB EOF and processing. 

What is "OOB EOF"? What's the big deal anyway? You're firing up encryptor
and at the same time block-by-block computing MDC (SHA-1 hash). When you
reach the last block, you have your MDC complete and can encrypt it as
block-after-last... When decrypting you always take the last 20 bytes
as MDC... What problem am I missing?

> And to ask a question, how do I know where the MAC is?

In the last 20 bytes of the plaintext, where else...

> I have to decrypt and hold back 20 bytes just in case I see the EOF?

You have to decrypt - then you have to "clip" the last 20 bytes of
the resulting plaintext and give them to MDC verifier. Of course 
you can be computing the MDC block-by-block as you're 
decrypting the message...

> format (if it is available)?  Other than backwards compatibility - which

Yes. It is preferable not to introduce the whole zoo of algorithms.
So with the move to 128-bit block ciphers I'd expect AND PREFER
the old 64-bit block ciphers to quietly go away, the sooner
the better.

> existing code (with provisos that it doesn't display as a signature).

I'm strongly against it. Such a signature does not make sense [to me].

> which will be there even for signed messages.

It is NOT a MAC - it's MDC (Modification Detection Code). Different
type, different application, different security considerations.

(:-)

> "non-signature" adds this function without the layer.

In short, I'm against it.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: Tom Zerucha <[email-masked]>
Date: Tue, 13 Apr 1999 15:47:38 -0400

> I don't know - does it really matter how to define "this" new way

It depends a lot if new ciphers are all going to use the new method, or if
it will be defined with existing ciphers.  If the method is going to be
specific to the ciphers, then it makes sense to incorporate it into the
ciphers.  If there are going to be multiple methods applied to ciphers, it
is best to define the methods.  The spec has ciphers and the PGPCFB method
defined in different areas.  If we add a method, it would be applicable to
ciphers.  Otherwise the method becomes part of the cipher and we should
restructure the document (and derivative code) that way.

> What is "OOB EOF"?

Out Of Band End of File, e.g. getting 0xffff instead of 0-0xff in getchar. 

> What's the big deal anyway? You're firing up encryptor

So we are going to require multithreading?  If I don't have that
capability, "firing up" multiple filters isn't as simple as you make it
out to be.  Can I pass the data through two layers instead of one?  Yes,
but I don't want to if I don't have to.  Especially since it would be
encrypt(mdc(hash-for-signature(plaintext))) now.  PGP is already bloating
as it is.

> In the last 20 bytes of the plaintext, where else...

If you don't know the length of the input, this means it is at which byte?

Saying something is 5 miles east of Kunkle doesn't help if you don't know
where Kunkle is.  So I keep feeding bytes to the hasher, and then oops, I
only have 10 bytes left.  I have to rewind now that I know the length of
the file.  Or I have to hold back 20 bytes until I know where the real EOF
is.

> decrypting the message...

So if the data is coming through a pipe, how do I know there are going to
be exactly 20 bytes and no more coming through?  If I want to run through
the file once to count, fine, but assume that I don't.

Either that or require the old style CTB prefixes - the ones that give the
length instead of the new ones designed to do streaming.  Streaming does
have disadvantages.

Or put the MDC at the beginning.  This should be just as easy, and you can
just save those 20 bytes, decrypt/hash and then memcmp(,,20).  This is
only slightly less difficult, but it would be on the encryption side, and
encryption is done fewer times than decryption.

> the old 64-bit block ciphers to quietly go away, the sooner

Then why not drop PGP entirely?  I doubt there is going to be a move to
the new ciphers until everyone has the newer versions, and there are still
people using 2.6.x.  In short, they won't go away.

> I'm strongly against it. Such a signature does not make sense [to me].

It isn't a signature.  It is the same 20 bytes encrypted, except within
the existing packet structure.  No new layers, processing, or code ripups. 
If you want to put 20 bytes of MDC somewhere, these packets have a place
for it, and it is easier to add one more new signature (non-signature) 
subtype than an entire new layer of processing. 

If you want an MDC, and there is already a place for MDCs, then it should
go there if the format can be adapted.

> In short, I'm against it.

And I am against adding an MDC to the "inside" of the symmetric encryption
packet.  There is already a defined place for one outside, although only
in the context of either null or PK encryption.

In short, if you really want to do this, then add an MDC-only signature
type or subtype.  The (non)signature packets will be encrypted with the
rest of the stream.  In fact, the null cipher type might work as is.

Does anyone have a reason that (plaintext+20) is going to be worse than
(1passhdr)(plaintext)(sig-MDC)?  The code for the latter already exists -
simply bypass the PK encryption.

This also adds the MDC capability to the old ciphers.  The spec already
warned about PK alg ID 0, or we can add a new one, but I don't know what
the various implementations do.  If MDC is that useful, it will be useful
with the old ciphers.

Or just define a completely new packet ID for the MDC.  It will be
basically a signature packet minus a lot of header and other bytes, but
you would have (plaintext)(MDC) with known boundaries.

---

From: uri <[email-masked]>
Date: Tue, 13 Apr 1999 16:23:44 -0400 (EDT)

Tom Zerucha says:
> So we are going to require multithreading? 

No, I'm merely saying that the logical processing would be

	do
	   get new plaintext block
	   update the hash
	   encrypt plaintext block and spit it out
	until last block is done
	spit out the MDC
	encrypt MDC

> If I don't have that

No. It's
	encrypt(plaintext||hash(plaintext))
    where
	mdc(A) = hash(A)

> If you don't know the length of the input, this means it is at which byte?

Since you can't avoid getting to the last byte when decrypting, and
since you have no business monkeying with MDC until you finished
decrypted, telling you that MDC is in the last 20 bytes is both
necessary and sufficient...

> where Kunkle is. 

Since you *are* going to Kunkle, and if you don't get there nothing
else matters - the "5 miles east" is as precise as you have to know.

> So I keep feeding bytes to the hasher, and then oops, I

A very good point, thank you! Yes, it is more complicated on decrypting
side, as you spotted (and I confess - I didn't).

However, as you yourself point out, the solution is simple, if less
than beautiful.

> the file once to count, fine, but assume that I don't.

Oh, I do assume you don't want to run through the file counting! (:-)

The practical solution I see is delaying the hash update when decrypting
by one block. I.e. you decrypt block K+1 and hash block K... Yes, it's
not going to win a beauty contest. But it will work.

> encryption is done fewer times than decryption.

Nope! The problem with this is - you'll *have* to run through the file
on extra time. Undesirable for pipes!

> Then why not drop PGP entirely? 

This you can figure out yourself (:-)

> I doubt there is going to be a move to

Which is why people preserve ugly backwards compatibility, but aren't
bending over their backs to modify/improve the old modes.

> go there if the format can be adapted.

OK, I don't object as strongly any more. I'm neutral now.

> rest of the stream.  In fact, the null cipher type might work as is.

But it's NOT a signature!

> you would have (plaintext)(MDC) with known boundaries.

Hmm... Not qualified to judge this.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: Werner Koch <[email-masked]>
Date: Tue, 13 Apr 1999 22:02:18 +0200

> as MDC... What problem am I missing?

Tom already described it.  You have always to store the last 20 bytes 
of what you are decrypting instead of writing it simply to the output.
We introduce the onepass signature packets to implementing a stream
mode of operation so why add the extra burden for deferring the last
bytes?

But I think this is still the most simple solution and we should do
it.  A more sophisticated solution could be to put MDCs every n byte
into the data to help early detection of modification.  However this
has not much to do with offline encryption but with online protocols
like SSH.   So I suggest we keep the simple solution but use use a new
packet type for it.

> the old 64-bit block ciphers to quietly go away, the sooner

I think it is bad style to change a standard which already defines how
to handle different blocksizes (albeit with some conflicts).

> I'm strongly against it. Such a signature does not make sense [to me].

It really does not make sense without a MAC (message authentication
code).

---

From: Tom Zerucha <[email-masked]>
Date: Tue, 13 Apr 1999 17:36:25 -0400

> Oh, I do assume you don't want to run through the file counting! (:-)

No, I want to both count and hash at the same time, but I can't because...

> not going to win a beauty contest. But it will work.

With the stream format the last block might be less than 20 bytes.  A 520
byte file will be 512+...8 (or for larger values, 5000 would be
4096+...4).  And you can't hold back one "block", at least it would be
difficult if the block is the maximum legal size (2^31 bytes?).  You have
to hold back at least 20 bytes at the end of any nonterminal packet.

> on extra time. Undesirable for pipes!

Only on encryption!  I would rather run through one more time there, than
once per decryption.  Decryption is really messy but only requires a 20
byte delay, so it is not quite the same thing.

> OK, I don't object as strongly any more. I'm neutral now.

Lets see what the other implementors have to say.  If expanding the
definition of an existing packet to "verification (signature or MDC)" 
packet is easy to do in the existing code base (incl NAI PGP 6.0!), we can
start implementing this now as a test.  Then we would have MDCs and be
able to merge them into the spec, and both spec and code would update in
synchronization.

> But it's NOT a signature!

I don't know what else to call it because it is identified as the
"signature packet" in the Spec.  Maybe we can start calling it the
"frooble" packet if that would be less confusing.

I prefer simply renaming "signature packet" to "verification packet" or
whatever it would be - and this nomenclature change should be done.  But I
can't use different words right now with out it being even more confusing.

---

From: Tom Zerucha <[email-masked]>
Date: Tue, 13 Apr 1999 17:49:01 -0400

> like SSH.   So I suggest we keep the simple solution but use use a new

This could be implemented with a new packet-stream type, so that the
partial packets could append X bytes.  Putting an MDC at the packetization
level is better than at the crypto level.  I.e

(1:4096)(4096:data)(MDC:20)...(1:17)(17:data)(MDC:20)

> to handle different blocksizes (albeit with some conflicts).

Which is why I call it a different "method".  The spec already has
something for the existing method (PGP/CFB) with larger block sizes, and
my implementation is set up to handle these correctly, at least as far as
I have been able to verify.

---

From: Adam Back <[email-masked]>
Date: Tue, 13 Apr 1999 23:51:26 +0100

Tom Zerucha writes:
> Uri writes:

I think Ian Brown is away from email at present travelling, but
perhaps systemics/Ian Grigg would have comments; the cryptix java PGP
implementation is heavily object oriented -- I would expect that
modifying for MDC sigs would be easy -- just adding a new
specialisation signature, with a new reserved number.

The append hash method however is all new, and has the buffering
problems Tom was identifying, and whilst it is easy to conceptualise
and say "oh that's easy just do blah" actually _doing it_ to some code
brings out the complexity of it fast.  PGP's 5.x and 6.x code is
object oriented too.

> can't use different words right now with out it being even more confusing.

The name of the packet in RFC2440 doesn't sound like a big stumbling
block here either.

Adam

---

From: Adam Back <[email-masked]>
Date: Tue, 13 Apr 1999 23:43:39 +0100

> be compatible with "new old" methods. Enough is enough.

We had plenty of warning about the MDC issue.  The issue was discussed
on this list over a year ago (Jan 98).  Even before that Gary Howland
presented the problem at Hip in Aug 97.  If I recall at the time ita
was reported that PGP made a press release or some kind of public
statement saying they had a fix for the problem.  We have a recently
released rfc2440 and people are now finally talking about fixing the
MDC problem, yet they want to do it in ways which rfc2440
implementations can't benefit from.

> A good enough reason for me to vote down the support for MDC in

Not really, the symmetric MDC packet is more elgant, as well as
providing the possibility of working with the existing RFC, and so
provides more overall security.  We only just finished writing 2440,
and you want to start obsoleting it.

There are I think more pgp2.x implementations than 5.x, 6.x and GPG
together.

I think your comments about ease of implementation are off-base -- Tom
Zerucha, who wrote an OpenPGP implementation votes that symmetric MDCs
are easier.  I haven't implemented OP, but I have implemented parts of
pgp2.x, and I think this change would be easier also.  It fits right
into the existing framework, and doesn't require buffering tricks.

> Let's say that we disagree here.

Perhaps if we could list the pros and cons:

- ease of implementation (MDC sig wins)
- adds security for more implementations (MDC sig wins)

What are your arguments against MDC sigs?

Note I am not against the "big clean up" phase planned for openPGP
2.0.  I am all for it.  I think PRZs suggestion that we add a new
encryption method (standard CFB etc) is a _good thing_.  However I
would sooner see MDCs implemented in a way which fits into the
existing framework, and thus is backwards compatible!  That's what the
framework is for -- so that there are defined means for algorithms to
get added.  Therefore I argue you should do what you can, especially
when it is more elegant anyway, within the existing framework.

Adam
-- 
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

---

From: uri <[email-masked]>
Date: Tue, 13 Apr 1999 18:51:44 -0400 (EDT)

> No, I want to both count and hash at the same time, but I can't because...

Yes you can - but you th hash may be one block behind. Still, you run
through the file only once, and do a bit of special things at the *end*.

> to hold back at least 20 bytes at the end of any nonterminal packet.

I meant - one cipher or hash block, i.e. 160 bits. So if you got the last 
*file* block 4 bytes, you figure that these 4 bytes together with the last 
16 bytes from the "saved" last cipher-block constitute the MDC.

> byte delay, so it is not quite the same thing.

But it seems unnecessary to introduce such "second run".

> Lets see what the other implementors have to say. 

Sure.

> "frooble" packet if that would be less confusing.

A "signature" vouches for the authenticity of the data. MDC vouches
only for its integrity...
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: Werner Koch <[email-masked]>
Date: Wed, 14 Apr 1999 19:43:42 +0200

> able to merge them into the spec, and both spec and code would update in

I like Tom's proposal.  If someone can define the extension to the
signature packet (or a new one) I'll add it to GnuPG ASAP.

---

From: Werner Koch <[email-masked]>
Date: Tue, 20 Apr 1999 18:18:08 +0200

> signature packet (or a new one) I'll add it to GnuPG ASAP.

Hmmm, no comments on this for a week.  Does this mean I should design
a new packet or extend the signature packet specs?