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