ietf-openpgp
[Top] [All Lists]

Re: Phil Zimmermann's suggestion - Implementation?

1999-04-13 15:51:26
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".


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.
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             uri(_at_)watson(_dot_)ibm(_dot_)com
-=-=-=-=-=-=-
<Disclaimer>