Subject: Message Integrity

From: Jon Callas <[email-masked]>
Date: Wed, 21 Apr 1999 16:24:46 -0700

My apologies for not jumping in here sooner.

The consensus that I've seen is against overloading message integrity on
signature packets. We also discussed it in Orlando, and there was great
consensus against it there. I confess that personally, I also question the
wisdom of separating them. Especially if it requires a shared key.

In Orlando, there was consensus that we wanted to add several things to
OpenPGP for our next RFC. They were:

(1) Message Integrity Codes (a.k.a. MDCs or whatever. I've been using the
term Message Integrity Code or MIC -- if people prefer the other
terminology, I can write it up that way.)

(2) Normalization of encryption modes. Among the solutions to this are (a)
using normal CFB mode or (b) using CBC mode. I've heard from people who
prefer each, and don't know if there's a consensus on which is better. I
don't care.

(3) Rich user IDs.

(4) A V5 signature packet that allows 4-byte lengths. There's a tangential
discussion to this that is to start deprecating some of the more bizarre
length types, but that's a can of worms I don't want to open today. Next
week.

(5) A signature sub-packet that allows a certificate to declare which of
the above advanced features it speaks. I've been calling this the
"features" subpacket.

Only (1) and (2) are germane to this present discussion.

A scheme that has been discussed, and I thought we had a lot of agreement
on even back in Orlando was to solve (1) and (2) with a new encrypted data
packet that used a standard encryption mode and appended a hash at the end.
I've been in discussion with several people who've offered several opinions
on what that hash can or should be, and I believe that the best thing to do
is just make it a SHA-1 hash, as a minimal OpenPGP implementation must
already have SHA-1 in it. No one who's done any work on it has come up with
a different solution that is better.

I really don't like overloading MICs on signature packets. That's a kluge,
and it offends my sensitive architect's aesthetics. OpenPGP already has
quite enough kluges in it. I'd prefer to stomp on a few rather than add
another. Adding in shared keys makes it a worse kluge. I can't see what
goodness comes from a null-signature packet.

I've been waiting for someone else to create this packet, and I'm tired of
waiting, so here's *my* definition of it. This new packet is like Packet 9
in semantics but consists of:

- Encrypted data, the output of the selected symmetric-key cipher
       operating in (XXX) mode.

-  A 20-octet SHA-1 of the plaintext contents of the packet. Note that if
the contents of the encrypted packet is another packet (or packets), the
hash runs over the whole of them.

I confess that I am concerned about the possible implementation
difficulties here, but I'm also confused, because I don't see the problem.
Unless the packet is encoded with indefinite length, you know how long the
thing is. So you just subtract 20 from the length, and you know how much to
hash. I am willing to write in there that if the packet is coded with
indefinite length, the last chunk MUST include at least one byte of data
and the 20-byte hash. Does this help any implementation problems? Tom? Hal?
Werner?

	Jon

---

From: Tom Zerucha <[email-masked]>
Date: Wed, 21 Apr 1999 20:41:07 -0400

> wisdom of separating them. Especially if it requires a shared key.

Or a well defined "anonymous" sign-only key, which is what I think Adam
Back was proposing.

> a different solution that is better.

When was the Orlando meeting and who attended?  New packet types should be
avoided if only because you cannot tell what old implmentations will do
with them.  They would know that they cannot handle a new algorithm in an
existing packet type because they would know it was an encryption packet.

I don't think anyone objects to using SHA-1 for the purpose of a MIC.

> goodness comes from a null-signature packet.

Throwing 20 bytes at the end of a stream instead of making it a packet is
a worse kluge (imho).  A standard anonymous key assigned to "MIC
validation only" wouldn't make it worse and would allow this functionality
in a method that is actually compatable with existing implementations.

The goodness is that the code is there (and hopefully tested), so that the
information - the hash result (which is already computed for signatures
when they are present) is simply inserted without the signature
computation step.  This takes only a few lines of code in most
implementations - the addition of a non-signature algorithm ID.  (I would
suggest ID 0 since it implied a null algorithm at one point).

We could be doing interoperability tests on MICs using existing algorithms
next week.

> - Encrypted data, the output of the selected symmetric-key cipher

Use the existing packet.  Specify a new algorithm number.

Or will no one ever want to do 3DES, CAST, or IDEA encryption with MIC?

Will the REQUIRED algorithms include this new algorithm?  Unless you do,
this is the only way you are going to get a MIC.

If you don't, but want the MIC to be SHOULD, the new packet ID is an old
packet (maybe with other fixes) but with appended MIC.

And I don't see the new algorithm(s) being adopted that quickly.  When is
SSL going to have Twofish?

> hash runs over the whole of them.

If you must do this outside of the existing signature packet, then make
just this the new packet, potentially with a corresponding 1-pass header
packet.

> and the 20-byte hash. Does this help any implementation problems? Tom? Hal?

Every encryption packet since 5.0 in many implementations uses the
indefinite length format.  So start by assuming every packet in this new
format is going to be (for the same reason Encrypters don't want to put
the 20 bytes up front - it requries a rewind operation so it won't work on
a stream - the old CTB/length had to be rewound to).

Your proposal adds a problem to the encryptor since the minimum indefinite
length byte is 512, so what if there are 500 bytes left?  You could simply
make the buffer 512+20 bytes and emit a end packet with the final length,
so it isn't that bad, but must be watched for.

Further, there is no "validation" routine at the end of the existing
decryptors.  The good/bad message handler will have to be added and
identify the encryption layer as detecting the fault.  If you complain
that signatures are a different class of validation, I would counter that
encryption is a different phylum.

But no one has said why the MIC can't simply be in its own packet, so I
get the virtual EOF for the encryption stream, then see the MIC packet
(i.e. a current signature packet with lots of stuff removed and a
different number) and pull 20 bytes from it.  So you have a separate
packet and packet handler.  It would be a MIC layer between the signature
and encryption layers.  Doing exactly one less step than the signature
layer.

Let me throw in one more complication.  The above formats generally have
fixed length, so you know where all the bytes are.  Extending to
validation packets would make the boundary where the end of message is
hard to find.

I don't understand how adding a new packet type with a new method
(encryption-cum-MIC) with new algorithm IDs and formats which are all
still undefined is less a kludge than simply using a new algorithm ID for
the new encryption algorithm, and specifying Algorithm 0 and storing the
SHA1 result as a plain MPI in the existing structure.

Everyone really wants new code, new layers, new specifiers?  I don't like
writing code that much, and I prefer simplicity.  And having existing
working, tested code as a base is better than ex-nihilo code.

Does anyone have any functional problems (e.g. security holes) with
modifying the existing signature packet into a validation packet?

---

From: Werner Koch <[email-masked]>
Date: Thu, 22 Apr 1999 10:13:56 +0200

> and the 20-byte hash. Does this help any implementation problems? Tom? Hal?

No, it would make thinks even more worse.  In my implementation the
encryption layer does not know about things like packet length or
wehter a packet uses partial length headers.  Requiring that the last
chunk must be at least 20 bytes would need some special hacks to allow
it.  There is an explicit statement, that the last chunk may even have 
a length of zero. 

I'd prefer an extra MIC packet which can be handled nearly the same as 
a signature packet and has the advantage of easier implementation (no
delay line), usable with 64 bit blocksizes too, extendable to be used
for file attributes (although I think, this has to go to the literal
data packet). 

However, to come to a solution we should use the
        IV|checkbytes|plaintext|SHA1
proposal and assign a new packet type to it (and add a version number
just in case we want to change it again).

How do we handle secret key material encryption with 128 bit
blocksizes?  Increase the IV in the packet to the blocksize or keep
it at 8 bytes?

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

---

From: Adam Back <[email-masked]>
Date: Thu, 22 Apr 1999 09:25:18 +0100

> Or a well defined "anonymous" sign-only key, which is what I think Adam

Yes that was a third proposal, which has the advantage over the other
two that it works with out changing old software, and new software
could be setup to regonize the defined keys, and display different
messages on that basis.

I also like Tom's suggestion of using algorithm ID 0 for signature.
Adds conotations of "no signature algorithm".  Nice.  Why don't you
try implementing that in your PGP implementation Tom?  It should come
out as fewer lines, and simpler code than the other method.  You
should be able to post the patch (export control wise) because it is
authentication only.

There is a potential problem with shared key, we would need to be
absolutely sure that people did not erroneously include certificates
made by it in the WoT calculation.

Distributing it with trust parameter of 0 might work.  It would need
to be looked at further wrt the major implementations behaviour.

Adam

---

From: Adam Back <[email-masked]>
Date: Thu, 22 Apr 1999 09:25:51 +0100

Jon Callas writes:
> signature packets. 

I disagree.  Perhaps you weren't reading.

Tom Zerucha and Werner Koch sounded like they were going to try out
verification packets.  I argued for the approach also.

Hal Finney presented the bundled MDC+encrypt approach, and did a
trial implementation.  

Uri Watson at first argued against verification packets based on ease
of implementing bundled MDC+enc, but revised that to neutral, viz:

Tom wrote:
> Uri wrote:
> > If you want an MDC, and there is already a place for MDCs, then it should
> > go there if the format can be adapted.
> 
> OK, I don't object as strongly any more. I'm neutral now.

So I tally that as 3 verify packet, one bundled MDC+encrypt, and one
neutral.  You breeze in late and call that a concensus for
MDC+encrypt?

> We also discussed it in Orlando, and there was great consensus
> against it there. 

I wasn't at Orlando.  No minutes were ever posted that I discovered.
Decisions are supposed to be made on list.

> I confess that personally, I also question the wisdom of separating
> them. Especially if it requires a shared key.

What shared key?  PRZ proposed SHA1 not a keyed MAC.

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: Thu, 22 Apr 1999 12:13:15 -0400 (EDT)

Adam Back says:
> of implementing bundled MDC+enc, but revised that to neutral, viz:...

Hmmm, It's Uri BLUMENTHAL (who happens to work at Watson Research Center :-).
[Though I'm sure old Thomas Watson would be proud if I were to adopt his
family name :-]
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: uri <[email-masked]>
Date: Thu, 22 Apr 1999 12:09:50 -0400 (EDT)

> just in case we want to change it again).

If the above is the *plaintext* - I agree.  I personally like
implicit IV=0x00...0 and the plaintext prepended with random
128 bits.

> blocksizes?  Increase the IV in the packet to the blocksize or keep

NO! With 128-bit cipher you MUST use 128-bit IV. [I understand it's
coming across rather strong - but then, how much is your security
worth to you?]
--
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: Werner Koch <[email-masked]>
Date: Thu, 22 Apr 1999 18:38:25 +0200

> If the above is the *plaintext* - I agree.  I personally like

Sure.

> implicit IV=0x00...0 and the plaintext prepended with random

So do I,  s/IV/random_bytes/

> NO! With 128-bit cipher you MUST use 128-bit IV. [I understand it's

So we have to fix it in the RFC (I already implemented it this way).

---

From: [email-masked]
Date: Thu, 22 Apr 1999 13:27:10 -0400

> should be able to post the patch (export control wise) because it is

There is only one detail.  Do we use the DER prefix with the 0 and 1 so it
looks like a standard bignum signature, or do we just use the 20 bytes?

---

From: [email-masked]
Date: Thu, 22 Apr 1999 13:47:47 -0400

On Thu, 22 Apr 1999, Adam Back wrote:

> out as fewer lines, and simpler code than the other method.

The patch is now 83 lines affecting 3 files (sigchk sigmak elitmk).  I
think the DER version would be a few more, and it took less than 30
minutes.  I am using a keyid of zero to trigger the MIC mode (internally I
derive the algorithm from the keyid, but I could a flag or something
else). 

(Though I need to add a test to switch from "signature" to "MIC").

---

From: Werner Koch <[email-masked]>
Date: Thu, 22 Apr 1999 21:26:56 +0200

> derive the algorithm from the keyid, but I could a flag or something

I'll be ready by tomorrow.  For now I also just append the 20 bytes
but I think it would make more sense to use a bignum.

---

From: Jon Callas <[email-masked]>
Date: Thu, 22 Apr 1999 12:58:56 -0700

At 9:38 AM -0700 4/22/1999, Werner Koch said:

The RFC needs to be clarified, but the section I quoted before was put
there to do it the way you said, with block-length IVs etc.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Thu, 22 Apr 1999 15:10:44 -0700

At 12:26 PM -0700 4/22/1999, Werner Koch said:

I agree. It makes sense to make it be a bignum.

To be clear on this, what are you doing?

I presume that this is a V4 signature, with signature type of 0 (binary
document), PKALG of 0 (no public-key algorithm), hash algorithm type of the
appropriate hash, no subpackets, two hash bytes that duplicate the
high-order octets of the hash, and then a single MPI containing the hash.
Is this correct?

	Jon

---

From: Jon Callas <[email-masked]>
Date: Thu, 22 Apr 1999 15:00:17 -0700

At 1:25 AM -0700 4/22/1999, Adam Back said:

Nope. The consensus that I've seen since late last year is for a new data
packet that has a standard encryption mode, be it CFB or CBC, and a hash in
it. What I see *now* is that you want to revise that consensus.

I've seen arguments as follows:

(1) The MIC-signature can ride on existing signature processing. However,
it raises the question of how to handle it and public-key signatures too.
The issue of wanting both MIC-sigs and PK-sigs and how they interact in a
single message needs to be looked at, especially if we care about backwards
compatibility.

It's also allegedly easier to implement this way. I find Tom's report of
how easy it is significant. It would be nice if we had someone implement
both methods so they can be compared.

(By the bye, it is not a goal of this working group to make it easier to
tack features on to 2.X, especially now that there are two other
implementations out there that can be relatively freely modified -- Tom's
and Werner's. One of the OpenPGP principles is to encourage but not require
compatibility with 2.X.)

(2) There's a desire to deprecate PGP-CFB mode over time, and use either
standard CFB or CBC mode. This requires a new data packet anyway, so why
not kill two birds with one stone?

(3) A MIC-signature computes a hash over the plaintext. The integrated
packet computes it over the actual encrypted content, which is likely to be
compressed data, and may also include a real signature. This has the
advantage of providing an integrity check on the signature and compression
when they're available, as well as the meta-data (mode, filename, etc.) of
the literal packet.

This is important in the case where a message has been damaged, and you'd
like to know it is damaged before you go to the trouble of calculating the
signature. It also lets you detect attacks where someone damages a
signature packet, or changes unhashed data in it. These are all reasons for
MICing data, do we want to lose this property?

There's a compromise solution here, which is to make a separate packet type
for MICing -- I forget who suggested this -- but if you're going to hash
the whole packet, not just its contents, then you lose the
ease-of-implementation benefit.

You suggested a shared public key. Sorry, I find that a kluge. If we're
willing to live with a MIC-signature that has only a hash in it, that's
fine. But using a universal public key makes me wince.

I'd like to see discussion of the points I laid out above. When I look at
them, it seems to me that the integrated packet is the best solution. Feel
free to change my mind on it.

	Jon

---

From: Adam Back <[email-masked]>
Date: Fri, 23 Apr 1999 00:06:07 +0100

Tom writes:
> minutes.  

Cool.

> I am using a keyid of zero to trigger the MIC mode (internally I

Wasn't keyid of all 0s already reserved for another purpose.  I seem
to recall a discussion by Hal and others some time back about reducing
the number of keyid bits to reduce identity leakage.  Ultimately this
came down to having an empty keyid, where the recipient would have to
check on private keys on their key ring sequentialy to discover which
one to use.

I don't know the outcome of this old discussion.  Did the variable
length keyid go beyond discussions?

Don't you use the algorithm ID (1 = RSA, 2 etc) as the item in the
switch statement in your existing code?  Couldn't you then use alg ID
= 0 for no sig?

Adam

---

From: Adam Back <[email-masked]>
Date: Fri, 23 Apr 1999 01:26:34 +0100

Jon writes:
> The consensus that I've seen since late last year is for a new data
> packet that has a standard encryption mode, be it CFB or CBC, and a
> hash in it. 

I did a little grepping of last years open-pgp traffic.  The posts
discussing MDCs are below.  None of them mentions this idea.  I asked
at the time if anyone at PGP planned to fix MDCs and Hal responded:

Hal wrote in Jul 98:
> There is no plan to add MAC or other lightweight signatures to PGP 6.0.
> That may go into a future version.

As far as I recall Hal's recent posting of PRZs "hash inside enc
envelope" was the first time I have seen that proposal.

As none of the posts to the list mention the proposal in question I
can't see how you can claim there was a concensus for it on list "last
year".

I have no idea what was discussed at the Orlando meeting, because as I
said, no minutes were ever published that I found.

These were all made around July 1998:

Tom:
> Unless they do something nonsensical, it would be easy to extend 1.0 - for
> example, 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".

Adam in response to Toms above proposal:
> The most important aspect of this, as Tom suggested, is that
> openPGP-1.0 should gracefully cope with this (and other similar)
> unknown signature packets, by still emitting plaintext.
> 
> I suggest that we consider reserving a packet number for MDC/Integrity
> check purposes.

Jon in response to Adam:
> If you can design something that is wholly backwards-compatible, it'll be
> trivial to put it in 1.1 or simple document it as an extension. Not being
> in 1.0 won't be an issue
> 
> If you can't design something backward compatible, then it's too late to go
> in 1.0. Either way, it doesn't make it.

So after arguing against the idea of reserving an MDC packet in Jul
98, and saying it'll be trivial to make something backwards compatible
with 1.0 without doing so, you then argue the reverse now, when Tom,
Werner and I bring up Tom's earlier proposal for this which would have
benefited from reserving a verification packet ID.

Adam

---

From: [email-masked]
Date: Thu, 22 Apr 1999 22:31:53 -0400

> check on private keys on their key ring sequentialy to discover which

This was for encryption, so you could place the message in a public forum
without identifying the recipient.

For signing it would be less practical, and I don't know if anyone really
implements it.  (i.e. you would have to keep the public keys private so
only the group could verify the signature and know who signed it).

The algorithm ID would be zero too.  My implementation selects the
signature algorithm based on key id, but that could be fixed too, though I
would need to alter the command line and maybe some API parameters.

> switch statement in your existing code?  Couldn't you then use alg ID

Basically this is what I do, but I have it in the form of if-elseif-else
type things instead of case statements.

---

From: Werner Koch <[email-masked]>
Date: Fri, 23 Apr 1999 06:31:33 +0200

> appropriate hash, no subpackets, two hash bytes that duplicate the

Hmmm, I think I have subpackets but I can drop them.

> high-order octets of the hash, and then a single MPI containing the hash.

Yes.   And I put a onepass signature packet in front with a keyid of
all 0 and a pubkey algo of 0; it is not required for decryption.

---

From: Anonymous <[email-masked]>
Date: Fri, 23 Apr 1999 20:19:13 +0200 (CEST)

> (4) A V5 signature packet that allows 4-byte lengths.

Yet another signature packet version! Is this a scheme to increase
S/MIME support?

---

From: Tom Zerucha <[email-masked]>
Date: Tue, 27 Apr 1999 19:59:01 -0400

> Hmmm, I think I have subpackets but I can drop them.

Same here - I include the time and keyid, but they were required for
signatures.

> all 0 and a pubkey algo of 0; it is not required for decryption.

My 1pass is optional, but the same thing happens.  It does start the
proper hash algorithm.

(I haven't done anything with the other method - a new MDC packet; too
many other projects at the moment).

---

From: Tom Zerucha <[email-masked]>
Date: Tue, 27 Apr 1999 20:24:14 -0400

> Hmmm, I think I have subpackets but I can drop them.

In the message you posted, the length of both types of subpackets were
zero.  My program recognized everything fine, but didn't get the right
hash value.

I cannot get the hash to match - are you also hashing the 6 byte length
plus like a signature?  Are you also hashing the literal header?  Or maybe
I should just ask which portion is being hashed.

Date: Tue, 27 Apr 1999 20:24:14 -0400
From: Tom Zerucha <[email-masked]>
To: Werner Koch <[email-masked]>
cc: [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

> Hmmm, I think I have subpackets but I can drop them.

In the message you posted, the length of both types of subpackets were
zero.  My program recognized everything fine, but didn't get the right
hash value.

I cannot get the hash to match - are you also hashing the 6 byte length
plus like a signature?  Are you also hashing the literal header?  Or maybe
I should just ask which portion is being hashed.

Date: Tue, 27 Apr 1999 19:59:01 -0400
From: Tom Zerucha <[email-masked]>
To: Werner Koch <[email-masked]>
cc: [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Restricting key sizes to mult of 64 bits
Reply-To: [email-masked]
Date: Tue, 27 Apr 1999 01:29:48 (NZST)
Sender: [email-masked]

>Some users have already encountered a problem with oddly sized keys. We
>shipped software which used Microsoft's built-in Crypto API (CAPI) to do the
>RSA calculations.  As it turned out, CAPI had a bug which prevented it from
>working properly with unusual key sizes.  Those users weren't able to use
>their keys with the CAPI version.

This has been a known problem (well, known to everyone but Microsoft) since the
very first CryptoAPI shipped about three years ago.  For people who haven't
seen this, MS assume that an RSA key has certain fixed properties (eg that p, q
= n/2 bits exactly, that e < 32 bits, and various other bletcherousness - noone
will ever need more than 640K, and noone will ever type a URL larger than 1024
characters).  I don't think PGP should have to include workarounds for bugs in
their code.

>We would like to reduce the chance of running into similar problems in the
>future, and keeping keys to round sizes should help.  The choice of 64 bits as
>the multiple is based on trading off the desire for plenty of key sizes versus
>minimizing the chance of an unsupported key size.  The fact that DSS uses 64
>bit multiples suggests that this is a reasonable value.

I'm not sure of the rationale for this in DSS (possibly some hardware
limitation, perhaps in the Capstone chips?) but requiring it isn't a good idea.
DSS assumes that you'll be using Kravitz' kosherizer to generate keys, however
there are other, better (in some circumstances) algorithms which can't easily
generate keys of a certain size.  For example the Lim-Lee algorithm, which
generates keys with certain very nice properties for DLP-based PKC's, doesn't
easily generate keys of a certain size (this is a problem with the X9.42
standard for DH, which mandates the use of the kosherizer for generating DH
keys (!!!) and then has to add all sorts of horrible kludges to get around
things like small subgroup attacks.  If they used Lim-Lee this wouldn't be a
problem, and generation would be much more efficient than with the kosherizer).

The point of this ramble is that requiring certain more or less arbitrary
properties (eg X9.42's requirement to use the kosherizer) greatly limits the
flexibility available during key generation while providing no clear advantage.

Peter.

Date: Fri, 23 Apr 1999 21:30:43 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Message Integrity
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> Or even better, use a special encryption packet to indicate that there
> is a MIC (MDC) following, and a special MIC packet to hold it following

I think this will be the cleanest solution.

  * Create a new encrypted data packet:
    - 1 byte version number (please, we have this on most others too)
    - 1 byte mdc-algorithm  (hash algorithm used or 0 for no MDC)
    - n byte encrypted-data (in standard CFB mode with prepended
			     random and check bytes)	
    
  * Create a MDC packet:
    - 1 byte  version number  
    - 1 byte  mdc-algorithm (should be > 0 )
    - n bytes hash  

I don't know whether it is better to use 1 or 3 for the version
numbers.  I think PGP 6 has some new packet types, so someone
else should suggest the numbers.

Implementation of this seems to be more easier than the hacked
signature packets.  Maybe a little bit more code but much easier to
understand.  And we don't need to redefine the specs (I still remember
the trouble I had when using the old rfc1991 comment packet and then
the one from the draft).

We can state that the new ciphers (which are not yet defined in the
specs) SHOULD use the new encryption packet. 

  Werner

Date: Fri, 23 Apr 1999 21:02:57 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: MDC testdata
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

I did some test encryptions with GnuPG and MDCs ala Tom.
MDCs are stored as bignums. I hope not to annoy you with this
large stuff of material.

File x1: 
********
:pubkey enc packet: version 3, algo 16, keyid 6AE6D7EE46A871F8
	data: [1023 bits]
	data: [1023 bits]
:encrypted data packet:
	length: 96
:compressed packet: algo=2
:onepass_sig packet: keyid 0000000000000000
	version 3, sigclass 00, digest 2, pubkey 0, last=1
:literal data packet:
	mode b, created 924893198, name="hallo",
	raw data: 25 bytes
:signature packet: algo 0, keyid 0000000000000000
	version 4, created 0, md5len 0, sigclass 00
	digest algo 2, begin of digest 9b c8
	MDC data: [160 bits]

File x2:  (without compression)
********
:pubkey enc packet: version 3, algo 16, keyid 6AE6D7EE46A871F8
	data: [1019 bits]
	data: [1023 bits]
:encrypted data packet:
	length: 97
:onepass_sig packet: keyid 0000000000000000
	version 3, sigclass 00, digest 2, pubkey 0, last=1
:literal data packet:
	mode b, created 924893233, name="hallo",
	raw data: 25 bytes
:signature packet: algo 0, keyid 0000000000000000
	version 4, created 0, md5len 0, sigclass 00
	digest algo 2, begin of digest 9b c8
	MDC data: [160 bits]

File x3: (Twofish)
********
:pubkey enc packet: version 3, algo 16, keyid 6AE6D7EE46A871F8
	data: [1020 bits]
	data: [1024 bits]
:encrypted data packet:
	length: 105
:onepass_sig packet: keyid 0000000000000000
	version 3, sigclass 00, digest 2, pubkey 0, last=1
:literal data packet:
	mode b, created 924893255, name="hallo",
	raw data: 25 bytes
:signature packet: algo 0, keyid 0000000000000000
	version 4, created 0, md5len 0, sigclass 00
	digest algo 2, begin of digest 9b c8
	MDC data: [160 bits]

And here are the keys (passphrase is "abc"):

pub  1024D/68697734 1999-03-08 Alpha Test (demo key) <[email-masked]>
uid                            Alice (demo key)
uid                            Alfa Test (demo key) <[email-masked]>
sub  1024g/46A871F8 1999-03-08 

Date: Fri, 23 Apr 1999 20:19:13 +0200 (CEST)
From: Anonymous <[email-masked]>
Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at <[email-masked]>.
Subject: Re: Message Integrity
To: [email-masked]
Sender: [email-masked]

Date: Fri, 23 Apr 1999 15:01:16 +0100
From: "Detlef =?iso-8859-1?Q?H=FChnlein?=" <[email-masked]>
Organization: Secunet GmbH - The Trust Company
To: "[email-masked]" <[email-masked]>
Subject: Final Call for Papers - CQRE [Secure] networking
Sender: [email-masked]

Hallo!

Please accept my sincere appologies, if you receive this 
Final Call for Papers multiple times.

The mail is just to remind you that there are only !!! THREE !!! 
more weeks until the deadline for submission of extended 
abstracts on May 14th, 1999.

Recent news:
* best paper award at CQRE
* publication of proceedings in Springer's LNCS
* first invited speakers: 
   - Stephen Kent     (GTE)
   - Bruce Schneier   (Counterpane)
   - Helena Handschuh (Gemplus/ENST)

Best regards
    Detlef Huehnlein

***************************************************************
                  Final Call for Papers
            CQRE [Secure] Congress & Exhibition
        Duesseldorf, Germany, Nov. 30 - Dec. 2 1999
---------------------------------------------------------------
provides a new international forum covering most aspects of
information security with a special focus to the role of
information security in the context of rapidly evolving 
economic processes.
---------------------------------------------------------------
Deadline for submission of extended abstracts: May 14, 1999
CQRE - website: http://www.cqre.net (under construction)
CfP - at:       http://www.secunet.de/forum/cqre.html
mailing-list:   send mailto:[email-masked]
(where the subject is "subscribe" without paranthesis)
***************************************************************
The "CQRE [Secure] networking" provides a new international 
forum giving a close-up view on information security in the 
context of rapidly evolving economic processes. The 
unprecedented reliance on computer technology transformed 
the previous technical side-issue "information security" to 
a management problem requiring decisions of strategic
importance. Hence, the targeted audience represents decision 
makers from government, industry, commercial, and academic 
communities.

If you are developing solutions to problems relating to the 
protection of your country´s information infrastructure or 
a commercial enterprise, consider submitting a paper to the 
"CQRE [Secure] networking" conference.

We are looking for papers and panel discussions covering:

* electronic commerce
  - new business processes
  - secure business transactions
  - online merchandising
  - electronic payment / banking
  - innovative applications
* network security
  - virtual private networks
  - security aspects in internet utilization
  - security aspects in multimedia applications
  - intrusion detection systems
* legal aspects
  - digital signatures acts
  - privacy and anonymity
  - crypto regulation
  - liability
* corporate security
  - access control
  - secure teleworking
  - enterprise key management
  - IT-audit
  - risk / disaster management
  - security awareness and training
  - implementation, accreditation, and operation of secure systems
    in a government, business, or industry environment
* security technology
  - cryptography
  - public key infrastructures
  - chip card technology
  - biometrics
* trust management
  - evaluation of products and systems
  - international harmonization of security evaluation criterias
* standardization
* future perspectives

Any other contribution addressing the involvement of IT security 
in economic processes will be welcome.

Authors are invited to submit an extended abstract of their 
contribution to the program chair. The submissions should be 
original research results, survey articles or "high quality" 
case studies and position papers. Product advertisements are 
welcome for presentation, but will not be considered for the
proceedings. Manuscripts must be in English, and should not be 
more than 2.000 words. The extended abstracts should be in a 
form suitable for anonymous review, with no author names,
affiliations, acknowledgements or obvious references. 
Contributions must not be submitted in parallel to any conference 
or workshop that has proceedings. Separately, an abstract of 
the paper with no more than 200 words and with title, name and 
addresses (incl. an E-mail address) of the authors shall be 
submitted. In the case of multiple authors the contacting 
author must be clearly identified. We strongly encourage
electronic submission in Postscript format. The submissions 
must be in 11 pt format, use standard fonts or include the 
necessary fonts. Proposals for panel discussions should also be
sent to the program chair. Panels of interest include those that
present alternative/controversial viewpoints or those that 
encourage lively discussions of relevant issues. Panels that
are collections of unrefereed papers will not be considered.

Panel proposals should be a minimum of one page describing the 
subject matter, the appropriateness of the panel for this 
conference and should identify participants and their respective
viewpoints.

best paper award:
This award will be presented at CQRE to the authors of the best
paper to be selected by the program committee.

mailing list/ web-site:
If you want to receive emails with up to date information, please
send a brief mail to [email-masked]. You will find this call for 
papers and further information at http://www.secunet.de/forum/cqre.html.

publication:
The proceedings will be published by Springer-Verlag in the Lecture
Notes of Computer Science (LNCS) Series. The final papers must be
prepared as described in http://www.springer.de/comp/lncs/authors.html.

important dates:
deadline for submission of extended abstracts  May 14,  1999
deadline for submission of panel proposals     June 1,  1999
notification of acceptance                     June 25, 1999
deadline for submission of complete papers     July 30, 1999

program committee:
Johannes Buchmann  (TU Darmstadt)
Dirk Fox           (Secorvo)
Walter Fumy        (Siemens)
Ruediger Grimm     (GMD)
Helena Handschuh   (ENST/Gemplus)
Thomas Hoeren      (Uni Muenster)
Pil Joong Lee      (POSTECH)
Alfred Menezes     (U.o.Waterloo/Certicom)
David Naccache     (Gemplus)
Clifford Neumann   (USC)
Joachim Posegga    (German Telekom)
Mike Reiter        (Bell Labs)
Matt Robshaw       (RSA)
Richard Schlechter (EU-comm.)
Bruce Schneier     (Counterpane)
Tsuyoshi Takagi    (NTT)
Yiannis Tsiounis   (GTE Labs)
Michael Waidner    (IBM)
Moti Yung          (CERTCO)
Robert Zuccherato  (Entrust)

program chair:
Rainer Baumgart
secunet - Security Networks GmbH
Weidenauer Str. 223 - 225
57076 Siegen
Germany

Tel.: +49-271-48950-15
Fax: +49-271-48950-50
[email-masked]

Date: Fri, 23 Apr 1999 06:31:33 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Message Integrity
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Date: Thu, 22 Apr 1999 22:31:53 -0400
From: [email-masked]
To: Adam Back <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

Date: Thu, 22 Apr 1999 22:26:17 -0400
From: [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

On Thu, 22 Apr 1999 [email-masked] wrote:

> Do you have a sense of how big the code would be to implement the MDC in
> the encryption layer as originally proposed?  Possibly if the MDC were
> in a separate packet so you could identify it easily?

My estimate would be over 300 lines (which for me is about 6%).  If the
MDC were in a separate packet (with an indicator at front similar to the 1
pass signature packet, or the MDC has to go up front), it would not be too
much worse than my current changes.  Although it would be a new packet
type, it would be fall into the structure in parallel with the signatures,
i.e. where I have signatures started, I could add an else if (MDC_PRESENT)
and fire up the same hashing routines.

Basically instead of adding algorithm 0 to the signature generator/checks,
I add a new MDC packet type where the signature packets are processed.

Let me give it a try (probably this weekend), and see.  I will use my own
packet format and IDs.

So I would need either the MDC itself or an indicator packet *before* the
MDC-ed stream for this to be easy.

Functionally this is the elstrippo signature packet for MDC/MICs with a
different ID.  But it should be easier to parse.

Date: Thu, 22 Apr 1999 18:15:08 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: consensus was not against verification packets (Re: Message Integrity)
Cc: [email-masked]
Sender: [email-masked]

Adam Back, <[email-masked]>, writes:
> discussing MDCs are below.  None of them mentions this idea.

Actually, there was some mention of it, but it did not use
the term MDC so your grep did not find it.  Take a look at
http://www.imc.org/ietf-open-pgp/mail-archive/msg01670.html where you
are responding to an earlier comment by Jon:

: > I thought the consensus was that with 1.X we would look at adding
: > some form of integrity check, perhaps with a new type of encrypted
: > data packet.
: 
: The reason I am keen on adding a MAC is a) it is broken (badly in my
: view) and needs fixing; b) it is easy to fix; c) it does not affect
: backwards compatibility.
: 
: I prefer a digest packet inside the encrypted envelope (at the end of
: the plaintext to aid one-pass processing), rather than a MAC for
: reasons of simplicity (people already have code to compute and emit
: digest packets for the available hashes).  It is probably easiest to
: define the digest packet as a signature packet.  (This can then borrow
: the one pass packets etc from existing signature parts).

Not so different from the present discussion...

Hal

Date: Fri, 23 Apr 1999 01:49:10 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Subject: old MDC discussions
Sender: [email-masked]

The old discussions, should anyone wish to review them, can be found
by starting at the following links in sequence:

http://www.imc.org/ietf-open-pgp/mail-archive/msg01746.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01748.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01754.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01756.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01757.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01758.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01763.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01770.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01771.html

>From msg01771.html particularly, we have a description of the same
proposal that was made recently, and Jon proposing _not_ reserving
explicit packet IDs for it as requested in a message a few previous.

Jon:
>   Adam Back:
>
>    I didn't suggest that MDCs go into 1.0 in the last round.  What I
>    suggested was that the following be verified:
>    
>         that when processing a message containing signatures a 1.0
>         implementation MUST continue to emit plaintext (ie fail
>         gracefully) in the presence of signature algorithms it does
>         not recognise.
>    
>    this readily allows adding MDCs or other signature algorithms in
>    version 1.1, and ensures backwards compatibility is possible.
>    
> Sure, but I don't think we need to add anything. If someone writes an
> implementation that (for instance) bus errors when it receives an algorithm
> encrypted with AES (which I pick because we all know it's going to go in,
> but it isn't there now), then the implementation is clearly broken. 
> 
> Signatures are different because there's a meaningful thing to do -- emit
> plaintext, and shrug over the sig -- which is a little different than the
> crypto, or compression, or whatever. But nonetheless, there are many
> failure and partial failure conditions, and an implementation that doesn't
> fail gracefully is broken.
> 
> This spec isn't a how-to-program manual, it's a format specification. By
> necessity it tells you a lot of what to do with the format, but there's a
> lot that this document can't tell an implementor.
> 
>         Jon

and some even older discussions:

http://www.imc.org/ietf-open-pgp/mail-archive/msg01112.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01113.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01115.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01117.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01114.html

Adam

From: "Salzman, Noah" <[email-masked]>
To: William Lewis <[email-masked]>, "Salzman, Noah" <[email-masked]>
Cc: [email-masked]
Subject: RE: typo?
Date: Thu, 22 Apr 1999 17:34:27 -0700
Sender: [email-masked]

Thank very much, I understand now.

--Noah--

> -----Original Message-----
> From: William Lewis [mailto:[email-masked]]
> Sent: Thursday, April 22, 1999 5:19 PM
> To: Salzman, Noah
> Cc: [email-masked]
> Subject: Re: typo?
> 
> 
> You wrote:
> > The generator constant in the code sample has a "1" that is 
> not in the
> > preceding text.
> 
> CRC polynomials are usually written without the leading term. 
> Whether the  
> constant in the code has the term is an implementation detail 
> --- for  
> example, if the CRC width is the same as the word width (e.g. 
> a CRC-32), it's  
> easier and faster not to write it that way.
> 
> I'd recommend 
> ftp://ftp.rocksoft.com/clients/rocksoft/papers/> crc_v3.txt as  
> 
> an introduction to theoretical and practical 
> aspects of CRCs.
> 

Date: Fri, 23 Apr 1999 01:26:34 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: consensus was not against verification packets (Re: Message Integrity)
Sender: [email-masked]

Adam

From: William Lewis <[email-masked]>
Date: Thu, 22 Apr 99 17:19:28 -0700
To: "Salzman, Noah" <[email-masked]>
Subject: Re: typo?
Cc: [email-masked]
Sender: [email-masked]

You wrote:
> The generator constant in the code sample has a "1" that is not in the
> preceding text.

CRC polynomials are usually written without the leading term. Whether the  
constant in the code has the term is an implementation detail --- for  
example, if the CRC width is the same as the word width (e.g. a CRC-32), it's  
easier and faster not to write it that way.

I'd recommend ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt as  
an introduction to theoretical and practical aspects of CRCs.

Date: Thu, 22 Apr 1999 16:45:25 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: typo?
Sender: [email-masked]

Noah - I think that is OK.  CRC24_POLY is used in the sample code as:

                   if (crc & 0x1000000)
                       crc ^= CRC24_POLY;

So the extra "1" in CRC24_POLY is actually there to clear the "1" in the
crc variable.  It might have been clearer to define CRC24_POLY without the
"1" and then to do

                   if (crc & 0x1000000)
                       crc ^= CRC24_POLY | 0x1000000;

or even

                   if (crc & 0x1000000) {
                       crc &= 0xffffff;
                       crc ^= CRC24_POLY;
                   }

but it works out the same.

Hal

Date: Fri, 23 Apr 1999 00:06:07 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

Cool.

Adam

From: "Salzman, Noah" <[email-masked]>
To: [email-masked]
Subject: typo?
Date: Thu, 22 Apr 1999 16:22:37 -0700
Sender: [email-masked]

Sorry to interrupt the new invigorated discussion, but is this a typo?

------------
The CRC is computed by using the generator 0x864CFB and an initialization of
0xB704CE.

<snip>

6.1. An Implementation of the CRC-24 in "C"

       #define CRC24_INIT 0xb704ceL
       #define CRC24_POLY 0x1864cfbL
------------

The generator constant in the code sample has a "1" that is not in the
preceding text.

--Noah--

Date: Thu, 22 Apr 1999 15:24:29 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Message Integrity
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> derive the algorithm from the keyid, but I could a flag or something

Do you have a sense of how big the code would be to implement the MDC in
the encryption layer as originally proposed?  Possibly if the MDC were
in a separate packet so you could identify it easily?

Hal

Date: Thu, 22 Apr 1999 15:23:42 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Message Integrity
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I still don't see that the signature packets are a very natural or
comfortable place to put this data.

We would probably use one-pass signature packets for this so that the MDC
(MIC) can go at the end and the encryptor doesn't need to buffer up all
the data.  The format of a one-pass signature is:

 - version number
 - signature type
 - hash algorithm
 - public key algorithm
 - signing keyid (8 bytes)
 - nesting flag

Most of these fields are not relevant for the MDC.  We need to put
a magic value into one of them (Tom is looking for all-zero keyid,
others had suggested using a zero public key algorithm).  The others are
really not meaningful.  The signature type with all its variations is not
relevant; hash algorithm is unnecessary, a fixed hash algorithm is fine;
public key algorithm and signing keyid aren't meaningful; nesting flag
is not relevant either.

Likewise, the signature packet fields are equally meaningless:

 - version number
 - length of hashed portion (must be 5)
 - signature type
 - signature creation time
 - key id of signer
 - public key algorithm
 - hash algorithm
 - left 16 bits of hash
 - Multi Precision Integer holding the signature

Again, we have signature type, key id, public key and hash algorithms,
all unnecessary or irrelevant.  We have a timestamp, also inappropriate
for an MDC (which is inherently a transient concept).  We have the left
16 bits of the hash!  Will we keep that, when we're going to be storing
the hash itself in the MPI signature field?  It's just going to be a copy
of two bytes of the hash.  Utterly pointless.

And last we have the signature itself, which is the only meaningful piece
of data in this entire packet, since that is where we will put the hash.
We have to agree on how to encode the hash, presumably as an MPI, which
implies special treatment of leading zeros.  Or maybe we'll just shove
the 20 bytes in there and have done with it since we're misusing the
rest of the packet so badly anyway.

Looking over these comments, it's clear that these packets are completely
inappropriate for the use to which we are proposing to put them.
This solution is a real kludge.

If we absolutely, positively had to put this data into signature packets,
maybe we should create a new version of the packets and use that.
Or better still, use new packet types.  Make the prefix packet be just
a flag that the following data will be checked with a MIC.  Then make
the trailer packet just have the MIC in it.  Simple and clean, unlike
the above.

Or even better, use a special encryption packet to indicate that there
is a MIC (MDC) following, and a special MIC packet to hold it following
the encryption packet, as Werner proposed.  It is not too different from
the original idea and if it would help with the implementation it seems
like a reasonable method.

Hal

Date: Thu, 22 Apr 1999 15:10:44 -0700
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Message Integrity
Sender: [email-masked]

	Jon

Date: Thu, 22 Apr 1999 15:00:17 -0700
To: Adam Back <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: consensus was not against verification packets (Re: Message Integrity)
Cc: [email-masked]
Sender: [email-masked]

	Jon

Date: Thu, 22 Apr 1999 12:58:56 -0700
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Message Integrity
Sender: [email-masked]

	Jon

Date: Thu, 22 Apr 1999 21:38:40 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Phil Zimmermann's suggestion - Implementation?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> > indefinite length, and to my mind, it's there to provide TLS-like function,
> > which is probably better done with TLS. :-)
> 
> I don't like them either, but they are there, and are perfectly valid to

And there are really applications for it:  What about creating a tar
from a large filesystem , encrypt it, put it on tape or CD - Do you
really want to use a temporary file of such a size - only to put the
hash on the front?  I started with GnuPG before I actually knew about
OpenPGP and invented an extension to the v3 format to allow encrypting
and signing of streams.  There are indeed folks who encrypt large
amounts of data and they don't want to waste space for temporary files.
Conclusion: Partial length headers are absolutely needed.

> And why wouldn't a MIC packet work, i.e. why do the 20 bytes have to be
> tacked onto the end of the encryption stream without the virtual EOF and
> one more packet?

And why not define that we put n bytes on the end of the encryption
stream and by some lucky coincident these bytes actually look like a
signature/MDC packet ;-)

Date: Thu, 22 Apr 1999 21:26:56 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Message Integrity
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Date: Thu, 22 Apr 1999 13:47:47 -0400
From: [email-masked]
To: Adam Back <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

Date: Thu, 22 Apr 1999 13:27:10 -0400
From: [email-masked]
To: Adam Back <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

Date: Thu, 22 Apr 1999 12:59:45 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Phil Zimmermann's suggestion - Implementation?
Sender: [email-masked]

On Wed, 21 Apr 1999, Jon Callas wrote:

> Tom, again -- unless the data is of indefinite-length, you *know* how long
> the thing is, and you just subtract 20 from the length you hash. Won't that
> work?

Yes, but the specification says that either packet format is valid and
most current implementations use the indefinite length format for any
potentially unknown length stream (e.g. encrypt stdin).

Ask Hal or someone else how easy it would be to make PGP 6.x do definite
length formats by default.

I simply asked if the 20 bytes of hash could be put at the front instead
of the end (a similar problem since if you have to rewind to put the
length in the fields, you could just move a few bytes forward and put the
hash data at the beginning).

In short, if you have definite length packets, there is probably no
penalty for putting the hash at the beginning. 

> And if indefinite length is a problem, we can always say you can't use
> indefinite length with a MICed packet. I have no especial love for
> indefinite length, and to my mind, it's there to provide TLS-like function,
> which is probably better done with TLS. :-)

I don't like them either, but they are there, and are perfectly valid to
use for any packet and add this given functionality.

If we start to get rid of these, we may as well depricate their use in
future releases.

And why wouldn't a MIC packet work, i.e. why do the 20 bytes have to be
tacked onto the end of the encryption stream without the virtual EOF and
one more packet?

Date: Thu, 22 Apr 1999 18:38:25 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Message Integrity
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Sure.

Date: Thu, 22 Apr 1999 09:31:33 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

> blocksizes?  Increase the IV in the packet to the blocksize or keep

I think for consistency and simplicity we should have all IVs be the
cipher's blocksize.  In the old-style encryption packets this is a
necessity, as I pointed out earlier.  It also simplifies implementation
in that you can just point at the IV in the packet and load it into
the cipher.  With 8 byte IVs I had to move the 8 bytes into a buffer
and zero the other 8 bytes to have a nice 16-byte block of data that I
could pass to the encryption algorithm.

Hal

From: uri <[email-masked]>
Subject: Re: consensus was not against verification packets (Re: Message Integrity)
To: [email-masked] (Adam Back)
Date: Thu, 22 Apr 1999 12:13:15 -0400 (EDT)
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

From: uri <[email-masked]>
Subject: Re: Message Integrity
To: [email-masked] (Werner Koch)
Date: Thu, 22 Apr 1999 12:09:50 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Date: Thu, 22 Apr 1999 09:25:18 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

Adam

Date: Thu, 22 Apr 1999 09:25:51 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: consensus was not against verification packets (Re: Message Integrity)
Sender: [email-masked]

Adam

Date: Thu, 22 Apr 1999 10:13:56 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Message Integrity
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Date: Thu, 22 Apr 1999 09:47:33 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: new approach to MDCs: single shared private key
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Adam Back <[email-masked]> writes:

> 	all we have to do is publish and agree upon a minimal sized
> 	RSA public and private key and publish it.

But not before Sep 20th, 2000.  Or we would have to make it optional.

Date: Wed, 21 Apr 1999 17:41:34 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

Just to clarify, I did not mean to suggest that the hash would be at the
beginning.  I agree that it is better to put it at the end, to facilitate
one pass operation.

What I meant to emphasize was that the hash would be encrypted, along with
the plaintext.  The input to the encryption would look like:

      checkbytes    plaintext    hash

This would all be encrypted to form the ciphertext.  The packet would then
look like:

      IV    ciphertext

Sorry if I was unclear.

Hal

Date: Wed, 21 Apr 1999 20:41:07 -0400
From: Tom Zerucha <[email-masked]>
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

Date: Wed, 21 Apr 1999 17:34:58 -0700
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Phil Zimmermann's suggestion - Implementation?
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Tom, again -- unless the data is of indefinite-length, you *know* how long
the thing is, and you just subtract 20 from the length you hash. Won't that
work?

And if indefinite length is a problem, we can always say you can't use
indefinite length with a MICed packet. I have no especial love for
indefinite length, and to my mind, it's there to provide TLS-like function,
which is probably better done with TLS. :-)

	Jon

Date: Wed, 21 Apr 1999 17:27:58 -0700
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Message Integrity
Sender: [email-masked]

At 5:12 PM -0700 4/21/1999, [email-masked] said:

   I did make a proposal for a format, to wit:

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

   I proposed to put check bytes before the plaintext so that we can tell
   when we have the right decryption key.  This is important in some cases,
   notably following symmetric ESK packets which don't have any internal
   check bytes in them.

   It is important to make it clear that the SHA-1 hash gets encrypted
   along with the plaintext data.  Otherwise it could leak info about
   the plaintext.

Mea culpa. Please forgive me. I obviously was on a mental lunch break.

Okay -- I thought the hash would be at the end, rather than the front, just
for one-passedness. OpenPGP tends to do that, to make it easy to pipeline,
and I would have thought that would mean hash at the end. Either way is
fine with me. Does anyone else have a preference?

   As I said, I didn't particularly have difficulties even in the general
   case, by using an extra buffer.  I don't really like putting restrictions
   on the indefinite length encoding for this case, when we don't have them
   anywhere else.  But if it would really make a difference for other
   implementations, we could consider it.

  If we do it, it should be sufficient to require that the whole hash
   be in one chunk (which will automatically be the last one), not to
   also require an extra byte of data.  This is enough that the decryptor
   will always know when he is looking at data which is part of the hash.
   That data is never broken up, and it is always in the final subpacket,
   which is recognizable in our encoding.  Furthermore, this should not be a
   significant constraint on the encryption end.  I wouldn't expect anyone
   to need to output the hash in more than one packet.  You get the hash
   in one step, and you have all the info you need to put it into a packet.

We do have one, that the first indefinite packet must be at least 512
bytes. But nonetheless, no restrictions are better than some, and if the
hash is at the front, then there's no problem. My suggestion was just to
make it easier for implementors, and if it doesn't, we don't need it.
Merely keeping the hash whole is also just fine with me.

	Jon

Date: Wed, 21 Apr 1999 17:12:21 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Message Integrity
Sender: [email-masked]

> hash runs over the whole of them.

I did make a proposal for a format, to wit:

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

I proposed to put check bytes before the plaintext so that we can tell
when we have the right decryption key.  This is important in some cases,
notably following symmetric ESK packets which don't have any internal
check bytes in them.

It is important to make it clear that the SHA-1 hash gets encrypted
along with the plaintext data.  Otherwise it could leak info about
the plaintext.

> and the 20-byte hash. Does this help any implementation problems? Tom? Hal?

As I said, I didn't particularly have difficulties even in the general
case, by using an extra buffer.  I don't really like putting restrictions
on the indefinite length encoding for this case, when we don't have them
anywhere else.  But if it would really make a difference for other
implementations, we could consider it.

If we do it, it should be sufficient to require that the whole hash
be in one chunk (which will automatically be the last one), not to
also require an extra byte of data.  This is enough that the decryptor
will always know when he is looking at data which is part of the hash.
That data is never broken up, and it is always in the final subpacket,
which is recognizable in our encoding.  Furthermore, this should not be a
significant constraint on the encryption end.  I wouldn't expect anyone
to need to output the hash in more than one packet.  You get the hash
in one step, and you have all the info you need to put it into a packet.

Hal Finney
Network Associates, Inc.

Date: Wed, 21 Apr 1999 19:38:20 -0400
From: [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Phil Zimmermann's suggestion - Implementation?
Sender: [email-masked]

On Wed, 21 Apr 1999 [email-masked] wrote:

> I have experimentally implemented the integrated message integrity
> check within the encryption/decryption layer.  It is not difficult to
> handle the 20-byte trailing hash during decryption.  I use a circular
> buffer in which I put the trailing part of each chunk of decrypted data.
> It always has the last 20 decrypted bytes in it.  The data is passed
> through the hash as we output it from this decryption layer; once we
> hit EOF we take the 20 bytes in the buffer and we know those should be
> matched against the calculated hash.
> 
> I can't speak for other implementations, but I found doing it this way to
> be fairly straightforward.  I don't see implementation difficulty as being
> a barrier to this approach, or a reason to put the integrity checking
> in a pseudo-signature packet.

Implementation difficulty of one thing is not a reason, but I could
probably come up with hundreds of tiny little things to make it better
which would add some value but bloat the code greatly after all were
implemented.  And we should also fix existing implementation/functional
problems such as the lack of a checksum on the new sym-encrypted-sym-key
packets so you have to try each key on the ciphertext. 

You could also create a new packet type, so the EOF would simply signal
that you should look for a(n encrypted) new packet type X with 20 bytes of
contents which is the hash result.

Otherwise, why bother with all this packet nonsense and the CTBs and
whatever in the first place?  You could theoretically not have any of this
and simply search backwards (or include a 2 byte tag) to the beginning of
the first signature packet.

There is a packet infrastructure.  This should be used in one capacity or
another.  I make an exception for header bytes because these are either of
fixed or well defined short lengths.  Tacking things on the end can be
made to work, but it is not a clean way to do things.

We have packets with undefined types which we can add one for this
function.  We also have a predefined packet which is (symmetrically) 
encrypted as part of the existing infrastructure which in normal usage
contains the same data, except in signed form so we call it a signature
packet, but only because it has to this point only contained signatures. 

To repeat: The reason to put integrity checking in a pseudo-signature
packet is because all the necessary code is ALREADY THERE, so instead of
adding a 20 byte delay line you only need a new algorithm ID to identify
this and an IF() test to bypass the signature validation routine.  If
something is already there and easily adapted it is silly to create a new
layer.

Sort of like an old comedy sketch when satellites were first being used
to transmit TV where Mr. Smith was in the kitchen, but they flew him
across the country so he could appear in Mrs. Smith's living room "live
via satellite.  You want to duplicate 70% of the existing signature packet
infrastructure and add a delay line layer because the MDC function is not
a "signature"?  I want to make a 2% change to the existing signature
routines that would accomplish the same function.

How many lines of code did it take for your change?  How much slower?
Remember to add in the hash computation.  And the second hash computation
if there is one if the same packet is going to be signed anyway.

Care to take a stab at adding that function to my opgp and count the lines
as a percentage?

And try my technique and count the impact on the code.  Or find some
reason the function fails to be accomplished by my method.  If you could
argue that it wouldn't work (or work well, or have security problems) I
would say do it your way (except in a unique packet).

> The problem with doing it in a signature packet is that it is a
> fundamentally different function than signatures.  The hash only provides
> integrity in the context of an encryption envelope.  Logically the
> integrity protection is a property of the encryption layer.  Doing the
> hash without encryption provides no integrity protection.  The signature
> packet is functionally the wrong place to put it.

As I pointed out, the "signature packet" can be called something
different, e.g. "verification packet" or "validation packet".  Had I known
that a MDC feature might be added I would have raised a big stink about
using the word "validation" or "verification" instead of "signature" for
the packet type in the RFC "just in case we want to do something other
than full signatures with it".  What is being asked for is merely a proper
subset of what happens to create the existing packets.

It may be a fundamentally different function, but it happens at exactly
the same point in the implmementation and merely omits one step - the
actual crypto function to validate the signature.  And if you are
encrypting, these packets are encrypted along with the message.

Normal messages are just the encrypted literal packet.  Or encryption
applied to a 1-pass validation (was signature) header, the literal packet,
and the validation packet.  You just have your hash over the V4 hashed
material value in addition to the literal packet. 

Your point about requiring encryption is correct, but you can more easily
have implementations reject unencrypted non-signature validation packets
as providing no information, i.e. only worry about the validation if the
whole came from the encryption.

And are you sure that no one is going to want to add the validation or
other information provided by the subpackets?  (e.g. Date info - you could
also add file permissions, length, etc. to the validation packet
infrastructure, but not to a fixed 20 byte MAC).

Date: Wed, 21 Apr 1999 16:24:46 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Message Integrity
Sender: [email-masked]

(3) Rich user IDs.

	Jon

Date: Wed, 21 Apr 1999 15:21:58 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Restricting key sizes to mult of 64 bits
Sender: [email-masked]

As has been noted, DSS requires that the keys be a multiple of 64.
According to M,Vo,&V (section 11.58, p453), DSA requires this too. It says,
"...the size of p can be any multiple of 64 bits between 512 and 1024 bits
inclusive." They are apparently quoting FIPS 186 on this. I know that
Schneier also says something similar.

I think it's tacit that DSA keys need to be multiples of 64 bits. I'm
willing to explicitly say this in the next revision. It is, of course,
polite for an implementation to permit odd-size keys, but an implementation
is permitted to reject this.

I don't see any reason to restrict the key sizes on Elgamal or RSA keys.
And as the owner of a 1723 bit RSA key, I'm against it.

	Jon

Date: Wed, 21 Apr 1999 15:05:31 -0700
To: "James H. Cloos Jr." <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Mixing rsa and dh/dsa
Sender: [email-masked]

At 02:31 PM 4/13/99 -0500, James H. Cloos Jr. wrote:

|Given a recipient with only an RSA keypair (algo 1), and a sender with
|only a DSA/Elgamal pair (algos 17 and 16), should the sender
|encrypt+sign, will any extant software be able to decrypt and verify?
|

If the sender has software that can do RSA, yes. If their software can't do
RSA (for example, suppose they had an NAI/PGP freeware version), then the
sender cannot encrypt to the recipient.

Any OpenPGP-compliant version, though will be able to verify DSA sigs and
encrypt to Elgamal keys.

Does that answer your question? Really your question is an implementation
question, not a standards question.

	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)

Date: Wed, 21 Apr 1999 22:35:10 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: DSS shared private key for MDCs (Re: shared private key for MDCs)
Sender: [email-masked]

And here is a shared private key for DSS MDCs.

I had to modify pgp50i to allow it to generate smaller keys, normally
it won't create DSS keys below 768 bits.  It doesn't appear to be able
to create DSS keys below 512 bits, and I doubt it would verify them or
make sigs with them either as DSS is defined to have key sizes from
512 to 1024 bits.  So the key is a 512 bit key, being the smallest
(for efficiency) valid key.

(I had to resort to emacs for removing the Elgamal encryption subkeys,
there appears no way to remove them separately, nor create DSS keys
without encryption subkeys with unix pgp 50i normally).

Type Bits KeyID      Created    Expires    Algorithm       Use
pub   512 0x0EE50720 1999-04-21 ---------- DSS             Sign only      

Type Bits KeyID      Created    Expires    Algorithm       Use
sec   512 0x0EE50720 1999-04-21 ---------- DSS             Sign only      

-----BEGIN PGP SECRET KEY BLOCK-----
Armor: arm.pl

lQD7BDceN7sRAgDhsbpuoOOFhXYe8WimMwrgH6+V2IecY6mrp8RgfE/grDI3yFc4
Y6TUJirYbsTA/l7vhRBO7yMkg76op/2mF+HDAKD/n1iSgq6e8M0g2++WPUR2UVsl
VwH/QRxvbzpoW4247IL8O4eqtgaDnekJg6G6hmZtcdWVX2NAfMdh3iqIK/AXdNkK
Yq/P3a47Zu99GGQwZ9Fc227NvgH/bxCPd6AIUFk7orBKwYbYNljjQ1ClVEalQVLv
LJTjGwIqSpwqzpvyiz1vFPpQXuhJ6iTX4FvbVqw+JeAbeBXMSQAAn0+t0HGYxE9p
GYtIONiEqv3oJFp+Cvu0GkludGVncml0eSBWZXJpZmljYXRpb24gS2V5
-----END PGP SECRET KEY BLOCK-----

And here is a conventionally encrypted message which has been signed with
the above key.  the conventional encrypt password is "fred" (no quotes).

% echo hello world > test
% pgpe -csa -zfred test -u 0x0EE50720
% cat test.asc
%

and here is what is displayed by unix pgp50i when you decrypt that:

% pgpv -zfred test.asc
Message is encrypted.
Opening file "test" type binary.
Good signature made 1999-04-21 21:24 GMT by key:
   512 bits, Key ID 0EE50720, Created 1999-04-21
   "Integrity Verification Key"

WARNING: The signing key is not trusted to belong to:
Integrity Verification Key
%

Adam

From: [email-masked]
Date: Wed, 21 Apr 1999 12:46:01 -0700
To: Adam Back <[email-masked]>
Subject: Re: new approach to MDCs: single shared private key
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 2:07 PM +0100 1999-04-21, Adam Back wrote:
>[elided]
>- PRZ identified the problem that even with signed messages often the
>public key is not present to verify them, so integrity is not assured.
>With openPGP and pgp(5|6).x where multiple signatures can be applied,
>the document could be signed by both the fixed published RSA key, and
>the user's private RSA key.            [...]

Adam,

The parallel signature extension I've added to the forthcoming
OpenPGP/MIME draft will make this very easy for MIME-compliant
mailers. Thomas Roessler and I are hoping to have the draft ready for
the Oslo IETF in July, and we'll have it up on the list for dsicussion
fairly soon.

    dave

An excerpt:
................................. cut here .................................
8.  Parallel (Multiple) Signatures

    Digitally signed messages conforming to this document are denoted by
    the "multipart/signed" content type, defined in RFC 1847, with a
    "protocol" parameter which MUST have a value of "multipart/mixed".
    (MUST be quoted).

    The "micalg" parameter MUST contain a comma-separated list of hash-
    symbols.  These hash-symbols identify the message integrity check
    (MIC) algorithm(s) used to generate the subsequent signature(s).
    Hash-symbols MUST NOT occur more than once in this list.

    The multipart/signed body MUST consist of exactly two parts.  The
    first part contains the signed data in MIME canonical format,
    including a set of appropriate content headers describing the data.

    The second part MUST be of type "multipart/mixed".  Each sub-part
    represents an individual digital signature which has been formed
    according to RFC 1847 and the specification of the signature protocol
    used.

    Example message:

         From: Dave Del Torto <[email-masked]>
         To: Raph Levien <[email-masked]>
         Mime-Version: 1.0
         Content-Type: multipart/signed; protocol="multipart/mixed";
            boundary=0000_031; micalg="pgp-md5,pgp-sha1,rsa-md5"

         --0000_031
         Content-Type: text/plain

         Hi Raph,

         Here's some text with parallel (multiple) digital signatures
         in various formats.

            dave

         ______________________________________________________________________
         "All email luxuriantly hand-crafted using only the finest ASCII text."

         --0000_031
         Content-Type: multipart/mixed; boundary=0000_032

         --0000_032
         Content-Type: application/pgp-signature

         -----BEGIN PGP SIGNATURE-----
         Version: PGP 2.6.2
         Comment: Hash computed using MD5 micalg.

         iQCVAwUBM0Iu16HBOF9KrwDlAQGaiQP9EU1YXgMSoNxDAqSmo7UoCE52DuYCfxm7
         x8RfRr9+Xz3nPFytSYM2TIWGMeKi1fVr5PhfjdrKvOh9sCq97h6zndZVpGA9x62k
         mPVn/QY3fz1eOdyJbYvW4ba7WQll5OoA6cqmEb9tWwh4ra4yE8hZMnLS9a0uPpuB
         5dpiTTAE/gY=
         =hD3D
         -----END PGP SIGNATURE-----

         --0000_032
         Content-Type: application/pgp-signature

         -----BEGIN PGP SIGNATURE-----
         Version: PGP for Personal Privacy 5.0
         Comment: Hash computed using SHA-1 micalg (FIPS 180-1).

         iQCVAwUBM0It9qHBOF9KrwDlAQFBaQQAisIzQUgyknT2v729b7MImcUc3ROdRBh6
         nwMyAfdewQYCDxqdDWvnD1UWoUjwjA1JNA6qhTXBxs8yPtZdDZaguOG2zWawyat9
         Jib556AuSx10psREDC3vNsaJ99MV8SKFF92H53l9w/YhVOA0aMZeNfLE0jJVypkY
         /so4/7DHhqQ=
         =/wlj
         -----END PGP SIGNATURE-----

         --0000_032
         Content-Type: application/x-pkcs7-signature
         Content-Transfer-Encoding: base64
         Comment: Hash computed using S/MIME MD5 micalg.

         MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEH
          [ciphertext elided]
         +kNIWIbxNiNje1wlzIhaGjrGrOnvYc8+tFn2LgAAAAAAAAAA

         --0000_032--

         --0000_031--

Date: Wed, 21 Apr 1999 15:44:29 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: shared private key for MDCs
Sender: [email-masked]

I thought I'd have a go at testing out the shared private key approach
to implementing an interity check/MDC (MDC=Modification Detection
Code).

pgp263i won't generate keys below 384 bits.  So I compiled one without
that restriction, and it seems that the the smallest key that (normal)
pgp263i will create signatures for and verify signatures for,
empirically is 289 bits.

(This is due to the padding that must fit inside the signature:

> PGP versions 2.3 and later encode the MD into the MPI as follows:
> 
>         MSB               .   .   .                  LSB
> 
>          0   1   FF(n bytes)   0   ASN(18 bytes)   MD(16 bytes)
> 
> See RFC1423 for an explanation of the meaning of the ASN string.
> It is the following 18 byte long hex value:
> 
>         3020300c06082a864886f70d020505000410

which it would seem from the above is 2+0+1+18+16=37 bytes, which is
296.  It seems that the implementation lets you get away with 289,
perhaps because the leading 0 is presumed on odd sized integers.)

So here is a 289 bit private and public key:

Type Bits/KeyID    Date       User ID
sec   289/AADC77C5 1999/04/21 Integrity Verification Key

-----BEGIN PGP SECRET KEY BLOCK-----
Version: 2.6.3i

lQCYAzcd278AAAEBIQGJDbfjBrve0Ips+daIHWQjgKyn5AUR8fxH6ODUATO0f6rc
d8UABREAAR9Q7DxygWLqG+BDnNlYQklSmn1cSDIiDELfP2k2A/ftZzMnITsAkOK8
EHA9EkYOnR//AD2uMfL2vwCRAbvJSkV5XA6mRK2lyGNugHSWewCPRIcJHBV0F/vY
OdbY0L5AgJ3RKqO0GkludGVncml0eSBWZXJpZmljYXRpb24gS2V5
=ZDof
-----END PGP SECRET KEY BLOCK-----

Type Bits/KeyID    Date       User ID
pub   289/AADC77C5 1999/04/21 Integrity Verification Key

Type Bits/KeyID    Date       User ID
pub   289/AADC77C5 1999/04/21 Integrity Verification Key

And here is a conventionally encrypted, uncompressed message which has
been signed with the above key.  the conventional encrypt password is
"fred" (no quotes).

% echo hello world > test
% pgp -csa -zfred test -u 0xAADC77C5
% cat test.asc

and here is what is displayed by pgp263i when you decrypt that:

% pgp -zfred test.asc
File is conventionally encrypted.  Just a moment....Pass phrase appears good. .
File has signature.  Public key is required to check signature.
.
Good signature from user "Integrity Verification Key".
Signature made 1999/04/21 14:35 GMT using 289-bit key, key ID AADC77C5
%

and by pgp50i when you decrypt it:

% pgpv -zfred test.asc
Message is encrypted.
Opening file "test" type binary.
Good signature made 1999-04-21 14:34 GMT by key:
   289 bits, Key ID AADC77C5, Created 1999-04-21
   "Integrity Verification Key"

WARNING: The signing key is not trusted to belong to:
Integrity Verification Key
%

I removed the self signature from the key because it seems pointless
to self sign a key which has a published private key.

Interestingly pgp263i seems to consider this key trusted due to the
presence of the private key on the private key ring, whereas pgp50i
considers it to have "undefined trust".

Adam

Date: Wed, 21 Apr 1999 14:07:54 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: new approach to MDCs: single shared private key
Sender: [email-masked]

Whilst looking at RFC2440 with a view to defining suitable algorithm
ids and minimal backwards compatible changes to try out the
verification packet approach, in response to Werner Koch's posts, an
insight struck me:

	all we have to do is publish and agree upon a minimal sized
	RSA public and private key and publish it.

This allows us to provide:

- the best backwards compatibility of all (allows even pgp23a to
*check* MDCs, which is even better than just "not choking" on them).

- the lowest implementation overhead of all (ie none!)

This approach:

- prevents Gary Howland's encrypted message modification attack
because the signature with known public and private key performs the
same function as a hash inside the encryption envelope.

- it doesn't provide non-repudiation because the private key is shared
(which is the whole point, we don't want non-repudiation in this
scenario, and some people have good reasons for not wanting it).

- any pgp2.3a and forward implementation can "implement" these MDCs
merely by adding this public and private key pair to their key ring.

- PRZ identified the problem that even with signed messages often the
public key is not present to verify them, so integrity is not assured.
With openPGP and pgp(5|6).x where multiple signatures can be applied,
the document could be signed by both the fixed published RSA key, and
the user's private RSA key.

- The same approach of a published public and private DSA key can be
used to do the same thing with DSA for implementations temporarily
avoiding RSA until the patent expires.

- The only extra overhead is the signature creation and verification.
The key size does not affect security, so using a small a key as
possible does not adversely affect security.  A 384 bit key, or
perhaps even 256 bit key would be perfectly adequate.  (The limit will
be imposed by the size of RSA block required to hold the minimum sized
padded document hash.)  The minimum key size that the already deployed
DSA and RSA signature verification code would consider a valid
signature

- The keyid on the keys can be set to the string "Integrity
Verification Key" to help ensure that implementations present
representative messages.

- These public and private keys can be distributed with new
implementations, and distrubted widely on the internet.

Comments?  I think it is a neat, and exciting trick which allows even
pgp2.3a to overcome the message modification problem with no
implementation work.

The only advantages of defining a different MDC packet (which is what
I was in the process of doing when this occured to me) is to avoid
this small computational and space overhead.

Defining an elegant, space and computationally efficiient
implementation at our leisure can be done once the standard RSA and
DSA private and public keys are agreed upon, as an optimally backwards
compatible approach can be used for old implementations.

Adam

Date: Tue, 20 Apr 1999 22:48:34 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Phil Zimmermann's suggestion - Implementation?
Sender: [email-masked]

I have experimentally implemented the integrated message integrity
check within the encryption/decryption layer.  It is not difficult to
handle the 20-byte trailing hash during decryption.  I use a circular
buffer in which I put the trailing part of each chunk of decrypted data.
It always has the last 20 decrypted bytes in it.  The data is passed
through the hash as we output it from this decryption layer; once we
hit EOF we take the 20 bytes in the buffer and we know those should be
matched against the calculated hash.

I can't speak for other implementations, but I found doing it this way to
be fairly straightforward.  I don't see implementation difficulty as being
a barrier to this approach, or a reason to put the integrity checking
in a pseudo-signature packet.

The problem with doing it in a signature packet is that it is a
fundamentally different function than signatures.  The hash only provides
integrity in the context of an encryption envelope.  Logically the
integrity protection is a property of the encryption layer.  Doing the
hash without encryption provides no integrity protection.  The signature
packet is functionally the wrong place to put it.

Hal Finney
NAI, Inc.

Date: Tue, 20 Apr 1999 18:18:08 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: MDC packet
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

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

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

Date: Fri, 16 Apr 1999 18:24:29 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Restricting key sizes to mult of 64 bits
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Michael Marking <[email-masked]> writes:

> >I can agree on a multiple of 8 bits but I don't the 
> >an advantage to use any other value.
> 
> Why?

Because it is the natural unit of measure on most computers.

> For a given maximum key size, this restriction cuts
> the available key space in half, approximately. What
> effect does it have on the difficulty of an attack?

I didn't mean that we need a restriction at all.   

Date: Fri, 16 Apr 1999 07:10:30 -0700
To: Werner Koch <[email-masked]>
From: Michael Marking <[email-masked]>
Subject: Re: Restricting key sizes to mult of 64 bits
Cc: [email-masked]
Sender: [email-masked]

At 10:09 PM 99/04/14 +0200, you wrote:
>[email-masked] writes:
>
>> At the same time, we are considering requiring that 
>> newly generated keys of the other types, ElGamal 
>> and RSA, also be multiple of 64 bits (note
>
>I can agree on a multiple of 8 bits but I don't the 
>an advantage to use any other value.

Why?

For a given maximum key size, this restriction cuts
the available key space in half, approximately. What
effect does it have on the difficulty of an attack?

>> to do the RSA calculations.  As it turned out, CAPI 
>> had a bug which prevented it from working properly 
>> with unusual key sizes.  Those users weren't able 
>> to use their keys with the CAPI version.
>
>Working around bugs in one companies new product is a 
>Bad Thing to do. 

Discovered errors are an indicator that additional, 
latent errors are likely to exist. The fringe cases 
are often the ones which encounter the errors. If we 
do not permit "odd" key sizes, or other inconvenient 
usage, then we may allow sloppy practices which 
ultimately might jeopardize the security of the user.

>There are many other issues we could fix for them by 
>changing the standards ;-). 

>Adding workarounds for some products which are around 
>for a long time is a different thing.

Yes. A warning to the user, or a documented
configuration option, is a much better solution.

Date: Wed, 14 Apr 1999 22:09:47 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Restricting key sizes to mult of 64 bits
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> At the same time, we are considering requiring that newly generated keys
> of the other types, ElGamal and RSA, also be multiple of 64 bits (note

I can agree on a multiple of 8 bits but I don't the an advantage to 
use any other value.

> to do the RSA calculations.  As it turned out, CAPI had a bug which
> prevented it from working properly with unusual key sizes.  Those users
> weren't able to use their keys with the CAPI version.

Working around bugs in one companies new product is a Bad Thing to do.
There are many other issues we could fix for them by changing the
standards ;-).  Adding workarounds for some products which are around
for a long time is a different thing.

Just my 0.02 Euros

Date: Wed, 14 Apr 1999 19:43:42 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: MDC packet (was: Phil Zimmermann's suggestion - Implementation?)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Tom Zerucha <[email-masked]> writes:

> 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

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.

Date: Wed, 14 Apr 1999 11:03:30 -0700
From: [email-masked]
To: [email-masked]
Subject: Restricting key sizes to mult of 64 bits
Sender: [email-masked]

The DSS spec requires that DSS keys be a multiple of 64 bits in size.
PGP has not enforced this limitation in the past, but we are adding that
now.

At the same time, we are considering requiring that newly generated keys
of the other types, ElGamal and RSA, also be multiple of 64 bits (note
that this is only enforced on keygen).  The rationale is that keys of
"oddball" sizes may not be properly supported by all implementations.
We want users' keys to be able to be used in a wide range of present and
future implementations, possibly including non-PGP environments like
smartcard systems and X.509 or SPKI.  By making the key sizes a nice,
round number, we improve the chances of them functioning properly in
these other environments.

Some users have already encountered a problem with oddly sized keys.
We shipped software which used Microsoft's built-in Crypto API (CAPI)
to do the RSA calculations.  As it turned out, CAPI had a bug which
prevented it from working properly with unusual key sizes.  Those users
weren't able to use their keys with the CAPI version.

We would like to reduce the chance of running into similar problems in
the future, and keeping keys to round sizes should help.  The choice of 64
bits as the multiple is based on trading off the desire for plenty of key
sizes versus minimizing the chance of an unsupported key size.  The fact
that DSS uses 64 bit multiples suggests that this is a reasonable value.

However, there is some concern that the user and developer community
may be opposed to losing this flexibility in their key size choices.
I was hoping to get some feedback here about whether this change seems
reasonable.  OpenPGP participants have provided valuable feedback in the
past regarding design decisions made by NAI, often after the fact.  This
time it would be helpful to find out beforehand if there will be opposition
to restricting newly generated keys in this way.

Thanks for your comments,

Hal Finney
NAI, Inc.

Date: Tue, 13 Apr 1999 23:43:39 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: MDC symmetric sig type vs new bundled encrypt+MDC (Re: Phil Zimmermann's suggestion for large ciphers)
Sender: [email-masked]

Uri writes:
> > 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.
> 
> 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.

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.

> > 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).
> 
> A good enough reason for me to vote down the support for MDC in
> "old" ciphers.

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.

> > I argue that these benefits make it worth favoring the new signature
> > type over appended hash approach.
> 
> 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

Date: Tue, 13 Apr 1999 23:51:26 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Phil Zimmermann's suggestion - Implementation?
Sender: [email-masked]

Tom Zerucha writes:
> Uri writes:
> 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.

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.

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

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

Adam

From: uri <[email-masked]>
Subject: Re: Phil Zimmermann's suggestion - Implementation?
To: [email-masked] (Tom Zerucha)
Date: Tue, 13 Apr 1999 18:51:44 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Tom Zerucha says:
> > 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...

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

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

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.

> > Nope! The problem with this is - you'll *have* to run through the file
> > 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.

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

> Lets see what the other implementors have to say. 

Sure.

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

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

Date: Tue, 13 Apr 1999 17:49:01 -0400
From: Tom Zerucha <[email-masked]>
To: [email-masked]
Subject: Re: Phil Zimmermann's suggestion - Implementation?
Sender: [email-masked]

On Tue, 13 Apr 1999, Werner Koch wrote:

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

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)

> I think it is bad style to change a standard which already defines how
> 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.

Date: Tue, 13 Apr 1999 17:41:03 -0400
From: Tom Zerucha <[email-masked]>
To: "James H. Cloos Jr." <[email-masked]>
cc: [email-masked]
Subject: Re: Mixing rsa and dh/dsa
Sender: [email-masked]

On Tue, 13 Apr 1999, James H. Cloos Jr. wrote:

> Given a recipient with only an RSA keypair (algo 1), and a sender with
> only a DSA/Elgamal pair (algos 17 and 16), should the sender
> encrypt+sign, will any extant software be able to decrypt and verify?

Yes.  The encryption is done using the RSA algorithm, but the signing is
done using DSA.  The recipient can decrypt using his RSA key and verify
from the DSA from a keyserver or keyring.

The encryption algorithm is separate and thus can be different from any
signature algorithm.

My test suite generates every possible combination, so I know it is
possible for this to work.  Whether any particular implementation handles
this depends on that implmementaiton, but there should not be any problems
if they simply did things in an obvious manner.

Date: Tue, 13 Apr 1999 17:36:25 -0400
From: Tom Zerucha <[email-masked]>
To: [email-masked]
Subject: Re: Phil Zimmermann's suggestion - Implementation?
Sender: [email-masked]

On Tue, 13 Apr 1999, uri wrote:

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

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

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.

> > 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.
> 
> Nope! The problem with this is - you'll *have* to run through the file
> 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.

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

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.

> > 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.
> 
> 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: uri <[email-masked]>
Subject: Re: Phil Zimmermann's suggestion - Implementation?
To: [email-masked] (Tom Zerucha)
Date: Tue, 13 Apr 1999 16:23:44 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Tom Zerucha says:
> > 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?
> 
> 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
> 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.

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

> > > And to ask a question, how do I know where the MAC 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?

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

> Saying something is 5 miles east of Kunkle doesn't help if you don't know
> 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
> 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.

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.

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

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.

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

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

> > 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.
> 
> Then why not drop PGP entirely? 

This you can figure out yourself (:-)

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

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

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

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

But it's NOT a signature!

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

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

Date: Tue, 13 Apr 1999 22:02:18 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Phil Zimmermann's suggestion - Implementation?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

uri <[email-masked]> writes:

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

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.

> 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

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

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

Date: Tue, 13 Apr 1999 15:47:38 -0400
From: Tom Zerucha <[email-masked]>
To: [email-masked]
Subject: Re: Phil Zimmermann's suggestion - Implementation?
Sender: [email-masked]

On Tue, 13 Apr 1999, uri wrote:

> > 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?
> 
> I don't know - does it really matter how to define "this" new way
> of processing?

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.

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

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.

> > And to ask a question, how do I know where the MAC 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.

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

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.

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

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.

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

> > Since you can have multiple signature packets, adding the symmetric MAC
> > "non-signature" adds this function without the layer.
> 
> 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.

To: [email-masked]
Subject: Mixing rsa and dh/dsa
From: "James H. Cloos Jr." <[email-masked]>
Date: 13 Apr 1999 14:31:12 -0500
Lines: 21
Sender: [email-masked]

Given a recipient with only an RSA keypair (algo 1), and a sender with
only a DSA/Elgamal pair (algos 17 and 16), should the sender
encrypt+sign, will any extant software be able to decrypt and verify?

- -JimC
- -- 
James H. Cloos, Jr.  <http://www.jhcloos.com/cloos/public_key> 1024D/ED7DAEA6 
<[email-masked]>     E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6

From: uri <[email-masked]>
Subject: Re: Phil Zimmermann's suggestion - Implementation?
To: [email-masked] (Tom Zerucha)
Date: Tue, 13 Apr 1999 14:05:38 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Tom Zerucha says:
> The new model becomes (please correct ommissions)
> 
> Plaintext -> MAC append -> IV/CFB xor -> Ciphertext
>                                ^
>                                |
>                    Secret -> Cipher

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

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

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

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

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

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

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.

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

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

> Doing a MAC within the encryption packet now adds a layer on the inside,
> 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.

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

(:-)

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

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

Date: Tue, 13 Apr 1999 13:13:31 -0400
From: Tom Zerucha <[email-masked]>
To: [email-masked]
Subject: Re: Phil Zimmermann's suggestion - Implementation?
Sender: [email-masked]

On Mon, 12 Apr 1999 [email-masked] wrote:

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

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

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)

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

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?

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

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

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

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.

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

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

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

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

Date: Tue, 13 Apr 1999 11:21:07 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Phil Zimmermann's suggestion for large ciphers
Sender: [email-masked]

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

Date: Tue, 13 Apr 1999 09:54:52 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Packet 5,7 and blocksizes
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Just a reminder that we have to change the specs to increase the
size of the IV in the secrek key material encryption from 8 bytes to
the blocksize.

And I still like to have a length of the IV in the packet (okay, for
the next version of the packet) becuase it makes parsing more easier.
Now I have to use a table of blocksizes for each cipher to do correct
parsing of the data; adding one byte for this should not be a problem.

Date: Tue, 13 Apr 1999 09:41:51 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Phil Zimmermann's suggestion for large ciphers
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

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

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

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
> compatible, anyway.

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

> 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

Right.

> 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

"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).

Date: Tue, 13 Apr 1999 09:48:14 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Phil Zimmermann's suggestion for large ciphers
Mail-Followup-To: [email-masked]
Sender: [email-masked]

uri <[email-masked]> writes:

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

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.
> Who cares?

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. 

Date: 13 Apr 1999 02:38:13 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Phil Zimmermann's suggestion for large ciphers
Sender: [email-masked]

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

I have an unconditionally secure MAC that's much faster than SHA-1---in
fact, even faster than MD5. The alpha implementation is available from

   http://pobox.com/~djb/hash127.html

Please send any comments or questions to the hash127 mailing list. To
subscribe, send an empty message to [email-masked].

> many people don't like to sign their messages for legal reasons,

Why? Because signatures can't be repudiated?

One easy solution, under the original Diffie-Hellman system, is to use a
MAC as above, where the MAC key is generated from the Diffie-Hellman
shared secret. The receiver can generate new MACs under the same key, so
he can't prove to a judge that a message came from you.

(There are similar solutions using RSA, but Diffie-Hellman is faster.)

---Dan

From: uri <[email-masked]>
Subject: Re: Phil Zimmermann's suggestion for large ciphers
To: [email-masked] (Adam Back)
Date: Mon, 12 Apr 1999 20:06:09 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Adam Back says:
> 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.

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.

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

We agree here.

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

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

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

No MAC - as MAC will require yet another key.

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

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

Date: Tue, 13 Apr 1999 00:41:53 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: Re: Phil Zimmermann's suggestion for large ciphers
Sender: [email-masked]

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:

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

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]>
Subject: Re: Phil Zimmermann's suggestion for large ciphers
To: [email-masked]
Date: Mon, 12 Apr 1999 19:21:13 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

[email-masked] says:
> 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.
> ...................... 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.

Good. About time.

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

Kill it.

>  - The non-standard treatment of IV

Later.

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

Fix it.

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

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

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

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.

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

Good enough.

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

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

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

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.

> Another issue is whether to use a fixed hash like SHA-1 rather than
> 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
> case of cryptographic signatures, and a fixed hash like SHA-1 should
> be suitable.

It is.

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

Nah, IMNSHO isn't worth it.

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

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

> The signature provides integrity protection as
> well as authentication, and so it is wasteful to also provide integrity
> protection as part of the encryption.

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

Date: Mon, 12 Apr 1999 16:07:09 -0700
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Phil Zimmermann's suggestion for large ciphers
Sender: [email-masked]

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)

Date: Mon, 12 Apr 1999 14:59:59 -0700
From: [email-masked]
To: [email-masked]
Subject: Phil Zimmermann's suggestion for large ciphers
Sender: [email-masked]

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.

Date: Mon, 12 Apr 99 20:32 +0200
From: [email-masked] (Ulf =?iso-8859-1?Q?M=F6ller?=)
To: [email-masked]
Subject: Re: Decrypting ElGamal messages
Newsgroups: ulf.open-pgp
Organization: HR13
Cc: [email-masked]
Sender: [email-masked]

>> Upon decryption, the recipient needs to check the PKCS-1 formatting,
>> the checksum, and that the symmetric algorithm byte is one of the
>> supported algorithms.  It then tries to decrypt the following message
>> block using that algorithm and session key, which block also has in
>> it a two-byte redundancy at the beginning to further detect bad keys.
>
>Thanks a lot for the information. Would have missed the checksum
>in the bulk data otherwise.

I don't think you can count it in.  While the semantics of a (Session
Key Packet, Literal Packet) message is not defined in the RFC, a naïve
implementor may very well try to be "generous in what they accept", as
is suggested elsewhere in the document.

PGP 5 does not accept such messages, but prints an "assertion failed"
message only if the PKCS #1 padding and the Session Key Packet
checksum are correct.

Date: Fri, 9 Apr 1999 15:45:02 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Sample Twofish message
Sender: [email-masked]

Werner Koch, <[email-masked]>, writes:
> [email-masked] writes:
>
> > I believe Uri was referring to the passphrase-protected secret key
> > data, which does use an IV in the conventional sense.
>
> Hmmm, from the pgp 2.6.3 documentation about secret key certificates:
>
> |  and the checksum is used to tell if the password was good.  The CFB
> |  IV field is just encrypted random data, assuming the "true" IV was
> |  zero.
>
> This is what is done in GnuPG too and I have checked interoperability
> against pgp 5.0beta.

This is actually pretty funny.  We're both interpreting it differently,
but we interoperate.

By my interpretation, the first 8 bytes are an IV.  We encrypt those
with the key, and XOR into the next 8 bytes to get the first 8 bytes
of plaintext.

With your interpretation, the IV is zero.  You encrypt that with the
key and XOR into the first 8 bytes to get 8 random bytes, which you
discard.  You then take the first block of ciphertext, whiich is the
first 8 bytes of data, encrypt it with the key, and XOR into the next
8 bytes to get the first 8 bytes of plaintext.

The result is exactly the same.  That's why it interoperates.  With
CFB mode, each ciphertext block acts like an "IV" for the next block.

The situation is different for encrypted data blocks, because there we
have the extra two bytes of check data which must be compared against the
decrypted form of the first 8 bytes.  So we must use the convention of
a zero IV to successfully decrypt that.  But with the encrypted secret
keys there are no check bytes and the two descriptions are equivalent
(as long as the IV size == the block size).

Sorry I have not yet sent out Phil's proposal, I've been having
connectivity problems today.

Hal Finney

Date: Fri, 9 Apr 1999 16:30:12 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Sample Twofish message
Sender: [email-masked]

>>>>> "Uri" == Uri Blumenthal <[email-masked]> writes:

 Uri> [email-masked] says:
 >> > IV length normally is equal to the block size. I see no reason
 >> to > divert from this.
 >> 
 >> With regard to the secret key encryption: The only real
 >> requirement on an IV is that it is unique for that key, that it
 >> does not match any other IV's and it doesn't match any of the
 >> ciphertext blocks which are used with that key.  For this purpose,
 >> 64 bits should be adequate unless we store more than 4 billion
 >> (2^32) private keys using the same passphrase (and even then the
 >> unique salt would save us).  So a 64 bit IV is plenty big.

 Uri> True. But:

 >> However in the interests of convenience and consistency it would
 >> probably make more sense to use the block size.  This avoids any
 >> ambiguities about whether a shorter IV should be left or right
 >> justified and how the remaining bits of the block should be filled
 >> in.

 Uri> Exactly!

I'm very hard pressed to see ANY valid argument for making an IV
smaller than the blocksize.  Even if it technically possible (which I
guess it is with CFB mode) it should not be done.  There is no benefit 
I can see, and a very clear issue: if you have a cypher with 128 bit
blocks, 128 bit strength, etc., what conceivable cryptographic merit
is there in introducing a 64 bit component into the puzzle?  Why go
through the process of analyzing the security implications and
demonstrating that there aren't any when there is no benefit to be
had?  Or of there is one, certainly not one that justifies months of
analysis? 

My impression from watching AES discussions is that weaknesses that
open up O(2^64) attacks of any kind are considered things to be
concerned about.  Not being an academically trained cryptographer I
may be reading too much into the discussion, but even so, that seems
like a logical position to take.

	paul

Date: Fri, 9 Apr 1999 20:30:24 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Sample Twofish message
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> block size.  Can we consider keeping the language to use the extra
> sync only for 64 bit block ciphers?

Yes.

Date: Fri, 9 Apr 1999 20:28:33 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Sample Twofish message
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> I believe Uri was referring to the passphrase-protected secret key
> data, which does use an IV in the conventional sense.

Hmmm, from the pgp 2.6.3 documentation about secret key certificates:

|  and the checksum is used to tell if the password was good.  The CFB
|  IV field is just encrypted random data, assuming the "true" IV was
|  zero.

This is what is done in GnuPG too and I have checked interoperability
against pgp 5.0beta.

> the rest of the packet anyway, so there is no need to parse it.  You do
> have information about the overall packet size from the packet headers,
> so you can just skip past the encrypted data.

Sure, it adds extra complexity to the already complex issue with 
S2K and pgp2 mode - but no problem ;-)

> approach for this problem.  I will post a summary later this morning.

This means late evening in Europe :-(

From: Uri Blumenthal <[email-masked]>
Subject: Re: Sample Twofish message
To: [email-masked]
Date: Fri, 9 Apr 1999 14:29:12 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

[email-masked] says:
> > IV length normally is equal to the block size. I see no reason to
> > divert from this.
> 
> With regard to the secret key encryption:
> The only real requirement on an IV is that it is unique for that key,
> that it does not match any other IV's and it doesn't match any of the
> ciphertext blocks which are used with that key.  For this purpose,
> 64 bits should be adequate unless we store more than 4 billion (2^32)
> private keys using the same passphrase (and even then the unique salt
> would save us).  So a 64 bit IV is plenty big.

True. But:

> However in the interests of convenience and consistency it would probably
> make more sense to use the block size.  This avoids any ambiguities
> about whether a shorter IV should be left or right justified and how
> the remaining bits of the block should be filled in.

Exactly!

> With regard to message encryption, the symmetrically encrypted data
> packets:
> 
> The 8+2 bytes which precede the message are not technically an IV; the
> IV is zero, and the 8+2 bytes are used in place of an IV to accomplish
> the same purpose. However this size does not work properly in the case
> of 128 bit blocks.

In essence those 8+2 bytes *are* performing the function of IV. 

> [...description of a problem....] This is a serious leak.

Probably. (:-)

> .........But still there is no reason to take this chance.
> Therefore we should increase the 8 bytes to be the size of the block
> cipher.

(:-) My wish precisely!

> It is not difficult to code the CFB sync to be optional based on
> block size.  Can we consider keeping the language to use the extra
> sync only for 64 bit block ciphers?

Probably. No strong preference either way.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Fri, 9 Apr 1999 10:02:52 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Sample Twofish message
Sender: [email-masked]

Werner Koch, <[email-masked]>, writes:
> Uri Blumenthal <[email-masked]> writes:
> > IV length normally is equal to the block size. I see no reason to
> > divert from this.
>
> Actually it is not the IV (which is always zero) but the random bytes 
> prepended to the plaintext.  However I think you are right and we
> should agree to use an IV of the blocksize instead of 8.  The problem
> with this is that an application needs to know the blocksize of all
> possible algorithms to parse the packet - maybe it is better to change
> it only if we specify a new version number of the packet, Hmmm...

I believe Uri was referring to the passphrase-protected secret key
data, which does use an IV in the conventional sense.

As far as the need to know the block size, this would only be a problem
if you faced an unknown cipher ID.  But in that case you can't decrypt
the rest of the packet anyway, so there is no need to parse it.  You do
have information about the overall packet size from the packet headers,
so you can just skip past the encrypted data.

I just spoke on the phone with Phil Zimmermann, who suggested a different
approach for this problem.  I will post a summary later this morning.

Hal

Date: Fri, 9 Apr 1999 12:56:43 -0400 (EDT)
From: Daniel Bleichenbacher <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Decrypting ElGamal messages
Sender: [email-masked]

Hal Finney <[email-masked]>, writes: 
> Daniel Bleichenbacher, <[email-masked]>, writes:
> > Can anyone tell me how an ElGamal encrypted message has to be 
> > decrypted? The open-pgp documentation doesn't give the answer.
> > I'm specially interested in how padding and checksums are handled.
> 
> With both RSA and ElGamal messages, the session key is prepended with a
> byte identifying the symmetric algorithm used to encrypt the bulk message
> data (typically one of three or four supported symmetric algorithm
> values can go here).  It is then appended with a two-byte checksum.
> The resulting string is PKCS-1 padded and encrypted.
> 
> Upon decryption, the recipient needs to check the PKCS-1 formatting,
> the checksum, and that the symmetric algorithm byte is one of the
> supported algorithms.  It then tries to decrypt the following message
> block using that algorithm and session key, which block also has in
> it a two-byte redundancy at the beginning to further detect bad keys.

Thanks a lot for the information. Would have missed the checksum
in the bulk data otherwise.

> > I'm asking this question, because ElGamal encryption has the
> > same multiplicative properties as RSA. In particular, given
> > the encryption of a message M (including padding), it is easy
> > to generate the encryption of M*S (mod p) for a given S, without
> > knowing M. Hence the same attack that was possible against SSL
> > potentially works against ElGamal, when used with PKCS #1 v1.5 
> > padding.
> 
> It would be good to mention this attack in a future version of the draft.
> It is important not to leak information about which step in the decryption
> process fails.
> 
> Then, in order to fake a successful encrypted session key, it must not
> only be properly PKCS-1 padded, it must also have a correct two-byte
> checksum (adding 16 bits of difficulty), it must have a legal symmetric
> algorithm byte (adding about 6 bits of difficulty), and it must pass the
> checksum test when the payload data is decrypted (adding another 16 bits).
> This would make the attack in total about 2^38 times harder than against
> a bare PKCS-1 leaking decryptor, which should be a significant barrier
> in most practical situations.

I'm not sure about this "2^38 times harder...", but estimating 
this number is exactly the goal of the whole exercise.
Are there any publications considering the security of the openpgp
message format against chosen ciphertext attacks?
As Peter Gutmann pointed out, a chosen ciphertext attacks would be
almost impossible against plain PGP. The openpgp standard should 
however be useful for any application using the same message format,
and client-server applications should not be prevented. 

> > BTW, is there any reason why PKCS #1 v1.5 padding is used and
> > not PKCS #1 v2?
> 
> Although the RFC came out recently, it documents existing practice which
> was developed in 1996.  At that time version 1.5 of PKCS 1 was extant.
> 
> Hal Finney
> NAI, Inc.

Daniel Bleichenbacher

Date: Fri, 9 Apr 1999 09:24:19 -0700
From: [email-masked]
To: [email-masked]
Subject: Re: Sample Twofish message
Cc: [email-masked]
Sender: [email-masked]

Uri Blumenthal, <[email-masked]>, writes:

> Werner Koch says:
> > We use a 8 byte IV for encrypting the secret key material; see
> > section 5.5.3.  Do we keep this 8 bytes or extend it to the blocksize?
>
> IV length normally is equal to the block size. I see no reason to
> divert from this.

With regard to the secret key encryption:

The only real requirement on an IV is that it is unique for that key,
that it does not match any other IV's and it doesn't match any of the
ciphertext blocks which are used with that key.  For this purpose,
64 bits should be adequate unless we store more than 4 billion (2^32)
private keys using the same passphrase (and even then the unique salt
would save us).  So a 64 bit IV is plenty big.

However in the interests of convenience and consistency it would probably
make more sense to use the block size.  This avoids any ambiguities
about whether a shorter IV should be left or right justified and how
the remaining bits of the block should be filled in.

With regard to message encryption, the symmetrically encrypted data
packets:

The 8+2 bytes which precede the message are not technically an IV; the
IV is zero, and the 8+2 bytes are used in place of an IV to accomplish
the same purpose.  However this size does not work properly in the case
of 128 bit blocks.

If we had two messages encrypted with the same key, then for each of
them we would encrypt a block of zeros and XOR that with the first 16
bytes of the message, to form the ciphertext.  Only the first 10 bytes
are random; the remaining 6 are plaintext.  Therefore the last 6 bytes
of this first block of data would be the first 6 bytes of plaintext,
xored with a value which was the same for each encryption where that
same key was used.  This would allow an attacker to recover the XOR of
the first 6 bytes of the plaintexts of multiple messages, and possibly
therefore to find these 6 bytes of plaintext.

This is a serious leak.  We would possibly be saved by the fact that
the spec says to use salt in hashing the passphrase, so it is unlikely
that any two messages are encrypted with the same key even if the same
passphrase is used.  But still there is no reason to take this chance.

Therefore we should increase the 8 bytes to be the size of the block
cipher.

Several people have commented that they don't like the extra CFB sync
operation which is done after the first 8+2 (or now 16+2) bytes are read.
It is a nonstandard operation and requires special code in the CFB module.
I had suggested that we skip the CFB for larger blocks, on the theory
that we would eventually migrate to larger block ciphers throughout,
and then we could retire the CFB sync along with the support of 64 bit
block ciphers.  This would be perhaps four or five years from now.

It is not difficult to code the CFB sync to be optional based on
block size.  Can we consider keeping the language to use the extra
sync only for 64 bit block ciphers?

Hal Finney
NAI, Inc.

Date: Fri, 9 Apr 1999 18:11:21 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Sample Twofish message
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Uri Blumenthal <[email-masked]> writes:

> IV length normally is equal to the block size. I see no reason to
> divert from this.

Actually it is not the IV (which is always zero) but the random bytes 
prepended to the plaintext.  However I think you are right and we
should agree to use an IV of the blocksize instead of 8.  The problem
with this is that an application needs to know the blocksize of all
possible algorithms to parse the packet - maybe it is better to change
it only if we specify a new version number of the packet, Hmmm...

From: Uri Blumenthal <[email-masked]>
Subject: Re: Sample Twofish message
To: [email-masked] (Werner Koch)
Date: Fri, 9 Apr 1999 11:44:12 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Werner Koch says:
> We use a 8 byte IV for encrypting the secret key material; see
> section 5.5.3.  Do we keep this 8 bytes or extend it to the blocksize?

IV length normally is equal to the block size. I see no reason to
divert from this.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Fri, 9 Apr 1999 13:21:35 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: New sample message
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

Here is a new sample message for 256 bit block ciphers.  Can anyone
please check it?

Note, that the message is preceded by 16 random bytes, then two more
bytes which are copies of the last two of the random ones. A CFB sync
is done after encrypting these 18 bytes.

The message is encrypted using the one-letter passphrase "x". 

The structure of this message is:

:symkey enc packet: version 4, cipher 10, s2k 3, hash 2
        salt 4f094cb39da872d8, count 96
:encrypted data packet:
        length: 49
:literal data packet:
        mode b, created 923655302, name="tf2",
        raw data: 20 bytes

The 256 bit key is:

  D5 13 A1 FA 34 9C 99 71 55 EC 8A 48 76 F8 BD 2E A1 24 D8 78 75
  0C 86 04 49 DF 3E 6F 85 56 25 D5

The begin of the plaintext messsage is:

  81 3D D9 FE 58 35 62 7A 1E 0D 1C 6F 4D 10 04 4C 04 4C

Date: Fri, 9 Apr 1999 11:33:21 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Sample Twofish message
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> Do we agree now that the right thing to do is to start with a 16-byte IV,
> encrypt 16 bytes, sync with 2 and then continue? That's what I thought we

ACK.

> all agreed on. If we agree that, then we don't have a problem, we have an
> elided description that needs to be expanded when we revise the RFC. I
> believe, though, that that's the right thing to do, work with full blocksizes.

We use a 8 byte IV for encrypting the secret key material; see
section 5.5.3.  Do we keep this 8 bytes or extend it to the blocksize?

From: Uri Blumenthal <[email-masked]>
Subject: Re: Sample Twofish message
To: [email-masked] (Werner Koch)
Date: Thu, 8 Apr 1999 21:17:36 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Werner Koch says:
> Okay, how can we resolve this conflict:
> >From section 5.7:
>    The data is encrypted in CFB mode, with a CFB shift size equal to the
>    cipher's block size.  The Initial Vector (IV) is specified as all
>    zeros.  Instead of using an IV, OpenPGP prefixes a 10-octet string to
>    the data before it is encrypted.  The first eight octets are random,
>    and the 9th and 10th octets are copies of the 7th and 8th octets,
>    respectively. After encrypting the first 10 octets, the CFB state is
>    resynchronized if the cipher block size is 8 octets or less.  The
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    last 8 octets of ciphertext are passed through the cipher and the
>    block boundary is reset.

1. For 128-bit block ciphers shouldn't the prefix be increased to,
   say, 18 bytes?

2. Shouldn't all procedures be adjusted to 16 octets for such ciphers?

> >From section 12.8:.........
> 
> 5.7 says that resync is only done for a blocksize <= 64 but 12.8 says
> that is done always (the following step by step list also says this).

I'd abandon (or fix :-) 12.8.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Decrypting ElGamal messages
Reply-To: [email-masked]
Date: Fri, 9 Apr 1999 13:10:55 (NZST)
Sender: [email-masked]

>>1. The implementor has managed to design a protocol which will accept
>>   arbitrary numbers of chosen-ciphertext messages and reply to each one with
>>   an exact indication of how the decrypt failed, leaking information about
>>   the decrypted message to an attacker.  This is a fairly remarkable feat,
>>   but let's say, just for arguments sake, that someone did do this.
 
>I'm not sure how remarkable this would be. Quite a large number of SSL servers
>actually returned the necessary error messages for an attack there. I think
>one shouldn't leave the chance here that the implementor makes mistakes and
>add some quidelines to the standard.
 
That's what I'd proposed earlier on in the same thread.  In addition you have
to remember that S/MIME and PGP are very different beasties from SSL, unless
you go out of your way to design a protocol which returns decryption results
you'd never get this situation, the best you can hope for is an SMTP-level
"Your mail probably got to some machine from which the recipient can collect
it" which never gets near the security layer.  Even though S/MIME has
provisions for signed receipts, the most they can communicate is "I got your
message", which is just a glorified form of the SMTP-level response and doesn't
help with this particular attack.
 
>>4. A typical query+response takes half a second (this means opening a
>>   connecting, generating a chosen-ciphertext message, transmitting it, having
>>   the victim decode and try to decrypt it, generating a response, wrapping up
>>   an exact indication of the decryption error it encountered, and sending it
>>   back to the attacker).
 
>The latest that I heard of was a server presented at the RSA conference that
>can do 1500 SSL connections per second.
 
Again, it's a special case for SSL.  For it to affect S/MIME or PGP you'd need
to set up an autoresponder running a custom protocol designed to facilitate the
attack (since it can't be done using any feature of standard S/MIME or PGP).
 
Peter.

Date: Thu, 8 Apr 1999 17:17:58 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Decrypting ElGamal messages
Sender: [email-masked]

Daniel Bleichenbacher, <[email-masked]>, writes:
> Can anyone tell me how an ElGamal encrypted message has to be 
> decrypted? The open-pgp documentation doesn't give the answer.
> I'm specially interested in how padding and checksums are handled.

With both RSA and ElGamal messages, the session key is prepended with a
byte identifying the symmetric algorithm used to encrypt the bulk message
data (typically one of three or four supported symmetric algorithm
values can go here).  It is then appended with a two-byte checksum.
The resulting string is PKCS-1 padded and encrypted.

Upon decryption, the recipient needs to check the PKCS-1 formatting,
the checksum, and that the symmetric algorithm byte is one of the
supported algorithms.  It then tries to decrypt the following message
block using that algorithm and session key, which block also has in
it a two-byte redundancy at the beginning to further detect bad keys.

> I'm asking this question, because ElGamal encryption has the
> same multiplicative properties as RSA. In particular, given
> the encryption of a message M (including padding), it is easy
> to generate the encryption of M*S (mod p) for a given S, without
> knowing M. Hence the same attack that was possible against SSL
> potentially works against ElGamal, when used with PKCS #1 v1.5 
> padding.

It would be good to mention this attack in a future version of the draft.
It is important not to leak information about which step in the decryption
process fails.

Then, in order to fake a successful encrypted session key, it must not
only be properly PKCS-1 padded, it must also have a correct two-byte
checksum (adding 16 bits of difficulty), it must have a legal symmetric
algorithm byte (adding about 6 bits of difficulty), and it must pass the
checksum test when the payload data is decrypted (adding another 16 bits).
This would make the attack in total about 2^38 times harder than against
a bare PKCS-1 leaking decryptor, which should be a significant barrier
in most practical situations.

> BTW, is there any reason why PKCS #1 v1.5 padding is used and
> not PKCS #1 v2?

Although the RFC came out recently, it documents existing practice which
was developed in 1996.  At that time version 1.5 of PKCS 1 was extant.

Hal Finney
NAI, Inc.

Date: Thu, 8 Apr 1999 18:26:39 -0400 (EDT)
From: Daniel Bleichenbacher <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Decrypting ElGamal messages
Sender: [email-masked]

> From: [email-masked] (Peter Gutmann)
> Date: Fri, 9 Apr 1999 09:46:07 (NZST)
>
> Daniel Bleichenbacher <[email-masked]> writes:
> 
> >I'm asking this question, because ElGamal encryption has the same 
> >multiplicative properties as RSA. In particular, given the encryption of a 
> >message M (including padding), it is easy to generate the encryption of M*S 
> >(mod p) for a given S, without knowing M. Hence the same attack that was 
> >possible against SSL potentially works against ElGamal, when used with PKCS 
> >#1 v1.5 padding.
> >
> >BTW, is there any reason why PKCS #1 v1.5 padding is used and not PKCS #1 v2?
>  
> This exact issue was debated on the ietf-smime list when I asked why X9.42 
> (which looks like the winning candidate from a 'Worst way to apply the DLP to 
> solving a key transport problem' competition... [remainder bobbitted to avoid 
> another flamewar over this :-]) was being used instead of the far more logical 
> Elgamal, which would be a direct, patent-free drop-in replacement for the 
> existing RSA key transport.  The only reason anyone could put up against 
> Elgamal was "You need to use OAEP because PKCS #1 padding is insecure".  In 
> response to this (at the end of a longish debate) I posted the following 
> back-of-the-envelope analysis:
>  
> -- Snip --
>  
> The second approach is to see just what it would take to implement this attack 
> on CMS (not S/MIME, but anything involving CMS).  For this analysis I'll make 
> several assumptions:
>  
> 1. The implementor has managed to design a protocol which will accept 
>    arbitrary numbers of chosen-ciphertext messages and reply to each one with 
>    an exact indication of how the decrypt failed, leaking information about
>    the decrypted message to an attacker.  This is a fairly remarkable feat, 
>    but let's say, just for arguments sake, that someone did do this.

I'm not sure how remarkable this would be. Quite a large number of SSL
servers actually returned the necessary error messages for an attack there.
I think one shouldn't leave the chance here that the implementor makes
mistakes and add some quidelines to the standard.

> 2. The implementor and any third-party reviewers have somehow missed the CERT 
>    advisory, RSA labs bulletin, publicity about the attack, and whatever else 
>    is around there which tells people about the problem and (very simple) fix.

They also have to know that ElGamal and RSA have similar mathematical
properties. But, again wouldn't it be better if these people were informed
via the standard?

> 3. The PKCS #1 implementation being used is correct (that is, it doesn't have 
>    the implementation bug which was found and fixed in the SSL implementations).

Sure. You need to include a message digest. But if I'm correct then 
open-pgp uses a 2 byte modular checksum. 

> 4. A typical query+response takes half a second (this means opening a 
>    connecting, generating a chosen-ciphertext message, transmitting it, having 
>    the victim decode and try to decrypt it, generating a response, wrapping up 
>    an exact indication of the decryption error it encountered, and sending it 
>    back to the attacker).

The latest that I heard of was a server presented at the RSA conference
that can do 1500 SSL connections per second.

> OK, so we have a server which does all of the above sitting there ready for 
> attack.  With a correct PKCS #1 implementation (that is, it checks the padding 
> as per the PKCS #1 spec), the complexity is approximately 1 million attempts 
> (for the 00 02 padding) x 20 (for the second 00 before the MEK) x 2 (for the 
> minimum of 8 nonzero bytes), or 40 million attempts (the 1 million attempts 
> requires the presence of the SSL implementation bug mentioned above).
>  
> This requires just under 8 months of CPU time to perform, after which you've 
> recovered a single MEK [S/MIME jargon for "message encryption key"].

The 1 million messages was an estimate for my algorithm for 1024 bit RSA
moduli. This algorithm is not optimal. 100'000 is probably reachable with
some work. Also for some strange moduli (e.g. 1025 bit) some experiments
required less than 10'000 messages. It's not hard to imagine that someone
configures a server that can be broken in much less than 1 hour.
(Please note, this is an estimate for plain PKCS #1 v 1.5 formatting.
I don't know anything about ElGamal padding yet.)
 
> I would suggest that anyone who doesn't notice that their server is under 
> continuous attack for 8 solid months has more than simple crypto problems to 
> worry about.
>  
> -- Snip --
>  
> Peter.

Intrusion detection tricks like this are certainly worth considering. But 
I'd prefer a protocol that doesn't rely on this.

Daniel 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Decrypting ElGamal messages
Reply-To: [email-masked]
Date: Fri, 9 Apr 1999 09:46:07 (NZST)
Sender: [email-masked]

Daniel Bleichenbacher <[email-masked]> writes:

>I'm asking this question, because ElGamal encryption has the same 
>multiplicative properties as RSA. In particular, given the encryption of a 
>message M (including padding), it is easy to generate the encryption of M*S 
>(mod p) for a given S, without knowing M. Hence the same attack that was 
>possible against SSL potentially works against ElGamal, when used with PKCS 
>#1 v1.5 padding.
>
>BTW, is there any reason why PKCS #1 v1.5 padding is used and not PKCS #1 v2?
 
This exact issue was debated on the ietf-smime list when I asked why X9.42 
(which looks like the winning candidate from a 'Worst way to apply the DLP to 
solving a key transport problem' competition... [remainder bobbitted to avoid 
another flamewar over this :-]) was being used instead of the far more logical 
Elgamal, which would be a direct, patent-free drop-in replacement for the 
existing RSA key transport.  The only reason anyone could put up against 
Elgamal was "You need to use OAEP because PKCS #1 padding is insecure".  In 
response to this (at the end of a longish debate) I posted the following 
back-of-the-envelope analysis:
 
-- Snip --
 
The second approach is to see just what it would take to implement this attack 
on CMS (not S/MIME, but anything involving CMS).  For this analysis I'll make 
several assumptions:
 
1. The implementor has managed to design a protocol which will accept 
   arbitrary numbers of chosen-ciphertext messages and reply to each one with 
   an exact indication of how the decrypt failed, leaking information about
   the decrypted message to an attacker.  This is a fairly remarkable feat, 
   but let's say, just for arguments sake, that someone did do this.
2. The implementor and any third-party reviewers have somehow missed the CERT 
   advisory, RSA labs bulletin, publicity about the attack, and whatever else 
   is around there which tells people about the problem and (very simple) fix.
3. The PKCS #1 implementation being used is correct (that is, it doesn't have 
   the implementation bug which was found and fixed in the SSL implementations).
4. A typical query+response takes half a second (this means opening a 
   connecting, generating a chosen-ciphertext message, transmitting it, having 
   the victim decode and try to decrypt it, generating a response, wrapping up 
   an exact indication of the decryption error it encountered, and sending it 
   back to the attacker).
 
OK, so we have a server which does all of the above sitting there ready for 
attack.  With a correct PKCS #1 implementation (that is, it checks the padding 
as per the PKCS #1 spec), the complexity is approximately 1 million attempts 
(for the 00 02 padding) x 20 (for the second 00 before the MEK) x 2 (for the 
minimum of 8 nonzero bytes), or 40 million attempts (the 1 million attempts 
requires the presence of the SSL implementation bug mentioned above).
 
This requires just under 8 months of CPU time to perform, after which you've 
recovered a single MEK [S/MIME jargon for "message encryption key"].
 
I would suggest that anyone who doesn't notice that their server is under 
continuous attack for 8 solid months has more than simple crypto problems to 
worry about.
 
-- Snip --
 
Peter.

Date: Thu, 08 Apr 1999 14:36:18 -0700
To: [email-masked], [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Sample Twofish message
Sender: [email-masked]

At 10:39 PM 4/7/99 -0700, [email-masked] wrote:

|Yes, you're right, that is inconsistent with section 5.7.  I don't
|know how we should resolve it.
|

When we were working on the RFC, the question of larger blocks came up, and
there were some suggestions of changing all the 8s to Ns, and 10s to N+2s
etc. There was the concern that we would make a mistake. We had the
advantage the first time that people (like Tom) coded to the original
description, and thus we had a check that it actually worked. So I put in
the paragraph in 12.8, as a quick way to describe how to do the right thing.

Do we agree now that the right thing to do is to start with a 16-byte IV,
encrypt 16 bytes, sync with 2 and then continue? That's what I thought we
all agreed on. If we agree that, then we don't have a problem, we have an
elided description that needs to be expanded when we revise the RFC. I
believe, though, that that's the right thing to do, work with full blocksizes.

	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)

Date: Thu, 8 Apr 1999 15:51:42 -0400 (EDT)
From: Daniel Bleichenbacher <[email-masked]>
To: [email-masked]
Subject: Decrypting ElGamal messages
Sender: [email-masked]

Can anyone tell me how an ElGamal encrypted message has to be 
decrypted? The open-pgp documentation doesn't give the answer.
I'm specially interested in how padding and checksums are handled.

I'm asking this question, because ElGamal encryption has the
same multiplicative properties as RSA. In particular, given
the encryption of a message M (including padding), it is easy
to generate the encryption of M*S (mod p) for a given S, without
knowing M. Hence the same attack that was possible against SSL
potentially works against ElGamal, when used with PKCS #1 v1.5 
padding.
BTW, is there any reason why PKCS #1 v1.5 padding is used and
not PKCS #1 v2?

-- Daniel Bleichenbacher

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Sample Twofish message
Date: 8 Apr 1999 08:54:19 GMT
Organization: IKS GmbH Jena
Lines: 6
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Werner Koch wrote:
>We should agree on an interpretation of these questions:
> * Use resyncing at all for ciphers with a blocksize > 64 ?

Use it if the processed cipher text is larger as the block size.
Do not concat ciphers of different message parts.

Date: Thu, 8 Apr 1999 07:49:57 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Sample Twofish message
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Okay, how can we resolve this conflict:

>From section 5.7:
   The data is encrypted in CFB mode, with a CFB shift size equal to the
   cipher's block size.  The Initial Vector (IV) is specified as all
   zeros.  Instead of using an IV, OpenPGP prefixes a 10-octet string to
   the data before it is encrypted.  The first eight octets are random,
   and the 9th and 10th octets are copies of the 7th and 8th octets,
   respectively. After encrypting the first 10 octets, the CFB state is
   resynchronized if the cipher block size is 8 octets or less.  The
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   last 8 octets of ciphertext are passed through the cipher and the
   block boundary is reset.

>From section 12.8:
   OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
   prefixes the plaintext with ten octets of random data, such that
   octets 9 and 10 match octets 7 and 8.  It does a CFB "resync" after
                                          ^^^^^^^^^^^^^^^^^^^^^
   encrypting those ten octets.

   Note that for an algorithm that has a larger block size than 64 bits,
   the equivalent function will be done with that entire block.  For
   example, a 16-octet block algorithm would operate on 16 octets, and
   then produce two octets of check, and then work on 16-octet blocks.

5.7 says that resync is only done for a blocksize <= 64 but 12.8 says
that is done always (the following step by step list also says this).

Please, can we agree on one version - I don't care which one, but it
is a bad idea to change this after the first message/secret-key has been
enciphered with a >64 bit blocksize cipher.  

We should agree on an interpretation of these questions:

 * Use resyncing at all for ciphers with a blocksize > 64 ?
 * Use it for encryption of secret key material in V3 packets ?
 * Use the blocksize or 64 bits for the CFB shift ?
 * Prepend 8+2 or blocksize+2 random bytes to the plaintext?
 * Keep the 8 byte salt for S2K modes?

Date: Wed, 7 Apr 1999 22:39:55 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Sample Twofish message
Sender: [email-masked]

Jon Callas, <[email-masked]>, writes:
> What about section 12.8 which says:
>
>    Note that for an algorithm that has a larger block size than 64 bits,
>    the equivalent function will be done with that entire block.  For
>    example, a 16-octet block algorithm would operate on 16 octets, and
>    then produce two octets of check, and then work on 16-octet blocks.

Yes, you're right, that is inconsistent with section 5.7.  I don't
know how we should resolve it.

Hal

Date: Wed, 07 Apr 1999 13:24:25 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Sample Twofish message
Sender: [email-masked]

What about section 12.8 which says:

   Note that for an algorithm that has a larger block size than 64 bits,
   the equivalent function will be done with that entire block.  For
   example, a 16-octet block algorithm would operate on 16 octets, and
   then produce two octets of check, and then work on 16-octet blocks.

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

Date: Tue, 6 Apr 1999 20:53:14 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
Subject: Organize Web Info...
Sender: [email-masked]

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

This message is sent in compliance of the new Email bill: SECTION 301.
Sender: INFOtrepreneur, 11012 Avenida De Los Lobos, San Diego, 
California, CA 92127 - Fax: (619) 672-1000 Email: [email-masked]
Per Section 301, Paragraph (a)(2)(C) of S.1618, further transmissions to you 
by the sender of this email may be stopped at no cost to you by ending a reply 
to this email address with the word "remove" in the subject line.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

NO MORE!  BACKTRACKING OF LOST AND CONFUSING 
WEB BOOKMARKS AND TEXT DATA FILES...

Based upon your Internet interests, I thought that you would be 
interesed in Web Info Catcher which allows you to capture and store 
text data from various sources, index, categorize and edit it instantly on 
screen while online.

Access all your reference and source material instantly at a click of a button,
while you are working, browsing, searching or offline. 

It's the fastest, up-to-date, and most efficient means to "RECALL" your data.
 
  * No need... to bookmark a multitude of web sites 
  * No need... to search for misplaced or lost text files 
  * No need... to print out endless reports 
  * No need... for a web browser to reference data

- Perfect for academics, researchers, business, info junkies, etc. 
- Create your own projects, reports, topics, favorites, research, etc. 
- Open numerous projects and setup your own index references 
- Attach and Capture text information from various sources 
- Edit your projects 
- Effectively organize your information 
- Categorize your information 
- Add custom indexes 
- Automatic alpha indexing 
- Searchable index 
- Scrollable index
- View information on screen while working 
- A Stand alone program 
- Add and delete information 
- Print out data in your own time

WHY BOOKMARK OR SAVE YOUR TEXT FILES?

DON'T DELAY!  Visit INFOtrepreneur today and discover a whole new way to 
capture and store your information sources, we will be happy to assist you.

DOWNLOAD your software demo: ftp://ftp.infotrepreneur.com/pub/wicdemo.exe

OR for more info: http://www.infotrepreneur.com/webcth.htm 

Sincerely
Gail van der Merwe

Date: Tue, 6 Apr 1999 19:47:10 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Sample Twofish message
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> The relevant paragraph from section 5.7 is:
[...] 
>    resynchronized if the cipher block size is 8 octets or less.  The
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ooops, I really missed that.  I only remembered from the discussion,
that we keep the special CFB mode.  

Many thanks - I hope I can decipher your mail in a few days.

  Werner

Date: Mon, 5 Apr 1999 13:44:40 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Sample Twofish message
Sender: [email-masked]

Werner Koch, <[email-masked]>, writes:
>
> [email-masked] writes:
>
> > Note also that the special CFB "sync" operation (after processing these 10
> > bytes) is not to be done with block ciphers whose block size is greater
> > than 8 bytes, hence is not done for Twofish.
>
> Hmmm, section 5.7 states that encryption is done in PGP's special CFB
> mode and there is no exception mentioned.  
>
> If I remember correct, we discussed this 128 bit block cipher issue
> last year and changed the draft accordingly. 

The relevant paragraph from section 5.7 is:

   The data is encrypted in CFB mode, with a CFB shift size equal to the
   cipher's block size.  The Initial Vector (IV) is specified as all
   zeros.  Instead of using an IV, OpenPGP prefixes a 10-octet string to
   the data before it is encrypted.  The first eight octets are random,
   and the 9th and 10th octets are copies of the 7th and 8th octets,
   respectively. After encrypting the first 10 octets, the CFB state is
   resynchronized if the cipher block size is 8 octets or less.  The
   last 8 octets of ciphertext are passed through the cipher and the
   block boundary is reset.

It only resynchronizes the CFB state if the cipher block size is 8
octets or less.  Twofish has a block size of 16 octets, hence the CFB
state does not get resynchronized.

Hal

Date: Mon, 5 Apr 1999 21:56:58 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Sample Twofish message
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[email-masked] writes:

> Note also that the special CFB "sync" operation (after processing these 10
> bytes) is not to be done with block ciphers whose block size is greater
> than 8 bytes, hence is not done for Twofish.

Hmmm, section 5.7 states that encryption is done in PGP's special CFB
mode and there is no exception mentioned.  

If I remember correct, we discussed this 128 bit block cipher issue
last year and changed the draft accordingly.