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