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.
If you want an MDC, and there is already a place for MDCs, then it should
go there if the format can be adapted.
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.